Re: My experience making an on-disk merge sort using ranges

On Wednesday, 27 February 2013 at 07:32:58 UTC, Jonathan M Davis wrote: In a way, all of that power and flexibility is exactly the problem. When dealing with generic code like Phobos does, it's fairly difficult to test it thoroughly enough to make sure that it works with all of the various inpu

Re: My experience making an on-disk merge sort using ranges

On Wednesday, February 27, 2013 08:05:28 Chris Cain wrote: > Thank you too. I was about to write my own range-based solution > to solve this problem and just happened across nWayUnion while I > was looking for useful components. I was close to coding my own > solution (using the heap from std.conta

Re: DIP27 available for destruction

On Wednesday, 27 February 2013 at 06:15:29 UTC, dennis luehring wrote: Am 27.02.2013 06:54, schrieb deadalnix: In current D, the ambiguity is _already_ resolved - if you want to function address, use & operator. D behave very much like C on that regard, so I don't really see how this can be

Re: My experience making an on-disk merge sort using ranges

On Wednesday, 27 February 2013 at 05:23:39 UTC, H. S. Teoh wrote: If only the naysayers knew how cool Phobos will be once we clean it up and polish it into the high-quality product that it should be. It's already showing its coolness right now by being able to do [...] To add on to your ra

Re: My experience making an on-disk merge sort using ranges

On Wednesday, 27 February 2013 at 04:21:41 UTC, Andrei Alexandrescu wrote: In all likelihood these are manifestations of simple bugs. Please submit all cases that should work but are failing (in the same bug report) and we'll get them fixed. It's honestly a bit scary opening my first bug r

Re: D for the JVM

On Tue, 2013-02-26 at 23:00 +0100, OlliP wrote: > I'm quite serious here, no joking ... Make a version of D for the > JVM and it'll be a big success for the language and a business > case at the same time. So many Java developers are meanwhile > really not amused anymore about the slow language

Re: DIP27 available for destruction

Am 27.02.2013 06:54, schrieb deadalnix: In current D, the ambiguity is _already_ resolved - if you want to function address, use & operator. D behave very much like C on that regard, so I don't really see how this can be true. void (*functionPtr)(); //both are valid and working in C functio

Re: DIP27 available for destruction

On Wednesday, February 27, 2013 03:23:04 deadalnix wrote: > On Tuesday, 26 February 2013 at 20:00:26 UTC, Jonathan M Davis > > wrote: > > Wouldn't this fall apart completely with auto or IFTI (implicit > > funtion > > template instantiation)? For instance take > > > > auto foo(T)(T blah) {...} >

Re: DIP27 available for destruction

On Wednesday, 27 February 2013 at 05:34:44 UTC, kenji hara wrote: The mistake in C is mixing of function name and function address. At least there is one ambiguity which appearance and meaning does not correspond one-to-one. That is false. In C, function pointers are done as follow : void fo

Re: DIP27 available for destruction

27-Feb-2013 09:34, kenji hara пишет: 2013/2/27 deadalnix mailto:deadal...@gmail.com>> > > On Wednesday, 27 February 2013 at 03:46:44 UTC, Andrei Alexandrescu wrote: >> >> On 2/26/13 10:33 PM, kenji hara wrote: >>> >>> 2013/2/27 Jonathan M Davis mailto:jmdavisp...@gmx.com> >>>

Re: DIP27 available for destruction

2013/2/27 deadalnix > > On Wednesday, 27 February 2013 at 03:46:44 UTC, Andrei Alexandrescu wrote: >> >> On 2/26/13 10:33 PM, kenji hara wrote: >>> >>> 2013/2/27 Jonathan M Davis >> > >>> >>>I believe that both Walter and Andrei have said on multiple >>>occasion

Re: My experience making an on-disk merge sort using ranges

On Tue, Feb 26, 2013 at 11:21:41PM -0500, Andrei Alexandrescu wrote: > On 2/26/13 10:31 PM, Chris Cain wrote: > >After reading bearophile's post, I realized I neglected to mention I > >was using 2.062. > > > >On Wednesday, 27 February 2013 at 03:16:39 UTC, bearophile wrote: > >> > >>With the latest

Re: DIP27 available for destruction

On Wednesday, 27 February 2013 at 03:46:44 UTC, Andrei Alexandrescu wrote: On 2/26/13 10:33 PM, kenji hara wrote: 2013/2/27 Jonathan M Davis mailto:jmdavisp...@gmx.com>> I believe that both Walter and Andrei have said on multiple occasions that one of C's big mistakes was conflating fu

Re: My experience making an on-disk merge sort using ranges

On 2/26/13 10:31 PM, Chris Cain wrote: After reading bearophile's post, I realized I neglected to mention I was using 2.062. On Wednesday, 27 February 2013 at 03:16:39 UTC, bearophile wrote: With the latest compiler this compiles to me ... Interesting. map!text() compiles but it crashes. It'

Re: DIP27 available for destruction

On 2/26/13 10:33 PM, kenji hara wrote: 2013/2/27 Jonathan M Davis mailto:jmdavisp...@gmx.com>> I believe that both Walter and Andrei have said on multiple occasions that one of C's big mistakes was conflating function names with their addresses, and this DIP appears to be try

Re: My experience making an on-disk merge sort using ranges

After reading bearophile's post, I realized I neglected to mention I was using 2.062. On Wednesday, 27 February 2013 at 03:16:39 UTC, bearophile wrote: With the latest compiler this compiles to me ... Interesting. map!text() compiles but it crashes. It's worth noting that map!text().cached(

Re: DIP27 available for destruction

2013/2/27 Jonathan M Davis > I believe that both Walter and Andrei have said on multiple occasions that > one > of C's big mistakes was conflating function names with their addresses, and > this DIP appears to be trying to do exactly that. And I honestly don't see > what it buys us. It just makes

Re: My experience making an on-disk merge sort using ranges

Chris Cain: import std.stdio, std.file, std.algorithm, std.conv; void main() { dirEntries("data", "*.out", SpanMode.shallow) .map!(e => File(e.name).byLine(KeepTerminator.yes) .map!(l => l.to!string())() )() .array(

Re: D as a prototyping language (for C/C++ projects)

On 2/26/2013 1:26 PM, H. S. Teoh wrote: Having too many ways of stating the same thing makes me wonder if there's some subtle bug lurking somewhere. What if isPresent is not 100% equivalent to !isBlank? And I don't mean just hypothetically; I've seen cases of libraries where bugs cause two suppos

Re: Release planning for 2.063

On Tuesday, 26 February 2013 at 22:39:13 UTC, Andrei Alexandrescu wrote: On 2/26/13 3:09 PM, Jacob Carlborg wrote: On 2013-02-26 18:41, Andrei Alexandrescu wrote: It has happened for the past 2-3 cycles already. Then why is it always such a rush to get form beta to release? So much to do,

Re: DIP27 available for destruction

On Tuesday, 26 February 2013 at 17:09:31 UTC, Dicebot wrote: I like overall approach and think it really should be rule of a thumb for designing D features - defining simple bullet-proof semantics and making conclusions from it. As opposed to syntax-based special case coverage. What I do find

Re: Passing a module in a template parameter list to __traits(allMembers, module)

> >> Use an alias: >> >> string GetMembers(alias T)() { > > > Excellent. An alias parameter is just what I was looking for. Thanks, > everyone! Ben, I present some ideas on this problem in a template tutorial you can find here: https://github.com/PhilippeSigaud/D-templates-tutorial In the pdf,

Re: DIP27 available for destruction

On Tuesday, 26 February 2013 at 23:40:09 UTC, Timon Gehr wrote: The DIP serves as specification for later compiler implementation. If it is not formal enough, the implementation may miss corner cases. One of the goals of the DIP is precisely to avoid corner cases, as they are a pain both fo

Re: DIP27 available for destruction

On Tuesday, 26 February 2013 at 21:01:04 UTC, Timon Gehr wrote: On 02/26/2013 05:16 PM, deadalnix wrote: ... As usual, destroy, I don't expect to get unanimity on that. But I tried very hard to get most benefit of actual situation, including the possibility of optional parentheses in some situ

Re: DIP27 available for destruction

On Tuesday, 26 February 2013 at 21:14:48 UTC, Dicebot wrote: Why? Functions does not have an address according to this DIP. How will you pass a callback to C code then, special case for "extern(C)"? D first class function *ARE* C function pointer already. The concept of taking the function ad

Re: DIP27 available for destruction

On Tuesday, 26 February 2013 at 20:42:57 UTC, Timon Gehr wrote: On 02/26/2013 06:09 PM, Dicebot wrote: I like overall approach and think it really should be rule of a thumb for designing D features - defining simple bullet-proof semantics and making conclusions from it. As opposed to syntax-ba

Re: DIP27 available for destruction

On Tuesday, 26 February 2013 at 20:00:26 UTC, Jonathan M Davis wrote: Wouldn't this fall apart completely with auto or IFTI (implicit funtion template instantiation)? For instance take auto foo(T)(T blah) {...} int func() { return 7; } void bar() { ... foo(func); //Does this call func or pa

Re: DIP27 available for destruction

On Tuesday, 26 February 2013 at 18:52:35 UTC, Dmitry Olshansky wrote: Ouch and I've reviewed an updated version of DIP 26 :) Mh-m OK the warm-up is done, and it was nice to see a refined DIP26. Time to get to the new stuff... I take it DIP27 was modeled after Scala? I think I like it but it

Re: DIP27 available for destruction

On Tuesday, 26 February 2013 at 18:03:43 UTC, Dmitry Olshansky wrote: I like the simplicity and the automatic anti-boilerplate "@property int blah;". That isn't simplicity, that is ease. And @property isn't covered by the DIP.

Re: Are there any default dmd optimizations

On Wed, Feb 27, 2013 at 02:28:44AM +0100, Adam D. Ruppe wrote: > On Wednesday, 27 February 2013 at 01:03:44 UTC, Walter Bright wrote: > >It's not actually a feature of ddoc at all. Ddoc just transmits > >its input to its output, expanding macros along the way. Alas, the real world is not quite tha

My experience making an on-disk merge sort using ranges

Greetings everyone, First, let me apologize that this is quite a long post. I hope that it doesn't scare you off. I wasn't exactly sure where to put this because I have the intention of learning more about D and its overall design as well as to let others know about some various difficulties

Re: Want to help D compiler development: Two possible weekend projects

On 2/26/2013 4:50 PM, Vladimir Panteleev wrote: On Sunday, 3 February 2013 at 00:37:55 UTC, David Nadlinger wrote: 1) Provide an Open Source clean-room implementation of response_expand, the function the DMD frontend uses to parse response files. Unfortunately, it is under the copyright belongs

Re: Want to help D compiler development: Two possible weekend projects

On 2/3/2013 6:52 PM, David Nadlinger wrote: I want to avoid getting in touch with any non-free compiler code as much as possible as Walter generally seems very conscious of licensing issues and I don't want to jeopardize the future of LDC. Having D be IP-clean is essential to the future of D.

Re: 2.062 RRM for Fedora 18 on dlang.org?

On 27-02-2013 02:28, Alex Rønne Petersen wrote: Hi, Wasn't there some effort put into a 2.062 RPM for Fedora 18 recently? Any chance we could get that uploaded to dlang.org? Title should have said "RPM" of course... -- Alex Rønne Petersen a...@alexrp.com / a...@lycus.org http://lycus.org

2.062 RRM for Fedora 18 on dlang.org?

Hi, Wasn't there some effort put into a 2.062 RPM for Fedora 18 recently? Any chance we could get that uploaded to dlang.org? -- Alex Rønne Petersen a...@alexrp.com / a...@lycus.org http://lycus.org

Re: Are there any default dmd optimizations

On Wednesday, 27 February 2013 at 01:03:44 UTC, Walter Bright wrote: It's not actually a feature of ddoc at all. Ddoc just transmits its input to its output, expanding macros along the way. The problem with that is it makes it extremely inconvenient to document a html library, and *impossible*

Re: Want to help D compiler development: Two possible weekend projects

On 2/3/2013 6:31 PM, David Nadlinger wrote: It's not like we realistically have to be afraid of Symantec suing anybody over that piece of code, but ideally Walter would be able to accept that rewritten piece of code back into DMD without having to fear any licensing issues. It's more about doin

Re: Are there any default dmd optimizations

On 2/26/2013 4:08 PM, Adam D. Ruppe wrote: On Tuesday, 26 February 2013 at 23:44:32 UTC, Walter Bright wrote: As Andrei has demonstrated, Ddoc can generate html, pdf, and ebooks without changing the Ddoc comments. This is not true in general because ddoc doesn't properly encode its output for

Re: Want to help D compiler development: Two possible weekend projects

On Sunday, 3 February 2013 at 00:37:55 UTC, David Nadlinger wrote: 1) Provide an Open Source clean-room implementation of response_expand, the function the DMD frontend uses to parse response files. Unfortunately, it is under the copyright belongs (partly?) to Symantec, so Walter can't simply

Re: D for the JVM

On Tue, 26 Feb 2013 14:00:16 -0800, OlliP wrote: I'm quite serious here, no joking ... Make a version of D for the JVM and it'll be a big success for the language and a business case at the same time. So many Java developers are meanwhile really not amused anymore about the slow language d

Re: Are there any default dmd optimizations

On Tuesday, 26 February 2013 at 23:44:32 UTC, Walter Bright wrote: As Andrei has demonstrated, Ddoc can generate html, pdf, and ebooks without changing the Ddoc comments. This is not true in general because ddoc doesn't properly encode its output for different formats (it doesn't even get html

Re: Typesafe variadics in any position

On 2/26/13 5:29 PM, H. S. Teoh wrote: On Tue, Feb 26, 2013 at 05:16:29PM -0500, Steven Schveighoffer wrote: On Tue, 26 Feb 2013 17:04:40 -0500, timotheecour wrote: I proposed this a few weeks ago, but nobody gave feedback. This would enable it without worrying about special cases. http://fo

Re: Are there any default dmd optimizations

On 2/26/13 4:23 PM, foobar wrote: I don't get what fault you find in the binary NOT operation. Regardless, my post wasn't really about specific features, (Walter actually mentioned those) but rather about the general design philosophy of D which I find lacking. Yes, it is obviously true that Rust

Re: D as a prototyping language (for C/C++ projects)

On Tuesday, 26 February 2013 at 15:26:17 UTC, Craig Dillabaugh wrote: I am a novice D programmer and use C++ in my work. One thing I find myself doing when I need to implement some non-trivial algorithm is that I will originally code it in D and perform testing from there to make sure I have the

Re: Are there any default dmd optimizations

On 2/26/2013 2:10 PM, foobar wrote: All of the above describes the benefits of having standardized documentation and I agree with that. That has nothing to do with DDoc's specific design compared to other similar efforts. A quick survey of languages shows that Ruby, Python, Java, C#, and many oth

Re: DIP27 available for destruction

On 02/26/2013 10:14 PM, Dicebot wrote: On Tuesday, 26 February 2013 at 20:42:57 UTC, Timon Gehr wrote: On 02/26/2013 06:09 PM, Dicebot wrote: I like overall approach and think it really should be rule of a thumb for designing D features - defining simple bullet-proof semantics and making conclu

Re: D as a prototyping language (for C/C++ projects)

On 2/26/13 4:01 PM, Jacob Carlborg wrote: On 2013-02-26 20:52, H. S. Teoh wrote: Do you have any specific examples? Return the date from two days ago: Ruby on Rails: 2.days.ago Date.today Time.now The last two return the time right now, how come? Andrei

Re: Are there any default dmd optimizations

On 2/26/13 3:51 PM, foobar wrote: On Tuesday, 26 February 2013 at 10:59:41 UTC, Dicebot wrote: I agree with all but small comment on unit tests : current approach makes it really easy to start adding tests for projects that do not have them and this is huge. So having "unittest" blocks themselve

Re: Typesafe variadics in any position

On Tue, 26 Feb 2013 17:29:10 -0500, H. S. Teoh wrote: On Tue, Feb 26, 2013 at 05:16:29PM -0500, Steven Schveighoffer wrote: On Tue, 26 Feb 2013 17:04:40 -0500, timotheecour wrote: >I proposed this a few weeks ago, but nobody gave feedback. This >would enable it without worrying about speci

Re: The new std.process is ready for review

On 2/26/2013 12:31 AM, Lee Braiden wrote: If it was, and there were unit tests as part of releases (or even commits to master, say), then this problem of RDMD breakage wouldn't happen. That's a different issue. The issue I was talking about was working D code no longer compiling due to librar

Re: Release planning for 2.063

On 2/26/13 3:09 PM, Jacob Carlborg wrote: On 2013-02-26 18:41, Andrei Alexandrescu wrote: It has happened for the past 2-3 cycles already. Then why is it always such a rush to get form beta to release? So much to do, so little time... Andrei

Re: Typesafe variadics in any position

On Tue, Feb 26, 2013 at 05:16:29PM -0500, Steven Schveighoffer wrote: > On Tue, 26 Feb 2013 17:04:40 -0500, timotheecour > wrote: > > >I proposed this a few weeks ago, but nobody gave feedback. This > >would enable it without worrying about special cases. > > > >http://forum.dlang.org/thread/miqt

Re: Typesafe variadics in any position

On Tue, Feb 26, 2013 at 10:38:39PM +0100, Vladimir Panteleev wrote: > On Tuesday, 26 February 2013 at 20:29:51 UTC, Steven Schveighoffer > wrote: > >Having a conversation about the design of the new std.process, I > >lamented that typesafe variadics must be the last element in the > >list of parame

Re: Passing a module in a template parameter list to __traits(allMembers, module)

On Tuesday, 26 February 2013 at 19:07:43 UTC, Andrej Mitrovic wrote: Use an alias: string GetMembers(alias T)() { Excellent. An alias parameter is just what I was looking for. Thanks, everyone! Ben

Re: Typesafe variadics in any position

On Tue, 26 Feb 2013 17:04:40 -0500, timotheecour wrote: I proposed this a few weeks ago, but nobody gave feedback. This would enable it without worrying about special cases. http://forum.dlang.org/thread/miqtvuufvlwgfzble...@forum.dlang.org feature request: special optional argument (__FIL

Re: Are there any default dmd optimizations

On Tuesday, 26 February 2013 at 19:53:11 UTC, Walter Bright wrote: On 2/25/2013 11:56 PM, foobar wrote: DDoc isn't part of the language but rather part of the compiler, nevertheless it has its downsides. [...] unittest is worse, I think you're missing something gigantic. Before D had ddoc,

Re: Typesafe variadics in any position

On Tue, 26 Feb 2013 16:38:39 -0500, Vladimir Panteleev wrote: On Tuesday, 26 February 2013 at 20:29:51 UTC, Steven Schveighoffer wrote: Having a conversation about the design of the new std.process, I lamented that typesafe variadics must be the last element in the list of parameters. C

Re: Are there any default dmd optimizations

On 02/26/2013 04:59 AM, Dicebot wrote: I agree with all but small comment on unit tests : current approach makes it really easy to start adding tests for projects that do not have them and this is huge. So having "unittest" blocks themselves is really a success feature. Tightly coupling handling

Re: Typesafe variadics in any position

I proposed this a few weeks ago, but nobody gave feedback. This would enable it without worrying about special cases. http://forum.dlang.org/thread/miqtvuufvlwgfzble...@forum.dlang.org feature request: special optional argument (__FILE__, ...) AFTER variadic template. Please let me know what

D for the JVM

I'm quite serious here, no joking ... Make a version of D for the JVM and it'll be a big success for the language and a business case at the same time. So many Java developers are meanwhile really not amused anymore about the slow language development of Java. Even C# is ways ahead of Java and

Re: Typesafe variadics in any position

On Tuesday, 26 February 2013 at 20:29:51 UTC, Steven Schveighoffer wrote: Having a conversation about the design of the new std.process, I lamented that typesafe variadics must be the last element in the list of parameters. Could the idea be expanded into allowing optional arguments in front

Re: D as a prototyping language (for C/C++ projects)

On Tue, Feb 26, 2013 at 10:01:59PM +0100, Jacob Carlborg wrote: [.[..] > Return the date from two days ago: > > Ruby on Rails: > 2.days.ago > Date.today > Time.now > > D: > Clock.currTime - 2.days > // Not sure how to do the other two in D > > This is not that bad but it's a bit less intuitive.

Re: Are there any default dmd optimizations

On Tuesday, 26 February 2013 at 18:41:24 UTC, Andrej Mitrovic wrote: On 2/26/13, foobar wrote: Rust on the other hand already integrated an ownership system and is already far ahead of D's design. Far ahead? It allows things like local variables shadowing earlier declarations: let monster_

Re: D as a prototyping language (for C/C++ projects)

On Tuesday, 26 February 2013 at 21:10:30 UTC, Ary Borenszweig wrote: On 2/26/13 6:01 PM, Jacob Carlborg wrote: On 2013-02-26 20:52, H. S. Teoh wrote: Do you have any specific examples? Return the date from two days ago: Ruby on Rails: 2.days.ago Date.today Time.now D: Clock.currTime - 2.da

Re: D as a prototyping language (for C/C++ projects)

On 2/26/13 6:01 PM, Jacob Carlborg wrote: On 2013-02-26 20:52, H. S. Teoh wrote: Do you have any specific examples? Return the date from two days ago: Ruby on Rails: 2.days.ago Date.today Time.now D: Clock.currTime - 2.days // Not sure how to do the other two in D This is not that bad but

Re: DIP27 available for destruction

On Tuesday, 26 February 2013 at 20:42:57 UTC, Timon Gehr wrote: On 02/26/2013 06:09 PM, Dicebot wrote: I like overall approach and think it really should be rule of a thumb for designing D features - defining simple bullet-proof semantics and making conclusions from it. As opposed to syntax-ba

Re: Typesafe variadics in any position

On Tue, Feb 26, 2013 at 09:59:22PM +0100, simendsjo wrote: > On Tuesday, 26 February 2013 at 20:52:46 UTC, Steven Schveighoffer > wrote: > >On Tue, 26 Feb 2013 15:36:11 -0500, Andrej Mitrovic > > wrote: > > > >>On Tuesday, 26 February 2013 at 20:29:51 UTC, Steven > >>Schveighoffer wrote: [...] > >>

Re: D as a prototyping language (for C/C++ projects)

On 2013-02-26 20:52, H. S. Teoh wrote: Do you have any specific examples? Return the date from two days ago: Ruby on Rails: 2.days.ago Date.today Time.now D: Clock.currTime - 2.days // Not sure how to do the other two in D This is not that bad but it's a bit less intuitive. Here we also hav

Re: D as a prototyping language (for C/C++ projects)

On 2013-02-26 20:52, H. S. Teoh wrote: Do you have any specific examples? Some more: isBlank and the opposite isPresent. These exists in Ruby on Rails, this is my D version: https://github.com/jacob-carlborg/mambo/blob/master/mambo/core/core.d -- /Jacob Carlborg

Re: DIP27 available for destruction

On 02/26/2013 05:16 PM, deadalnix wrote: ... As usual, destroy, I don't expect to get unanimity on that. But I tried very hard to get most benefit of actual situation, including the possibility of optional parentheses in some situations (even if I'm not the biggest fan of it, I recognize that the

Re: Typesafe variadics in any position

On Tuesday, 26 February 2013 at 20:52:46 UTC, Steven Schveighoffer wrote: On Tue, 26 Feb 2013 15:36:11 -0500, Andrej Mitrovic wrote: On Tuesday, 26 February 2013 at 20:29:51 UTC, Steven Schveighoffer wrote: Would it be something people want? Yes. Also related: http://d.puremagic.com/issue

Re: Are there any default dmd optimizations

On Tuesday, 26 February 2013 at 10:59:41 UTC, Dicebot wrote: I agree with all but small comment on unit tests : current approach makes it really easy to start adding tests for projects that do not have them and this is huge. So having "unittest" blocks themselves is really a success feature. T

Re: Typesafe variadics in any position

On Tue, 26 Feb 2013 15:36:11 -0500, Andrej Mitrovic wrote: On Tuesday, 26 February 2013 at 20:29:51 UTC, Steven Schveighoffer wrote: Would it be something people want? Yes. Also related: http://d.puremagic.com/issues/show_bug.cgi?id=8687 One extremely common and important use-case of allo

Re: Are there any default dmd optimizations

On Tue, Feb 26, 2013 at 09:41:09PM +0100, Andrej Mitrovic wrote: > On 2/26/13, H. S. Teoh wrote: > > Most just have outdated comments (if at all!) > > Some projects even maintain documentation *separately* from the > codebase, which leads to a ton of outdated stuff. For example look at > the list

Re: DIP27 available for destruction

On 02/26/2013 06:09 PM, Dicebot wrote: I like overall approach and think it really should be rule of a thumb for designing D features - defining simple bullet-proof semantics and making conclusions from it. As opposed to syntax-based special case coverage. ... Like it or not, that is what a com

Re: Typesafe variadics in any position

On Tue, Feb 26, 2013 at 03:29:51PM -0500, Steven Schveighoffer wrote: > Having a conversation about the design of the new std.process, I > lamented that typesafe variadics must be the last element in the > list of parameters. [...] > But why? This seems perfectly plausible to me: > > spawnProcess

Re: Typesafe variadics in any position

On Tuesday, 26 February 2013 at 20:29:51 UTC, Steven Schveighoffer wrote: Would it be something people want? Yes. Also related: http://d.puremagic.com/issues/show_bug.cgi?id=8687 One extremely common and important use-case of allowing it is this: foo(string[] args..., string file = __FILE

Re: DIP27 available for destruction

On 02/26/2013 09:00 PM, Jonathan M Davis wrote: ... auto foo(T)(T blah) {...} int func() { return 7; } void bar() { ... foo(func); //Does this call func or pass its address? auto f = func; //Does this call func or take its address? ... } ... Neither.

Re: The new std.process is ready for review

On Tue, Feb 26, 2013 at 09:07:06PM +0100, Jacob Carlborg wrote: > On 2013-02-26 17:45, Steven Schveighoffer wrote: > > >without extra allocation. However, we have two conflicting parts to > >spawnProcess that would be optional -- the variadic arg list, and the > >optional redirected handles and c

Typesafe variadics in any position

Having a conversation about the design of the new std.process, I lamented that typesafe variadics must be the last element in the list of parameters. But I would love to have a version that simply takes parameters as parameters. In Tango's process class, it was a nice feature. Stuff like

Re: Are there any default dmd optimizations

On Tue, Feb 26, 2013 at 11:53:11AM -0800, Walter Bright wrote: > On 2/25/2013 11:56 PM, foobar wrote: > >DDoc isn't part of the language but rather part of the compiler, > >nevertheless it has its downsides. [...] > >unittest is worse, > > I think you're missing something gigantic. Before D had d

Re: Passing a module in a template parameter list to __traits(allMembers, module)

On 2013-02-26 20:29, Andrej Mitrovic wrote: Well it's definitely an edge-case we'll have to be careful about. :) I don't know why packages can be passed as an alias. Do we have any defined behavior for using packages and traits? What the original post is doing, getting all its members? -- /J

Re: New std.uni: ready for more beating

On Tuesday, February 26, 2013 20:34:13 Jacob Carlborg wrote: > On 2013-02-26 17:51, Dmitry Olshansky wrote: > > Let's not go there. And uni is not obsession at all. POSIX 'O_CREAT' is. > > The obsession is that there's quite a lot of shortened names in D. Really? There are a few (particularly old

Re: The new std.process is ready for review

On 2013-02-26 17:45, Steven Schveighoffer wrote: without extra allocation. However, we have two conflicting parts to spawnProcess that would be optional -- the variadic arg list, and the optional redirected handles and configuration. We could just go full-bore variadic... I'm thinking named

Re: Release planning for 2.063

On 2013-02-26 18:41, Andrei Alexandrescu wrote: It has happened for the past 2-3 cycles already. Then why is it always such a rush to get form beta to release? -- /Jacob Carlborg

Re: The new std.process is ready for review

On Tue, 26 Feb 2013 14:33:14 -0500, Lars T. Kyllingstad wrote: On Tuesday, 26 February 2013 at 18:24:08 UTC, Steven Schveighoffer wrote: That's not how it works. The expression [] allocates. Isn't that just a shortcoming of DMD? I thought 'scope' was all about avoiding such allocations

Re: Are there any default dmd optimizations

On Tuesday, February 26, 2013 11:53:11 Walter Bright wrote: > On 2/25/2013 11:56 PM, foobar wrote: > > DDoc isn't part of the language but rather part of the compiler, > > nevertheless it has its downsides. [...] > > unittest is worse, > > I think you're missing something gigantic. [SNIP] I agree

Re: Release planning for 2.063

On Tue, 2013-02-26 at 13:36 -0500, Nick Sabalausky wrote: […] > *cough* DVM 1. I had forgotten about that :-( 2. Doesn't it only support DMD? 3. In moving from BitBucket to Git, support for 64-bit Linux appears to have been dropped. :-((( 4. Jordi's Debian repository is working well fo

Re: DIP27 available for destruction

On Tuesday, February 26, 2013 17:16:37 deadalnix wrote: > Carmack said : « I will always take an aggressively simple > approach to things » and so I did, as I love cargo cult. > > More seriously, I face the need of more simplicity into D quite > often, as the feature matrix is quite heavy. > > So

Re: The new std.process is ready for review

On 2013-02-26 15:50, Steven Schveighoffer wrote: Except there are non-string arguments at the end, stdin/stdout/stderr/config Wow, that was a couple of extra parameters. Didn't actually look before. -- /Jacob Carlborg

Re: Are there any default dmd optimizations

On 2/25/2013 11:56 PM, foobar wrote: DDoc isn't part of the language but rather part of the compiler, nevertheless it has its downsides. [...] unittest is worse, I think you're missing something gigantic. Before D had ddoc, the documentation for Phobos was TERRIBLE - it was mostly missing, an

Re: D as a prototyping language (for C/C++ projects)

On Tue, Feb 26, 2013 at 08:49:12PM +0100, Jacob Carlborg wrote: > On 2013-02-26 18:45, Andrei Alexandrescu wrote: > > >These are great data points. We should figure how to improve D to > >lessen the barriers in both directions. > > It helps by having convenient functions in the standard library.

Re: The new std.process is ready for review

On Tuesday, February 26, 2013 20:33:14 Lars T. Kyllingstad wrote: > On Tuesday, 26 February 2013 at 18:24:08 UTC, Steven > > Schveighoffer wrote: > > On Tue, 26 Feb 2013 12:03:51 -0500, Lars T. Kyllingstad > > > > wrote: > >> On Tuesday, 26 February 2013 at 16:45:08 UTC, Steven > >> > >> Schvei

Re: D as a prototyping language (for C/C++ projects)

On 2013-02-26 18:45, Andrei Alexandrescu wrote: These are great data points. We should figure how to improve D to lessen the barriers in both directions. It helps by having convenient functions in the standard library. It also helps with not having to import a lot of modules just to get somet

Re: The new std.process is ready for review

On Tuesday, 26 February 2013 at 18:24:08 UTC, Steven Schveighoffer wrote: On Tue, 26 Feb 2013 12:03:51 -0500, Lars T. Kyllingstad wrote: On Tuesday, 26 February 2013 at 16:45:08 UTC, Steven Schveighoffer wrote: On Tue, 26 Feb 2013 11:09:48 -0500, Lars T. Kyllingstad wrote: spawnProcess([

Re: New std.uni: ready for more beating

On 2013-02-26 17:51, Dmitry Olshansky wrote: Let's not go there. And uni is not obsession at all. POSIX 'O_CREAT' is. The obsession is that there's quite a lot of shortened names in D. -- /Jacob Carlborg

Re: Passing a module in a template parameter list to __traits(allMembers, module)

On 2/26/13, H. S. Teoh wrote: > I think it's a problem with the precedence of the binary ! operator. Well it's definitely an edge-case we'll have to be careful about. :) I don't know why packages can be passed as an alias. Do we have any defined behavior for using packages and traits?

Re: Passing a module in a template parameter list to __traits(allMembers, module)

On 02/26/2013 11:03 AM, Ben Gertzfield wrote: Hi folks, In preparation for my upcoming talk at DConf 2013, I'm working on a compile-time dependency injection prototype for D. I'd like part of public interface for this system to take a module at compile time, and return a list of the classes in

Re: DIP27 available for destruction

On Tuesday, 26 February 2013 at 18:52:35 UTC, Dmitry Olshansky wrote: I take it DIP27 was modeled after Scala? As far as I see it - better than Scala, as it uses real first-class function types, not just decorated classes. Wonder how it will interact with other paradigms though.

Re: Passing a module in a template parameter list to __traits(allMembers, module)

On Tue, Feb 26, 2013 at 08:07:42PM +0100, Andrej Mitrovic wrote: [...] > Also make sure you parenthesize the call in GetMembers. For some > reason these two are different: > > GetMembers!std.stdio // actually calls (GetMembers!std).stdio > GetMembers!(std.stdio) > > That could be a bug though.

  1   2   >