I really wanted to get D1 to work in a path with spaces, but it couldn't
seem to find the phobos library even if I hardcoded the path in sc.ini and
used quotes. I came up with a workaround that I thought I would share. I
just used the short version of the path which is intended for DOS
comp
Trass3r wrote:
Is anybody already working on OpenCL bindings now that Nvidia finally
released a public OpenCL driver?
If no one has started on a D binding then maybe a C# binding would be an
ideal start?
http://www.opentk.com/news/C%2523-opencl-bindings-ready-for-testing
In the docs for "return statement" in statement.html it says:
---
ReturnStatement:
return;
return Expression ;
Expression is allowed even if the function specifies a void return type.
The Expression will be evaluated, but nothing will be returned.
This makes sense for things we de
bearophile wrote:
Walter Bright:
I've been thinking of transitioning dmd's semantic analysis to using immutable
data structures because it will reduce allocations, not increase them.<
As usual I am ignorant about such matters, so I can't give you a good answer.
But from what I've seen in imm
Chris Nicholson-Sauls wrote:
> My personal experience with Scala, at least, has been that it doesn't
> hurt anything.
Scala uses the Java garbage collector, which can take all kinds of abuse
without flinching.
--
Rainer Deyke - rain...@eldwood.com
Andrei Alexandrescu wrote:
In this article:
http://www.gotw.ca/publications/mill18.htm
Herb Sutter makes a powerful argument that overridable functions
(customization points) should actually not be the same as the publically
available interface. This view rhymes with the Template Method patte
Don:
> In the docs for "return statement" in statement.html it says:
> ---
> ReturnStatement:
> return;
> return Expression ;
>
> Expression is allowed even if the function specifies a void return type.
> The Expression will be evaluated, but nothing will be returned.
I agree that mak
Walter Bright wrote:
Denis Koroskin wrote:
> On Sat, 26 Sep 2009 22:30:58 +0400, Walter Bright
> wrote:
>> D has borrowed ideas from many different languages. The trick is to
>> take the good stuff and avoid their mistakes .
>
> How about this one:
>
http://sadekdrobi.com/2008/12/22/null
Walter Bright:
>No, it is done with one indirection.<
If even Andrei, a quite intelligent person that has written big books on C++,
may be wrong on such a basic thing, then I think there's a problem.
It can be good to create an html page that explains how some basic things of D
are implemented
Don:
> Maybe if D had better flow analysis, the demand for
> non-nullable references wouldn't be so great.
I know a good enough C# programmer that agrees with you, he says that thanks to
the flow analysis C#compiler performs, the need for non-nullable references is
not so strong.
> (Neither
bearophile Wrote:
> Don:
>
> > In the docs for "return statement" in statement.html it says:
> > ---
> > ReturnStatement:
> > return;
> > return Expression ;
> >
> > Expression is allowed even if the function specifies a void return type.
> > The Expression will be evaluated, but noth
On 2009-09-29 07:23:54 -0400, bearophile said:
This makes sense for things we definitely want to allow, such as:
void foo() { return bar(); }
where bar() is another void function.
If bar() is a void function then "return bar();" looks like a bug. Why
do you want to allow such semantically wr
On Tue, Sep 29, 2009 at 4:04 AM, Don wrote:
> Andrei Alexandrescu wrote:
>>
>> In this article:
>>
>> http://www.gotw.ca/publications/mill18.htm
>>
>> Herb Sutter makes a powerful argument that overridable functions
>> (customization points) should actually not be the same as the publically
>> ava
The following is a quote from the transcript of this:
http://www.infoq.com/interviews/armstrong-peyton-jones-erlang-haskell
(To see the whole transcript click on the "show all" button, and then select
"no style" if you use Firefox).
This part of the dialogue shows a possible usage for pure (or m
Don Wrote:
> In the docs for "return statement" in statement.html it says:
> ---
> ReturnStatement:
> return;
> return Expression ;
>
> Expression is allowed even if the function specifies a void return type.
> The Expression will be evaluated, but nothing will be returned.
>
>
>
On Tue, 29 Sep 2009 15:43:55 +0400, Jason House
wrote:
bearophile Wrote:
Don:
> In the docs for "return statement" in statement.html it says:
> ---
> ReturnStatement:
> return;
> return Expression ;
>
> Expression is allowed even if the function specifies a void return
type.
>
Don wrote:
In the docs for "return statement" in statement.html it says:
---
ReturnStatement:
return;
return Expression ;
Expression is allowed even if the function specifies a void return type.
The Expression will be evaluated, but nothing will be returned.
This makes sense for
Jason House wrote:
bearophile Wrote:
Don:
In the docs for "return statement" in statement.html it says:
---
ReturnStatement:
return;
return Expression ;
Expression is allowed even if the function specifies a void return type.
The Expression will be evaluated, but nothing will be r
Chris Nicholson-Sauls Wrote:
> bearophile wrote:
> > Walter Bright:
> >
> >> I've been thinking of transitioning dmd's semantic analysis to using
> >> immutable data structures because it will reduce allocations, not increase
> >> them.<
> >
> > As usual I am ignorant about such matters, so I
Adam D. Ruppe wrote:
On Fri, Sep 25, 2009 at 09:29:21AM +0200, Don wrote:
I demonstrated that the combination of CTFE + string mixins,
even in D1, was dramatically more powerful than the proposed macros. It
became clear that we didn't have a macro design that was anywhere near
powerful enough,
Derek Parnell wrote:
On Mon, 28 Sep 2009 19:27:03 -0500, Andrei Alexandrescu wrote:
language_fan wrote:
int min;
foreach(int value; list)
if (value < min) min = value;
Oops, you forgot to define a flag variable or initialize to int.min
You mean int.max :o).
if (list.length == 0)
bearophile wrote:
Walter Bright:
No, it is done with one indirection.<
If even Andrei, a quite intelligent person that has written big books on C++,
may be wrong on such a basic thing, then I think there's a problem.
It can be good to create an html page that explains how some basic things
Tim Matthews schrieb:
If no one has started on a D binding then maybe a C# binding would be an
ideal start?
http://www.opentk.com/news/C%2523-opencl-bindings-ready-for-testing
There also is a semiofficial C++ binding
(http://www.khronos.org/registry/cl/)
and one for Java (http://ochafik.free
Yigal Chripun wrote:
On 29/09/2009 00:31, Nick Sabalausky wrote:
"Yigal Chripun" wrote in message
news:h9r37i$tg...@digitalmars.com...
These aren't just marginal performance gains, they can easily be up to
15-30% improvements, sometimes 50% and more. If this is too complex or
the risk is to
Consider:
class Apple {}
class Orange {}
void main() {
writeln(new Apple == new Orange);
}
This program always prints "false". By and large, it is odd that one
would attempt comparison between unrelated classes. I was thinking, is
this ever legitimate, or we should just disallow it stati
bearophile wrote:
Don:
Maybe if D had better flow analysis, the demand for
non-nullable references wouldn't be so great.
I know a good enough C# programmer that agrees with you, he says that thanks to
the flow analysis C#compiler performs, the need for non-nullable references is
not so stro
Bill Baxter wrote:
On Tue, Sep 29, 2009 at 4:04 AM, Don wrote:
Andrei Alexandrescu wrote:
In this article:
http://www.gotw.ca/publications/mill18.htm
Herb Sutter makes a powerful argument that overridable functions
(customization points) should actually not be the same as the publically
avai
Andrei Alexandrescu wrote:
Consider:
class Apple {}
class Orange {}
void main() {
writeln(new Apple == new Orange);
}
This program always prints "false". By and large, it is odd that one
would attempt comparison between unrelated classes. I was thinking, is
this ever legitimate, or we s
Andrei Alexandrescu wrote:
Consider:
class Apple {}
class Orange {}
void main() {
writeln(new Apple == new Orange);
}
This program always prints "false". By and large, it is odd that one
would attempt comparison between unrelated classes. I was thinking, is
this ever legitimate, or we s
Trass3r wrote:
Tim Matthews schrieb:
If no one has started on a D binding then maybe a C# binding would be
an ideal start?
http://www.opentk.com/news/C%2523-opencl-bindings-ready-for-testing
There also is a semiofficial C++ binding
(http://www.khronos.org/registry/cl/)
and one for Java (htt
On Tue, 29 Sep 2009 18:54:28 +0400, Andrei Alexandrescu
wrote:
Consider:
class Apple {}
class Orange {}
void main() {
writeln(new Apple == new Orange);
}
This program always prints "false". By and large, it is odd that one
would attempt comparison between unrelated classes. I was t
Jeremie Pelletier:
> Flow analysis must be implemented by the compiler, nonnull references
> can be enforced by a runtime wrapper
The point of nonnull references is all in its compile-time enforced constraints.
> Besides DMD must have some basic flow analysis already since it does
> notice wh
Denis Koroskin:
> BTW, nowadays, they define IComparable interface, which is a
> recommended way to implement comparison functions.
>
> That's why I'm all for removing opEquals from Object.
I think that asks for some extra optimizations that I think currently D
front-end doesn't perform.
Bye
On Tue, Sep 29, 2009 at 11:17 AM, Denis Koroskin <2kor...@gmail.com> wrote:
>
> I believe Java and C# took bool Object.equals(Object other); way because
> they lacked generics intially and stored all the instances as Objects in
> containers (having equals method in Object allowed them proper orderi
bearophile wrote:
Jeremie Pelletier:
Flow analysis must be implemented by the compiler, nonnull references
can be enforced by a runtime wrapper
The point of nonnull references is all in its compile-time enforced constraints.
Besides DMD must have some basic flow analysis already since it do
On Mon, 28 Sep 2009 18:58:01 -0400, gzp wrote:
Hello,
Iám new to D so i might be all wrong. Given the code:
class Foo {
int opApply( int delegate(ref real) dg ) {...} //A.
int opApply( int delegate(real) dg ) {...} // B,
}
...
Foo foo = new Foo;
foreach( a; fo
Bill Baxter wrote:
On Tue, Sep 29, 2009 at 4:04 AM, Don wrote:
Andrei Alexandrescu wrote:
In this article:
http://www.gotw.ca/publications/mill18.htm
Herb Sutter makes a powerful argument that overridable functions
(customization points) should actually not be the same as the publically
avai
Jeremie Pelletier schrieb:
http://www.2shared.com/file/8117304/76c7c9ac/OpenCL.html
I wrote these some time ago after first hearing about OpenCL, only to
realize there was no implementations yet. Then I got a new laptop with a
9800M only to realize ATI had an OpenCL driver available days later
On Mon, 28 Sep 2009 21:43:20 -0400, Jesse Phillips
wrote:
On Mon, 28 Sep 2009 16:01:10 -0400, Steven Schveighoffer wrote:
On Mon, 28 Sep 2009 15:35:07 -0400, Jesse Phillips
wrote:
language_fan Wrote:
Have you ever used functional languages? When you develop in Haskell
or SML, how often
Trass3r wrote:
Jeremie Pelletier schrieb:
http://www.2shared.com/file/8117304/76c7c9ac/OpenCL.html
I wrote these some time ago after first hearing about OpenCL, only to
realize there was no implementations yet. Then I got a new laptop with
a 9800M only to realize ATI had an OpenCL driver avai
Ary Borenszweig wrote:
Andrei Alexandrescu wrote:
Consider:
class Apple {}
class Orange {}
void main() {
writeln(new Apple == new Orange);
}
This program always prints "false". By and large, it is odd that one
would attempt comparison between unrelated classes. I was thinking, is
this
Denis Koroskin wrote:
On Tue, 29 Sep 2009 18:54:28 +0400, Andrei Alexandrescu
wrote:
Consider:
class Apple {}
class Orange {}
void main() {
writeln(new Apple == new Orange);
}
This program always prints "false". By and large, it is odd that one
would attempt comparison between unrel
On Tue, Sep 29, 2009 at 8:46 AM, Don wrote:
> Bill Baxter wrote:
>>
>> On Tue, Sep 29, 2009 at 4:04 AM, Don wrote:
>>>
>>> Andrei Alexandrescu wrote:
In this article:
http://www.gotw.ca/publications/mill18.htm
Herb Sutter makes a powerful argument that overridable fu
Bill Baxter wrote:
On Tue, Sep 29, 2009 at 8:46 AM, Don wrote:
Bill Baxter wrote:
And also, is this statement true?
since C++ programmers tend to "when in doubt, make it virtual"
Do they? (Might be true, but I don't remember ever hearing it anywhere
else).
They might in practice, but the
== Quote from Jeremie Pelletier (jerem...@gmail.com)'s article
> Andrei Alexandrescu wrote:
> > Jeremie Pelletier wrote:
> >>> Is this Linux specific? what about other *nix systems, like BSD and
> >>> solaris?
> >>
> >> Signal handler are standard to most *nix platforms since they're part
> >> of t
== Quote from Sean Kelly (s...@invisibleduck.org)'s article
>
> One thing I'm not entirely sure about is whether the signal handler will
> always
> have a valid, C-style call stack tracing back into user code. These errors
> are
> triggered by hardware, and I really don't know what kind of trick
Sean Kelly wrote:
== Quote from Jeremie Pelletier (jerem...@gmail.com)'s article
Andrei Alexandrescu wrote:
Jeremie Pelletier wrote:
Is this Linux specific? what about other *nix systems, like BSD and
solaris?
Signal handler are standard to most *nix platforms since they're part
of the posix
Sean Kelly wrote:
== Quote from Sean Kelly (s...@invisibleduck.org)'s article
One thing I'm not entirely sure about is whether the signal handler will always
have a valid, C-style call stack tracing back into user code. These errors are
triggered by hardware, and I really don't know what kind o
On 29/09/2009 18:13, Andrei Alexandrescu wrote:
Denis Koroskin wrote:
On Tue, 29 Sep 2009 18:54:28 +0400, Andrei Alexandrescu
wrote:
Consider:
class Apple {}
class Orange {}
void main() {
writeln(new Apple == new Orange);
}
This program always prints "false". By and large, it is odd that o
Yigal Chripun wrote:
On 29/09/2009 18:13, Andrei Alexandrescu wrote:
Denis Koroskin wrote:
On Tue, 29 Sep 2009 18:54:28 +0400, Andrei Alexandrescu
wrote:
Consider:
class Apple {}
class Orange {}
void main() {
writeln(new Apple == new Orange);
}
This program always prints "false". By and l
bearophile wrote:
If even Andrei, a quite intelligent person that has written big books
on C++, may be wrong on such a basic thing, then I think there's a
problem.
Not everyone is an expert on everything, and how vptrs and vtbl[]s and
casting actually work for multiple inheritance is far from
== Quote from Jeremie Pelletier (jerem...@gmail.com)'s article
> Sean Kelly wrote:
> > == Quote from Sean Kelly (s...@invisibleduck.org)'s article
> >> One thing I'm not entirely sure about is whether the signal handler will
> >> always
> >> have a valid, C-style call stack tracing back into user
Jeremie Pelletier wrote:
> struct NonNull(C) if(is(C == class)) {
> C ref;
> invariant() { assert(ref !is null); }
> T opDot() { return ref; }
> }
This only catches null errors at runtime. The whole point of a non-null
type is to catch null errors at compile time.
--
Rainer Deyke -
Sean Kelly wrote:
== Quote from Jeremie Pelletier (jerem...@gmail.com)'s article
Sean Kelly wrote:
== Quote from Sean Kelly (s...@invisibleduck.org)'s article
One thing I'm not entirely sure about is whether the signal handler will always
have a valid, C-style call stack tracing back into user
Rainer Deyke wrote:
Jeremie Pelletier wrote:
struct NonNull(C) if(is(C == class)) {
C ref;
invariant() { assert(ref !is null); }
T opDot() { return ref; }
}
This only catches null errors at runtime. The whole point of a non-null
type is to catch null errors at compile time.
Tha
Jeremie Pelletier:
> Its dead easy to insert null into a nonnull reference,
If it's easy to put a null into a nonnull by *mistake*, then that system needs
to be designed better.
> and since you
> expect the type to never be null its the last thing you're gonna check.
I agree, but I think in
Jeremie Pelletier schrieb:
Some thing may have changed since then
Yeah, some constants have changed and a few functions.
I'm modifying the bindings right now.
Denis Koroskin wrote:
Unfortunately, you still have to special-case void type in a lot of
cases. Here are just 2 examples:
And that's why there were ideas to allow declaring void variables.
IMHO these void variables should allow all common operations on normal
variables (assignment, passing as
"Jeremie Pelletier" wrote in message
news:h9tv1s$do...@digitalmars.com...
> Rainer Deyke wrote:
>> Jeremie Pelletier wrote:
>>> struct NonNull(C) if(is(C == class)) {
>>> C ref;
>>> invariant() { assert(ref !is null); }
>>> T opDot() { return ref; }
>>> }
>>
>> This only catches null
Trass3r wrote:
Jeremie Pelletier schrieb:
Some thing may have changed since then
Yeah, some constants have changed and a few functions.
I'm modifying the bindings right now.
Cool, can you post a link to the updated version when you're done? I'm
gonna start toying with CL in a week or two wh
bearophile wrote:
This part of the dialogue shows a possible usage for pure (or more
pure) languages: to correctly implement, avoiding to go mad, very
tricky transactional algorithms.
D's scope statement specifically addresses transactional safety.
Marianne Gagnon Wrote:
> OS X uses \n. \r dates from OS 9 (see http://en.wikipedia.org/wiki/Newline)
>
> As simple as that ;)
IMHO \r as line separator and MacRoman encoding should be killed with fire.
I've had too much trouble with these OS9isms generated by some apps that tried
to be nice.
Here's my current version:
http://ul.to/be4o02
Jarrett Billingsley wrote:
On Tue, Sep 29, 2009 at 11:17 AM, Denis Koroskin <2kor...@gmail.com> wrote:
I believe Java and C# took bool Object.equals(Object other); way because
they lacked generics intially and stored all the instances as Objects in
containers (having equals method in Object allo
Andrei Alexandrescu wrote:
I seem to recall that
interface dispach in D does a linear search in the interfaces list, so
you may want to repeat your tests with a variable number of interfaces,
and a variable position of the interface being used.
Such numbers are not interesting to me. On avera
Jeremie Pelletier wrote:
> Rainer Deyke wrote:
>> This only catches null errors at runtime. The whole point of a non-null
>> type is to catch null errors at compile time.
>>
>
> Thats what flow analysis is for, since these are mostly uninitialized
> variables rather than null ones.
Nitpick: ther
On 29/09/2009 16:41, Jeremie Pelletier wrote:
What I argued about was your view on today's software being too big and
complex to bother optimize it.
that is not what I said.
I was saying that hand optimized code needs to be kept at minimum and
only for visible bottlenecks, because the risk o
67 matches
Mail list logo
