On 10-3-2010 8:11, Lionello Lunesu wrote:
I'll be presenting the D Programming Language at the next monthly BLUG
meeting. It'll mostly be for people who haven't heard of D yet. There'll
be a fair chunk of D1 in there, but I'm hoping to touch some of D2's new
features as well.
These meetings
ololo, dsource is down :3
Lionello Lunesu wrote:
The presentation came and went, and was much appreciated, judging from
the reactions :)
Great! I hope you enjoyed it as well.
I've done a bit of tinkering with the Juno library
(http://www.dsource.org/projects/juno) to both automate Office applications,
and to write a simple COM addin for Outlook. In both cases, that was using a
tool that creates D interface definitions from a COM type library.
My knowledge of D is
Steven Schveighoffer wrote:
On Tue, 13 Apr 2010 19:47:13 -0400, Jason House
jason.james.ho...@gmail.com wrote:
Steven Schveighoffer Wrote:
On Tue, 13 Apr 2010 15:50:36 -0400, Christoph Mueller
ruu...@googlemail.com wrote:
I'm currently writing a library in D2 which uses intensively
On Wed, 14 Apr 2010 07:29:28 -0400, Don nos...@nospam.com wrote:
Steven Schveighoffer wrote:
On Tue, 13 Apr 2010 19:47:13 -0400, Jason House
jason.james.ho...@gmail.com wrote:
Steven Schveighoffer Wrote:
On Tue, 13 Apr 2010 15:50:36 -0400, Christoph Mueller
ruu...@googlemail.com wrote:
Steven Schveighoffer Wrote:
Given that structs have become extremely powerful, and with the advent of
opDispatch, would it be possible to deprecate supporting COM via D
interfaces in favor of a library solution?
Don suggested defining them the same way as C++ classes.
There are some
On 14-apr-10, at 15:10, Steven Schveighoffer wrote:
On Wed, 14 Apr 2010 08:22:59 -0400, Jason House jason.james.ho...@gmail.com
wrote:
Steven Schveighoffer Wrote:
Given that structs have become extremely powerful, and with the
advent of
opDispatch, would it be possible to deprecate
Fawzi Mohamed wrote:
please note that multiple inheritance in interfaces is still buggy,
things like casting directly an interface to another (without casting to
object first) or taking a delegate to a method of a super interface that
is not the first one fail in ugly ways.
I have become very
On Wed, 14 Apr 2010 09:34:38 -0400, Fawzi Mohamed fa...@gmx.ch wrote:
On Wed, 14 Apr 2010 08:22:59 -0400, Jason House
jason.james.ho...@gmail.com wrote:
Don suggested defining them the same way as C++ classes.
I like this, implicit casting to object would be very convenient, but
note
On 14-apr-10, at 15:55, Walter Bright wrote:
Fawzi Mohamed wrote:
please note that multiple inheritance in interfaces is still buggy,
things like casting directly an interface to another (without
casting to object first) or taking a delegate to a method of a
super interface that is not
On 14-apr-10, at 16:08, Steven Schveighoffer wrote:
On Wed, 14 Apr 2010 09:34:38 -0400, Fawzi Mohamed fa...@gmx.ch
wrote:
On Wed, 14 Apr 2010 08:22:59 -0400, Jason House jason.james.ho...@gmail.com
wrote:
Don suggested defining them the same way as C++ classes.
I like this, implicit
Steven Schveighoffer Wrote:
Given that structs have become extremely powerful, and with the advent of
opDispatch, would it be possible to deprecate supporting COM via D
interfaces in favor of a library solution?
COM interface is not a D interface.
There are some crappy drawbacks for
Steven Schveighoffer Wrote:
Walter, can you confirm that extern(C++) interfaces are equivalent to
inheriting IUnknown? If not, what are the differences?
The difference is COM ABI is standardized, C++ ABI is implementation-defined.
If you are lucky, you can guess, which ABI is meant by
Kagamin wrote:
Steven Schveighoffer Wrote:
Walter, can you confirm that extern(C++) interfaces are equivalent to
inheriting IUnknown? If not, what are the differences?
The difference is COM ABI is standardized, C++ ABI is implementation-defined.
If you are lucky, you can guess, which ABI
Don Wrote:
I think that's extremely unlikely, since
MSVC defines __interface to be a COM interface.
It defines interface to be a C++ abstract class.
Sorry for the slow answer, I have some things to catch up.
Fawzi Mohamed:
integral overflow are helpful only if you have automatic conversion to a
larger type,
I don't understand what you mean here. There are various ways to detect
overflows, from the simple ones like using a long to compute
This recent blog post says nothing new for people that know C, it contains just
few notes about some undefined C behaviours, but it's a starting point for what
I want to say in this post:
http://james-iry.blogspot.com/2010/04/c-is-not-assembly.html
Undefined behaviours help adapt the language
bearophile wrote:
So far I've just given a light reading of the code. Notes:
- pow(x, 2) and sqrt(y) can be written as x ^^ 2 and y ^^ 0.5 (but you have to
import std.math anyway, because of a bug).
That's not a bug. It's intentional. x ^^ y will probably always require
import std.math,
Don wrote:
bearophile wrote:
So far I've just given a light reading of the code. Notes:
- pow(x, 2) and sqrt(y) can be written as x ^^ 2 and y ^^ 0.5 (but you
have to import std.math anyway, because of a bug).
That's not a bug. It's intentional. x ^^ y will probably always require
import
Lars T. Kyllingstad wrote:
Don wrote:
bearophile wrote:
So far I've just given a light reading of the code. Notes:
- pow(x, 2) and sqrt(y) can be written as x ^^ 2 and y ^^ 0.5 (but
you have to import std.math anyway, because of a bug).
That's not a bug. It's intentional. x ^^ y will
Don:
That's not a bug. It's intentional. x ^^ y will probably always require
import std.math, if y is a floating point number.
What's the rationale behind this decision?
I have filed it as a bug many days ago, because I think it's a wrong intention:
Don:
Thank you for your answer and comments.
Because pow() for floating point, when implemented properly, is a HUGE
function, that ends up dragging almost all of std.math into the
executable. And I think it's deceptive to do that silently.
To make it completely built-in, basically all of
bearophile wrote:
Don:
Thank you for your answer and comments.
Because pow() for floating point, when implemented properly, is a HUGE
function, that ends up dragging almost all of std.math into the
executable. And I think it's deceptive to do that silently.
To make it completely built-in,
Don wrote:
Lars T. Kyllingstad wrote:
Don wrote:
bearophile wrote:
So far I've just given a light reading of the code. Notes:
- pow(x, 2) and sqrt(y) can be written as x ^^ 2 and y ^^ 0.5 (but
you have to import std.math anyway, because of a bug).
That's not a bug. It's intentional. x ^^
Lars T. Kyllingstad wrote:
Don wrote:
Lars T. Kyllingstad wrote:
Don wrote:
bearophile wrote:
So far I've just given a light reading of the code. Notes:
- pow(x, 2) and sqrt(y) can be written as x ^^ 2 and y ^^ 0.5 (but
you have to import std.math anyway, because of a bug).
That's not a
- the two nested loops in the main are more efficient as ref double,
this is something dmd will need to fix;
A test shows that on ldc the two nested loops are a little faster without the
ref. I'd like the compiler to use a const ref with the foreach iterates on
array items bigger than a word.
I'm catching up with the posts.
Joseph Wakeling:
As for iteration, I don't know to what degree D's foreach() across
arrays compares to for() commands in C++ -- I guess it should be pretty
close in performance, no?
As you have seen from my benchmarks, when with dmd you use:
foreach (x; arr)
On 14/04/10 20:54, Don wrote:
I have a vague recollection that correctly-rounded pow() will require
bigint (can't quite remember, though). I'm also concerned about build
tools -- I don't want them to have to know about the dependency.
As a bare minimum, the error message will need to improve
http://d.puremagic.com/issues/show_bug.cgi?id=3415
Rainer Schuetze r.sagita...@gmx.de changed:
What|Removed |Added
Keywords||patch
http://d.puremagic.com/issues/show_bug.cgi?id=4089
--- Comment #1 from Rainer Schuetze r.sagita...@gmx.de 2010-04-14 00:44:11
PDT ---
sorry, the patch produced wrong brackets. Here's a better version:
Index: json.c
===
--- json.c
http://d.puremagic.com/issues/show_bug.cgi?id=3934
--- Comment #1 from bearophile_h...@eml.cc 2010-04-14 07:35:46 PDT ---
A person in the IRC channel suggests that this too can be bad (this program
compiles and runs with dmd 2.043):
extern struct foo;
void main() {}
--
Configure issuemail:
http://d.puremagic.com/issues/show_bug.cgi?id=2244
Fawzi Mohamed fa...@gmx.ch changed:
What|Removed |Added
Status|NEW |RESOLVED
http://d.puremagic.com/issues/show_bug.cgi?id=2683
Fawzi Mohamed fa...@gmx.ch changed:
What|Removed |Added
CC||elit...@gmx.de
---
http://d.puremagic.com/issues/show_bug.cgi?id=2437
Don clugd...@yahoo.com.au changed:
What|Removed |Added
Keywords||patch
--- Comment #6 from
http://d.puremagic.com/issues/show_bug.cgi?id=4077
--- Comment #8 from Sobirari Muhomori dfj1es...@sneakemail.com 2010-04-14
10:28:27 PDT ---
An academic example of use is to NOT short-circuit evaluation of operands.
--
Configure issuemail:
http://d.puremagic.com/issues/show_bug.cgi?id=2544
--- Comment #9 from Sobirari Muhomori dfj1es...@sneakemail.com 2010-04-14
10:36:19 PDT ---
(In reply to comment #5)
Although it is technically a subset of bug 2095
To be precise, it's theoretically a subset of 2095, but technically they are
http://d.puremagic.com/issues/show_bug.cgi?id=3971
--- Comment #2 from Sobirari Muhomori dfj1es...@sneakemail.com 2010-04-14
11:07:25 PDT ---
What static, dynamic, a and b mean? And those diagrams?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are
http://d.puremagic.com/issues/show_bug.cgi?id=3832
--- Comment #1 from bearophile_h...@eml.cc 2010-04-14 13:43:14 PDT ---
With dmd 2.043 that program generates the error messages:
test.d(2): Error: must import std.math to use ^^ operator
test.d(2): Error: undefined identifier module test.std
http://d.puremagic.com/issues/show_bug.cgi?id=4091
Summary: Small docs page about dynamic array implementation
Product: D
Version: future
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
http://d.puremagic.com/issues/show_bug.cgi?id=2544
Stewart Gordon s...@iname.com changed:
What|Removed |Added
OS/Version|Linux |All
--- Comment #10
Thanks!
This tool is probably the most helpful one for my D development.
42 matches
Mail list logo
