Re: another d demoscene entry

2009-10-18 Thread #ponce
Same for me. It just crashes while loading. The debug version is more informative. It says: Error: CompileError : Cannot compile data/shaders/glow.fs LOG : (1) : error C5018: length of constructed vectors cannot exceed 4 These three lines are not in log.txt, but everything else is.

Re: Revamping associative arrays

2009-10-18 Thread bearophile
Andrei Alexandrescu: I like how you leave no stone unturned. Regardless of what the final quality of the D2 language will be, I will always think you have done your best to improve it. I will say so to the people I know too. I have already discussed about D AAs in the past, but I guess it was

Re: Communicating between in and out contracts

2009-10-18 Thread Rainer Deyke
Andrei Alexandrescu wrote: Rainer Deyke wrote: The expression may mutate stuff. It shouldn't. It's an error if it does, just like it's an error for an assertion or post/precondition to have any side effects. It would be nice if the compiler could catch this error, but failing that, 'old'

Re: Revamping associative arrays

2009-10-18 Thread Walter Bright
language_fan wrote: It would be great if the underlying implementation could be switched based on the task at hand. The AAs could be completely library provided, with only a small built-in syntactical sugaring on top of it. They already are. In D1, the complete implementation is in

Re: Revamping associative arrays

2009-10-18 Thread Max Samukha
On Sat, 17 Oct 2009 22:47:21 +0200, grauzone n...@example.net wrote: Max Samukha wrote: On Sat, 17 Oct 2009 13:28:51 -0500, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Associative arrays are today quite problematic because they don't offer any true iteration. Furthermore, the

Re: Revamping associative arrays

2009-10-18 Thread bearophile
Walter Bright: You can iterate over both keys and values with: foreach (key, value; aa) I know this, of course, but you are missing the point by a mile. An explicit foreach is not the only way you may want to iterate an AA on. If I have a higher order function like map, I must be able

Re: Revamping associative arrays

2009-10-18 Thread bearophile
Max Samukha: I agree. But the problem is the lack of a decent way to instantiate an empty AA. Now you either have to do idiotic things like: int[int] a; a[1] = 1; a.remove(1); Or wrap the array in another type. This is an empty AA, you need nothing else: int[int] a; In my post I have

Re: Revamping associative arrays

2009-10-18 Thread bearophile
bearophile: That you can use for example like this, to give an empty AA to a foo() function: foo(AA!(int, float)); I have just found that you can also use null there. It's less explicit because if you take a look at the call site only, you don't know that the receiver will need an AA.

Re: Revamping associative arrays

2009-10-18 Thread Piotrek
bearophile Wrote: I'd really like the default iteration on an AA to yield its keys, instead of values as currently done. Because if I have a key I can find its value, while the opposite is not possible, so having keys is much more useful. This is true in Python too. In my dlibs all

Re: dmd support for IDEs and the D tool chain

2009-10-18 Thread Walter Bright
Eric Suen wrote: Because of many programming language is not design for speed, there is no point to write a compiler in there native language. Even Java's compiler is writtern in Java, why not D? Compiler bootstrapping is very basic technique, Doing this would make it more difficult than

Re: Revamping associative arrays

2009-10-18 Thread Max Samukha
On Sun, 18 Oct 2009 04:29:57 -0400, bearophile bearophileh...@lycos.com wrote: Max Samukha: I agree. But the problem is the lack of a decent way to instantiate an empty AA. Now you either have to do idiotic things like: int[int] a; a[1] = 1; a.remove(1); Or wrap the array in another

execute file size is much big from dmd1041.

2009-10-18 Thread dwt_test
I use bud build the dwt.lib. then use dmd -L+dwt.lib build the execute file. it is much fast then other ways. the problem is , the execute file size is become very big since dmd 1.41 . I try dwt-win and dwt Shawn Liu , the execute file size is both grow big. I try dmd 1.035 to dmd 1.041,

