Re: D seems interesting, but...

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

Re: D interface for C library problems

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 simpl

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

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 wi

Re: D seems interesting, but...

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

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 mentione

Re: 48 hour game jam

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 thos

Re: Import improvement

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 p

Re: Import improvement

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

Re: 48 hour game jam

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

Re: Account on ARM/Debian

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

Re: alias A = B; syntax

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)

Re: Account on ARM/Debian

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

Re: D seems interesting, but...

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

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,

Re: More D & Rust

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

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

Re: Account on ARM/Debian

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 underp

Re: D seems interesting, but...

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

Re: alias A = B; syntax

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; // wha

Re: alias A = B; syntax

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

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

Re: 48 hour game jam

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

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? I presume then the probability becomes lower (but I don't have statistics to support this opinion.) Bye, bearophile

Re: Import improvement

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 tha

Re: Account on ARM/Debian

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 te

Re: alias A = B; syntax

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!

Re: Import improvement

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 spec

Re: 48 hour game jam

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"

Re: Import improvement

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.*" o

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

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 pop

Re: 48 hour game jam

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

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

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

make install; where do .di files go?

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?

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/]i

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

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 import

Re: Account on ARM/Debian

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.

Re: Import improvement

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

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

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 goi

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

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

Re: alias A = B; syntax

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

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

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

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

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 deep

Re: 48 hour game jam

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

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

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

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

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

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

Re: 48 hour game jam

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/o

Re: Account on ARM/Debian

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

Re: alias A = B; syntax

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

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

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 fr

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

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

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

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

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

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 reaso

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

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

Re: alias A = B; syntax

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

Re: 48 hour game jam

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

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

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$PR

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

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

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?

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

Re: alias A = B; syntax

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

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

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

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

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 n

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

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 sub

Re: 48 hour game jam

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

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

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

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 tha

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

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

Re: 48 hour game jam

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

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

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 mad

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

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 though

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

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 in

Re: 48 hour game jam

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

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

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 r

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

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, w

Re: Import improvement

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

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

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

Re: alias A = B; syntax

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, th

Re: alias A = B; syntax

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

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 aft

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

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], an

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

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

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

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 m

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

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

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

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 i

Re: Tricky semantics of ranges & potentially numerous Phobos bugs

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

Re: More D & Rust

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

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 t

Re: 48 hour game jam

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

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

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

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

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

Re: Strange Loop 2012

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 typ

Re: More D & Rust

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 someti

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

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 p

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

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 co

Re: 48 hour game jam

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 (som

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

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:

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

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/insta

  1   2   >