Re: D seems interesting, but...

[1100110]

On Tue, 16 Oct 2012 01:47:16 -0500, Jacob Carlborg  wrote:


On 2012-10-16 01:54, 1100110 wrote:


Doesn't work on Arch 64bit either.  I tried to fix it at one point and
gave it up...


Please report the issue so it's not forgotten. You don't need to have  
fix or a pull request, just information how I should reproduce it.


https://bitbucket.org/doob/dvm


OK. Install dvm using directions on bitbucket.

dvm install -l
(no output)
dvm list
No installed D compilers

Thats it.  No errors, I'll make a issue in a bit.

--
Using Opera's revolutionary email client: http://www.opera.com/mail/

Re: D interface for C library problems

[1100110]

On Tue, 16 Oct 2012 01:42:07 -0500, Jacob Carlborg  wrote:


On 2012-10-16 01:33, 1100110 wrote:


Also the names of the particular fields do not have to match exactly.
In a few C projects, you will find a field with the name 'version' which
is a D keyword.

It seems to work just fine if you simply change it to 'ver' on similar.

Take a look at the deimos project to see a few examples in action.
(Also please attempt to get it into deimos if that is what you are
thinking about.)


For structs the size only need to be the same. Depending on how you  
operate on the struct the size of the individual fields, alignment and  
padding should match as well.




That's what I suspected, but It's nice to know that for a fact.
Thank you.
--
Using Opera's revolutionary email client: http://www.opera.com/mail/

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

[Mehrdad]

On Tuesday, 16 October 2012 at 06:03:56 UTC, Jonathan M Davis 
wrote:
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.

- Jonathan M Davis


+1

Re: D seems interesting, but...

[Jacob Carlborg]

On 2012-10-16 09:04, 1100110 wrote:


OK. Install dvm using directions on bitbucket.

dvm install -l
(no output)
dvm list
No installed D compilers

Thats it.  No errors, I'll make a issue in a bit.


The -l flag seems to be horrible broken. Can you try "dvm install 2.060".

--
/Jacob Carlborg

Re: alias A = B; syntax

[Rob T]

On Tuesday, 16 October 2012 at 05:27:53 UTC, Jonathan M Davis 
wrote:
I'm unaware of any real difference between the two other than 
those I already
mentioned. They're pretty much the same thing, so I don't know 
why you're

saying that they're different.


Different, as in the ways you've mentioned :)

In response to the OP, I initially felt the same way, but it can 
be argued that the current syntax is more applicable to the type 
declaration syntax.


If we compare the proposed alternate syntax with current, which 
is better?


alias int Int;
Int x = 0;

vs

alias Int = int;
Int x = 0;

When I compare the two in this way, I'm inclined to keep things 
as they are.


--rt

Re: 48 hour game jam

[Manu]

On 15 October 2012 16:18, Martin Drasar  wrote:

> On 15.10.2012 13:52, Manu wrote:
> > We did a 48hr game jam at work this past weekend.
> > We decided to do our entry in D, to further prove that D was a viable
> > and productive solution for real-world game dev.
> >
> > Here's our entry, for those interested.
> > It has only been built/tested in Windows using VS2010, but it should
> > theoretically work on Linux and consoles as well (but the build scripts
> > aren't setup to do it automatically).
> > If there is interest, I will create the build scripts, and test on Linux.
> >
> > https://github.com/RemedyGameJam/stache/wiki
> >
>
> Matt Damon on top of Mt. Fiji and four badass fighters... Sign me in!
> But how do you control that thing? The only thing that did something was
> Alt-F4.
>
> I haven't built it myself, just downloaded the zip from github and
> dx11_43.dll from somewhere.
>

Uploaded a new build with keyboard controls (prev only gamepad supported),
and also bundled the DLL's, which some people didn't seem to have on their
system...

Re: Import improvement

[Sönke Ludwig]

Am 10/16/2012 2:10 AM, schrieb Peter Alexander:
> On Monday, 15 October 2012 at 23:43:53 UTC, 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.
> 
> It's cute, but I think it is terribly misleading. I wouldn't recommend
> that to anyone.

I agree, in vibe.d it's just a little pun on the name, but in general it
could of course be mistaken as a file name.

I've used pack.pack instead of pack.all or pack._ in the past, but
somehow all of them are kind of ugly without being able to just say
'pack', as in the DIP.

Re: Import improvement

[Sönke Ludwig]

> 
> 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?

Strong words aside, let me tell you that the "vibe.d" import is just a
small convenience for quick projects, so that you don't have to write
yuor own main() function - something that in general appeals to quite a
few people when using web frameworks in dynamic languages.

In this context it was just a funny idea to name it like this (named
after the project, not to make it look like a file, of course) and make
it a kind of unique trait. However, this is by no means a pattern. The
module that imports everything is "vibe.vibe".

Re: 48 hour game jam

[Danni Coy]

Nice work -- I can use this as a reference to get started with D and Fuji
right?


On Tue, Oct 16, 2012 at 6:03 PM, Manu  wrote:

> On 15 October 2012 16:18, Martin Drasar  wrote:
>
>> On 15.10.2012 13:52, Manu wrote:
>> > We did a 48hr game jam at work this past weekend.
>> > We decided to do our entry in D, to further prove that D was a viable
>> > and productive solution for real-world game dev.
>> >
>> > Here's our entry, for those interested.
>> > It has only been built/tested in Windows using VS2010, but it should
>> > theoretically work on Linux and consoles as well (but the build scripts
>> > aren't setup to do it automatically).
>> > If there is interest, I will create the build scripts, and test on
>> Linux.
>> >
>> > https://github.com/RemedyGameJam/stache/wiki
>> >
>>
>> Matt Damon on top of Mt. Fiji and four badass fighters... Sign me in!
>> But how do you control that thing? The only thing that did something was
>> Alt-F4.
>>
>> I haven't built it myself, just downloaded the zip from github and
>> dx11_43.dll from somewhere.
>>
>
> Uploaded a new build with keyboard controls (prev only gamepad supported),
> and also bundled the DLL's, which some people didn't seem to have on their
> system...
>

Re: Account on ARM/Debian

[Alix Pexton]

On 16/10/2012 02:06, Walter Bright wrote:

On 10/15/2012 5:39 PM, Brad Roberts wrote:

I wouldn't go out and buy one just for this.  The raspberry's are pretty
underpowered anyway.


They're so cheap, it's no big deal even if they're a total loss.



I have a RasPi already!

I might be able to get it connected up to my brother's static ip and 
have it sitting headless on top of the router, but I'll have to ask him 
first of course!


I'll let you know what he says, and start asking questions about how to 
set it up if he agrees ^^


A...

Re: alias A = B; syntax

[Don Clugston]

On 16/10/12 05:18, Nick Sabalausky wrote:

On Tue, 16 Oct 2012 05:00:56 +0200
"stas"  wrote:


For me syntax alias int Int; seems unnatural.
I'd love to write
alias Int = int;
alias fptr = void(int)*;

This looks much more readable for me and harmonized with
int x = 0;
template T(alias A = Object) {...}

Does anybody share this opinion?
Any chance this syntax goes into D someday?


I'm pretty sure it was already decided that this would be added, but
just hasn't made it in yet. I've been fairly eager for it. I find the
current syntax too inconsistent and confusing.



That's my recollection too. I find that even after using it for years, I 
still have to pause and think for a moment whenever I see an alias:


alias Foo Bar;
// is this declaring Foo as an alias of Bar? Or Bar as an alias of Foo?
And if I see:
alias Foo int;
it doesn't instantly stand out to me as the wrong way round. There's a 
delay of 1-2 seconds.


Somehow this is something that my brain refuses to see as natural, no 
matter how many times it sees it. Whereas:


alias Bar = Foo;

is instantly clear, even though I've almost never seen it.

Re: Account on ARM/Debian

[Alix Pexton]

On 16/10/2012 10:22, Alix Pexton wrote:

On 16/10/2012 02:06, Walter Bright wrote:

On 10/15/2012 5:39 PM, Brad Roberts wrote:

I wouldn't go out and buy one just for this.  The raspberry's are pretty
underpowered anyway.


They're so cheap, it's no big deal even if they're a total loss.



I have a RasPi already!

I might be able to get it connected up to my brother's static ip and
have it sitting headless on top of the router, but I'll have to ask him
first of course!

I'll let you know what he says, and start asking questions about how to
set it up if he agrees ^^

A...


He says OK!

Is just SSH enough for you to work with or do you need any other ports open?

The regular port numbers for some things are not available though (80, 
443, 20, 21) but I'm sure that won't be a problem ^^


A...

Re: D seems interesting, but...

[David Nadlinger]

On Monday, 15 October 2012 at 23:54:54 UTC, 1100110 wrote:
From what I've seen, LDC and GDC both rename their versions of 
phobos so that they won't interfere.


This is correct.

David

Re: 48 hour game jam

[Jacob Carlborg]

On 2012-10-15 13:52, Manu wrote:

We did a 48hr game jam at work this past weekend.
We decided to do our entry in D, to further prove that D was a viable
and productive solution for real-world game dev.

Here's our entry, for those interested.
It has only been built/tested in Windows using VS2010, but it should
theoretically work on Linux and consoles as well (but the build scripts
aren't setup to do it automatically).
If there is interest, I will create the build scripts, and test on Linux.

https://github.com/RemedyGameJam/stache/wiki


When using git submodules the recommended way of cloning is to use "git 
clone --recursive".


--
/Jacob Carlborg

Re: More D & Rust

[Kagamin]

Well, it's true non-null types can be statically checked. But if 
you try to code without nulls, what is the chance to run into 
null pointer?

Re: Account on ARM/Debian

[Iain Buclaw]

On 16 October 2012 10:42, Alix Pexton  wrote:
> On 16/10/2012 10:22, Alix Pexton wrote:
>>
>> On 16/10/2012 02:06, Walter Bright wrote:
>>>
>>> On 10/15/2012 5:39 PM, Brad Roberts wrote:

 I wouldn't go out and buy one just for this.  The raspberry's are pretty
 underpowered anyway.
>>>
>>>
>>> They're so cheap, it's no big deal even if they're a total loss.
>>>
>>
>> I have a RasPi already!
>>
>> I might be able to get it connected up to my brother's static ip and
>> have it sitting headless on top of the router, but I'll have to ask him
>> first of course!
>>
>> I'll let you know what he says, and start asking questions about how to
>> set it up if he agrees ^^
>>
>> A...
>
>
> He says OK!
>
> Is just SSH enough for you to work with or do you need any other ports open?
>
> The regular port numbers for some things are not available though (80, 443,
> 20, 21) but I'm sure that won't be a problem ^^
>
> A...

SSH will be fine, thanks. :-)

Do you need a static IP set on the firewall to allow connections in?


-- 
Iain Buclaw

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

Re: Account on ARM/Debian

[Alix Pexton]

On 16/10/2012 11:48, Iain Buclaw wrote:

On 16 October 2012 10:42, Alix Pexton  wrote:

On 16/10/2012 10:22, Alix Pexton wrote:


On 16/10/2012 02:06, Walter Bright wrote:


On 10/15/2012 5:39 PM, Brad Roberts wrote:


I wouldn't go out and buy one just for this.  The raspberry's are pretty
underpowered anyway.



They're so cheap, it's no big deal even if they're a total loss.



I have a RasPi already!

I might be able to get it connected up to my brother's static ip and
have it sitting headless on top of the router, but I'll have to ask him
first of course!

I'll let you know what he says, and start asking questions about how to
set it up if he agrees ^^

A...



He says OK!

Is just SSH enough for you to work with or do you need any other ports open?

The regular port numbers for some things are not available though (80, 443,
20, 21) but I'm sure that won't be a problem ^^

A...


SSH will be fine, thanks. :-)

Do you need a static IP set on the firewall to allow connections in?




I don't think so, will have to throw that one over to my brother to be 
sure ^^


My network-admin-fu is somewhat lacking ><

A...

Re: D seems interesting, but...

[Kagamin]

On Monday, 15 October 2012 at 20:19:22 UTC, Gerry Weaver wrote:
When running dmd, none of the read (and friends) syscalls 
happen as far as the kernel is concerned. This would lend some 
credibility to the lib theory. However, it's quite odd that 
results are the same for each time dmd is executed. I would 
expect a random result or even a segfault/abort on different 
runs.


Shouldn't the application be terminated when a library fails to 
load?

Re: alias A = B; syntax

[stas]

On Tuesday, 16 October 2012 at 09:32:49 UTC, Don Clugston wrote:


Somehow this is something that my brain refuses to see as 
natural, no matter how many times it sees it.


Exactly.

In C inconsistency was even more vivid:
sometimes I saw
#define BOOL int
and other times
typedef int Bool;  // what a heck?

Re: alias A = B; syntax

[martin]

On Tuesday, 16 October 2012 at 09:32:49 UTC, Don Clugston wrote:
Somehow this is something that my brain refuses to see as 
natural, no matter how many times it sees it. Whereas:


alias Bar = Foo;

is instantly clear, even though I've almost never seen it.


+1 to that. :)

