Re: Reducing template constraint verbosity? [was Re: Slides from my ACCU Silicon Valley talk]

[Patrick Down]

== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
Would it help to allow 'else' and 'else if' on the template constraints?

void foo(R)(R r) if(isRandomAccessRange!R)
{...}
else if(isInputRange!R)
{...}

This could basically be translated into two specializations like this:

void foo(R)(R r) if(isRandomAccessRange!R) {...}
void foo(R)(R r) if(isInputRange!R && !isRandomAccessRange!R) {...}

Re: Game development is worthless? WTF? (Was: Why Ruby?)

[Patrick Down]

bearophile Wrote:
> Yet I hope Walter will not waste 6 hours every day *playing* World of 
> warcraft :-)

He does however write games sometimes: http://www.classicempire.com/

Re: The Right Approach to Exceptions

[Patrick Down]

Andrei Alexandrescu Wrote:

> On 2/18/12 4:26 PM, Jonathan M Davis wrote (abridged):
> GetOptException
> FlagArgumentMissingException
> InvalidFlagArgumentException
> UnknownFlagException
> FileException
> FileNotFoundException
> NotFileException
> NotDirException
> AccessDeniedException
> 
> I died inside a little.
> 
> Andrei
> 

As a lurker watching this debate with interest I just had an idea out of the 
blue idea that may or may not have value but might reduce the desire to create 
a new exception type Exception type for every error. 

What if the catch syntax was extended to take both a type and a condition.  

try {
  write(filename, ...);
}
catch(FileException e; e.errno == EEXIST) {
}
catch(FileException e; e.errno == EROFS) {
}

I realize that this is just syntactic sugar for catch(...) { if(...) {}} feel 
free to shoot it down.

Re: Three Unlikely Successful Features of D

[Patrick Down]

On Wednesday, 21 March 2012 at 02:47:20 UTC, Walter Bright wrote:
Andrei discovered an amazing use of auto. It enables you to 
create variables with voldemort types "that may not be named".


+1 LOL for Voldemort types

DMD on OSX Lion

[Patrick Down]

The package on the download page warns that "This package is 
intended for Mac OS X Leopard (10.5) only."  Is this one safe to 
use on Lion?  Is executable in the "all platforms" zip file 
better or do I need to build it from source?

Re: DMD on OSX Lion

[Patrick Down]

On Monday, 28 May 2012 at 15:44:37 UTC, Sean Kelly wrote:
On May 28, 2012, at 8:36 AM, "Patrick Down" 
 wrote:




The package on the download page warns that "This package is 
intended for Mac OS X Leopard (10.5) only."  Is this one safe 
to use on Lion?  Is executable in the "all platforms" zip file 
better or do I need to build it from source?


The binary works just fine on Lion.


Thanks

Re: D on ARM

[Patrick Down]

Andrew Wiley Wrote:

> So it seems that ARM is going to be getting quite a bit bigger in the
> future, between the rise of smarter phones and Windows 8 support, and in
> general D just doesn't exist on ARM.

I second this.  I've followed D for a while but most of my development has 
moved to mobile ARM platforms.   

Re: D on next-gen consoles and for game development

[Patrick Down]

On Saturday, 25 May 2013 at 05:29:31 UTC, deadalnix wrote:

This is technically possible, but you said you make few 
allocations. So with the tax on pointer write or the reference 
counting, you'll pay a lot to collect very few garbages. I'm 
not sure the tradeoff is worthwhile.




Incidentally, I ran across this paper that talks about a 
reference counted garbage collector that claims to address this 
issue.  MIght be of interest to this group.


http://researcher.watson.ibm.com/researcher/files/us-bacon/Bacon03Pure.pdf

From the paper:

There are two primary problems with reference counting, namely:
(1) run-time overhead of incrementing and decrementing the 
reference count each time a

pointer is copied, particularly on the stack; and
(2) inability to detect cycles and consequent necessity of 
including a second garbage collection technique to deal with 
cyclic garbage.
In this paper we present new algorithms that address these 
problems and describe a
new multiprocessor garbage collector based on these techniques 
that achieves maximum
measured pause times of 2.6 milliseconds over a set of eleven 
benchmark programs that

perform significant amounts of memory allocation.

Re: phobos dependencies

[Patrick Down]

On Friday, 20 December 2013 at 17:40:08 UTC, H. S. Teoh wrote:
in the current import path, then implicitly try to import x.y 
and lookup

z in that module. Then you could just write:

void f(T)(T t) if (std.range.isInputRange!T) ...

and the compiler will automatically import std.range within 
that scope.


How about:

scope import std.range;
// lazy import std.range; ?

void f(T)(T t) if (std.range.isInputRange!T) ...