On Fri, 06 Jan 2012 23:31:52 -0800, torhu wrote:
On 06.01.2012 21:02, Adam Wilson wrote:
COFF is an absolute requirements when working on Windows, yet DMD
doesn't
support it. Everything, every programming interface, every application
running on x64 Windows is built with COFF, the default o
Am 07.01.2012 08:08, schrieb Nick Sabalausky:
"Paulo Pinto" wrote in message
news:je7vvh$253f$1...@digitalmars.com...
Hi,
I just saw a follow up article from Herb Sutter about
the future of parallel computing.
http://herbsutter.com/welcome-to-the-jungle/
Very interesting read. Excuse me if s
On Friday, 6 January 2012 at 23:48:31 UTC, Jacob Carlborg wrote:
On 2012-01-06 21:51, Trass3r wrote:
The only proper solution is using something like clang to
write a C++->D
converter.
First only headers, later source code.
I'm working on that, slowly.
btw, I wonder if it's all that good to
Personally I would say that I am only able to not
use an IDE on hobby and very small scale projects.
On my line of work, where most projects are scattered around
the globe, with millions of lines and modules, the code navigation
tools that IDEs provide are priceless.
Now I am back to .NET after
On 06.01.2012 21:02, Adam Wilson wrote:
On Fri, 06 Jan 2012 10:27:58 -0800, Manu wrote:
Okay, so I was trying to link to a C lib, and I realised... DMD doesn't
support/produce VS compatible libs.
I should have realised this sooner, noting the cv debuginfo.
So like... WTF?
How am I supposed t
"Paulo Pinto" wrote in message
news:je92bp$t68$1...@digitalmars.com...
>
> But he is in a way right.
>
> Even the small embedded systems are slowly becoming multicore. The most
> recent ARM processors are now multicore.
>
Yes, because after all, who *doesn't* need to decode genomes on their
te
Hi,
so you are also following Andre's attemps to revive the
old homebrew developer feeling. :)
I also miss those days. I grew up with the ZX Spectrum,
doing some BASIC and Z80 stuff, then most of my friends
moved up to the Amiga 500 and I eventually got a PC,
since my dad was the opinion the PC
On 7 January 2012 08:40, Nick Sabalausky wrote:
> "Manu" wrote in message
> news:mailman.144.1325892989.16222.digitalmar...@puremagic.com...
> >
> > Most windows programmers will simply not consider the
> > language until it is well supported in Visual Studio
> >
>
> Yea, and that's very unfortu
On 7 January 2012 10:40, Adam Wilson wrote:
> On Fri, 06 Jan 2012 23:31:52 -0800, torhu wrote:
>
> On 06.01.2012 21:02, Adam Wilson wrote:
>>
>>>
>>> COFF is an absolute requirements when working on Windows, yet DMD doesn't
>>> support it. Everything, every programming interface, every applicat
On 7 January 2012 11:37, Don wrote:
> On 06.01.2012 21:02, Adam Wilson wrote:
>
>> On Fri, 06 Jan 2012 10:27:58 -0800, Manu wrote:
>>
>> Okay, so I was trying to link to a C lib, and I realised... DMD doesn't
>>> support/produce VS compatible libs.
>>> I should have realised this sooner, noting
On 01/07/12 04:27, Martin Nowak wrote:
> __v128 add(__v128 a, __v128 b) pure
> {
> __v128 res = a;
> asm (res, b)
> {
> ADD res, b;
> }
> return res;
> }
> This is effectively achieves the same as writing this with intrinsics.
> It also greatly improves the composition
07.01.2012 5:12, Andrej Mitrovic пишет:
Oooh I've just realized something, the *compilation* calls are what's
destroying the performance. I was using "dmd test.d&& test.exe"
instead of just "test.exe" and this would generate a new exe which
screwed up the results.
So regex has nothing to do wit
Hi Manu,
nice to hear about your experience with C#.
I am a bit of half-insider in the game industry, being
a IGDA member for some years and also attended two
GDCE so far.
Several reasons have kept me from getting a job in the
industry, but I still follow what's happening quite closely.
From w
On 01/06/12 21:16, Walter Bright wrote:
> Aligning to non-powers of 2 will never work. As for other alignments, they
> only will work if the underlying storage is aligned to that or greater.
> Otherwise, you'll have to resort to the method outlined above.
>
>
>> What about GCC? Will/does it sup
On 2012-01-07 06:11, Walter Bright wrote:
On 1/6/2012 11:37 AM, Trass3r wrote:
Am 06.01.2012, 20:26 Uhr, schrieb Walter Bright
:
Long term, I hope to get a better solution, but this is where we're
at at the
moment.
What's the current state of the plan?
Can we hope for a switch to COFF?
My p
On 2012-01-07 10:31, Trass3r wrote:
On Friday, 6 January 2012 at 23:48:31 UTC, Jacob Carlborg wrote:
On 2012-01-06 21:51, Trass3r wrote:
The only proper solution is using something like clang to write a C++->D
converter.
First only headers, later source code.
I'm working on that, slowly.
bt
On 7 January 2012 15:24, Paulo Pinto wrote:
> Hi Manu,
>
> nice to hear about your experience with C#.
>
> I am a bit of half-insider in the game industry, being
> a IGDA member for some years and also attended two
> GDCE so far.
>
> Several reasons have kept me from getting a job in the
> indust
On Wed, 04 Jan 2012 19:12:04 -0500, Sean Kelly
wrote:
On Jan 4, 2012, at 2:55 PM, Andrew Wiley wrote:
On Wed, Jan 4, 2012 at 2:12 PM, Sean Kelly
wrote:
This assumes that there is no existing monitor for the object. At
best you'll get a memory leak here.
Then is there any way to sa
Thanks for the explanation.
I am convinced that eventually AAA game engines can be
made in a GC enabled language like D, they just need to
be coded in a different way, more GC-friendly.
But this is just a wish about progress, and I don't have
any real industry experience to say it will really ha
On 7 January 2012 17:27, Paulo Pinto wrote:
> Thanks for the explanation.
>
> I am convinced that eventually AAA game engines can be
> made in a GC enabled language like D, they just need to
> be coded in a different way, more GC-friendly.
>
I tend to disagree. I see it trending in the opposite
Manu:
> and updating in finer grained (probably
> threaded) tight loops across neatly (cache friendly) packed bundles of like
> objects. That's where engines are going.
I agree. Something related:
http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programmin
There's still a race condition between unlocking the monitor and freeing the
memory.
Sent from my iPhone
On Jan 7, 2012, at 7:25 AM, "Steven Schveighoffer" wrote:
> On Wed, 04 Jan 2012 19:12:04 -0500, Sean Kelly wrote:
>
>> On Jan 4, 2012, at 2:55 PM, Andrew Wiley wrote:
>>
>>> On Wed, Jan
On 07.01.2012 04:18, Andrei Alexandrescu wrote:
On 1/6/12 5:52 PM, Walter Bright wrote:
Support the 10 vector types as basic types, support them with the
arithmetic infix operators, and use intrinsics for the rest of the
operations. I believe this scheme:
1. will look better in code, and will b
On Saturday, 7 January 2012 at 16:10:32 UTC, Don wrote:
Sorry Andrei, I have to disagree with that in the strongest
possible terms. I would have mentioned AAs as a very strong
argument in the opposite direction!
Amen. AAs are *still* broken from this change. If you
take a look at my cgi.d, you
On 7 January 2012 17:55, bearophile wrote:
> Manu:
>
> > and updating in finer grained (probably
> > threaded) tight loops across neatly (cache friendly) packed bundles of
> like
> > objects. That's where engines are going.
>
> I agree. Something related:
>
>
> http://research.scee.net/files/pres
On 1/7/12 10:10 AM, Don wrote:
Sorry Andrei, I have to disagree with that in the strongest possible
terms. I would have mentioned AAs as a very strong argument in the
opposite direction!
Moving AAs from a built-in to a library type has been an unmitigated
disaster from the implementation side. A
On 1/7/12 10:19 AM, Adam D. Ruppe wrote:
On Saturday, 7 January 2012 at 16:10:32 UTC, Don wrote:
Sorry Andrei, I have to disagree with that in the strongest possible
terms. I would have mentioned AAs as a very strong argument in the
opposite direction!
Amen. AAs are *still* broken from this ch
On Saturday, 7 January 2012 at 16:55:00 UTC, Andrei Alexandrescu
wrote:
Well they are broken because the change has not been carried to
completion.
Here's my position: if we get a library implementation that
works better than the compiler implementation, let's do it. If
they
are equal in use o
On Sat, 07 Jan 2012 11:08:51 -0500, Sean Kelly
wrote:
There's still a race condition between unlocking the monitor and freeing
the memory.
Wouldn't that result in a segfault or other error? How is that worse than
the current state of affairs?
-Steve
Am 07.01.2012 16:44, schrieb Manu:
On 7 January 2012 17:27, Paulo Pinto mailto:pj...@progtools.org>> wrote:
Thanks for the explanation.
I am convinced that eventually AAA game engines can be
made in a GC enabled language like D, they just need to
be coded in a different way, mor
On 01/07/12 17:10, Don wrote:
> On 07.01.2012 04:18, Andrei Alexandrescu wrote:
> Also consider how the hard-coding of associative arrays in
>> an awkward interface inside the runtime has stifled efficient
>> implementations, progress, and innovation in that area. Still a lot of
>> work needed ther
On 1/7/12, Trass3r wrote:
> So much for Optlink being the fastest linker cause it's all
> written in shiny assembler ^^
Well I wasn't timing linking, I was timing the app itself. Optlink
does actually seem a tiny little bit faster than unilink (we're
talking a few milliseconds here), however unil
A great IDE is essential for D to really succeed.
Visual D is a solid start but it isn't really usable for a large
project yet.
- The debugging experience is funky, it can't seem to see many
variables
- hovering over variables generally doesn't show anything useful
- hitting . doesn't p
On 1/7/2012 8:10 AM, Don wrote:
Moving AAs from a built-in to a library type has been an unmitigated disaster
from the implementation side. And it has so far brought us *nothing* in return.
Not "hardly anything", but *NOTHING*. I don't even have any idea of what good
could possibly come from it.
On 01/06/2012 11:08 PM, Nick Sabalausky wrote:
"Paulo Pinto" wrote in message
news:je7vvh$253f$1...@digitalmars.com...
> Hi,
>
> I just saw a follow up article from Herb Sutter about
> the future of parallel computing.
>
> http://herbsutter.com/welcome-to-the-jungle/
>
> Very interesting r
Manu:
> The tendency to encourage use of dynamic arrays will be a major problem.
I don't know how much big that problem will be, D dynamic arrays are quite
handy, but I agree that static arrays need to be encouraged more in D (and
currently most algorithms of Phobos don't work with static array
The reason I am conviced is that C++ was the last systems
programming language with manual memory management. All the
languages people are
developing as possible C++ replacement do have some form of
automatic
memory management.
Meanwhile smart pointers and a GC API became part of the C++
la
"Paulo Pinto" wrote in message
news:je9e3t$1g3l$1...@digitalmars.com...
> Hi,
>
> so you are also following Andre's attemps to revive the
> old homebrew developer feeling. :)
>
Yea, I grew up on that sort of thing. And I'd been working with Andre'
(LaMothe, of course) since well before he start
On 07-01-2012 19:43, Froglegs wrote:
A great IDE is essential for D to really succeed.
Visual D is a solid start but it isn't really usable for a large project
yet.
- The debugging experience is funky, it can't seem to see many variables
- hovering over variables generally doesn't show anything
On 1/5/2012 4:03 PM, Sean Kelly wrote:
Oh right, I guess it would have to, since variables can be used by name
within asm blocks. I guess it just doesn't do code movement across asm
blocks then?
Right. More generally, it does not do data flow analysis within an asm block,
treating it as a bla
Am 07.01.2012 19:59, schrieb bearophile:
Manu:
The tendency to encourage use of dynamic arrays will be a major problem.
I don't know how much big that problem will be, D dynamic arrays are quite
handy, but I agree that static arrays need to be encouraged more in D (and
currently most algori
"Manu" wrote in message
news:mailman.164.1325940038.16222.digitalmar...@puremagic.com...
>
> What would you propose I try to convince me that VS is shit and
> unproductive?
>
You're twisting my words around. That's not what I said.
> If you're going to talk about bloated heavy-weight IDE's, hav
The idea is to make versions of code that are environment dependent and
never change during runtime, _without_ resorting to if statements. This
statement would be valid only inside function bodies.
Examples of such versions may be:
* supported SIMD CPU extensions MMX, SSE, SSE2, etc.
* AMD vs I
On 1/7/2012 11:00 AM, Froglegs wrote:
For a GC to be used at the C++/D layer it would need to be
1) optional always, D makes it optional but you loose a solid chunk of the
language if you ditch GC, what remains is in some ways inferior to C++(no
escaping lambda without GC, /cry)
2) no long pause
On 1/7/12 12:48 PM, Walter Bright wrote:
On 1/7/2012 8:10 AM, Don wrote:
Moving AAs from a built-in to a library type has been an unmitigated
disaster
from the implementation side. And it has so far brought us *nothing*
in return.
Not "hardly anything", but *NOTHING*. I don't even have any idea
Just for the record, my post was intentionally excessively inflammatory. I
do like a good IDE vs non-IDE debate! :P
On 7 January 2012 22:22, Nick Sabalausky wrote:
> So...you agree that it's widespread...and you hate it...Ok, I give up:
> Exactly how is that *not* "overrated"?
>
In that, I don'
On 7 January 2012 20:43, Froglegs wrote:
> Aside from C++ I also use Lua quite often and even in a light weight
> scripting language like Lua I much prefer an IDE(Decoda--Manu it works with
> embedded scripts btw).
>
Cheers for the pro-tip! :)
On 7 January 2012 22:44, Piotr Szturmaj wrote:
> The idea is to make versions of code that are environment dependent and
> never change during runtime, _without_ resorting to if statements. This
> statement would be valid only inside function bodies.
>
> Examples of such versions may be:
> * supp
On 8 January 2012 00:31, Manu wrote:
> On 7 January 2012 22:44, Piotr Szturmaj wrote:
>
>> The idea is to make versions of code that are environment dependent and
>> never change during runtime, _without_ resorting to if statements. This
>> statement would be valid only inside function bodies.
>
On 7 January 2012 20:59, bearophile wrote:
> Manu:
>
> > The tendency to encourage use of dynamic arrays will be a major problem.
>
> I don't know how much big that problem will be, D dynamic arrays are quite
> handy, but I agree that static arrays need to be encouraged more in D (and
> currently
Right now, Mutex will assert if you assign it to an object with a monitor. Or
it would with a non-release build. That's the only entirely safe thing to do.
Sent from my iPhone
On Jan 7, 2012, at 9:27 AM, "Steven Schveighoffer" wrote:
> On Sat, 07 Jan 2012 11:08:51 -0500, Sean Kelly wrote:
>
On 7 January 2012 21:00, Froglegs wrote:
> Well games often already integrate scripting languages, generally Lua or
> Mono, which are both GC based. But this is for the game logic, not for the
> high performance parts of the code.
>
Indeed. And this is usually just to mitigate the fact that C++
On 7 January 2012 23:26, Walter Bright wrote:
> There are more options with D:
>
> 3) Disable GC from collecting during critical parts of the code, i.e. you
> can still new all you want, it just won't run collection cycles.
>
This may be nice, but there is never a 'non-critical' part of a game w
On 7/01/12 11:17 PM, Manu wrote:
On 7 January 2012 21:00, Froglegs mailto:lug...@gmail.com>> wrote:
Well games often already integrate scripting languages, generally
Lua or Mono, which are both GC based. But this is for the game
logic, not for the high performance parts of the code
"Manu" wrote in message
news:mailman.174.1325975010.16222.digitalmar...@puremagic.com...
> Just for the record, my post was intentionally excessively inflammatory. I
> do like a good IDE vs non-IDE debate! :P
>
Heh, fair enough. Hell, it's not as if I'm not known for being overly
inflammatory..
Indeed. And this is usually just to mitigate the fact that C++
is so crap
at this sort of code. Maybe D will be tolerable, and this
breaking out to
script won't be necessary? (though I'm dubious)
Yeah C++ is a migraine for that type of code:( I think D would
be nicer than C++ for gameplay
On 1/7/2012 1:28 PM, Andrei Alexandrescu wrote:
Having a pluggable interface so the implementation can be changed is all
right, as long as the binary API does not change.
If the binary API changes, then of course, two different libraries
cannot be linked together. I strongly oppose any changes wh
Currently D allows code like this (I think you are supposed to use opAssign
here...):
struct MyTypedefInt {
int x;
this(int xx) { this.x = xx; }
// void opAssign(int xx) { this.x = xx; }
}
void main() {
MyTypedefInt x = 1; // OK
}
But if you put the elements into an array they
On Sat, Jan 7, 2012 at 12:29 PM, Nick Sabalausky wrote:
> "Paulo Pinto" wrote in message
> news:je9e3t$1g3l$1...@digitalmars.com...
> > Hi,
> >
> > so you are also following Andre's attemps to revive the
> > old homebrew developer feeling. :)
> >
>
> Yea, I grew up on that sort of thing. And I'd
On 1/7/2012 6:00 AM, Jacob Carlborg wrote:
Will dmd still produce OMF or will it be changed to produce COFF?
It will be irrelevant, as the linker will read whatever it puts out, and the
linker will read COFF.
There is no reason why a linker cannot transparently read many object and
library
Walter:
> I don't think that is entirely fair in regards to the SIMD stuff. It reminds
> me
> of after I spent a couple years at Caltech, where every class was essentially
> a
> math class.
I think that in several (but not all) fields of science and technology your
limits are often determine
On Sun, Jan 8, 2012 at 10:12 AM, Froglegs wrote:
>
> Indeed. And this is usually just to mitigate the fact that C++ is so crap
>> at this sort of code. Maybe D will be tolerable, and this breaking out to
>> script won't be necessary? (though I'm dubious)
>>
>
> Yeah C++ is a migraine for that ty
On 7/01/12 9:28 PM, Andrei Alexandrescu wrote:
What's built inside the compiler is like axioms in math, and what's
library is like theorems supported by the axioms. A good language, just
like a good mathematical system, has few axioms and many theorems. That
means the system is coherent and expre
On 8/01/12 12:14 AM, Walter Bright wrote:
On 1/7/2012 1:28 PM, Andrei Alexandrescu wrote:
But most always it's NOT, and definitely not in the
context of a complex data structure like a hash table. I also think
that adding
a hecatomb of built-in types and functions has smells, though to a
good ex
On 8 January 2012 02:54, Peter Alexander wrote:
> I agree with Manu that we should just have a single type like __m128 in
> MSVC. The other types and their conversions should be solvable in a library
> with something like strong typedefs.
>
Walter put in a reasonable effort to sway me to his side
"Froglegs" wrote in message
news:lwcqnrvamqlnjjlxz...@dfeed.kimsufi.thecybershadow.net...
>
> can reload scripts while program is executing. Neither D nor C++ work
> here.
>
Why not a dll? Those can be compiled/loaded/reloaded at runtime. And since
it's just scripts, it wouldn't take long to c
On 1/7/2012 4:54 PM, Peter Alexander wrote:
I think it simply requires a lot of work in the compiler.
Not that much work. Most of it segues nicely into the previous work I did
supporting the XMM floating point code gen.
On 8 January 2012 03:40, Nick Sabalausky wrote:
> "Froglegs" wrote in message
> news:lwcqnrvamqlnjjlxz...@dfeed.kimsufi.thecybershadow.net...
> >
> > can reload scripts while program is executing. Neither D nor C++ work
> > here.
> >
>
> Why not a dll? Those can be compiled/loaded/reloaded at ru
On 8 January 2012 03:44, Walter Bright wrote:
> On 1/7/2012 4:54 PM, Peter Alexander wrote:
>
>> I think it simply requires a lot of work in the compiler.
>>
>
> Not that much work. Most of it segues nicely into the previous work I did
> supporting the XMM floating point code gen.
>
What is this
On 1/7/2012 3:30 PM, Manu wrote:
On 7 January 2012 23:26, Walter Bright mailto:newshou...@digitalmars.com>> wrote:
There are more options with D:
3) Disable GC from collecting during critical parts of the code, i.e. you
can still new all you want, it just won't run collection cycles
"Brad Anderson" wrote in message
news:mailman.185.1325982241.16222.digitalmar...@puremagic.com...
> On Sat, Jan 7, 2012 at 12:29 PM, Nick Sabalausky wrote:
>
>> "Paulo Pinto" wrote in message
>> news:je9e3t$1g3l$1...@digitalmars.com...
>> > Hi,
>> >
>> > so you are also following Andre's attemp
On 8 January 2012 03:46, Walter Bright wrote:
> It should also be possible to do the gc in another thread running at low
> priority, if the only other running thread is doing the critical stuff and
> is not the sole holder of references to any GC allocated memory it is using.
>
... sound like un
On 1/8/2012 9:23 AM, Brad Anderson wrote:
On Sat, Jan 7, 2012 at 12:29 PM, Nick Sabalausky wrote:
"Paulo Pinto" mailto:pj...@progtools.org>>
wrote in message
news:je9e3t$1g3l$1...@digitalmars.com...
> Hi,
>
> so you are also following Andre's attemps to revive the
On 8/01/12 1:32 AM, Manu wrote:
On 8 January 2012 02:54, Peter Alexander mailto:peter.alexander...@gmail.com>> wrote:
I agree with Manu that we should just have a single type like __m128
in MSVC. The other types and their conversions should be solvable in
a library with something lik
On 8/01/12 1:48 AM, Manu wrote:
On 8 January 2012 03:44, Walter Bright mailto:newshou...@digitalmars.com>> wrote:
On 1/7/2012 4:54 PM, Peter Alexander wrote:
I think it simply requires a lot of work in the compiler.
Not that much work. Most of it segues nicely into the previou
On 1/7/2012 5:32 PM, Manu wrote:
Here are some points we discussed... how do we do these (efficiently) in a
library?
Another issue - matching the name mangling and parameter passing/return
conventions of how other C/C++ compilers deal with vector types. That is
currently not doable with a li
On 1/7/2012 6:32 PM, Peter Alexander wrote:
On 64-bit, floats are stored in XMM registers (just as single scalars).
Yes.
I don't think it does any vectorization yet though.
Right. It doesn't do that.
It does mean that the register
allocation of those registers is already complete though.
On 1/7/2012 5:54 PM, Manu wrote:
On 8 January 2012 03:46, Walter Bright mailto:newshou...@digitalmars.com>> wrote:
It should also be possible to do the gc in another thread running at low
priority, if the only other running thread is doing the critical stuff and
is not the sole holde
On 1/7/2012 4:12 PM, Peter Alexander wrote:
The main advantage of Lua for game code (in my opinion) is runtime reloading,
and the ability to avoid recompiles just to test some new game logic. That's not
so easy with C++.
D is far faster at compiling than C++.
Here's an interesting discussion that may reflect the perceptions and
misperceptions about D within the larger community.
http://www.cplusplus.com/forum/lounge/58832/
Andrei
On 01/07/2012 08:47 PM, Manu wrote:
> On 8 January 2012 03:40, Nick Sabalausky wrote:
>
> "Froglegs" mailto:lug...@gmail.com>> wrote in message
> news:lwcqnrvamqlnjjlxz...@dfeed.kimsufi.thecybershadow.net...
> >
> > can reload scripts while program is executing. Neither D nor C++
"Mike Parker" wrote in message
news:jeatr8$tq0$1...@digitalmars.com...
>
> I was a regular lurker for a while. Until around the time of the Hasbro
> suit. When I saw 'Abscissa' posting over at the DSource forums, and later
> connected it with Nick, I thought it likely to be the same Abscissa fr
Chad J wrote:
On 01/07/2012 08:47 PM, Manu wrote:
On 8 January 2012 03:40, Nick Sabalausky wrote:
"Froglegs" mailto:lug...@gmail.com>> wrote
in message
news:lwcqnrvamqlnjjlxz...@dfeed.kimsufi.thecybershadow.net...
>
> can reload scripts while program is executing. Neither D
nor C++ work
On Saturday, January 07, 2012 22:19:53 Andrei Alexandrescu wrote:
> Here's an interesting discussion that may reflect the perceptions and
> misperceptions about D within the larger community.
>
> http://www.cplusplus.com/forum/lounge/58832/
Not exactly the most informed discussion. But I would ex
On 1/8/2012 3:57 PM, Jonathan M Davis wrote:
On Saturday, January 07, 2012 22:19:53 Andrei Alexandrescu wrote:
Here's an interesting discussion that may reflect the perceptions and
misperceptions about D within the larger community.
http://www.cplusplus.com/forum/lounge/58832/
Not exactly the
"Andrei Alexandrescu" wrote in message
news:jeb5h6$1c76$1...@digitalmars.com...
> Here's an interesting discussion that may reflect the perceptions and
> misperceptions about D within the larger community.
>
> http://www.cplusplus.com/forum/lounge/58832/
>
Every time I log in and go to that pag
86 matches
Mail list logo