Re: 48 hour game jam

[Manu]

On 16 October 2012 12:18, Danni Coy  wrote:

> Nice work -- I can use this as a reference to get started with D and Fuji
> right?
>
>
> On Tue, Oct 16, 2012 at 6:03 PM, Manu  wrote:
>
>> On 15 October 2012 16:18, Martin Drasar  wrote:
>>
>>> On 15.10.2012 13:52, Manu wrote:
>>> > We did a 48hr game jam at work this past weekend.
>>> > We decided to do our entry in D, to further prove that D was a viable
>>> > and productive solution for real-world game dev.
>>> >
>>> > Here's our entry, for those interested.
>>> > It has only been built/tested in Windows using VS2010, but it should
>>> > theoretically work on Linux and consoles as well (but the build scripts
>>> > aren't setup to do it automatically).
>>> > If there is interest, I will create the build scripts, and test on
>>> Linux.
>>> >
>>> > https://github.com/RemedyGameJam/stache/wiki
>>> >
>>>
>>> Matt Damon on top of Mt. Fiji and four badass fighters... Sign me in!
>>> But how do you control that thing? The only thing that did something was
>>> Alt-F4.
>>>
>>> I haven't built it myself, just downloaded the zip from github and
>>> dx11_43.dll from somewhere.
>>>
>>
>> Uploaded a new build with keyboard controls (prev only gamepad
>> supported), and also bundled the DLL's, which some people didn't seem to
>> have on their system...
>>
>
Sure. I also backported the fixes into Fuji, and polished up the D bindings
last night to work on Linux.
Was gonna put a Linux build script in there, since most people here are
linux users.

Re: 48 hour game jam

[Manu]

On 16 October 2012 12:50, Jacob Carlborg  wrote:

> On 2012-10-15 13:52, Manu wrote:
>
>> We did a 48hr game jam at work this past weekend.
>> We decided to do our entry in D, to further prove that D was a viable
>> and productive solution for real-world game dev.
>>
>> Here's our entry, for those interested.
>> It has only been built/tested in Windows using VS2010, but it should
>> theoretically work on Linux and consoles as well (but the build scripts
>> aren't setup to do it automatically).
>> If there is interest, I will create the build scripts, and test on Linux.
>>
>> https://github.com/**RemedyGameJam/stache/wiki
>>
>
> When using git submodules the recommended way of cloning is to use "git
> clone --recursive".


Ah, well. Allegedly I'm still rather a git noob. I'll update that, although
the following steps still stand.
I didn't have any luck making the subrepos default to a particular branch.
(It worked once, but I couldn't see why, and then it stopped working)

Re: More D & Rust

[bearophile]

Kagamin:

Well, it's true non-null types can be statically checked. But 
if you try to code without nulls, what is the chance to run 
into null pointer?


I presume then the probability becomes lower (but I don't have 
statistics to support this opinion.)


Bye,
bearophile

Re: Import improvement

[Manu]

On 16 October 2012 11:22, Sönke Ludwig  wrote:

> >
> > 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?
>
> Strong words aside, let me tell you that the "vibe.d" import is just a
> small convenience for quick projects, so that you don't have to write
> yuor own main() function - something that in general appeals to quite a
> few people when using web frameworks in dynamic languages.
>
> In this context it was just a funny idea to name it like this (named
> after the project, not to make it look like a file, of course) and make
> it a kind of unique trait. However, this is by no means a pattern. The
> module that imports everything is "vibe.vibe".
>

What's wrong with the reasonably established '_' module though? Trying to
make it appear like a source filename is a deception. That may confuse the
programmer.
That said, I didn't realise the project incorporated '.d' in the project
name. I was under the impression it was being carried to other projects too
that may not share the same naming pun.

Re: Account on ARM/Debian

[Regan Heath]

On Mon, 15 Oct 2012 20:31:58 +0100, Walter Bright  
 wrote:



On 10/15/2012 10:05 AM, 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?


It would be pretty cool to run this on a Raspberry Pi! Anyone up to the  
challenge to build such a system?


My Pi arrives on the 22nd and I'd like to give this a go.

Is it just me, or does the Raspberry Pi represent an opportunity for D to  
capture a new generation of new users/programmers.  I would think that  
making D compile for ARM would be a fairly high priority in that case?


I was also thinking, wouldn't it be neat to write an operating system for  
the Pi in in D..  man I wish there were more hours in a day!


R

--
Using Opera's revolutionary email client: http://www.opera.com/mail/

Re: alias A = B; syntax

[Timon Gehr]

On 10/16/2012 06:01 AM, Andrej Mitrovic wrote:

On 10/16/12, Nick Sabalausky  wrote:

I'm pretty sure it was already decided that this would be added, but
just hasn't made it in yet. I've been fairly eager for it. I find the
current syntax too inconsistent and confusing.


Yep.

Paging Dr. Kenji!



This can be implemented in the parser, so it is quite simple.

Re: Import improvement

[Sönke Ludwig]

Am 10/16/2012 1:53 PM, schrieb Manu:
> 
> What's wrong with the reasonably established '_' module though? Trying
> to make it appear like a source filename is a deception. That may
> confuse the programmer.
> (...)

Again, it has *not* the same meaning as a _.d module. It's just a
single, very special, module. I totally agree with the possible
confusion in general.

But speaking of '_' (and I have to admit that I didn't look at that many
projects) - I've never seen that in the wild. And (IMO) "import
something._" also looks quite awkward and non-self-explanatory, much
more than either "something.all", "something.*" or
"something.something". Making it just into "import somthing;" with some
compiler support would of course change the game.

Leaving all that aside, in larger projects I always just import single
modules and rarely use public imports, only when there are compelling
reasons. So I would definitely welcome something along the lines of what
you proposed.

Re: 48 hour game jam

[Jacob Carlborg]

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


Sure. I also backported the fixes into Fuji, and polished up the D
bindings last night to work on Linux.
Was gonna put a Linux build script in there, since most people here are
linux users.


We want a script for Mac OS X as well :)
I replaced "dist/bin/premake4" with a Mac OS X binary and I tried 
running "stache/Fuji/create_project.sh". this is the output I got:


...

 Building Fuji (release) 
Creating ../Build/Release/Fuji
glew.c
DebugMenu.cpp
In file included from ../../dist/include/Fuji/Fuji.h:356,
 from ../Source/DebugMenu.cpp:1:
../../dist/include/Fuji/MFTypes.h:69: error: ‘ssize_t’ does not name a type
In file included from ../../dist/include/Fuji/Fuji.h:390,
 from ../Source/DebugMenu.cpp:1:
../../dist/include/Fuji/Util.h: In function ‘void MFFixUp(T*&, void*, int)’:
../../dist/include/Fuji/Util.h:54: error: ‘intp’ was not declared in 
this scope

../../dist/include/Fuji/Util.h:54: error: expected `;' before ‘offset’
../../dist/include/Fuji/Util.h:57: error: ‘offset’ was not declared in 
this scope
../../dist/include/Fuji/Util.h:59: error: ‘offset’ was not declared in 
this scope

make[1]: *** [../Build/Release/Fuji/DebugMenu.o] Error 1
make: *** [Fuji] Error 2


--
/Jacob Carlborg

Re: Import improvement

[Jacob Carlborg]

On 2012-10-16 14:36, Sönke Ludwig wrote:


But speaking of '_' (and I have to admit that I didn't look at that many
projects) - I've never seen that in the wild. And (IMO) "import
something._" also looks quite awkward and non-self-explanatory, much
more than either "something.all", "something.*" or
"something.something". Making it just into "import somthing;" with some
compiler support would of course change the game.


"import something;", how would you know if it's a module or a package? I 
really would like to be able to use "import something.*" but the 
compiler doesn't support it, so .all/._ is the best we can do for now.


--
/Jacob Carlborg

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

[H. S. Teoh]

On Mon, Oct 15, 2012 at 10:59:26PM -0700, 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.
[...]

But nothing about the definition of a range, as currently defined in
std.range, guarantees that whatever value was returned by .front is
still valid after popFront() is called.

I'm not saying that this should be the "correct" behaviour, but the
current definition does not prohibit a range from, say, reusing an array
to compute its next element. For example, one may have a range that
returns the permutations of a given array, in which popFront() permutes
the elements in-place. In this case, .front will become invalid once
popFront() is called. Many of the current range-based functions will not
work correctly in this case.

Of course, it's arguable whether such ranges should be admissible, but
as far as the current definition goes, I don't see anything that states
otherwise. If we don't make such things clear, then we're bound to run
into pathological cases where bugs will creep in because of unstated
assumptions in the code.


T

-- 
Fact is stranger than fiction.

Re: 48 hour game jam

[Manu]

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

> On 2012-10-16 13:40, Manu wrote:
>
>  Sure. I also backported the fixes into Fuji, and polished up the D
>> bindings last night to work on Linux.
>> Was gonna put a Linux build script in there, since most people here are
>> linux users.
>>
>
> We want a script for Mac OS X as well :)
> I replaced "dist/bin/premake4" with a Mac OS X binary and I tried running
> "stache/Fuji/create_project.**sh". this is the output I got:
>
> ...
>
>  Building Fuji (release) 
> Creating ../Build/Release/Fuji
> glew.c
> DebugMenu.cpp
> In file included from ../../dist/include/Fuji/Fuji.**h:356,
>  from ../Source/DebugMenu.cpp:1:
> ../../dist/include/Fuji/**MFTypes.h:69: error: ‘ssize_t’ does not name a
> type
> In file included from ../../dist/include/Fuji/Fuji.**h:390,
>  from ../Source/DebugMenu.cpp:1:
> ../../dist/include/Fuji/Util.**h: In function ‘void MFFixUp(T*&, void*,
> int)’:
> ../../dist/include/Fuji/Util.**h:54: error: ‘intp’ was not declared in
> this scope
> ../../dist/include/Fuji/Util.**h:54: error: expected `;' before ‘offset’
> ../../dist/include/Fuji/Util.**h:57: error: ‘offset’ was not declared in
> this scope
> ../../dist/include/Fuji/Util.**h:59: error: ‘offset’ was not declared in
> this scope
> make[1]: *** [../Build/Release/Fuji/**DebugMenu.o] Error 1
> make: *** [Fuji] Error 2


Well I've not tested mac, but I'll make the Linux build work tonight, and
from that, you should be able to adapt it easily.
Does OSX have X11 libs?
If there is no X11 libs for OSX, then you will need to knock up an
MFDisplay_OSX.cpp for cocoa, which should be trivial (just create a window,
then call into MFRenderer_OpenGL.cpp init, as the windows/X11 ones do).
Infact, I'd really like to have a proper cocoa version anyway... ;)

You might also have problems with sound and input in osx, if they aren't
using the same libraries as linux. Writing the backend drivers for new
platforms is very easy, I've just never wanted to run on a mac.
I don't suppose you might like to help me out making proper support for
OSX? I'll be home on a couple of hours if we could take it offline then.
There's probably 2-3 drivers that need to be written, and some tweaks to
the typical C++ platform disambiguation nonsense at the top of Fuji.h.

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

[H. S. Teoh]

In the course of digging deeper into why the new Cartesian product
implementation is triggering buggy behaviour, I found this:

import std.algorithm;
import std.range;
import std.stdio;

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 r = zip(sequence!"n"(cast(size_t)0), A.save, B.save)
.map!((a) => chain(
zip(repeat(a[1]), B.save.take(a[0])),
zip(A.save.take(a[0]+1), repeat(a[2]))
))
.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;
}

void main() {
// Two ranges to test with
auto A = sequence!"100+2*n"(cast(size_t)0);
auto B = sequence!"200+2*n+1"(cast(size_t)0);

// This code is exactly the same as the code in cprod().
auto r = zip(sequence!"n"(cast(size_t)0), A.save, B.save)
.map!((a) => chain(
zip(repeat(a[1]), B.save.take(a[0])),
zip(A.save.take(a[0]+1), repeat(a[2]))
))
.joiner;

// This works correctly
writeln(r.map!"[a[0],a[1]]".take(20));

writeln("");

// But this is garbled. Why?
writeln(cprod(A,B).map!"[a[0],a[1]]".take(20));
}

FWIW, here is the output from my machine:

[[100, 201], [102, 201], [100, 203], [102, 203], [104, 201], [104, 203], [100, 
205], [102, 205], [104, 205], [106, 201], [106, 203], [106, 205], [100, 207], 
[102, 207], [104, 207], [106, 207], [108, 201], [108, 203], [108, 205], [108, 
207]]

[[100, 201], [102, 201], [20, 203], [104, 203], [104, 201], [104, 205], [20, 
205], [104, 205], [106, 205], [106, 201], [106, 205], [106, 207], [20, 207], 
[104, 207], [106, 207], [108, 207], [108, 201], [108, 205], [108, 207], [108, 
209]]


Notice in the second output range, that the third element is [20, 203]
instead of [100, 203], and thereafter a bunch of elements are skipped,
and things just start going haywire after that.

The only difference between the two is that the first is computed within
main(), and the second is returned from a function call. Does this mean
that it's unsafe to return composed ranges from functions? I'm trying to
think what might be going wrong. Could it be that the composed ranges
are stack-allocated temporaries that go out of scope upon returning from
the function, so the returned range is actually accessing invalid
memory? (That is a really scary thought.)


T

-- 
Bare foot: (n.) A device for locating thumb tacks on the floor.

make install; where do .di files go?

[Manu]

I'm trying to make an installer.
Easy for C, headers go in /usr/[local/]include.
Where do D's imports go? I can't find a place that DMD and GDC agree on...
surely there should be one standard location so packages can write
installers?

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

[Iain Buclaw]

On 16 October 2012 14:41, Manu  wrote:
> I'm trying to make an installer.
> Easy for C, headers go in /usr/[local/]include.
> Where do D's imports go? I can't find a place that DMD and GDC agree on...
> surely there should be one standard location so packages can write
> installers?

/usr/[local/]include/d is the standard path.  Each compiler tends to
have it's own subfolder here anyway...

Hmm... for GDC you can set $DPATH environment variable and it will
adhere to it (add directories to list of include paths).


-- 
Iain Buclaw

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

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

[Manu]

so are subfolders in include/d normal? it should I just install my package
in include/d directly?

On 16 October 2012 17:01, Iain Buclaw  wrote:

> On 16 October 2012 14:41, Manu  wrote:
> > I'm trying to make an installer.
> > Easy for C, headers go in /usr/[local/]include.
> > Where do D's imports go? I can't find a place that DMD and GDC agree
> on...
> > surely there should be one standard location so packages can write
> > installers?
>
> /usr/[local/]include/d is the standard path.  Each compiler tends to
> have it's own subfolder here anyway...
>
> Hmm... for GDC you can set $DPATH environment variable and it will
> adhere to it (add directories to list of include paths).
>
>
> --
> Iain Buclaw
>
> *(p < e ? p++ : p) = (c & 0x0f) + '0';
>

Re: Account on ARM/Debian

[Iain Buclaw]

On 16 October 2012 13:00, Regan Heath  wrote:
> On Mon, 15 Oct 2012 20:31:58 +0100, Walter Bright
>  wrote:
>
>> On 10/15/2012 10:05 AM, 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?
>>
>>
>> It would be pretty cool to run this on a Raspberry Pi! Anyone up to the
>> challenge to build such a system?
>
>
> My Pi arrives on the 22nd and I'd like to give this a go.
>
> Is it just me, or does the Raspberry Pi represent an opportunity for D to
> capture a new generation of new users/programmers.  I would think that
> making D compile for ARM would be a fairly high priority in that case?
>
> I was also thinking, wouldn't it be neat to write an operating system for
> the Pi in in D..  man I wish there were more hours in a day!
>

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.

-- 
Iain Buclaw

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

Re: Import improvement

[Sönke Ludwig]

Am 10/16/2012 3:11 PM, schrieb Jacob Carlborg:
> On 2012-10-16 14:36, Sönke Ludwig wrote:
> 
>> But speaking of '_' (and I have to admit that I didn't look at that many
>> projects) - I've never seen that in the wild. And (IMO) "import
>> something._" also looks quite awkward and non-self-explanatory, much
>> more than either "something.all", "something.*" or
>> "something.something". Making it just into "import somthing;" with some
>> compiler support would of course change the game.
> 
> "import something;", how would you know if it's a module or a package? I
> really would like to be able to use "import something.*" but the
> compiler doesn't support it, so .all/._ is the best we can do for now.
> 

The compiler has to walk the directory structure anyway. If it stops at
a directory, it looks for _.d/package.d/... and uses that.

http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP16

It would definitely be good to have a decistion if the compiler will
support it at some point to not start naming all those modules all.d
only to dicover later that the compiler wants to have _.d.

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

[bearophile]

Jonathan M Davis:

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 like byLine() to be a range, so it's compatible with 
std.algorithm stuff. But a short time after the creation of 
byLine() I suggested to make it copy (dup) lines on default and 
not copy them on request, this means:


auto lineBuff = "foo.txt".File().byLine().array();
==> good result


auto lineBuff = "foo.txt".File().byLine!false().array();
==> doesn't copy, garbage result.

I design my ranges like that. It's safe because on default (or if 
you don't know what you are doing) it copies, and it's a bit 
slower. When you know what you are doing and you want more speed, 
you disable the copy with a compile-time argument.


Bye,
bearophile

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

[bearophile]

H. S. Teoh:


If we don't make such things clear, then we're bound to run
into pathological cases where bugs will creep in because of 
unstated assumptions in the code.


A good language/std library has to protect the ignorant, where 
possible. And this is a place where it's easy to do this.


Bye,
bearophile

Re: alias A = B; syntax

[Tommi]

On Tuesday, 16 October 2012 at 03:00:57 UTC, stas wrote:

For me syntax alias int Int; seems unnatural.
I'd love to write
alias Int = int;
alias fptr = void(int)*;


You can cast your vote for the new syntax over there:
http://d.puremagic.com/issues/show_bug.cgi?id=3011


By the way, in C++11 you can now also say:

using MyRealType = double;

...instead of:

typedef double MyRealType;

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

[Joseph Rushton Wakeling]

On Tuesday, 16 October 2012 at 14:23:28 UTC, bearophile wrote:
I design my ranges like that. It's safe because on default (or 
if you don't know what you are doing) it copies, and it's a bit 
slower. When you know what you are doing and you want more 
speed, you disable the copy with a compile-time argument.


Have to say that in my (admittedly not so extensive) experience 
of byLine, it's slow enough anyway that I can't imagine the extra 
performance hit you describe would be that onerous.  Certainly 
worth it for making it "safe" as a range.

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

[Tommi]

On Tuesday, 16 October 2012 at 05:49:11 UTC, 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.


Isn't the deeper underlying problem here the fact that there's no 
generic way to make a deep copy in this language (does any 
language?) Making a deep copy of front would be a clean solution. 
I don't know how to implement this generic deep copying 
functionality though. For example: what would be the semantics of 
deep-copying a range?

Re: 48 hour game jam

[Jacob Carlborg]

On 2012-10-16 15:29, Manu wrote:


Well I've not tested mac, but I'll make the Linux build work tonight,
and from that, you should be able to adapt it easily.
Does OSX have X11 libs?


Yes, Mac OS X has X11.


If there is no X11 libs for OSX, then you will need to knock up an
MFDisplay_OSX.cpp for cocoa, which should be trivial (just create a
window, then call into MFRenderer_OpenGL.cpp init, as the windows/X11
ones do).
Infact, I'd really like to have a proper cocoa version anyway... ;)


Yeah, a proper Cocoa version is always nice.


You might also have problems with sound and input in osx, if they aren't
using the same libraries as linux. Writing the backend drivers for new
platforms is very easy, I've just never wanted to run on a mac.
I don't suppose you might like to help me out making proper support for
OSX? I'll be home on a couple of hours if we could take it offline then.
There's probably 2-3 drivers that need to be written, and some tweaks to
the typical C++ platform disambiguation nonsense at the top of Fuji.h.


It depends on how much work it is, but I can have a look.

--
/Jacob Carlborg

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

[Jacob Carlborg]

On 2012-10-16 16:01, Iain Buclaw wrote:


/usr/[local/]include/d is the standard path.  Each compiler tends to
have it's own subfolder here anyway...


DMD doesn't look anywhere outside of its folder by default.

--
/Jacob Carlborg

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

[H. S. Teoh]

On Tue, Oct 16, 2012 at 05:01:57PM +0200, Tommi wrote:
> On Tuesday, 16 October 2012 at 05:49:11 UTC, 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.
> 
> Isn't the deeper underlying problem here the fact that there's no
> generic way to make a deep copy in this language (does any language?)
> Making a deep copy of front would be a clean solution. I don't know
> how to implement this generic deep copying functionality though. For
> example: what would be the semantics of deep-copying a range?

I don't think the problem here is whether we have a deep copy or not,
but that the semantics of ranges are not defined clearly enough. If we
clearly state, for example, that whatever is returned by .front must
persist beyond popFront(), then it would be up to the range to implement
the deep copy, e.g., return the .dup or .idup'd array instead of a
reference to an internal buffer.

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.


T

-- 
"Holy war is an oxymoron." -- Lazarus Long

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

[Manu]

On 16 October 2012 18:09, Jacob Carlborg  wrote:

> On 2012-10-16 16:01, Iain Buclaw wrote:
>
>  /usr/[local/]include/d is the standard path.  Each compiler tends to
>> have it's own subfolder here anyway...
>>
>
> DMD doesn't look anywhere outside of its folder by default.


Well, that's obviously crap. What is the approach most people take when
they want to install their library?
I'll just do what's considered standard...

Can DMD just be fixed to include [local/]/include/d in it's default search
paths? I presume GDC and LDC already look there?

Re: 48 hour game jam

[Manu]

On 16 October 2012 18:02, Jacob Carlborg  wrote:

> On 2012-10-16 15:29, Manu wrote:
>
>  Well I've not tested mac, but I'll make the Linux build work tonight,
>> and from that, you should be able to adapt it easily.
>> Does OSX have X11 libs?
>>
>
> Yes, Mac OS X has X11.


What about alsa/pulse/oss, linux input?
I presume OSX has it's own variants of each of these things.


 If there is no X11 libs for OSX, then you will need to knock up an
>> MFDisplay_OSX.cpp for cocoa, which should be trivial (just create a
>> window, then call into MFRenderer_OpenGL.cpp init, as the windows/X11
>> ones do).
>> Infact, I'd really like to have a proper cocoa version anyway... ;)
>>
>
> Yeah, a proper Cocoa version is always nice.


Indeed, but does that involve .m files? :)


 You might also have problems with sound and input in osx, if they aren't
>> using the same libraries as linux. Writing the backend drivers for new
>> platforms is very easy, I've just never wanted to run on a mac.
>> I don't suppose you might like to help me out making proper support for
>> OSX? I'll be home on a couple of hours if we could take it offline then.
>> There's probably 2-3 drivers that need to be written, and some tweaks to
>> the typical C++ platform disambiguation nonsense at the top of Fuji.h.
>>
>
> It depends on how much work it is, but I can have a look.


I'll do it with you/do most of it myself, I just need someone to test it,
and give me OSX advice.

Re: Account on ARM/Debian

[Walter Bright]

On 10/16/2012 7:04 AM, Iain Buclaw wrote:

I was also thinking, wouldn't it be neat to write an operating system for
the Pi in in D..  man I wish there were more hours in a day!



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.


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.

Re: alias A = B; syntax

[stas]

On Tuesday, 16 October 2012 at 14:45:41 UTC, Tommi wrote:

You can cast your vote for the new syntax over there:
http://d.puremagic.com/issues/show_bug.cgi?id=3011



That is awesome. I didn't know about that issue.
Let's vote, guys!

The issue have been there from 2009 and has only 5 votes.
I am sure if more people knew about it the number of votes would 
be much greater.

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

[deadalnix]

Le 16/10/2012 15:30, H. S. Teoh a écrit :

On Mon, Oct 15, 2012 at 10:59:26PM -0700, 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.

[...]

But nothing about the definition of a range, as currently defined in
std.range, guarantees that whatever value was returned by .front is
still valid after popFront() is called.

I'm not saying that this should be the "correct" behaviour, but the
current definition does not prohibit a range from, say, reusing an array
to compute its next element. For example, one may have a range that
returns the permutations of a given array, in which popFront() permutes
the elements in-place. In this case, .front will become invalid once
popFront() is called. Many of the current range-based functions will not
work correctly in this case.

Of course, it's arguable whether such ranges should be admissible, but
as far as the current definition goes, I don't see anything that states
otherwise. If we don't make such things clear, then we're bound to run
into pathological cases where bugs will creep in because of unstated
assumptions in the code.


T



The default semantic should be the safe one.

Providing backdoor for experienced developer is useful, but it does arm 
as default behavior.

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

[Jordi Sayol]

Al 16/10/12 17:17, En/na Manu ha escrit:
> On 16 October 2012 18:09, Jacob Carlborg mailto:d...@me.com>> 
> wrote:
> 
> On 2012-10-16 16:01, Iain Buclaw wrote:
> 
> /usr/[local/]include/d is the standard path.  Each compiler tends to
> have it's own subfolder here anyway...
> 
> 
> DMD doesn't look anywhere outside of its folder by default.
> 
> 
> Well, that's obviously crap. What is the approach most people take when they 
> want to install their library?
> I'll just do what's considered standard...

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. There are some D libraries deb packages containing a 
"pkg-config" file (.pc) on the apt repository https://code.google.com/p/d-apt/

> 
> Can DMD just be fixed to include [local/]/include/d in it's default search 
> paths? I presume GDC and LDC already look there?

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.

-- 
Jordi Sayol

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

[deadalnix]

Le 16/10/2012 17:17, H. S. Teoh a écrit :

On Tue, Oct 16, 2012 at 05:01:57PM +0200, Tommi wrote:

On Tuesday, 16 October 2012 at 05:49:11 UTC, 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.


Isn't the deeper underlying problem here the fact that there's no
generic way to make a deep copy in this language (does any language?)
Making a deep copy of front would be a clean solution. I don't know
how to implement this generic deep copying functionality though. For
example: what would be the semantics of deep-copying a range?


I don't think the problem here is whether we have a deep copy or not,
but that the semantics of ranges are not defined clearly enough. If we
clearly state, for example, that whatever is returned by .front must
persist beyond popFront(), then it would be up to the range to implement
the deep copy, e.g., return the .dup or .idup'd array instead of a
reference to an internal buffer.



It wouldn't be enough. Does several call to front recompute things ? See 
http://d.puremagic.com/issues/show_bug.cgi?id=8803

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

[David Nadlinger]

On Tuesday, 16 October 2012 at 15:17:20 UTC, Manu wrote:
Can DMD just be fixed to include [local/]/include/d in it's 
default search

paths? I presume GDC and LDC already look there?


Just add -L-L/usr/local/include to your dmd.conf. LDC also 
doesn't look there by default, and I see little reason to change 
this.


David

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

[David Nadlinger]

On Tuesday, 16 October 2012 at 16:08:35 UTC, David Nadlinger 
wrote:
Just add -L-L/usr/local/include to your dmd.conf. LDC also 
doesn't look there by default, and I see little reason to 
change this.


Just to clarify: For LDC, -L-L$PREFIX/include/d _is_ included in 
the default configuration file, but the compiler doesn't 
automatically add the path internally.


The reason for this is simple: In some situations, you do _not_ 
want your compiler to go looking in some hard-coded directory, so 
we would have to add an extra switch to disable that behavior. 
And with two versions of D being around, and $PREFIX often being 
what a D1/Tango installation defaults to as well, those 
situations aren't as uncommon as one might think at first.


David

Re: alias A = B; syntax

[Era Scarecrow]

On Tuesday, 16 October 2012 at 07:52:51 UTC, Rob T wrote:

alias int Int;
Int x = 0;

vs

alias Int = int;
Int x = 0;

When I compare the two in this way, I'm inclined to keep things 
as they are.


 alias Int = int;

 this looks too much like variable declaration and instantiation, 
perhaps with only one it looks better to go this way. But what if 
you need several? Perhaps an unrealistic example, let's increase 
it by a factor of seven.


alias SomeChar = char;
alias SomeShort = short;
alias SomeInt = int;
alias SomeUInt = uint;
alias SomeLong = long;
alias SomeFloat = float;
alias SomeDouble = double;
uint  MaybeBroken = nutmeg;
const SomeChar FavoriateLanguage = 'D';
const SomeShort universeAndEverything = 42;
const SomeInt hundredThousand = 100_000;
const SomeUInt million = SomeInt * 10;
const SomeLong largeNumber = SomeUInt * SomeUInt;
const SomeFloat pi = 3.14;
const SomeDouble pi2 = pi*pi;
const MaybeBroken maybe= 2;

or

alias SomeChar = char;
const SomeChar FavoriateLanguage = 'D';
alias SomeShort = short;
const SomeShort universeAndEverything = 42;
alias SomeInt = int;
const SomeInt hundredThousand = 100_000;
alias SomeUInt = uint;
const SomeUInt million = SomeInt * 10;
uint  MaybeBroken = nutmeg;
const MaybeBroken maybeBroke = 2;
alias SomeLong = long;
const SomeLong largeNumber = SomeUInt * SomeUInt;
alias SomeFloat = float;
const SomeFloat pi = 3.14;
alias SomeDouble = double;
const SomeDouble pi2 = pi*pi;

vs

alias char SomeChar;
alias short SomeShort;
alias int SomeInt;
alias uint SomeUInt;
alias long SomeLong;
alias float SomeFloat;
alias double SomeDouble;
alias nutmeg MaybeBroken;
const SomeChar FavoriateLanguage = 'D';
const SomeShort universeAndEverything = 42;
const SomeInt hundredThousand = 100_000;
const SomeUInt million = SomeInt * 10;
const SomeLong largeNumber = SomeUInt * SomeUInt;
const SomeFloat pi = 3.14;
const SomeDouble pi2 = pi*pi;
const MaybeBroken maybeBroken = 2;

or

alias char SomeChar;
const SomeChar FavoriateLanguage = 'D';
alias short SomeShort;
const SomeShort universeAndEverything = 42;
alias int SomeInt;
const SomeInt hundredThousand = 100_000;
alias nutmeg MaybeBroken;
const MaybeBroken maybeBroken = 2;
alias uint SomeUInt;
const SomeUInt million = SomeInt * 10;
alias long SomeLong;
const SomeLong largeNumber = SomeUInt * SomeUInt;
alias float SomeFloat;
const SomeFloat pi = 3.14;
alias double SomeDouble;
const SomeDouble pi2 = pi*pi;


 Without the assignment operator it stands out a little more of 
it's intention and not a variable declaration. But honestly both 
work, I wouldn't mind having the alternate syntax (as long as the 
language doesn't clutter and break anything).

Re: 48 hour game jam

[Manu]

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

> On 2012-10-16 13:40, Manu wrote:
>
>  Sure. I also backported the fixes into Fuji, and polished up the D
>> bindings last night to work on Linux.
>> Was gonna put a Linux build script in there, since most people here are
>> linux users.
>>
>
> We want a script for Mac OS X as well :)
> I replaced "dist/bin/premake4" with a Mac OS X binary and I tried running
> "stache/Fuji/create_project.**sh". this is the output I got:
>
> ...
>
>  Building Fuji (release) 
> Creating ../Build/Release/Fuji
> glew.c
> DebugMenu.cpp
> In file included from ../../dist/include/Fuji/Fuji.**h:356,
>  from ../Source/DebugMenu.cpp:1:
> ../../dist/include/Fuji/**MFTypes.h:69: error: ‘ssize_t’ does not name a
> type
> In file included from ../../dist/include/Fuji/Fuji.**h:390,
>  from ../Source/DebugMenu.cpp:1:
> ../../dist/include/Fuji/Util.**h: In function ‘void MFFixUp(T*&, void*,
> int)’:
> ../../dist/include/Fuji/Util.**h:54: error: ‘intp’ was not declared in
> this scope
> ../../dist/include/Fuji/Util.**h:54: error: expected `;' before ‘offset’
> ../../dist/include/Fuji/Util.**h:57: error: ‘offset’ was not declared in
> this scope
> ../../dist/include/Fuji/Util.**h:59: error: ‘offset’ was not declared in
> this scope
> make[1]: *** [../Build/Release/Fuji/**DebugMenu.o] Error 1
> make: *** [Fuji] Error 2



Wanna jump on IRC, or some IM? googletalk?

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

[Manu]

On 16 October 2012 19:20, David Nadlinger  wrote:

> On Tuesday, 16 October 2012 at 16:08:35 UTC, David Nadlinger wrote:
>
>> Just add -L-L/usr/local/include to your dmd.conf. LDC also doesn't look
>> there by default, and I see little reason to change this.
>>
>
> Just to clarify: For LDC, -L-L$PREFIX/include/d _is_ included in the
> default configuration file, but the compiler doesn't automatically add the
> path internally.
>
> The reason for this is simple: In some situations, you do _not_ want your
> compiler to go looking in some hard-coded directory, so we would have to
> add an extra switch to disable that behavior. And with two versions of D
> being around, and $PREFIX often being what a D1/Tango installation defaults
> to as well, those situations aren't as uncommon as one might think at first.


Okay, I don't feel like my question is any clearer...

Why wouldn't you want a standard shared include path?
/usr/include works great for C, I don't see why there wouldn't be something
like that for D for compiler-agnostic 3rd party libs.

But my question is, where do I install includes? I'm not really a linux
user, I just want someone to tell me where to put it :) .. and if there
isn't a direct answer, then perhaps that's a problem that needs to be
addressed?

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

[Peter Alexander]

On Tuesday, 16 October 2012 at 15:47:49 UTC, deadalnix wrote:
It wouldn't be enough. Does several call to front recompute 
things ? See http://d.puremagic.com/issues/show_bug.cgi?id=8803


That's up to the range. You shouldn't rely on it caching anything 
(map does not, but it used to).

Re: Import improvement

[Jacob Carlborg]

On 2012-10-16 16:14, Sönke Ludwig wrote:


The compiler has to walk the directory structure anyway. If it stops at
a directory, it looks for _.d/package.d/... and uses that.


I was more thinking of the developer reading the code.

--
/Jacob Carlborg

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

[Jacob Carlborg]

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


Well, that's obviously crap. What is the approach most people take when
they want to install their library?
I'll just do what's considered standard...


I mostly only build from source using git submodules. I have one or two 
libraries placed in the DMD directory.



Can DMD just be fixed to include [local/]/include/d in it's default
search paths? I presume GDC and LDC already look there?


Preferably I would like a package manager to handle this.

--
/Jacob Carlborg

Re: alias A = B; syntax

[kenji hara]

2012/10/16 Andrej Mitrovic :
> On 10/16/12, Nick Sabalausky  wrote:
>> I'm pretty sure it was already decided that this would be added, but
>> just hasn't made it in yet. I've been fairly eager for it. I find the
>> current syntax too inconsistent and confusing.
>
> Yep.
>
> Paging Dr. Kenji!

The result of my challenging.
https://github.com/D-Programming-Language/dmd/pull/1187

Kenji Hara

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

[Jonathan M Davis]

On Tuesday, October 16, 2012 06:30:53 H. S. Teoh wrote:
> On Mon, Oct 15, 2012 at 10:59:26PM -0700, 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.
> 
> [...]
> 
> But nothing about the definition of a range, as currently defined in
> std.range, guarantees that whatever value was returned by .front is
> still valid after popFront() is called.
> 
> I'm not saying that this should be the "correct" behaviour, but the
> current definition does not prohibit a range from, say, reusing an array
> to compute its next element. For example, one may have a range that
> returns the permutations of a given array, in which popFront() permutes
> the elements in-place. In this case, .front will become invalid once
> popFront() is called. Many of the current range-based functions will not
> work correctly in this case.
> 
> Of course, it's arguable whether such ranges should be admissible, but
> as far as the current definition goes, I don't see anything that states
> otherwise. If we don't make such things clear, then we're bound to run
> into pathological cases where bugs will creep in because of unstated
> assumptions in the code.

There's only so much that the compiler can check for you. Sure, we could say 
in the docs that front must still be valid after a call to popFront (and 
perhaps we should), but there's no way to validate that.

There's also no way to validate that front always returns the same value, or 
that popFront actually pops a value, or that it pops only one value, etc. 
Pretty much _all_ that we can verify with template constraints is function 
signatures. So, we can _never_ fully restrict range types to exactly what 
would be considered correct.

So, if we have expectations about how ranges should/must work, then that 
should be in the docs somewhere, but the definition of a range from the 
compiler's perspective can only ever be defined by eponymous templates which 
can't possibly verify correct behavior, meaning that something like ByLine 
will always be permitted even if it doesn't work, because it breaks the 
semantic design of ranges.

- Jonathan M Davis

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

[H. S. Teoh]

On Tue, Oct 16, 2012 at 07:02:58PM +0200, Jonathan M Davis wrote:
> On Tuesday, October 16, 2012 06:30:53 H. S. Teoh wrote:
[...]
> > I'm not saying that this should be the "correct" behaviour, but the
> > current definition does not prohibit a range from, say, reusing an
> > array to compute its next element. For example, one may have a range
> > that returns the permutations of a given array, in which popFront()
> > permutes the elements in-place. In this case, .front will become
> > invalid once popFront() is called. Many of the current range-based
> > functions will not work correctly in this case.
> > 
> > Of course, it's arguable whether such ranges should be admissible,
> > but as far as the current definition goes, I don't see anything that
> > states otherwise. If we don't make such things clear, then we're
> > bound to run into pathological cases where bugs will creep in
> > because of unstated assumptions in the code.
> 
> There's only so much that the compiler can check for you. Sure, we
> could say in the docs that front must still be valid after a call to
> popFront (and perhaps we should), but there's no way to validate that.

I wasn't talking about compiler validation. I was talking about clearly
defining, in the docs or otherwise, what exactly a range is, and what is
expected of it. Right now, it's rather nebulous what exactly constitutes
a range. I thought byLine() was a perfectly valid range, but apparently
you think otherwise. The two aren't compatible, since they lead to wrong
code that has buggy behaviour when passed something it doesn't expect.


[...]
> So, if we have expectations about how ranges should/must work, then
> that should be in the docs somewhere, but the definition of a range
> from the compiler's perspective can only ever be defined by eponymous
> templates which can't possibly verify correct behavior, meaning that
> something like ByLine will always be permitted even if it doesn't
> work, because it breaks the semantic design of ranges.
[...]

So what is (or should be) the semantic design of ranges? Let's work out
a precise definition so that we have something to build on.


T

-- 
Three out of two people have difficulties with fractions. -- Dirk Eddelbuettel

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

[Manu]

On 16 October 2012 19:59, Jacob Carlborg  wrote:

> On 2012-10-16 17:17, Manu wrote:
>
>  Well, that's obviously crap. What is the approach most people take when
>> they want to install their library?
>> I'll just do what's considered standard...
>>
>
> I mostly only build from source using git submodules. I have one or two
> libraries placed in the DMD directory.


Okay, well I'll stick with that for now I guess.


 Can DMD just be fixed to include [local/]/include/d in it's default
>> search paths? I presume GDC and LDC already look there?
>>
>
> Preferably I would like a package manager to handle this.


Well, a solution I can use now would be nice.
Nominating a directory at least until such an established package manager
emerges might be a convenient intermediary.

Re: 48 hour game jam

[Jacob Carlborg]

On 2012-10-16 18:39, Manu wrote:


Wanna jump on IRC, or some IM? googletalk?


Sure, I'll be in the D IRC channel with the alias "doob".

--
/Jacob Carlborg

Re: 48 hour game jam

[Jacob Carlborg]

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


What about alsa/pulse/oss, linux input?
I presume OSX has it's own variants of each of these things.


Yes, it has it's own variants. Although I have no experience with these 
frameworks.



Indeed, but does that involve .m files? :)


Yes, it's possible do it in D as well. I see that Fuji is written in 
C++, so your choices are: Objective-C, D or Objective-C++. Objective-C++ 
is basically Objective-C and C++ in the same source file. But it's not 
possible to mix the object models, i.e. a C++ class cannot inherit from 
an Objective-C class, or the other way around.


Here's an Objective-C - D bridge I've made, it has some documentation of 
how to interact with Objective-C from another language:


http://www.dsource.org/projects/dstep/wiki/ObjcBridge/BridgeInternals


I'll do it with you/do most of it myself, I just need someone to test
it, and give me OSX advice.


Ok, I'll see. Then it shouldn't be any problems.

--
/Jacob Carlborg

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

[Jonathan M Davis]

On Tuesday, October 16, 2012 06:40:54 H. S. Teoh wrote:
> Notice in the second output range, that the third element is [20, 203]
> instead of [100, 203], and thereafter a bunch of elements are skipped,
> and things just start going haywire after that.
> 
> The only difference between the two is that the first is computed within
> main(), and the second is returned from a function call. Does this mean
> that it's unsafe to return composed ranges from functions?

No. I don't know what's going on, but it sounds like there's a bug somewhere.

> I'm trying to
> think what might be going wrong. Could it be that the composed ranges
> are stack-allocated temporaries that go out of scope upon returning from
> the function, so the returned range is actually accessing invalid
> memory? (That is a really scary thought.)

If you have a range over static array, then yes, you will have serious issues 
if you return a range over it, because the data is going away, but that's not 
going to happen with a struct or class. The class would be safely on the heap, 
and the struct will get appropriately copied. But one area that could get 
hairy if dmd is buggy is if you're using delegates which access the stack 
frame. It's supposed to work just fine, but it requires that a closure be 
allocated so that the state of the stack frame is saved (and is therefore 
valid after the function call has completed). So, things could definitely go 
funny if there are any bugs in there.

I have no idea what's going wrong for you here (I'd have to spend time 
studying exactly what your code is doing), but there's either a bug in your 
code or a compiler bug which is causing you problems, because aside from 
slices of static arrays, it's perfectly safe to return stack-allocated stuff 
functions - including several layers of ranges.

- Jonathan M Davis

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

[Jonathan M Davis]

On Tuesday, October 16, 2012 08:17:40 H. S. Teoh wrote:
> On Tue, Oct 16, 2012 at 05:01:57PM +0200, Tommi wrote:
> > On Tuesday, 16 October 2012 at 05:49:11 UTC, 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.
> > 
> > Isn't the deeper underlying problem here the fact that there's no
> > generic way to make a deep copy in this language (does any language?)
> > Making a deep copy of front would be a clean solution. I don't know
> > how to implement this generic deep copying functionality though. For
> > example: what would be the semantics of deep-copying a range?
> 
> I don't think the problem here is whether we have a deep copy or not,
> but that the semantics of ranges are not defined clearly enough. If we
> clearly state, for example, that whatever is returned by .front must
> persist beyond popFront(), then it would be up to the range to implement
> the deep copy, e.g., return the .dup or .idup'd array instead of a
> reference to an internal buffer.

1. There is no generic way to deep copy stuff. So, requiring a deep copy of 
front just plain doesn't make sense. It would be completely untenable. By 
doing so, you basically make it impossible to use the result of front beyond a 
call to popFront in the general case.

2. Often, a deep copy isn't needed in the least, even with a messed up range 
like ByLine. If it were an array of class objects rather than char, doing a 
deep copy would needlessly copy all of those class objects as well. It could 
quickly become a performance nightmare.

- Jonathan M Davis

Re: 48 hour game jam

[Manu]

On 16 October 2012 20:13, Jacob Carlborg  wrote:

> On 2012-10-16 18:39, Manu wrote:
>
>  Wanna jump on IRC, or some IM? googletalk?
>>
>
> Sure, I'll be in the D IRC channel with the alias "doob".


Cool, I'm idling in there.

Re: alias A = B; syntax

[Andrej Mitrovic]

On 10/16/12, kenji hara  wrote:
> The result of my challenging.
> https://github.com/D-Programming-Language/dmd/pull/1187

Awesome. :)

Re: Import improvement

[Jonathan M Davis]

On Monday, October 15, 2012 11:37:06 Andrei Alexandrescu wrote:
> 1. I expect large packages to introduce a module "all.di" or "_.di" to
> publicly import everything in the package. That could help some use cases.

It would be fantastic if we could get something like DIP15/16 implemented 
which made it possible to do

import my.pkg;

instead of

import my.pkg.all;

or

import my.pkg._;

or whatever folks have come up with. And everything's there already except
for making it so that when my.pkg is a package, importing my.pkg then
imports a specially-named package inside of my.pkg with whatever public
imports you want to have when importing the entire package. I started looking
into implementing it a while back but got sidetracked before I could get
very far.

- Jonathan M Davis

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

[Jonathan M Davis]

On Tuesday, October 16, 2012 10:13:57 H. S. Teoh wrote:
> I wasn't talking about compiler validation. I was talking about clearly
> defining, in the docs or otherwise, what exactly a range is, and what is
> expected of it. Right now, it's rather nebulous what exactly constitutes
> a range. I thought byLine() was a perfectly valid range, but apparently
> you think otherwise. The two aren't compatible, since they lead to wrong
> code that has buggy behaviour when passed something it doesn't expect.

ByLine is perfectly valid range insofar as you realize that it's likely to go 
completely south if you use it in any way that could involve keeping front 
around after popFront has been called, which means that anything which relies 
on keeping front around isn't going to work. So, it's a range, but it's 
essentially an unsafe one (though I'm not sure that it's an un-@safe one).

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.

Ranges _can_ define semantics which violate that, but they have to make it 
clear that they do so that programmers using them realize that they may not 
work right with a lot of range-based functions (which potentially makes it so 
that it they really shouldn't have been ranges in the first place).

> So what is (or should be) the semantic design of ranges? Let's work out
> a precise definition so that we have something to build on.

As far as front (or back) goes, range-based functions should be able to rely 
on

1. front returning the exact same value on every call until popFront has been 
called (though there's no guarantee that front won't have to be recalculated 
on each call, so assigning the result of front to a local variable is 
advisable for efficiency if front must be used multiple times before a call to 
popFront).

2. the result of front continuing to be valid and unchanged after popFront has 
been called if it was assigned to a variable.

Any range is free to violate this, but because range-based functions are free 
to rely on it, such ranges risk not working correctly with many range-based 
functions and must be used with caution.

- Jonathan M Davis

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

[Tommi]

On Tuesday, 16 October 2012 at 17:19:26 UTC, Jonathan M Davis 
wrote:

1. There is no generic way to deep copy stuff.


Could you elaborate on that a bit more?

How about a deep-assign operator? The compiler could implicitly 
define it at least for arrays and for structs that don't have 
mutable indirection:


struct MyStruct
{
int _value;

// implicit:
ref MyStruct opDeepAssign(ref const MyStruct ms)
{
this = ms;
return this;
}
}

int[] array1 = [1, 2, 3];
int[] array2;
array2.opDeepAssign(array1); // array2 = array1.dup;

And there would be hasDeepAssign!T traits and whatnot.

Re: 48 hour game jam

[Ethan]

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.


I don't actually have my Mac over from Australia yet to whip up 
some code examples, or even port Fuji myself. But needless to say 
this is the (free download) book I've been using as reference:


http://www.pangeasoft.net/book/buy.html

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.

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

[David Gileadi]

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

Any range is free to violate this, but because range-based functions are free
to rely on it, such ranges risk not working correctly with many range-based
functions and must be used with caution.


As a D dabbler, it seems wrong to me that a built-in range like byLine, 
which is often used in example code, should have weird side effects with 
the built-in methods in std.algorithm.  IMO this needs to be fixed one 
way or another, and a mere documentation change is likely not enough for 
casual D users.

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

[Mike Wey]

On 10/16/2012 06:55 PM, Manu wrote:

Okay, I don't feel like my question is any clearer...

Why wouldn't you want a standard shared include path?
/usr/include works great for C, I don't see why there wouldn't be
something like that for D for compiler-agnostic 3rd party libs.

But my question is, where do I install includes? I'm not really a linux
user, I just want someone to tell me where to put it :) .. and if there
isn't a direct answer, then perhaps that's a problem that needs to be
addressed?


/usr/[local/]include/d seems to be the most common, and it should work 
great for compiler-agnostic libs.
But for the standard library like D1-Tango mentioned earlier it probably 
isn't the right place.


--
Mike Wey

Re: Import improvement

[Sönke Ludwig]

Am 10/16/2012 6:55 PM, schrieb Jacob Carlborg:
> On 2012-10-16 16:14, Sönke Ludwig wrote:
> 
>> The compiler has to walk the directory structure anyway. If it stops at
>> a directory, it looks for _.d/package.d/... and uses that.
> 
> I was more thinking of the developer reading the code.
> 

Ah OK, sorry. There is no direct way of course. But assuming that it
semantically makes sense to import a package and because it's necessary
to look at some kind of documentation before importing anything anyway,
I guess that could be a tolerable shortcoming.

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

[monarch_dodra]

On Tuesday, 16 October 2012 at 17:17:36 UTC, Jonathan M Davis
wrote:

On Tuesday, October 16, 2012 06:40:54 H. S. Teoh wrote:
Notice in the second output range, that the third element is 
[20, 203]
instead of [100, 203], and thereafter a bunch of elements are 
skipped,

and things just start going haywire after that.

The only difference between the two is that the first is 
computed within
main(), and the second is returned from a function call. Does 
this mean

that it's unsafe to return composed ranges from functions?


No. I don't know what's going on, but it sounds like there's a 
bug somewhere.



I'm trying to
think what might be going wrong. Could it be that the composed 
ranges
are stack-allocated temporaries that go out of scope upon 
returning from
the function, so the returned range is actually accessing 
invalid

memory? (That is a really scary thought.)


If you have a range over static array, then yes, you will have 
serious issues
if you return a range over it, because the data is going away, 
but that's not
going to happen with a struct or class. The class would be 
safely on the heap,
and the struct will get appropriately copied. But one area that 
could get
hairy if dmd is buggy is if you're using delegates which access 
the stack
frame. It's supposed to work just fine, but it requires that a 
closure be
allocated so that the state of the stack frame is saved (and is 
therefore
valid after the function call has completed). So, things could 
definitely go

funny if there are any bugs in there.

I have no idea what's going wrong for you here (I'd have to 
spend time
studying exactly what your code is doing), but there's either a 
bug in your
code or a compiler bug which is causing you problems, because 
aside from
slices of static arrays, it's perfectly safe to return 
stack-allocated stuff

functions - including several layers of ranges.

- Jonathan M Davis


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.

Re: alias A = B; syntax

[so]

On Tuesday, 16 October 2012 at 17:05:14 UTC, kenji hara wrote:


The result of my challenging.
https://github.com/D-Programming-Language/dmd/pull/1187

Kenji Hara


As far as i remember, Andrei said that it was planned and the 
syntax will support templates too (like C++0x template alias). 
So, this might not be enough.


Something like:
alias vec(T) = vector!(T, allocator);

Re: alias A = B; syntax

[stas]

On Tuesday, 16 October 2012 at 17:05:14 UTC, kenji hara wrote:

The result of my challenging.
https://github.com/D-Programming-Language/dmd/pull/1187



Respect.

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

[H. S. Teoh]

On Tue, Oct 16, 2012 at 07:28:38PM +0200, Jonathan M Davis wrote:
> On Tuesday, October 16, 2012 10:13:57 H. S. Teoh wrote:
[...]
> ByLine is perfectly valid range insofar as you realize that it's
> likely to go completely south if you use it in any way that could
> involve keeping front around after popFront has been called, which
> means that anything which relies on keeping front around isn't going
> to work. So, it's a range, but it's essentially an unsafe one (though
> I'm not sure that it's an un-@safe one).
> 
> 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.

I think a better solution is to somehow differentiate between ranges
whose .front value is permanent (arrays), and ranges whose .front values
are transient (e.g. byLine, but we shouldn't single it out because there
are other occasions where you may *want* to have a range that doesn't
call .dup every time -- say a range over all permutations of an array
that modifies the array in-place).

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).


> Ranges _can_ define semantics which violate that, but they have to
> make it clear that they do so that programmers using them realize that
> they may not work right with a lot of range-based functions (which
> potentially makes it so that it they really shouldn't have been ranges
> in the first place).

I think this approach of what amounts to guessing which ranges are
safe/unsafe with which functions is what's untenable. We all know that
people don't read documentation, or at least, not thoroughly. Something
like this is too easy to miss, and bugs will slip into code unnoticed
for a long time, and then explode in your face. It's unsafe by default,
which goes against D's philosophy.

I think the problem is better addressed by an .isTransient property that
can be selected by templates at compile-time.  I agree that requiring
*every* range function to expect .front to mutate upon calling
.popFront() is unreasonable, but *some* functions *can* be written in a
way that they will still work. Marking ranges with transient .front
values will allow functions that *can* take transient ranges do so,
while leaving other functions accepting only non-transient ranges. That
way, if somebody tries to pass a transient range to a template that only
works with a non-transient range, they will know at compile-time instead
of getting a nasty surprise later on.


> > So what is (or should be) the semantic design of ranges? Let's work
> > out a precise definition so that we have something to build on.
> 
> As far as front (or back) goes, range-based functions should be able
> to rely on
> 
> 1. front returning the exact same value on every call until popFront
> has been called (though there's no guarantee that front won't have to
> be recalculated on each call, so assigning the result of front to a
> local variable is advisable for efficiency if front must be used
> multiple times before a call to popFront).
> 
> 2. the result of front continuing to be valid and unchanged after
> popFront has been called if it was assigned to a variable.
> 
> Any range is free to violate this, but because range-based functions
> are free to rely on it, such ranges risk not working correctly with
> many range-based functions and must be used with caution.
[...]

I don't like the idea that some ranges _may_ or _may not_ work with some
functions. That's just too unreliable, and it's too easy to make
mistakes. Let's put in an isTransient property on the unsafe ranges and
let the templates' signature constraints enforce passing the right kind
of range.


On Tue, Oct 16, 2012 at 10:58:23AM -0700, David Gileadi wrote:
[...]
> As a D dabbler, it seems wrong to me that a built-in range like
> byLine, which is often used in example code, should have weird side
> effects with the built-in methods in std.algorithm.  IMO this needs to
> be fixed one way or another, and a mere documentation change is likely
> not enough for casual D users.

I agree. We should add an isTransient property to at least the built-in
ranges in Phobos, so that at least those ranges will always work
properly (or complain loudly at compile-time if passed to the wrong
function).

User-defined ranges need to be mar

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

[H. S. Teoh]

On Tue, Oct 16, 2012 at 08:44:56PM +0200, monarch_dodra wrote:
> On Tuesday, 16 October 2012 at 17:17:36 UTC, Jonathan M Davis
> wrote:
> >On Tuesday, October 16, 2012 06:40:54 H. S. Teoh wrote:
> >>Notice in the second output range, that the third element is [20,
> >>203] instead of [100, 203], and thereafter a bunch of elements are
> >>skipped, and things just start going haywire after that.
> >>
> >>The only difference between the two is that the first is computed
> >>within main(), and the second is returned from a function call. Does
> >>this mean that it's unsafe to return composed ranges from functions?
> >
> >No. I don't know what's going on, but it sounds like there's a bug
> >somewhere.
> >
> >>I'm trying to think what might be going wrong. Could it be that the
> >>composed ranges are stack-allocated temporaries that go out of scope
> >>upon returning from the function, so the returned range is actually
> >>accessing invalid memory? (That is a really scary thought.)
> >
> >If you have a range over static array, then yes, you will have
> >serious issues if you return a range over it, because the data is
> >going away, but that's not going to happen with a struct or class.
> >The class would be safely on the heap, and the struct will get
> >appropriately copied. But one area that could get hairy if dmd is
> >buggy is if you're using delegates which access the stack frame. It's
> >supposed to work just fine, but it requires that a closure be
> >allocated so that the state of the stack frame is saved (and is
> >therefore valid after the function call has completed). So, things
> >could definitely go funny if there are any bugs in there.

Hmm. There *is* a delegate being passed to map(). Would that cause
problems? Theoretically it shouldn't, but as you said, if dmd isn't
handling it correctly that could cause problems.


> >I have no idea what's going wrong for you here (I'd have to spend
> >time studying exactly what your code is doing), but there's either a
> >bug in your code or a compiler bug which is causing you problems,
> >because aside from slices of static arrays, it's perfectly safe to
> >return stack-allocated stuff functions - including several layers of
> >ranges.

I'm at a loss as to where the bug in my code could be, since I have two
identical copies of the same code, one works, and the other doesn't, and
the only difference between them is that one is returning a range from a
separate function.


[...]
> 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.

Thanks! This problem has been bugging me (har har) all through last
night and this morning.


T

-- 
"Real programmers can write assembly code in any language. :-)" -- Larry Wall

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

[Jonathan M Davis]

On Tuesday, October 16, 2012 10:58:23 David Gileadi wrote:
> On 10/16/12 10:28 AM, Jonathan M Davis wrote:
> > Any range is free to violate this, but because range-based functions are
> > free to rely on it, such ranges risk not working correctly with many
> > range-based functions and must be used with caution.
> 
> As a D dabbler, it seems wrong to me that a built-in range like byLine,
> which is often used in example code, should have weird side effects with
> the built-in methods in std.algorithm. IMO this needs to be fixed one
> way or another, and a mere documentation change is likely not enough for
> casual D users.

ByLine needs to do what it does for performance reasons, so its implementation 
makes a lot of sense, and it really wouldn't make sense for it to do what 
would be necessary to make it work as a normal range (since that would mean 
allocating a new buffer for every line), so if the fact that it's likely to be 
used and then misused by newbies is a big problem, then that's a strong 
argument for making it just use opApply rather than being a proper range. I 
certainly don't think that it makes sense to change how ranges work in general 
just to better support ByLine's weirdness. it would be far too restrictive to 
do so.

- Jonathan M Davis

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

[H. S. Teoh]

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

-- 
Государство делает вид, что платит нам зарплату, а мы делаем вид, что работаем.

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

[Jonathan M Davis]

On Tuesday, October 16, 2012 19:51:09 Tommi wrote:
> On Tuesday, 16 October 2012 at 17:19:26 UTC, Jonathan M Davis
> 
> wrote:
> > 1. There is no generic way to deep copy stuff.

There is no standard function for copying anything. dup and idup are array-
specific. It's a commonly used function name for a clone function on objects, 
but that's just a convention and not even necessarily a consistently used one. 
Some types are value types and so simply making a copy of them does a deep 
copy, whereas others are reference types and making a copy only does a shallow 
copy (hence why save was created for ranges). There's no way to look at a type 
and know how to correctly copy it. The best that could be done would be to 
standardize on dup, in which case it would be defined it for all built-in stuff 
via UFCS, and any user-defined stuff that wanted to be generically copied would 
define it. But we haven't done anything like that.

But really, not even that would be enough, because dup doesn't do a deep copy 
on arrays. It does something in between a shallow copy and a deep copy. It 
copies the array itself rather than the pointer, meaning that you get a 
totally separate array, but it doesn't do a deep copy of the elements, so if 
you had an array of reference types, anything done to the duped array's 
elements (other than assigning them new references) will affect the originals.

> How about a deep-assign operator? The compiler could implicitly
> define it at least for arrays and for structs that don't have
> mutable indirection:
> 
> struct MyStruct
> {
> int _value;
> 
> // implicit:
> ref MyStruct opDeepAssign(ref const MyStruct ms)
> {
> this = ms;
> return this;
> }
> }
> 
> int[] array1 = [1, 2, 3];
> int[] array2;
> array2.opDeepAssign(array1); // array2 = array1.dup;
> 
> And there would be hasDeepAssign!T traits and whatnot.

Something like that could probably be done, but that's not really all that 
different from just defining dup for stuff and having a hasDup trait, which can 
be done without any changes to the language like opDeepAssign would require. 
And again, it doesn't quite do the job due to how dup on arrays work. We'd 
probably need to add a function to the standard library (e.g. deepCopy) which 
would be defined for all built-in types and which user-defined types could 
define 
(with something hasDeepCopy being there to check for it), and then code could 
use that for doing deep copies. So again, it's possible, but it doesn't 
currently exist.

- Jonathan M Davis

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

[H. S. Teoh]

On Tue, Oct 16, 2012 at 09:21:18PM +0200, Jonathan M Davis wrote:
[...]
> We'd probably need to add a function to the standard library (e.g.
> deepCopy) which would be defined for all built-in types and which
> user-defined types could define (with something hasDeepCopy being
> there to check for it), and then code could use that for doing deep
> copies. So again, it's possible, but it doesn't currently exist.
[...]

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.


T

-- 
He who sacrifices functionality for ease of use, loses both and deserves 
neither. -- Slashdotter

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

[Jonathan M Davis]

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 think this approach of what amounts to guessing which ranges are
> safe/unsafe with which functions is what's untenable. We all know that
> people don't read documentation, or at least, not thoroughly. Something
> like this is too easy to miss, and bugs will slip into code unnoticed
> for a long time, and then explode in your face. It's unsafe by default,
> which goes against D's philosophy.

The problem is that what ByLine is doing is incredibly abnormal. So, we're 
talking about affecting how all ranges do things just to satisfy one, 
incredibly abnormal use case. It's just that this one range is heavily used, 
making the fact that it doesn't work normally a problem. But given that even 
using opApply with ByLine would require the programmer to understand how to 
use it correctly (since simply keeping the buffer around after an iteration 
would still break in that case), the programmer has to understand the 
weirdness of ByLine _regardless_, making it so that I don't know that it's 
ultimately all that big a deal that many range-based functions will choke on 
it. The main problem I see with that is similar to the problem with relying on 
CTFE - a simple change to a function could make it so that what _did_ work 
correctly suddenly stops working correctly and will only be caught if that 
particular use case has unit tests (highly unlikely with ByLine).

So, really, I'm in favor of just making ByLine use opApply and make it so that 
it's not a range. That doesn't completely fix the problem, but it reduces its 
scope and doesn't complicate the rest of Phobos in the process.

- Jonathan M Davis

Re: More D & Rust

[Ziad Hatahet]

On Tue, Oct 16, 2012 at 3:35 AM, Kagamin  wrote:

> Well, it's true non-null types can be statically checked. But if you try
> to code without nulls, what is the chance to run into null pointer?
>

You mean by calling external (potentially unsafe) code that contains null
pointers?

--
Ziad

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

[jerro]

Hmm. There *is* a delegate being passed to map(). Would that 
cause
problems? Theoretically it shouldn't, but as you said, if dmd 
isn't

handling it correctly that could cause problems.


I'm looking at the disassembly of cprod 
(http://pastebin.com/ngTax6B8) and there doesn't seem to be a 
call to _d_allocmemory in it. AFAIK it should be if the memory 
for the variables that the delegate uses was allocated on the 
heap?

Re: 48 hour game jam

[ponce]

On Monday, 15 October 2012 at 11:52:49 UTC, Manu wrote:

We did a 48hr game jam at work this past weekend.



Now that's a hilarious game :) good job.

Re: More D & Rust

[bearophile]

Ziad Hatahet:

You mean by calling external (potentially unsafe) code that 
contains null pointers?


This is *not* a significant problem for a language with a well 
designed non-null system. See how ATS language removes similar 
problems.


Bye,
bearophile

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

[H. S. Teoh]

On Tue, Oct 16, 2012 at 09:21:11PM +0200, Jonathan M Davis wrote:
> 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.

But like I said, we shouldn't single out ByLine just because it's what I
happened to run into this time. This is part of a larger issue, which is
that currently, we *assume* that ranges will not invalidate the value of
.front when popFront() is called. But many kinds of ranges don't fulfill
this (currently unstated) requirement. ByLine is only one of the more
common examples.

Another example that I've mentioned is a range which returns the
permutations of an array by swapping array elements in-place.

Yet another example, that actually came up in my own code, is an
expression tree structure that represents potentially multiple values
(it contains operators like ±). There is a method that returns a range
of all possible values the tree can take on. Individual values are in
fact vectors, which means .front returns real[]. It is much more
efficient to implement, for example, ± just by flipping the signs of
each component of the vector in-place, than to .dup every single time.
If one is searching for a specific vector, for example, it would be
wasteful to .dup every real[] that gets generated, only to immediately
discard it.

So this is a non-trivial example of a range that modifies the array
returned by .front when you call popFront(), but is otherwise a
perfectly valid range.

And I argue that these "transient ranges" as I call them do have their
place. One can iterate over them, call find() or canFind() on them,
etc., all the normal things one does with ranges, which are what makes
the concept of ranges so powerful. The only thing is that one has to be
careful about saving the value of .front and then calling popFront().

Marking these ranges with some kind of marker, like isTransient, will
help solve this problem. It doesn't have to be done everywhere: just for
the few ranges that exhibit this property. And it only needs to be
checked by functions that require .front to not mutate under them when
they call popFront(). Most functions in Phobos, I suspect, don't even
need to bother with it. So it should be a relatively small change. Seems
to be a win-win situation to me.


> > I think this approach of what amounts to guessing which ranges are
> > safe/unsafe with which functions is what's untenable. We all know
> > that people don't read documentation, or at least, not thoroughly.
> > Something like this is too easy to miss, and bugs will slip into
> > code unnoticed for a long time, and then explode in your face. It's
> > unsafe by default, which goes against D's philosophy.
> 
> The problem is that what ByLine is doing is incredibly abnormal. So,
> we're talking about affecting how all ranges do things just to satisfy
> one, incredibly abnormal use case. It's just that this one range is
> heavily used, making the fact that it doesn't work normally a problem.

I don't agree that what ByLine does is abnormal. If this were indeed the
case, it would greatly limit the scope of ranges and range-based
functions. You wouldn't be able to implement ranges that reuse buffers
(as I described above), and you may end up being forced to use
inefficient implementations just to satisfy the few functions that
assume that .front doesn't mutate when you call popFront(). I don't see
that as an advantageous position to take. Many range-based functions
*do* work with ByLine and other such ranges, so why impose arbitrary
restrictions on them?

Better to just treat the special cases specially (transient ranges +
functions that assume .front can be safely copied), and let the general
case work as it is already working.


[...]
> So, really, I'm in favor of just making ByLine use opApply and make it
> so that it's not a range. That doesn't completely fix the problem, but
> it reduces its scope and doesn't complicate the rest of Phobos in the
> process.
[...]

This is the simplest way out, I suppose, but it does lim

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

[Jonathan M Davis]

On Tuesday, October 16, 2012 12:15:01 H. S. Teoh wrote:
> I'm at a loss as to where the bug in my code could be, since I have two
> identical copies of the same code, one works, and the other doesn't, and
> the only difference between them is that one is returning a range from a
> separate function.

You'd probably have to reduce your code piece by piece until it starts acting 
the same in both cases and then try and determine the smallest example 
possible using that. Then it could become fairly clear whether it's a library 
bug or a compiler bug. But narrowing it down is likely to be rather unpleasant 
regardless.

- Jonathan M Davis

Re: Strange Loop 2012

[Philippe Sigaud]

On Tue, Oct 16, 2012 at 1:39 AM, bearophile  wrote:
>
> "Wolfe-Graph.pdf":

I read this one on the plane today. Clojure does make for some elegant code.
I think it's doable in D, with the usual metaprogramming suspects.


> "LaucherSnively-TypesVsTests.pdf":
>
> This pack compares strong static typing against writing unittests. What is
> the best of the two? The expected answer is that they are two different
> things, they help the programmer on different things, so they are both
> useful.

I read this one too (similar tastes or did you read them all?). I
admit being a bit disappointed by the wishy-washy conclusion. I use
both types and unit tests (in D!), but I'm more a static typing guy
myself.

Re: More D & Rust

[bearophile]

Marco Leise:


I agree with them, that it would be nice if D classes could
naturally be placed on the stack.


Allocating D class instances in-place (on the stack or inside 
other structs/class instances) is not hard, but in practice I 
never do it (Like I never use Rebindable or Typedef. I sometimes 
use Nullable or AssumeUnique). But to make it safe enough you 
probably need a smarter type system, that they have mostly 
finished designing in Rust.


Avoiding most heap allocations is positive because it reduces the 
amount of garbage, reduces pressure on the GC, gives good 
performance even if you use a not too much refined GC, avoids GC 
precision troubles, helps use less levels of indirection, and 
generally helps keep the code faster.


Another thing Rust team is doing is (I think) having the 
reference compiler based on LLVM. This means saving time to 
develop only the front-end and designing the language. Scala 
development was quick because the "back-end" and the GC was 
already done (but of course it introduced some limitations. Now 
they are porting Scala to the LLVM, removing most or all of the 
limitations, but they keep all layers of the compiler but the 
last one, so they have to translate stack-based code to the 
infinite-number-of-registers-based IR of LLVM, and I think this 
is sub-optimal, but they will have time to fix this problem later 
removing one more stage in the middle).


Bye,
bearophile

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

[jerro]

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.

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

[Nick Sabalausky]

On Tue, 16 Oct 2012 17:48:54 +0200
Jordi Sayol  wrote:

> Al 16/10/12 17:17, En/na Manu ha escrit:
> > On 16 October 2012 18:09, Jacob Carlborg  > > wrote:
> > 
> > On 2012-10-16 16:01, Iain Buclaw wrote:
> > 
> > /usr/[local/]include/d is the standard path.  Each compiler
> > tends to have it's own subfolder here anyway...
> > 
> > 
> > DMD doesn't look anywhere outside of its folder by default.
> > 
> > 
> > Well, that's obviously crap. What is the approach most people take
> > when they want to install their library? I'll just do what's
> > considered standard...
> 
> 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?

> There are some D libraries deb packages containing a "pkg-config"
> file (.pc) on the apt repository https://code.google.com/p/d-apt/
> 
> > 
> > Can DMD just be fixed to include [local/]/include/d in it's default
> > search paths? I presume GDC and LDC already look there?
> 
> 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 ;)

Re: 48 hour game jam

[bearophile]

Ethan:


but I have
already come across a few things that make me think it's about
99% ready for production code instead of the full 100%.


D has some rough edges still, and I think most of such rough 
edges are now known to D designers and the D community. Some of 
those edges will be fixed (some of them even have an already 
written patch in GitHub!), while some of them probably will not 
be fixed or will not be fixed soon, sometimes because there is no 
good way to fix them among the ecology of the other D features, 
or because D designers don't want to fix them (like some 
segfaults caused by nulls).




I'll go in to more detail in another thread,


Good. Reports from practical usage are usually interesting.


but I did find it odd that D is a language that aims to make 
life easier for the programmer

yet makes you jump through hoops at times.


D design comes from people that have a long experience of C and 
C++ (and some experience of Java and a bit of experience of 
Python, and Perl). This means in D you find many details wisely 
designed. But another consequence is that several parts are also 
designed in a old style. Some parts of D design are surely far 
away from some new trends in language design. A lot of experience 
about older ways is both a blessing and a curse :-)


Bye,
bearophile

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

[H. S. Teoh]

On Tue, Oct 16, 2012 at 12:33:20PM -0700, H. S. Teoh wrote:
[...]
> 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?
[...]

I found a reduced case:

import std.algorithm;
import std.range;
import std.stdio;

auto boo() {
auto C = [2];
return
[1,1]
.map!((a) => C)
.joiner
;
}

void main() {
auto C = [2];
writeln(
[1,1]
.map!((a) => C)
.joiner
.take(12));

writeln("");

writeln(boo().take(12));
}

Excuse the odd formatting, I wanted to make sure the [1,1,1].map!(...)
parts are line-for-line identical between boo() and main().

This example segfaults in the last writeln. Commenting out .joiner makes
the segfault go away. Reducing [1,1] to a 1-element array makes the
problem go away. Replacing C with [1] makes the problem go away.
Removing map!(...) and replacing it with something involving C makes the
problem go away. Deleting the .take(12) outputs a whole mass of garbage
values and then segfaults.

So it seems like there is some kind of bad interaction between map and
joiner. Maybe as jethro said, it's wrong code produced by dmd for the
delegate passed to map? It seems to be dependent on the reference to the
local variable C, which seems to imply a corrupted (or just
out-of-scope?) delegate context.


T

-- 
The best way to destroy a cause is to defend it poorly.

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

[Nick Sabalausky]

On Tue, 16 Oct 2012 18:17:10 +0300
Manu  wrote:
> 
> Well, that's obviously crap. What is the approach most people take
> when they want to install their library?

I'm at the point where I don't even bother. I just pass in -I[path] as
needed. It *greatly* simplifies instructions for compiling/installing
stuff. Otherwise the instructions amount to a big convoluted pile of
crap that will essentially be read by the user as "D desperately needs a
fucking package manager, I'm not jumping through these retarded hoops
that are system-specific anyway, I'm going back to Python."