Re: 64-bit

2009-10-18 Thread language_fan
Sat, 17 Oct 2009 22:56:44 -0400, Just Visiting thusly wrote: I won't deny that for certain people 32-bit systems are still perfectly useful. Just my clients do not share this view for a series of good reasons. Even their older systems tend to be 64-bit nowadays. Migration towards 64-bit OSes

Re: Revamping associative arrays

2009-10-18 Thread Andrei Alexandrescu
bearophile wrote: Andrei Alexandrescu: I like how you leave no stone unturned. Regardless of what the final quality of the D2 language will be, I will always think you have done your best to improve it. I will say so to the people I know too. Well it should be said Walter is doing his best

Error: long has no effect in expression (0)

2009-10-18 Thread dwt_test
I use dmd 1.049 , dmd 1.050, dmd r215 to build dwt-win static lib. dmd @AllFiles.txt -d -ofdwt.lib -lib -op -JE:\dmd\gui\res there is a error throw out by dmd: internal\ole\win32\COM.d(378): Error: long has no effect in expression (0) it repeat 5 times. the problem is , the line content is

Re: execute file size is much big from dmd1041.

2009-10-18 Thread dwt_test
dwt_test дµ½: I use bud build the dwt.lib. then use dmd -L+dwt.lib build the execute file. it is much fast then other ways. the problem is , the execute file size is become very big since dmd 1.41 . I try dwt-win and dwt Shawn Liu , the execute file size is both grow big. I try dmd

Re: Revamping associative arrays

2009-10-18 Thread bearophile
Piotrek: No! No! No! Maybe you are wrong. Life is complex so I am usually wrong, because it's hard to consider all sides of a thing, but sometimes other people are even more wrong :-) I remember that I spent many hours on finding bug in python's script written by me in my job. The reason was

Re: 64-bit

2009-10-18 Thread Fawzi Mohamed
On 2009-10-18 11:32:07 +0200, language_fan f...@bar.com.invalid said: Sat, 17 Oct 2009 22:56:44 -0400, Just Visiting thusly wrote: I won't deny that for certain people 32-bit systems are still perfectly useful. Just my clients do not share this view for a series of good reasons. Even their

Re: Revamping associative arrays

2009-10-18 Thread Sergey Gromov
Sun, 18 Oct 2009 06:18:34 -0400, bearophile wrote: Then I couldn't understand why the hell iterating on collection returns a key in the first place. It's so not intuitive. What's intuitive on iterating on values? Well, I think Walter agrees with you, I remember his explanation (iterating on

Re: Revamping associative arrays

2009-10-18 Thread bearophile
Andrei Alexandrescu: I'm not sure whether much or any of this is attainable within D2. The things I've written about aren't all equally important and they don't require the same amount of work to be implemented. I am sorry for writing that gazpacho. There are two things that I think are more

Re: 64-bit

2009-10-18 Thread language_fan
Sun, 18 Oct 2009 16:35:53 +0200, Fawzi Mohamed thusly wrote: On 2009-10-18 11:32:07 +0200, language_fan f...@bar.com.invalid said: Sat, 17 Oct 2009 22:56:44 -0400, Just Visiting thusly wrote: I won't deny that for certain people 32-bit systems are still perfectly useful. Just my clients

Re: Revamping associative arrays

2009-10-18 Thread Bill Baxter
On Sun, Oct 18, 2009 at 10:56 AM, bearophile bearophileh...@lycos.com wrote: The opEquals among AAs requires probably less than 20 lines of code. Two persons (plus Walter, of course) have said they don't like to iterate on the keys first. The other people have kept muzzle shut so I can't tell

Re: DFL IDE Editor ?

2009-10-18 Thread dolive
Robert Jacques дµ½: On Thu, 24 Sep 2009 16:31:56 -0400, dolive doliv...@sina.com wrote: Robert Jacques дµ½: On Thu, 24 Sep 2009 14:21:55 -0400, dolive doliv...@sina.com wrote: Robert Jacques Ã�´µÂÂ#65533; On Thu, 24 Sep 2009 06:22:57 -0400, dolive89

