Jeremie Pelletier wrote:
>
> Sweeney makes some strong points in his presentation, it's true that the line
> between CPU and GPU is growing thinner and thinner, and GPU programming is
> not the easiest thing to learn. I had an easier time learning ASM than I did
> learning the GPU pipeline in
davidl Wrote:
> ÔÚ Tue, 11 Aug 2009 08:54:07 +0800£¬bearophile
> дµÀ:
>
> > D2/D3 may become a good language to create video games, this is a new
> > interesting document that shows some of the things D2 users may want to
> > use it for:
> > http://graphics.cs.williams.edu/archive/Sweeney
在 Tue, 11 Aug 2009 08:54:07 +0800，bearophile
写道:
D2/D3 may become a good language to create video games, this is a new
interesting document that shows some of the things D2 users may want to
use it for:
http://graphics.cs.williams.edu/archive/SweeneyHPG2009/TimHPG2009.pdf
I don't know ho
Benji Smith wrote:
Andrei Alexandrescu wrote:
Daniel Keep wrote:
Andrei Alexandrescu wrote:
Michel Fortin wrote:
On 2009-08-09 11:10:48 -0400, Andrei Alexandrescu
said:
It's also arguable that all functions in std.string should take
const(char)[]. Or, you know, const(T)[], since D support
Andrei Alexandrescu wrote:
Daniel Keep wrote:
Andrei Alexandrescu wrote:
Michel Fortin wrote:
On 2009-08-09 11:10:48 -0400, Andrei Alexandrescu
said:
It's also arguable that all functions in std.string should take
const(char)[]. Or, you know, const(T)[], since D supports encodings
other th
D2/D3 may become a good language to create video games, this is a new
interesting document that shows some of the things D2 users may want to use it
for:
http://graphics.cs.williams.edu/archive/SweeneyHPG2009/TimHPG2009.pdf
I don't know how D2 can adapt itself to help in such regards.
Bye,
bear
Andrei Alexandrescu Wrote:
> Jeremie Pelletier wrote:
> > Andrei Alexandrescu Wrote:
> >
> >> Jeremie Pelletier wrote:
> >>> Lars T. Kyllingstad Wrote:
> >>>
> I just filed a bug report (3240) that describes a case where IFTI is
> used in Phobos, and where this causes errors when the f
On Mon, Aug 10, 2009 at 6:53 PM, bearophile wrote:
> If such tests are correct, then the new resizable arrays of D2 will indeed
> have some performance penality (something like 13%-17% in this test, but
> results may change with other array sizes).
I don't see why that's a big problem. If you'
dsimcha:
> import std.stdio, std.perf;
[...]
> Results:
> Direct: 226
> Indirect: 229
Thank you. Following your example I have tried to do a bit more realistic tests.
// test1.d, for D2, Phobos
import std.stdio: writeln;
import std.perf: PerformanceCounter;
final class TNew(T) {
T* ptr;
Jeremie Pelletier wrote:
Andrei Alexandrescu Wrote:
Jeremie Pelletier wrote:
Lars T. Kyllingstad Wrote:
I just filed a bug report (3240) that describes a case where IFTI is
used in Phobos, and where this causes errors when the function is used
with a different type than the one used in the
Jeremie Pelletier wrote:
Walter: what will the string types be aliased to now: still
immutable(char)[] or immutable(char)[new]?
immutable(char)[]
I think it would be best to have them use the array [new] type.
The vast majority of uses will not need to be resizeable.
Functions which do no
Andrei Alexandrescu Wrote:
> Steven Schveighoffer wrote:
> > On Mon, 03 Aug 2009 18:00:59 -0400, Andrei Alexandrescu
> > wrote:
> >
> >> http://www.reddit.com/r/programming/comments/975ng/diving_into_the_d_programming_language_tdpl/
> >>
> >>
> >>
> >> (Don't tell anyone, but I plan to rewrit
Andrei Alexandrescu Wrote:
> Jeremie Pelletier wrote:
> > Lars T. Kyllingstad Wrote:
> >
> >> I just filed a bug report (3240) that describes a case where IFTI is
> >> used in Phobos, and where this causes errors when the function is used
> >> with a different type than the one used in the unit
Alexey wrote:
Hello!
Sorry for my bad English.
I have some questions about dmd development:
1. What about support FreeBsd in dmd2?
I haven't done it yet because nobody has asked for it.
2. Are there any plans to support Solaris and others OS?
Yes (it's already there for D1, just not distrib
Steven Schveighoffer wrote:
On Mon, 03 Aug 2009 18:00:59 -0400, Andrei Alexandrescu
wrote:
http://www.reddit.com/r/programming/comments/975ng/diving_into_the_d_programming_language_tdpl/
(Don't tell anyone, but I plan to rewrite it.)
Andrei
Wow, my head's spinning :)
That's a lot of da
Reply to Steven,
On Sun, 09 Aug 2009 15:51:46 -0400, bearophile
wrote:
grauzone:
Then what is there to complain?<
I have paid for 2 GB RAM, so I am allowed to desire a 1800 MB array
:-)
hehe. Not necessarily.
There are often hardware/OS limitations. For example, many 32-bit
Intel c
Jeremie Pelletier:
>I can't even think of an use for such large arrays. There is always a way to
>split the allocation in smaller ones which will be easy to map in the
>available virtual memory space.<
You not being able to imagine a good use case doesn't imply there isn't one :-)
This program
On Mon, 10 Aug 2009 15:21:48 -0400, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
On Mon, 10 Aug 2009 14:38:24 -0400, Stewart Gordon
wrote:
Since nobody's yet asked
What type would .dup and .idup return?
The best choice I can see is to make .dup return T[new] and .idup
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
bearophile wrote:
> Walter Bright:
>
> I like this general proposal, it sounds like something that can improve D a
> little. There are many other things that have to be improved in D, but baby
> steps are enough to go somewhere :-)
>
>> Slices will
Steven Schveighoffer wrote:
On Mon, 10 Aug 2009 14:38:24 -0400, Stewart Gordon
wrote:
Since nobody's yet asked
What type would .dup and .idup return?
The best choice I can see is to make .dup return T[new] and .idup
return invariant(T)[].
This brings up another question. Should some
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
http://www.digitalmars.com/d/archives/digitalmars/D/OPTLINK_and_LARGEADDRESSAWARE_88061.html
bearophile wrote:
> In a small program on Windows XP I have to allocate a large chunk of RAM,
> about 1847 MB of RAM. This PC has 2 GB RAM. So I use std.c.st
bearophile Wrote:
> Robert Fraser:
> > I agree it's a bug, and probably a rather major one. However in a real
> > use case, any program that needs 1800+ MB arrays should be 64-bit only.
>
> In that program there's essentially just that large array.
> What is the size of biggest array you suggest
On Mon, 10 Aug 2009 14:38:24 -0400, Stewart Gordon
wrote:
Since nobody's yet asked
What type would .dup and .idup return?
The best choice I can see is to make .dup return T[new] and .idup return
invariant(T)[].
This brings up another question. Should something like immutable(T)[new
Jeremie Pelletier wrote:
Lars T. Kyllingstad Wrote:
I just filed a bug report (3240) that describes a case where IFTI is
used in Phobos, and where this causes errors when the function is used
with a different type than the one used in the unittest. (The well known
"IFTI doesn't work with impl
Jeremie Pelletier wrote:
Walter: what will the string types be aliased to now: still immutable(char)[]
or immutable(char)[new]?
I think it would be best to have them use the array [new] type.
It would be more efficient to cut out this middleman for things that
aren't going to change the len
Since nobody's yet asked
What type would .dup and .idup return?
The best choice I can see is to make .dup return T[new] and .idup return
invariant(T)[].
Stewart.
On Mon, 10 Aug 2009 14:15:41 -0400, bearophile
wrote:
Steven Schveighoffer:
My point is, don't count on having 2GB of usable space even if you
physically have 2GB of RAM, it may not be the case.
I was looking for using 1.8 GB not 2.
Better off to not desire than to complain about edge co
Steven Schveighoffer:
> My point is, don't count on having 2GB of usable space even if you
> physically have 2GB of RAM, it may not be the case.
I was looking for using 1.8 GB not 2.
>Better off to not desire than to complain about edge conditions based on
>hardware limitations.<
With C I ca
On Sun, 09 Aug 2009 15:51:46 -0400, bearophile
wrote:
grauzone:
Then what is there to complain?<
I have paid for 2 GB RAM, so I am allowed to desire a 1800 MB array :-)
hehe. Not necessarily.
There are often hardware/OS limitations. For example, many 32-bit Intel
chipsets support 4G
Robert Fraser:
> I agree it's a bug, and probably a rather major one. However in a real
> use case, any program that needs 1800+ MB arrays should be 64-bit only.
In that program there's essentially just that large array.
What is the size of biggest array you suggest to use in a D/C program on a 3
Alexey wrote:
Hello!
Sorry for my bad English.
I have some questions about dmd development:
1. What about support FreeBsd in dmd2?
It seems the binary isn't included, you probably have to compile it
yourself (It might be that it doesn't compile on freebsd, which is why
there's no binary inclu
Eljay wrote:
As cent/ucent, should a keyword be reserved for 256? 512? 1024?
- - - - - - - - - - - - - - -
Most programming languages are loathe to add new keywords, because that has the
chance to impact existing code.
So the time to add keywords for D 2.0(alpha) is now, since the language
Don wrote:
> You didn't respond to my assertion: even if you _could_ do it, why would
> you want to? ** sucks as an exponential operator. I dispute the
> contention that ** is a natural choice. It comes from the same language
> that brought you IF X .NE. 2
There are too many languages that suppor
bearophile wrote:
grauzone:
Then what is there to complain?<
I have paid for 2 GB RAM, so I am allowed to desire a 1800 MB array :-)
I agree it's a bug, and probably a rather major one. However in a real
use case, any program that needs 1800+ MB arrays should be 64-bit only.
Jeremie Pelletier, el 10 de agosto a las 13:01 me escribiste:
> Lars T. Kyllingstad Wrote:
>
> > Walter Bright wrote:
> > > Lars T. Kyllingstad wrote:
> > >> I've always wondered: Why are strings of type immutable(char)[], and
> > >> not immutable(char[])?
> > >
> > > So:
> > >
> > >string
Andrei Alexandrescu, el 10 de agosto a las 10:15 me escribiste:
> Leandro Lucarella wrote:
> >Sergey Gromov, el 10 de agosto a las 16:32 me escribiste:
> >>Sat, 08 Aug 2009 17:32:30 -0400, Jeremie Pelletier wrote:
> >>
> >>>I just had an idea to help keep track of unittests, right now we're
> >>>t
Hello!
Sorry for my bad English.
I have some questions about dmd development:
1. What about support FreeBsd in dmd2?
2. Are there any plans to support Solaris and others OS?
3. Are there any plans to support 64-bits system? And if it is,
when?
--
Alexey
On Mon, 03 Aug 2009 18:00:59 -0400, Andrei Alexandrescu
wrote:
http://www.reddit.com/r/programming/comments/975ng/diving_into_the_d_programming_language_tdpl/
(Don't tell anyone, but I plan to rewrite it.)
Andrei
Wow, my head's spinning :)
That's a lot of data/concepts in one chapter. H
Lars T. Kyllingstad Wrote:
> Walter Bright wrote:
> > Lars T. Kyllingstad wrote:
> >> I've always wondered: Why are strings of type immutable(char)[], and
> >> not immutable(char[])?
> >
> > So:
> >
> >string a = "hello";
> >a = "foo";
> >
> > works.
>
>
> Ah, of course. :) Thanks.
>
Lars T. Kyllingstad Wrote:
> I just filed a bug report (3240) that describes a case where IFTI is
> used in Phobos, and where this causes errors when the function is used
> with a different type than the one used in the unittest. (The well known
> "IFTI doesn't work with implicit conversions" p
David Gileadi Wrote:
> Daniel Keep wrote:
> > Jeremie Pelletier wrote:
> >> If a function has both an asm and D implementations inside its body, and
> >> the D version can be executed at compile time, but the asm one is much
> >> faster at runtime. Is it possible to have the compiler use the D c
On Sun, Aug 9, 2009 at 4:29 PM, Walter Bright wrote:
> D has a number of subtle problems (performance and semantic) that arise when
> arrays are resized. The solution is to separate resizeable array types from
> slices. Slices will retain the old:
>
> T[] slice;
>
> syntax. Resizeable arrays will
Lars T. Kyllingstad wrote:
> Lars T. Kyllingstad wrote:
>> Daniel Keep wrote:
>>>
>>> Lars T. Kyllingstad wrote:
...
>>>
>>> Knocked this up in about two minutes. Might be handy.
>>>
>>> template TestInstantiateImpl(alias Tmpl, Ts...)
>>> {
>>> static if( Ts.length > 0 )
>>> {
>>>
Sat, 08 Aug 2009 19:26:48 -0600, Rainer Deyke thusly wrote:
>
> I don't think D needs two inline comment forms, but /+...+/ is no less
> ambiguous than /*...*/. Don't forget about the unary '+' operator:
We could also overload .. to define a vector dot product, and *** for
cross product.
Andrei Alexandrescu Wrote:
> Leandro Lucarella wrote:
> > Sergey Gromov, el 10 de agosto a las 16:32 me escribiste:
> >> Sat, 08 Aug 2009 17:32:30 -0400, Jeremie Pelletier wrote:
> >>
> >>> I just had an idea to help keep track of unittests, right now we're
> >>> turning on printf's at the beginn
On Sun, 09 Aug 2009 16:29:21 -0400, Walter Bright
wrote:
D has a number of subtle problems (performance and semantic) that arise
when arrays are resized. The solution is to separate resizeable array
types from slices. Slices will retain the old:
T[] slice;
syntax. Resizeable arrays
Leandro Lucarella wrote:
Sergey Gromov, el 10 de agosto a las 16:32 me escribiste:
Sat, 08 Aug 2009 17:32:30 -0400, Jeremie Pelletier wrote:
I just had an idea to help keep track of unittests, right now we're turning on
printf's at the beginning of a test to know which one fails, and adding p
On Mon, 10 Aug 2009 10:11:52 -0400, Andrei Alexandrescu
wrote:
Walter Bright wrote:
Kagamin wrote:
Of what type will strings be?
immutable(char)[]
Of what type will be the result of concatenation?
T[new]
Hmmm, I see a problem.
auto s1 = "Hello";
auto s2 = " world";
auto s = s1 ~ s2
Sergey Gromov, el 10 de agosto a las 16:32 me escribiste:
> Sat, 08 Aug 2009 17:32:30 -0400, Jeremie Pelletier wrote:
>
> > I just had an idea to help keep track of unittests, right now we're turning
> > on printf's at the beginning of a test to know which one fails, and adding
> > printfs every
On Sun, 09 Aug 2009 15:53:23 -0400, Bill Baxter wrote:
On Sun, Aug 9, 2009 at 11:25 AM, grauzone wrote:
Bill Baxter wrote:
Interesting thing I found out about C# properties.
The syntax
int Thing {
get { return _thing; }
set { _thing = value; }
}
is rewritten by the C# compiler into
in
Daniel Keep wrote:
Jeremie Pelletier wrote:
If a function has both an asm and D implementations inside its body, and the D
version can be executed at compile time, but the asm one is much faster at
runtime. Is it possible to have the compiler use the D code path at compile
time (ie to fill in
On Thu, 06 Aug 2009 18:08:00 -0400, Chad J
wrote:
So I dug up Andrei's thread that mentioned something about properties
that hasn't been discussed as of recent: expensive copy semantics.
...
Towards the end of the discussion Steven Schveighoffer mentioned that
this need to acquire and rele
Lars T. Kyllingstad wrote:
Daniel Keep wrote:
Lars T. Kyllingstad wrote:
...
Knocked this up in about two minutes. Might be handy.
template TestInstantiateImpl(alias Tmpl, Ts...)
{
static if( Ts.length > 0 )
{
alias Tmpl!(Ts[0]) test;
alias TestInstantiateImpl!(Tmpl
Walter Bright wrote:
Kagamin wrote:
Of what type will strings be?
immutable(char)[]
Of what type will be the result of concatenation?
T[new]
Hmmm, I see a problem.
auto s1 = "Hello";
auto s2 = " world";
auto s = s1 ~ s2;
Some might be surprised that the type of s is not the same as tha
Daniel Keep wrote:
Lars T. Kyllingstad wrote:
...
Knocked this up in about two minutes. Might be handy.
template TestInstantiateImpl(alias Tmpl, Ts...)
{
static if( Ts.length > 0 )
{
alias Tmpl!(Ts[0]) test;
alias TestInstantiateImpl!(Tmpl, Ts[1..$]).next next;
}
Lars T. Kyllingstad wrote:
> ...
Knocked this up in about two minutes. Might be handy.
template TestInstantiateImpl(alias Tmpl, Ts...)
{
static if( Ts.length > 0 )
{
alias Tmpl!(Ts[0]) test;
alias TestInstantiateImpl!(Tmpl, Ts[1..$]).next next;
}
else
{
Sun, 09 Aug 2009 16:10:38 -0500, Andrei Alexandrescu wrote:
> Michel Fortin wrote:
>> On 2009-08-09 14:10:10 -0400, Andrei Alexandrescu
>> said:
>>
But shouldn't they work with *ranges* in general, a string being only
a specific case?
>>>
>>> That's true as well! In my dreams, me and
Fri, 07 Aug 2009 17:02:33 -0700, Robert Jacques wrote:
>> Moreover compiler intrinsics are
>> functions which compiler recognizes and treats specially, usually by
>> replacing them with a single processor instruction.
>
> We weren't discussing implementation with intrinsics, but as with a
> sta
Sat, 08 Aug 2009 17:32:30 -0400, Jeremie Pelletier wrote:
> I just had an idea to help keep track of unittests, right now we're turning
> on printf's at the beginning of a test to know which one fails, and adding
> printfs everywhere quickly becomes redundant. Also if the test succeeds and
> ex
Sun, 09 Aug 2009 13:29:21 -0700, Walter Bright wrote:
> D has a number of subtle problems (performance and semantic) that arise
> when arrays are resized. The solution is to separate resizeable array
> types from slices. Slices will retain the old:
>
> T[] slice;
>
> syntax. Resizeable arr
I just filed a bug report (3240) that describes a case where IFTI is
used in Phobos, and where this causes errors when the function is used
with a different type than the one used in the unittest. (The well known
"IFTI doesn't work with implicit conversions" problem.) I have a strong
suspicion
Walter Bright wrote:
Lars T. Kyllingstad wrote:
I've always wondered: Why are strings of type immutable(char)[], and
not immutable(char[])?
So:
string a = "hello";
a = "foo";
works.
Ah, of course. :) Thanks.
-Lars
Don wrote:
Miles wrote:
Lars T. Kyllingstad wrote:
Neither of the natural candidates, a^b and a**b, are an option, as they
are, respectively, already taken and ambiguous.
I think that a ** b can be used, is not ambiguous except for the
tokenizer of the language. It is the same difference you
Lars T. Kyllingstad wrote:
I've always wondered: Why are strings of type immutable(char)[], and not
immutable(char[])?
So:
string a = "hello";
a = "foo";
works.
Walter Bright wrote:
Kagamin wrote:
Of what type will strings be?
immutable(char)[]
I've always wondered: Why are strings of type immutable(char)[], and not
immutable(char[])?
I mean, there is no point in allowing resizing of strings, when
assigning to the new elements is impossible.
-
grauzone wrote:
> Don wrote:
>> That doesn't work, because you still get new code being converted from
>> C. It can't look the same, but behave differently.
>
> int* a, b;
>
> Ooops...
Since that changes the type of b, it's at least likely to give you a
compile error.
Although I suppose you c
Kagamin wrote:
Of what type will strings be?
immutable(char)[]
Of what type will be the result of concatenation?
T[new]
Walter Bright Wrote:
> Resizeable arrays will be declared as:
>
> T[new] array;
>
> The new expression:
>
> new T[10]
>
> will return a T[new].
>
> T[new] will implicitly convert to T[], but not the other way.
>
> slice.length will become read-only.
Of what type will strings be? Of
grauzone wrote:
Don wrote:
That doesn't work, because you still get new code being converted from
C. It can't look the same, but behave differently.
int* a, b;
Ooops...
Touche. C declaration syntax is dreadful.
Don wrote:
That doesn't work, because you still get new code being converted from
C. It can't look the same, but behave differently.
int* a, b;
Ooops...
Miles wrote:
Lars T. Kyllingstad wrote:
Neither of the natural candidates, a^b and a**b, are an option, as they
are, respectively, already taken and ambiguous.
I think that a ** b can be used, is not ambiguous except for the
tokenizer of the language. It is the same difference you have with:
Jeremie Pelletier pisze:
aarti_pl Wrote:
Hello!
This is just another reminder about ongoing voting about properties:
http://www.igsoft.net/dpolls/index.php
Current results:
* about 68% of responders want to have special syntax for properties
* from people wanting new syntax most people want
72 matches
Mail list logo
