On Sun, 18 Apr 2010 17:06:22 +0200, Rainer Schuetze wrote:
Hello,
I'd like to announce the initial release of Visual D, a Visual Studio
package providing both project management and language services for
integration of the D programming language into Visual Studio.
The cv2pdb was already
Chris Mueller wrote:
I also hope some videos will be available for this event :)
That would be great!
Sorry, there were no videos taken of the event.
Now we have reached #56 :)
Let's go clicking to get #1
exactly how to we do this? There is not 'buy now' button.
click cover - click a buy-button :)
or even better - preorder the book!! (that would help more, since
this bestsellerlist will be uncovered ...)
no matter the name. it is the accuracy that matters.
so: could we have it in D?
Hi,
you don't need to create json-files per d-file. I added the -Xf option
to the lib-generating line in druntime/win32.mak:
### Library generation #
$(DRUNTIME): $(OBJS) $(SRCS) win32.mak
$(DMD) -lib -Xf..\json\druntime.json -of$(DRUNTIME) $(DFLAGS)
I would like to propose two improvements to the DDoc system. They
should both be possible to implement, since DDoc is built into the compiler.
1. Aliases documented as what they're aliasing
Take the following code:
void foo(T)(T t) { ... }
/// Integer foo.
alias foo!int intFoo;
I've uploaded my json-files here:
http://www.dsource.org/projects/visuald/browser/downloads/phobos-2.043-json.zip?format=raw
I'm using a patched version of druntime, so not everything in there
might be matching your sources. The phobos file is the more interesting
part anyway.
BCS wrote:
Walter Bright wrote:
* People really understand and get testing and how it improves programming.
For example, this hilarious video was shown by James Bach, who created it:
http://www.youtube.com/watch?v=M37VOKIaDUw
Walter Bright:
* Not all functional programming languages do concurrency well. Haskell and
OCaml in particular have severe fundamental problems with it such that
parallelizing your code makes it slower.
What kind of problems have you seen in Haskell?
I have read several articles about parallel
Robert Jacques:
Ray-tracers are insanely memory IO bound, not compute bound,
From my experiments those little ray-tracers are mostly bound to the time
taken by the ray intersection tests.
So what you're seeing is the difference between 80-bits and 64-bits of memory,
not the FP performance.
On 4/23/10 02:14, Adam D. Ruppe wrote:
On Thu, Apr 22, 2010 at 07:48:31PM -0400, bearophile wrote:
The third solution is what I'd like to be able to write.
How about this?
===
import std.stdio;
import std.traits;
int add(int a, int b) { return a+b; }
int mul(int a, int b) { return a*b; }
Walter Bright Wrote:
* Not all functional programming languages do concurrency well. Haskell and
OCaml in particular have severe fundamental problems with it such that
parallelizing your code makes it slower.
Do you have a reference on that? I'll produce one to the contrary:
On 4/23/10 01:48, bearophile wrote:
In Python I sometimes use the name of a given function reference (all lambdas are named
lambda), this is a minimal example:
def add(a, b): return a + b
def mul(a, b): return a * b
for func in [add, mul]:
print func.__name__, func(10, 20)
In D for
Jacob Carlborg:
I think http://www.dsource.org/projects/flectioned is what you are
looking for. Don't know if it still works though.
Thank you for the link, I have forgotten about flectioned.
Some of those capabilities of flectioned are important enough to deserve to be
inside Phobos2 (or
bearophile wrote:
Walter Bright:
* Not all functional programming languages do concurrency well. Haskell and
OCaml in particular have severe fundamental problems with it such that
parallelizing your code makes it slower.
What kind of problems have you seen in Haskell? I have read several
Clemens wrote:
Walter Bright Wrote:
* Not all functional programming languages do concurrency well. Haskell and
OCaml in particular have severe fundamental problems with it such that
parallelizing your code makes it slower.
Do you have a reference on that? I'll produce one to the contrary:
Walter Bright wrote:
It wasn't me, it was Russell Wider.
That's Russel Winder.
Walter Bright:
It wasn't me, it was Russell Wider. He wrote a parallel pi calculating
program
in several languages, and then tried it with 1, 2, 4, and 8 cores. The more
cores, the longer the Haskell program took. Charting the core use showed that
only one core would run at a time.
bearophile wrote:
Walter Bright:
OCaml has a global interpreter lock which explains its behavior. Russell
didn't know why the Haskell behavior was so bad. He allowed that it was
possible he was misusing it.
You have just the illusion to have learned something about this. Trying to
read too
On Fri, Apr 23, 2010 at 02:02:57PM +0200, Jacob Carlborg wrote:
Yes we still need classinfo, if you you store an object in a base class
reference classinfo will give you the runtime type (the subclass) and
__traits will give you the compile time type (the base class).
Ah, of course, that
Is this a bug, or am I being dense? I've tried it this on 2.036,2.042
and 2.043 and on each the compiler produces errors. Searched bugzilla
for template and instantiated and template and instantiate
struct A(uint N) {
}
void unary_op(uint N)(A!(N)) {
}
void main() {
A!(3) a3;
Clemens wrote:
Ah, ok. As bearophile noted, that person seems to have not much experience
with Haskell, to put it politely. Obviously I didn't see the presentation and
don't want to judge too harshly, but if your summary is an accurate
representation of its take-away points, that reeks badly of
Gareth Charnock wrote:
Is this a bug, or am I being dense? I've tried it this on 2.036,2.042
and 2.043 and on each the compiler produces errors. Searched bugzilla
for template and instantiated and template and instantiate
struct A(uint N) {
}
void unary_op(uint N)(A!(N)) {
}
void main() {
On Fri, 23 Apr 2010 10:25:35 -0300, Gareth Charnock gar...@oerc.ox.ac.uk
wrote:
Is this a bug, or am I being dense? I've tried it this on 2.036,2.042
and 2.043 and on each the compiler produces errors. Searched bugzilla
for template and instantiated and template and instantiate
struct
On Fri, 23 Apr 2010 09:43:10 -0300, Robert Jacques sandf...@jhu.edu
wrote:
On Fri, 23 Apr 2010 10:25:35 -0300, Gareth Charnock
gar...@oerc.ox.ac.uk wrote:
Is this a bug, or am I being dense? I've tried it this on 2.036,2.042
and 2.043 and on each the compiler produces errors. Searched
Thanks!
Robert Jacques wrote:
On Fri, 23 Apr 2010 10:25:35 -0300, Gareth Charnock
gar...@oerc.ox.ac.uk wrote:
Is this a bug, or am I being dense? I've tried it this on 2.036,2.042
and 2.043 and on each the compiler produces errors. Searched bugzilla
for template and instantiated and template
On 04/23/2010 07:00 AM, Clemens wrote:
(As an aside, I'm generally a bit put off by the
hostility towards programming language research and theory in the D
community. We don't need no stinking theory, we'll just roll our own
ad-hoc solution which will work much better because ivory-tower
On 04/23/2010 08:30 AM, Walter Bright wrote:
Clemens wrote:
Ah, ok. As bearophile noted, that person seems to have not much
experience
with Haskell, to put it politely. Obviously I didn't see the
presentation and
don't want to judge too harshly, but if your summary is an accurate
representation
...er... ...
I think I'll just put on the dunce hat and stand in the corner then.
This is why, as someone with dyslexia, I like statically typed
languages. I hate finding out about these errors at runtime.
Lars T. Kyllingstad wrote:
Gareth Charnock wrote:
Is this a bug, or am I being dense?
Michael Rynn wrote:
OK where's the naive version of the D Pi program that scales up with
1,2,4 cores? How far off are we? Is the concurrency module working with
it yet?
Nobody's written a library function to parallelize a map/reduce yet.
Andrei Alexandrescu wrote:
On 04/23/2010 08:30 AM, Walter Bright wrote:
For example, Andrei has expended a great deal of effort on making the
naive use of stdio also the fast way.
And the correct way.
Yes.
BTW, if it isn't obvious, the Erlang and Clojure versions of the Pi program were
Walter Bright Wrote:
Clemens wrote:
Ah, ok. As bearophile noted, that person seems to have not much experience
with Haskell, to put it politely. Obviously I didn't see the presentation
and
don't want to judge too harshly, but if your summary is an accurate
representation of its
On Fri, 23 Apr 2010 11:10:48 -0300, Walter Bright
newshou...@digitalmars.com wrote:
Michael Rynn wrote:
OK where's the naive version of the D Pi program that scales up with
1,2,4 cores? How far off are we? Is the concurrency module working with
it yet?
Nobody's written a library
Clemens wrote:
I tried to have a look at it (not that I'm anything near a Haskell expert), but
this link just gives me an empty directory:
http://www.russel.org.uk/Bazaar/Pi_Quadrature
I'll see if Russel will email me the code.
Robert Jacques wrote:
On Fri, 23 Apr 2010 11:10:48 -0300, Walter Bright
newshou...@digitalmars.com wrote:
Michael Rynn wrote:
OK where's the naive version of the D Pi program that scales up with
1,2,4 cores? How far off are we? Is the concurrency module working
with it yet?
Nobody's
On Fri, 23 Apr 2010 11:16:29 -0300, Clemens eriatark...@gmail.com wrote:
[snip]
I tried to have a look at it (not that I'm anything near a Haskell
expert), but this link just gives me an empty directory:
http://www.russel.org.uk/Bazaar/Pi_Quadrature
Try
Walter Bright, el 23 de abril a las 06:30 me escribiste:
Clemens wrote:
Ah, ok. As bearophile noted, that person seems to have not much experience
with Haskell, to put it politely. Obviously I didn't see the presentation and
don't want to judge too harshly, but if your summary is an accurate
Clemens, el 23 de abril a las 09:06 me escribiste:
All I've got is Russel Winder's talk on it, Parallelism: The Functional
Imperative, with the code and benchmarks. He ran them in real time.
http://www.russel.org.uk/
Ah, ok. As bearophile noted, that person seems to have not much
Hello bearophile,
Even if you are right, real-life programs often need to process good
amounts of memory, so using reals they are slower.
Exactly, that is the one case where float and double are better, where large
volumes of data need to be processed, normally in a regular fashion. For
Clemens:
I'd really recommend spending a few days with Haskell.
I think 5 days of serious use are enough for Walter to learn some of the ideas
of C#4 and its IDE. But I don't think few days are enough to learn the ideas of
Haskell.
Bye,
bearophile
Walter Bright:
You shouldn't have to be an expert in a language that is supposedly good at
parallelism in order to get good results from it.
Being easy to learn to use is not one of the qualities of Haskell. If you want
to write efficient programs in Haskell you need lot of brain, you can see
bearophile wrote:
Being Haskell not easy, it's even possible for me to not understand the
explanation if some Haskell expert eventually explains me why that Haskell
program was slow :-)
It's statements like this (and I've heard this repeatedly) that makes me wonder
what the value of Haskell
Leandro Lucarella wrote:
Walter Bright, el 23 de abril a las 06:30 me escribiste:
Clemens wrote:
Ah, ok. As bearophile noted, that person seems to have not much experience
with Haskell, to put it politely. Obviously I didn't see the presentation and
don't want to judge too harshly, but if your
Walter Bright wrote:
Robert Jacques wrote:
On Fri, 23 Apr 2010 11:10:48 -0300, Walter Bright
newshou...@digitalmars.com wrote:
Michael Rynn wrote:
OK where's the naive version of the D Pi program that scales up with
1,2,4 cores? How far off are we? Is the concurrency module working
with it
BCS wrote:
Hello bearophile,
Even if you are right, real-life programs often need to process good
amounts of memory, so using reals they are slower.
Exactly, that is the one case where float and double are better, where
large volumes of data need to be processed, normally in a regular
Don wrote:
A simple rule of thumb: if it's an array, use float or double. If it's
not, use real.
I agree. The only reason to use float or double is to save on storage.
Nick Sabalausky wrote:
Walter Bright newshou...@digitalmars.com wrote in message
news:hqsn2j$1s2...@digitalmars.com...
bearophile wrote:
Being Haskell not easy, it's even possible for me to not understand the
explanation if some Haskell expert eventually explains me why that
Haskell
program
Walter Bright:
I agree. The only reason to use float or double is to save on storage.
A little D1 program, that I compile with LDC:
import tango.stdc.stdio: printf;
import tango.stdc.stdlib: atof;
alias real FP;
void main() {
FP x = atof(1.5);
FP y = atof(2.5);
FP xy = x * y;
Walter Bright newshou...@digitalmars.com wrote in message
news:hqsuac$29r...@digitalmars.com...
Nick Sabalausky wrote:
Walter Bright newshou...@digitalmars.com wrote in message
news:hqsn2j$1s2...@digitalmars.com...
bearophile wrote:
Being Haskell not easy, it's even possible for me to not
Don:
A simple rule of thumb: if it's an array, use float or double. If it's
not, use real.
The rule of thumb from me is: if you care for performance never use real type.
Bye,
bearophile
On Fri, Apr 23, 2010 at 14:57, Robert Jacques sandf...@jhu.edu wrote:
PS. You can get things like this to work using template constraints.
For example, here's a horrible hack:
void unary_op(T)(T value)
if(T.stringof[0..3] == A!( T.stringof[$-1..$] == ) ){}
Maybe a bit less hacky (?)
Walter Bright Wrote:
Don wrote:
A simple rule of thumb: if it's an array, use float or double. If it's
not, use real.
I agree. The only reason to use float or double is to save on storage.
There is another reason: performance, when combined with vectorized code. If I
use 4 32-bit
On 23/04/2010 18:37, bearophile wrote:
Clemens:
I'd really recommend spending a few days with Haskell.
I think 5 days of serious use are enough for Walter to learn some of the ideas
of C#4 and its IDE. But I don't think few days are enough to learn the ideas of
Haskell.
Bye,
bearophile
Mike Farnsworth wrote:
There is another reason: performance, when combined with vectorized code. If
I use 4 32-bit floats to represent my vectors, points, etc. in my ray tracer,
I can stuff them into an SSE register and use intrinsics to really, *really*
speed it up. Especially if I use the
Fri, 23 Apr 2010 10:57:31 -0700, Walter Bright wrote:
bearophile wrote:
Being Haskell not easy, it's even possible for me to not understand the
explanation if some Haskell expert eventually explains me why that
Haskell program was slow :-)
It's statements like this (and I've heard this
Fri, 23 Apr 2010 08:57:54 -0500, Andrei Alexandrescu wrote:
On 04/23/2010 07:00 AM, Clemens wrote:
(As an aside, I'm generally a bit put off by the hostility towards
programming language research and theory in the D community. We don't
need no stinking theory, we'll just roll our own ad-hoc
Fri, 23 Apr 2010 06:23:22 -0700, Walter Bright wrote:
bearophile wrote:
Walter Bright:
OCaml has a global interpreter lock which explains its behavior.
Russell didn't know why the Haskell behavior was so bad. He allowed
that it was possible he was misusing it.
You have just the illusion
Fri, 23 Apr 2010 08:00:32 -0400, Clemens wrote:
If you try to put ideas of
pure functional programming into D, I think it would be a good idea to
at least be somewhat familiar with the way the reigning king of that
particular niche does it.
Maybe Walter is trying to break the world record
Tue, 20 Apr 2010 21:38:57 -0400, Nick Sabalausky wrote:
Nick Sabalausky a...@a.a wrote in message
news:hqljod$ca...@digitalmars.com...
Justin Johansson n...@spam.com wrote in message
news:hqk7ve$2ou...@digitalmars.com...
my current thinking seems to be aligning with others that JavaScript
Walter Bright Wrote:
Don wrote:
A simple rule of thumb: if it's an array, use float or double. If it's
not, use real.
I agree. The only reason to use float or double is to save on storage.
Portability will become more important as evo algos get used more.
Especially in combination with
On Fri, 23 Apr 2010 19:09:55 -0400, retard r...@tard.com.invalid wrote:
Fri, 23 Apr 2010 06:23:22 -0700, Walter Bright wrote:
You shouldn't have to be an expert in a language that is supposedly good
at parallelism in order to get good results from it.
Why not? Do you think parallelism is
OK,
So I'm just finishing up porting dcollections into D2, and I came across
this sucky problem:
range opSlice(cursor b, cursor e)
{
// for hashmap, we only support ranges that begin on the first
cursor,
// or end on the last cursor.
if((b == begin
retard r...@tard.com.invalid wrote in message
news:hqt9pa$2sg...@digitalmars.com...
Tue, 20 Apr 2010 21:35:03 -0400, bearophile wrote:
Nick Sabalausky:
I use Haxe for any and all PHP and Flash development
I have an OT question: Haxe and similar things add another layer between
the code you
retard r...@tard.com.invalid wrote in message
news:hqtaa3$307...@digitalmars.com...
Tue, 20 Apr 2010 21:38:57 -0400, Nick Sabalausky wrote:
Nick Sabalausky a...@a.a wrote in message
news:hqljod$ca...@digitalmars.com...
Justin Johansson n...@spam.com wrote in message
retard r...@tard.com.invalid wrote in message
news:hqt94i$2sg...@digitalmars.com...
Fri, 23 Apr 2010 08:57:54 -0500, Andrei Alexandrescu wrote:
On 04/23/2010 07:00 AM, Clemens wrote:
(As an aside, I'm generally a bit put off by the hostility towards
programming language research and theory
Steven Schveighoffer さんは書きました:
OK,
So I'm just finishing up porting dcollections into D2, and I came across
this sucky problem:
range opSlice(cursor b, cursor e)
{
// for hashmap, we only support ranges that begin on the first
cursor,
// or end on the last cursor.
Steven Schveighoffer wrote:
No, the problem is that it potentially makes him give away the rights
to the dmd backend. Which I think he can't legally do, even if he
wanted to.
I don't think there is any danger of this, it would be well established
that Walter wrote all his proprietary
On Fri, 23 Apr 2010 11:55:42 -0400, Joseph Wakeling
joseph.wakel...@webdrake.net wrote:
Steven Schveighoffer wrote:
Personally, I am not too concerned about the backend performance, it's
not critical to D at this time. Someone, somewhere, will make this
better, and then any code written in
Steven Schveighoffer wrote:
As long as you discount the vast differences in allocation performance,
the code generated should be just as good as code generated by a C++
compiler. Your interpretation of performance did not focus on the right
part :) Your test application heavily used
On 23/04/10 17:22, #ponce wrote:
In C++ implicit constructors and conversion operators allow a user-defined type
to act quite like a builtin-type.
struct half
{
half(float x);l
inline operator float() const;
}
allows to write:
half x = 1.f;
float f = x;
and this
On Fri, 23 Apr 2010 12:28:55 -0400, Joseph Wakeling
joseph.wakel...@webdrake.net wrote:
Steven Schveighoffer wrote:
As long as you discount the vast differences in allocation performance,
the code generated should be just as good as code generated by a C++
compiler. Your interpretation of
Steven Schveighoffer wrote:
I do see the point about allocation and reallocation -- what was
bothering me a bit was that even taking those aspects out of the code
and preallocating everything, I could write C++ code that _didn't_
preallocate and still ran (much) faster ... :-)
If you are
Joseph Wakeling wrote:
No ... ! That was true in the original code I posted, but following
bearophile's kind example that part of the code was updated to a form
along the lines of,
Just for reference, here are the two pieces of code, for side-by-side
comparison. As far as I can tell the
On Fri, 23 Apr 2010 14:00:50 -0400, Joseph Wakeling
joseph.wakel...@webdrake.net wrote:
Joseph Wakeling wrote:
No ... ! That was true in the original code I posted, but following
bearophile's kind example that part of the code was updated to a form
along the lines of,
Just for reference,
On Fri, Apr 23, 2010 at 18:46, Robert Clipsham rob...@octarineparrot.comwrote:
On 23/04/10 17:22, #ponce wrote:
In C++ implicit constructors and conversion operators allow a user-defined
type to act quite like a builtin-type.
struct half
{
half(float x);l
inline operator
http://d.puremagic.com/issues/show_bug.cgi?id=3207
--- Comment #13 from Leandro Lucarella llu...@gmail.com 2010-04-23 07:39:00
PDT ---
The last thread in the review process is here:
http://thread.gmane.org/gmane.comp.gdb.patches/57197
From this:
Mihail Sorry for too very long delay. I fix
http://d.puremagic.com/issues/show_bug.cgi?id=3809
--- Comment #2 from Don clugd...@yahoo.com.au 2010-04-23 12:51:54 PDT ---
Starting with the simple thing: the missing line number in the division by 0
error message.
PATCH: interpret.c, near the start of BinExp::interpretAssignCommon().
http://d.puremagic.com/issues/show_bug.cgi?id=3538
Robert Clipsham rob...@octarineparrot.com changed:
What|Removed |Added
Keywords||patch
http://d.puremagic.com/issues/show_bug.cgi?id=3809
--- Comment #3 from Don clugd...@yahoo.com.au 2010-04-23 12:58:21 PDT ---
(In reply to comment #2)
Starting with the simple thing: the missing line number in the division by 0
error message.
PATCH: interpret.c, near the start of
http://d.puremagic.com/issues/show_bug.cgi?id=4059
Robert Clipsham rob...@octarineparrot.com changed:
What|Removed |Added
Keywords||patch
---
http://d.puremagic.com/issues/show_bug.cgi?id=2484
nfx...@gmail.com changed:
What|Removed |Added
CC||nfx...@gmail.com
--- Comment #4
81 matches
Mail list logo