Re: Revamping associative arrays

2009-10-18 Thread Piotrek
bearophile pisze: Piotrek: No! No! No! Maybe you are wrong. Life is complex so I am usually wrong, because it's hard to consider all sides of a thing, but sometimes other people are even more wrong :-) I didn't mean to be offensive. All people (including me) have tendency to claim that

Re: Revamping associative arrays

2009-10-18 Thread Andrei Alexandrescu
bearophile wrote: Andrei Alexandrescu: I'm not sure whether much or any of this is attainable within D2. The things I've written about aren't all equally important and they don't require the same amount of work to be implemented. I am sorry for writing that gazpacho. There are two things

Re: Revamping associative arrays

2009-10-18 Thread Piotrek
Bill Baxter pisze: I think the default should be to iterate over whatever 'in' looks at. I was almost convinced, because that rule has a sense. But treating normal arrays and associative array has more sense to me. fun (SomeObject object) { foreach (element;object.arr1){ //normal, but how

Re: Revamping associative arrays

2009-10-18 Thread Bill Baxter
On Sun, Oct 18, 2009 at 1:12 PM, Piotrek star...@tlen.pl wrote: Bill Baxter pisze: I think the default should be to iterate over whatever 'in' looks at. I was almost convinced, because that rule has a sense. But treating normal arrays and associative array has more sense to me. fun

Re: 64-bit

2009-10-18 Thread Stanley Steel
Why I mentioned desktop applications is that currently the trend has been to replace old 32-bit intel/amd processors in desktop use. And most desktop apps are written in systems programming languages. You can hardly buy any non-64-bit capable processor from any pc store these days. The people are

Re: 64-bit

2009-10-18 Thread language_fan
Sun, 18 Oct 2009 14:45:39 -0600, Stanley Steel thusly wrote: Why I mentioned desktop applications is that currently the trend has been to replace old 32-bit intel/amd processors in desktop use. And most desktop apps are written in systems programming languages. You can hardly buy any

The demise of T[new]

2009-10-18 Thread Walter Bright
The purpose of T[new] was to solve the problems T[] had with passing T[] to a function and then the function resizes the T[]. What happens with the original? The solution we came up with was to create a third array type, T[new], which was a reference type. Andrei had the idea that T[new]

Re: The demise of T[new]

2009-10-18 Thread bearophile
Walter Bright: Andrei had the idea that T[new] could be dispensed with by making a builder library type to handle creating arrays by doing things like appending, and then delivering a finished T[] type. This is similar to what std.outbuffer and std.array.Appender do, they just need a bit

Re: Revamping associative arrays

2009-10-18 Thread grauzone
Piotrek wrote: bearophile Wrote: I'd really like the default iteration on an AA to yield its keys, instead of values as currently done. Because if I have a key I can find its value, while the opposite is not possible, so having keys is much more useful. This is true in Python too. In my

Re: Revamping associative arrays

2009-10-18 Thread bearophile
Bill Baxter: It shouldn't be harder to port D1 code to D2 than C code! In the world for every line of D1 code you may want to port to D2, there are probably 100 or 1000+ lines of C code that you may want to port to D2, so the situation is not the same. Keeping compatibility with C is far more

Re: The demise of T[new]

2009-10-18 Thread Denis Koroskin
On Mon, 19 Oct 2009 01:05:39 +0400, Walter Bright newshou...@digitalmars.com wrote: The purpose of T[new] was to solve the problems T[] had with passing T[] to a function and then the function resizes the T[]. What happens with the original? The solution we came up with was to create a

Re: Revamping associative arrays

2009-10-18 Thread Denis Koroskin
On Mon, 19 Oct 2009 01:37:36 +0400, bearophile bearophileh...@lycos.com wrote: Bill Baxter: It shouldn't be harder to port D1 code to D2 than C code! In the world for every line of D1 code you may want to port to D2, there are probably 100 or 1000+ lines of C code that you may want to

Re: Revamping associative arrays

2009-10-18 Thread bearophile
grauzone: In a perfect world, iterating over an AA would yield a tuple (key, value). You could iterate over either the keys or values by iterating over a view on the key or value list. I'm surprised Python doesn't do that. I don't know why Python has originally chosen to iterate on just

Re: The demise of T[new]

2009-10-18 Thread grauzone
Walter Bright wrote: We both feel that this would simplify D, make it more flexible, and remove some awkward corner cases like the inability to say a.length++. How would this remove this corner case? What do you think? Whether T[new] is bultin (mostly implemented in the runtime), or a

Re: The demise of T[new]

2009-10-18 Thread Andrei Alexandrescu
grauzone wrote: Walter Bright wrote: We both feel that this would simplify D, make it more flexible, and remove some awkward corner cases like the inability to say a.length++. How would this remove this corner case? Can't increment length if it's read-only. Andrei

Re: Revamping associative arrays

2009-10-18 Thread bearophile
Denis Koroskin: Why would you want to port C code to D, if you can easily interface with it? First of all you have to consider programmer experience, they know C, so keeping the language backwards compatible with C helps them avoid bugs and learn D faster. If you ignore what programmers know,

Re: The demise of T[new]

2009-10-18 Thread Denis Koroskin
On Mon, 19 Oct 2009 01:55:28 +0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Denis Koroskin wrote: On Mon, 19 Oct 2009 01:05:39 +0400, Walter Bright newshou...@digitalmars.com wrote: The purpose of T[new] was to solve the problems T[] had with passing T[] to a function

Re: The demise of T[new]

2009-10-18 Thread dsimcha
== Quote from Walter Bright (newshou...@digitalmars.com)'s article The purpose of T[new] was to solve the problems T[] had with passing T[] to a function and then the function resizes the T[]. What happens with the original? The solution we came up with was to create a third array type,

Re: Revamping associative arrays

2009-10-18 Thread Piotrek
Bill Baxter pisze: On Sun, Oct 18, 2009 at 1:12 PM, Piotrek star...@tlen.pl wrote: Bill Baxter pisze: I think the default should be to iterate over whatever 'in' looks at. I was almost convinced, because that rule has a sense. But treating normal arrays and associative array has more sense

Re: Revamping associative arrays

2009-10-18 Thread Christopher Wright
Moritz Warning wrote: On Sat, 17 Oct 2009 18:58:08 +, BCS wrote: what will this do? foreach(key; aa.keys) if(Test(key)) aa.remove(key); It's undefined behavior. You shouldn't try to mutate the aa while iterating. I hope that will be fixed. It took me some time to find this out.

Re: Revamping associative arrays

2009-10-18 Thread Bill Baxter
On Sun, Oct 18, 2009 at 3:28 PM, Piotrek star...@tlen.pl wrote: Bill Baxter pisze: On Sun, Oct 18, 2009 at 1:12 PM, Piotrek star...@tlen.pl wrote: Bill Baxter pisze: I think the default should be to iterate over whatever 'in' looks at. I was almost convinced, because that rule has a

Re: Revamping associative arrays

2009-10-18 Thread Christopher Wright
Piotrek wrote: bearophile Wrote: I'd really like the default iteration on an AA to yield its keys, instead of values as currently done. Because if I have a key I can find its value, while the opposite is not possible, so having keys is much more useful. This is true in Python too. In my

Re: The demise of T[new]

2009-10-18 Thread Andrei Alexandrescu
dsimcha wrote: Here's my proposal for how T[new] should work: 1. It should be a reference type to be consistent with slices. Yes, slices are kind of a hybrid, but they're more semantically similar to reference types than value types. If you can't modify the length of a slice anymore, then

Re: The demise of T[new]

2009-10-18 Thread dsimcha
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article 3. A T[new] should be implicitly convertible to a slice. For example: auto foo = someFunctionThatReturnsTnew(); // foo is a T[new]. T[] bar = someFunctionThatReturnsTnew(); // Works. bar is a T[]. The

Re: The demise of T[new]

2009-10-18 Thread Andrei Alexandrescu
dsimcha wrote: == Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article 3. A T[new] should be implicitly convertible to a slice. For example: auto foo = someFunctionThatReturnsTnew(); // foo is a T[new]. T[] bar = someFunctionThatReturnsTnew(); // Works. bar is a T[].

Re: DFL IDE Editor ?

2009-10-18 Thread Robert Jacques
On Sun, 18 Oct 2009 15:19:28 -0400, dolive doliv...@sina.com wrote: Robert Jacques дµ½: On Thu, 24 Sep 2009 16:31:56 -0400, dolive doliv...@sina.com wrote: Robert Jacques Ã�´µ½: On Thu, 24 Sep 2009 14:21:55 -0400, dolive doliv...@sina.com wrote: Robert Jacques

Re: The demise of T[new]

2009-10-18 Thread dsimcha
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article dsimcha wrote: == Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article 3. A T[new] should be implicitly convertible to a slice. For example: auto foo = someFunctionThatReturnsTnew(); // foo

Re: The demise of T[new]

2009-10-18 Thread downs
Walter Bright wrote: The purpose of T[new] was to solve the problems T[] had with passing T[] to a function and then the function resizes the T[]. What happens with the original? The solution we came up with was to create a third array type, T[new], which was a reference type. Andrei had

Re: The demise of T[new]

2009-10-18 Thread dsimcha
== Quote from downs (default_357-l...@yahoo.de)'s article Walter Bright wrote: The purpose of T[new] was to solve the problems T[] had with passing T[] to a function and then the function resizes the T[]. What happens with the original? The solution we came up with was to create a third

Re: The demise of T[new]

2009-10-18 Thread Jason House
Andrei Alexandrescu Wrote: grauzone wrote: Walter Bright wrote: We both feel that this would simplify D, make it more flexible, and remove some awkward corner cases like the inability to say a.length++. How would this remove this corner case? Can't increment length if it's

Re: The demise of T[new]

2009-10-18 Thread dsimcha
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article Jason House wrote: Andrei Alexandrescu Wrote: grauzone wrote: Walter Bright wrote: We both feel that this would simplify D, make it more flexible, and remove some awkward corner cases like the inability to say

Re: The demise of T[new]

2009-10-18 Thread Andrei Alexandrescu
Jason House wrote: Andrei Alexandrescu Wrote: grauzone wrote: Walter Bright wrote: We both feel that this would simplify D, make it more flexible, and remove some awkward corner cases like the inability to say a.length++. How would this remove this corner case? Can't increment length if

Re: The demise of T[new]

2009-10-18 Thread Andrei Alexandrescu
dsimcha wrote: == Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article Jason House wrote: Andrei Alexandrescu Wrote: grauzone wrote: Walter Bright wrote: We both feel that this would simplify D, make it more flexible, and remove some awkward corner cases like the

Proposed D2 Feature: = for anonymous delegates

2009-10-18 Thread Jason House
Am I the only one that has trouble remembering how to write an inline anonymous delegate when calling a function? At a minimum, both Scala and C# use (args) = { body; } syntax. Can we please sneak it into D2?

Re: Proposed D2 Feature: = for anonymous delegates

2009-10-18 Thread Andrei Alexandrescu
Jason House wrote: Am I the only one that has trouble remembering how to write an inline anonymous delegate when calling a function? At a minimum, both Scala and C# use (args) = { body; } syntax. Can we please sneak it into D2? We have (args) { body; } Andrei

Re: The demise of T[new]

2009-10-18 Thread Jason House
Andrei Alexandrescu Wrote: dsimcha wrote: == Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article Jason House wrote: Andrei Alexandrescu Wrote: grauzone wrote: Walter Bright wrote: We both feel that this would simplify D, make it more flexible, and remove some

Re: Proposed D2 Feature: = for anonymous delegates

2009-10-18 Thread Jason House
Andrei Alexandrescu Wrote: Jason House wrote: Am I the only one that has trouble remembering how to write an inline anonymous delegate when calling a function? At a minimum, both Scala and C# use (args) = { body; } syntax. Can we please sneak it into D2? We have (args) { body; }

Re: dmd support for IDEs and the D tool chain

2009-10-18 Thread BCS
Hello Nick, BCS n...@anon.com wrote in message If mine did that I'd shoot him (a scorching e-mail :) You should both feel lucky. The best I had was a class where we filled in the bodies of a handful of small functions in a trivial assembler (trivial meaning completely bare-minimum, and no

Re: dmd support for IDEs and the D tool chain

2009-10-18 Thread BCS
Hello Ellery, BCS wrote: Hello Ellery, For some reason, my professor seems to be skipping LR parsing. If mine did that I'd shoot him (a scorching e-mail :) It's probably because he can't make us write a LALR parser by hand. For a small language he could. My prof has done several 2-4

Re: The demise of T[new]

2009-10-18 Thread dsimcha
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article dsimcha wrote: == Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article Jason House wrote: Andrei Alexandrescu Wrote: grauzone wrote: Walter Bright wrote: We both feel that this would

Re: Revamping associative arrays

2009-10-18 Thread Chris Nicholson-Sauls
BCS wrote: Hello Chris Nicholson-Sauls, Andrei Alexandrescu wrote: Associative arrays are today quite problematic because they don't offer any true iteration. Furthermore, the .keys and .values properties create new arrays, which is wasteful. Another issue with associative arrays is that

Re: dmd support for IDEs + network GUI

2009-10-18 Thread Adam D. Ruppe
On Mon, Oct 12, 2009 at 09:06:38PM -0400, Nick Sabalausky wrote: Excellent! Sounds exactly like what I had in mind. I'll definately want to keep an eye on this. Any webpage or svn or anything yet? I wrote up some of a webpage for it over the weekend: http://arsdnet.net/dws/ I haven't had a

Re: 64-bit

2009-10-18 Thread BCS
Hello Nick, One more correction. The date I mention for Walter post is incorrect. It is in fact 11/08/2009 8:49 a.m. For us yanks that would be 08/11/2009 To Just Visting, no problem. Nick B

Re: DFL IDE Editor ?

2009-10-18 Thread Sam Hu
Robert Jacques Wrote: Do you have a DFL for dmd2.035 ? thank you very much ! dolive Yes, I've e-mailed it to you. Hi Robert, It would be grateful if you could add samhu.sa...@gmail.com in your list. Regards, Sam

Re: DFL IDE Editor ?

2009-10-18 Thread Robert Jacques
On Sun, 18 Oct 2009 23:51:37 -0400, Sam Hu samhudotsa...@gmail.com wrote: Robert Jacques Wrote: Do you have a DFL for dmd2.035 ? thank you very much ! dolive Yes, I've e-mailed it to you. Hi Robert, It would be grateful if you could add samhu.sa...@gmail.com in your list. Regards, Sam

Re: The demise of T[new]

2009-10-18 Thread downs
dsimcha wrote: == Quote from downs (default_357-l...@yahoo.de)'s article Walter Bright wrote: The purpose of T[new] was to solve the problems T[] had with passing T[] to a function and then the function resizes the T[]. What happens with the original? The solution we came up with was to

Re: DFL IDE Editor ?

2009-10-18 Thread dolive
Robert Jacques дµ½: On Sun, 18 Oct 2009 23:51:37 -0400, Sam Hu samhudotsa...@gmail.com wrote: Robert Jacques Wrote: Do you have a DFL for dmd2.035 ? thank you very much ! dolive Yes, I've e-mailed it to you. Hi Robert, It would be grateful if you could add

Re: DFL IDE Editor ?

2009-10-18 Thread dolive
Robert Jacques дµ½: On Sun, 18 Oct 2009 23:51:37 -0400, Sam Hu samhudotsa...@gmail.com wrote: Robert Jacques Wrote: Do you have a DFL for dmd2.035 ? thank you very much ! dolive Yes, I've e-mailed it to you. Hi Robert, It would be grateful if you could add

Re: The demise of T[new]

2009-10-18 Thread Walter Bright
dsimcha wrote: The bugs in the current arrays are pretty nasty from a theoretical safety/purity point of view (esp. the one that's a hole in immutability), but are seldom run into in practice. We'd like to get D to the point where guarantees can be offered. This really sets it apart from C++,

Re: Sorry, I just love templates, AAs and mixins :)

2009-10-18 Thread Saaa
Ellery Newcomer wrote: grauzone wrote: Saaa wrote: public void addToAA(char[] var_name, KT, ET)(KT key, ET element) { mixin(ET.stringof~`[]* elements = key in `~var_name~`;`); if( elements == null ) { ET[] temp; temp.length = 1; temp[0] = element;

Re: Sorry, I just love templates, AAs and mixins :)

2009-10-18 Thread Saaa
Ary Borenszweig wrote: Saaa wrote: public void addToAA(char[] var_name, KT, ET)(KT key, ET element) { mixin(ET.stringof~`[]* elements = key in `~var_name~`;`); if( elements == null ) { ET[] temp; temp.length = 1; temp[0] = element; mixin(var_name~`[key] = temp;`);

Re: Sorry, I just love templates, AAs and mixins :)

2009-10-18 Thread Chris Nicholson-Sauls
Saaa wrote: Ary Borenszweig wrote: Saaa wrote: public void addToAA(char[] var_name, KT, ET)(KT key, ET element) { mixin(ET.stringof~`[]* elements = key in `~var_name~`;`); if( elements == null ) { ET[] temp; temp.length = 1; temp[0] = element; mixin(var_name~`[key] =

[Issue 2487] regexp .* fails to capture space in a greedy way

2009-10-18 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2487 David Simcha dsim...@yahoo.com changed: What|Removed |Added Status|NEW |RESOLVED

[Issue 2108] regexp.d: The greedy dotstar isn't so greedy

2009-10-18 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2108 David Simcha dsim...@yahoo.com changed: What|Removed |Added CC||swadena...@gmail.com

[Issue 2973] std.math.pow(int, int), etc.

2009-10-18 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2973 David Simcha dsim...@yahoo.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED

[Issue 3416] New: Non-compilable template instantiation in is(typeof()) fails compilation

2009-10-18 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3416 Summary: Non-compilable template instantiation in is(typeof()) fails compilation Product: D Version: 2.035 Platform: Other OS/Version: Windows Status: NEW

[Issue 3416] Non-compilable template instantiation in is(typeof()) fails compilation

2009-10-18 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3416 Max Samukha samu...@voliacable.com changed: What|Removed |Added Severity|normal |blocker ---

[Issue 3417] New: std.stdio.File needs size

2009-10-18 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3417 Summary: std.stdio.File needs size Product: D Version: 2.035 Platform: Other OS/Version: Windows Status: NEW Severity: enhancement Priority: P2 Component:

[Issue 2973] std.math.pow(int, int), etc.

2009-10-18 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2973 --- Comment #8 from Andrei Alexandrescu and...@metalanguage.com 2009-10-18 13:06:15 PDT --- (In reply to comment #7) Since I filed this one and I'm thoroughly convinced now that it's not necessary and noone else seems to want it, I'm