We're back in business publishing DConf talks!
https://news.ycombinator.com/newest (please vote quickly)
https://twitter.com/D_Programming/status/484730864220504064
https://www.facebook.com/dlang.org/posts/877858112227871
http://youtu.be/cJGNItlMWBM
Sorry for the unusual formatting.
Paul
A candidate implementation of decimal numbers (arbitrary-precision
floating-point numbers) is available for review at
https://github.com/andersonpd/eris/tree/master/eris/decimal. This
is a
substantial rework of an earlier implementation which was located
at
After the success of the last D hackday, EMSI is going to attempt to have
a D hackday once a month as close as we can to the first Friday of the
month. Our next round will be Friday July 11.
Last time 24 issues were marked as resolved by the community (including
EMSI).
Please join us in
On Thursday, 3 July 2014 at 23:17:33 UTC, Jonathan Crapuchettes
wrote:
After the success of the last D hackday, EMSI is going to
attempt to have
a D hackday once a month as close as we can to the first Friday
of the
month. Our next round will be Friday July 11.
Last time 24 issues were marked
Encountering issues posting the 2.066.0-b1
A number of technical difficulties resulted in a delayed beta review.
The review period has commenced and will continue until 0700 UTC (
PDT) 14 July 2014. Your assistance in identifying and reporting bugs are
greatly appreciated.
Binaries are located here:
ALL
On 7/3/2014 6:13 PM, Andrew Edwards wrote:
A number of technical difficulties resulted in a delayed beta review. The review
period has commenced and will continue until 0700 UTC ( PDT) 14 July 2014.
Thank you, Andrew!
The same set of available files are also here:
http://downloads.dlang.org/pre-releases/2014/
NOTE: The amd64 linux build is listed as available, but it's not, yet.
On 7/3/14, 6:13 PM, Andrew Edwards via Digitalmars-d-announce wrote:
A number of technical difficulties resulted in a delayed
On Thursday, 3 July 2014 at 23:17:33 UTC, Jonathan Crapuchettes
wrote:
After the success of the last D hackday, EMSI is going to
attempt to have
a D hackday once a month as close as we can to the first Friday
of the
month. Our next round will be Friday July 11.
Last time 24 issues were marked
I think it's better to remove mention about D1 on main page. It's
not actual and present time. But now it's took to many space...
On 3 Jul 2014 01:50, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 7/2/2014 2:28 PM, Iain Buclaw via Digitalmars-d wrote:
On 2 July 2014 19:58, via Digitalmars-d digitalmars-d@puremagic.com
wrote:
I don't really understand the reasoning here. Is D Intel x86 specific?
On 3 Jul 2014 04:50, Sean Kelly via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Thursday, 3 July 2014 at 01:13:13 UTC, H. S. Teoh via Digitalmars-d
wrote:
I'm not sure I understand how removing support 80-bit floats hurts
interoperability with C? I thought none of the standard C
On Wednesday, 2 July 2014 at 12:24:51 UTC, Ola Fosheim Grøstad
wrote:
On Wednesday, 2 July 2014 at 12:16:18 UTC, Wanderer wrote:
D is not even production ready, so why should there be? Who in
their right mind would use a language in limbo for building a
serious operating system or do embedded
On 7/2/2014 6:11 PM, H. S. Teoh via Digitalmars-d wrote:
What should we do in the case of hardware that offers strange hardware
types, like a hypothetical 48-bit floating point type? Should D offer a
built-in type for that purpose, even if it only exists on a single chip
that's used by 0.01% of
On 7/2/2014 11:38 PM, Iain Buclaw via Digitalmars-d wrote:
I suppose I am just a bit. At the time I was thinking about the spec on _argptr
(which has been fixed), __simd and intrinsics.
You do have a good point with those aspects.
On 7/2/2014 8:48 PM, Sean Kelly wrote:
I'm still unclear whether we're aiming for C interoperability or hardware
support though, based on Walter's remark about SPARC and PPC. There, 'long
double' is represented differently but is not backed by specialized hardware, so
I'm guessing D would make
On Monday, 23 June 2014 at 16:33:13 UTC, Chris Cain wrote:
It's not really about the time complexity but the absolute time
it must take. But I showed the example that shows that the fact
that any stable sort must do extra work:
[2,2,2,2,1]
An unstable sort may swap the first 2 and the 1
On 7/3/14, 12:29 AM, Wanderer wrote:
Nobody, never, measures sort algorithms by amount of swaps.
That... is quite the claim. -- Andrei
On 03/07/2014 12:40 AM, deadalnix wrote:
On Wednesday, 2 July 2014 at 19:05:56 UTC, Walter Bright wrote:
On 7/2/2014 11:08 AM, Gary Willoughby wrote:
Here is one of my all time favourite talks from Steve Yegge (Senior
Engineer at
Google) at OSCON 2007 entitled How to Ignore Marketing and
On Wednesday, 2 July 2014 at 17:34:46 UTC, Gary Willoughby wrote:
On Wednesday, 2 July 2014 at 11:02:58 UTC, Dicebot wrote:
We don't have any recognizable branding worth fighting for. I
can't even remember how current D logo looks like without
checking the website, it is just some image in the
On Wednesday, 2 July 2014 at 23:32:36 UTC, w0rp wrote:
I just brought the Twitter module back.
:( it was so much better with this ugly widget gone and replaced
with something actually useful.
This is a topic I've already discussed a little in past.
In D I use tuples often, and I print them all the time, mostly
while I write the code. Ranges of tuples are generated by some
Phobos functions, and are generated by my map functios too. But
if you print those ranges you quickly find a
On Thursday, 3 July 2014 at 00:49:33 UTC, Walter Bright wrote:
On 7/2/2014 2:28 PM, Iain Buclaw via Digitalmars-d wrote:
On 2 July 2014 19:58, via Digitalmars-d
digitalmars-d@puremagic.com wrote:
I don't really understand the reasoning here. Is D Intel x86
specific?
Yes it is, more than you
On Thursday, 3 July 2014 at 07:29:42 UTC, Wanderer wrote:
Nobody, never, measures sort algorithms by amount of swaps.
What if you're sorting a large database with large records?
On Wed, 02 Jul 2014 23:56:21 -0700
Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote:
On 7/2/2014 8:48 PM, Sean Kelly wrote:
I'm still unclear whether we're aiming for C interoperability or
hardware support though, based on Walter's remark about SPARC and
PPC. There, 'long
I'm sorry to bump up an old thread, but whatever happened to
this? I was just using 'groupby' in Python for a common data
migration pattern I've developed...
# Build a dictionary of parent - child relationships
# from a datbase query, for quick and dirty data migration.
# This runs in linear
On Thursday, 3 July 2014 at 10:48:53 UTC, w0rp wrote:
y[0], tuple(y[1])
That's suppose to be a : there sorry, not a comma.
On 3 July 2014 11:49, Jonathan M Davis via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Wed, 02 Jul 2014 23:56:21 -0700
Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote:
On 7/2/2014 8:48 PM, Sean Kelly wrote:
I'm still unclear whether we're aiming for C
On 03/07/2014 9:13 AM, Andrei Alexandrescu wrote:
On 7/3/14, 12:29 AM, Wanderer wrote:
Nobody, never, measures sort algorithms by amount of swaps.
That... is quite the claim. -- Andrei
Most of the algorithm rankings I am aware of list both compares and
swaps, because which one has the
On 03/07/2014 10:40 AM, Dicebot wrote:
On Wednesday, 2 July 2014 at 17:34:46 UTC, Gary Willoughby wrote:
On Wednesday, 2 July 2014 at 11:02:58 UTC, Dicebot wrote:
We don't have any recognizable branding worth fighting for. I can't
even remember how current D logo looks like without checking
On Thursday, 3 July 2014 at 09:42:05 UTC, Dicebot wrote:
On Wednesday, 2 July 2014 at 23:32:36 UTC, w0rp wrote:
I just brought the Twitter module back.
:( it was so much better with this ugly widget gone and
replaced with something actually useful.
I actually didn't intend to remove it
On 03/07/2014 10:40 AM, Dicebot wrote:
On Wednesday, 2 July 2014 at 17:34:46 UTC, Gary Willoughby wrote:
On Wednesday, 2 July 2014 at 11:02:58 UTC, Dicebot wrote:
We don't have any recognizable branding worth fighting for. I can't
even remember how current D logo looks like without checking
On 03/07/2014 12:35 PM, w0rp wrote:
On Thursday, 3 July 2014 at 09:42:05 UTC, Dicebot wrote:
On Wednesday, 2 July 2014 at 23:32:36 UTC, w0rp wrote:
I just brought the Twitter module back.
:( it was so much better with this ugly widget gone and replaced with
something actually useful.
I
On 3 July 2014 12:40, Alix Pexton via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 03/07/2014 10:40 AM, Dicebot wrote:
On Wednesday, 2 July 2014 at 17:34:46 UTC, Gary Willoughby wrote:
On Wednesday, 2 July 2014 at 11:02:58 UTC, Dicebot wrote:
We don't have any recognizable branding
On 07/03/2014 05:16 AM, Wanderer wrote:
On Wednesday, 2 July 2014 at 17:21:36 UTC, Jonathan M Davis via
Digitalmars-d wrote:
By not putting these functions on Object, it allows them to have whatever
attributes they need when declared in derived types. Without that,
we're stuck
That's not the
On Thursday, 3 July 2014 at 11:35:36 UTC, w0rp wrote:
On Thursday, 3 July 2014 at 09:42:05 UTC, Dicebot wrote:
On Wednesday, 2 July 2014 at 23:32:36 UTC, w0rp wrote:
I just brought the Twitter module back.
:( it was so much better with this ugly widget gone and
replaced with something
On Thursday, 3 July 2014 at 11:40:34 UTC, Alix Pexton wrote:
I started working on this little document last night while
angry and tired, maybe it should find its way to the wiki.
https://docs.google.com/document/d/1Sb4xnZUbzVRIicsfnxBFhTvRH4EOYq88wZexAuGcnaE/edit
Its the last time I'm going
On 03/07/2014 1:00 PM, Iain Buclaw via Digitalmars-d wrote:
You mispelt Useage
/spelling troll
There is no red underline this end and invoking the spell checker is
only finding the hex colour codes at the moment. But means nothing as I
discovered just this morning that the google docs
On Wednesday, 2 July 2014 at 20:04:50 UTC, Gary Willoughby wrote:
The 'new' design by w0rp (http://w0rp.com:8010/) does none of
those things. He's well intentioned but even things like basic
text layout and white space usage are completely lacking.
I didn't notice that link before, and if on
On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic
wrote:
Hello,
I've been D enthusiast for couple of years now (but I do not
participate much in discussions here, although I read forums
almost daily), and I keep telling people about D and how
awesome it is.
But, all this time
On Thursday, 3 July 2014 at 11:21:34 UTC, Iain Buclaw via
Digitalmars-d wrote:
The spec should be clearer on that. The language should
respect the long double ABI of the platform it is targeting
- so if the compiler is targeting a real=96bit system, but
the max supported on the chip is
On 3 July 2014 14:51, Joseph Rushton Wakeling via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Thursday, 3 July 2014 at 11:21:34 UTC, Iain Buclaw via Digitalmars-d
wrote:
The spec should be clearer on that. The language should respect the long
double ABI of the platform it is
On Thursday, 3 July 2014 at 11:40:34 UTC, Alix Pexton wrote:
I agree!
I started working on this little document last night while
angry and tired, maybe it should find its way to the wiki.
https://docs.google.com/document/d/1Sb4xnZUbzVRIicsfnxBFhTvRH4EOYq88wZexAuGcnaE/edit
Very nice; thank
On Thursday, 3 July 2014 at 10:13:20 UTC, ed wrote:
What if you're sorting a large database with large records?
Databases don't sort their records physically. The main reason
for that is that each record has many columns so there are many
various possible sort orders.
Instead, databases
On 03/07/2014 3:44 PM, Wyatt wrote:
On Thursday, 3 July 2014 at 11:40:34 UTC, Alix Pexton wrote:
I agree!
I started working on this little document last night while angry and
tired, maybe it should find its way to the wiki.
Hi,
std.math.internal.gammafunction is the last module with failing
unittest on ARM, simply because it assumes that reals are always in
x86 extended precision format which is obviously not true on ARM.
I haven't got the required (maths) knowledge to fix this, so it'd be
very appreciated if
On Thursday, 3 July 2014 at 06:56:20 UTC, Walter Bright wrote:
On 7/2/2014 8:48 PM, Sean Kelly wrote:
I'm still unclear whether we're aiming for C interoperability
or hardware
support though, based on Walter's remark about SPARC and PPC.
There, 'long
double' is represented differently but is
On Thursday, 3 July 2014 at 11:30:57 UTC, Alix Pexton wrote:
Saying that one is always more significant than the other is
far too much of an oversimplification.
I just thought, with the presence of structs in D, things are not
that simple. Structs don't use references and their contents is
On Thursday, 3 July 2014 at 14:44:06 UTC, Wyatt wrote:
[...]
Very nice; thank you. Though, having thought on it some more,
I would suggest the capital D and the two moons are the most
important aspect in terms of a distinctive mark.
The red background is currently an element of the logo
On Thursday, 3 July 2014 at 11:40:34 UTC, Alix Pexton wrote:
I agree!
I started working on this little document last night while
angry and tired, maybe it should find its way to the wiki.
https://docs.google.com/document/d/1Sb4xnZUbzVRIicsfnxBFhTvRH4EOYq88wZexAuGcnaE/edit
Its the last time
On Thursday, 3 July 2014 at 15:40:33 UTC, Wanderer wrote:
On Thursday, 3 July 2014 at 11:30:57 UTC, Alix Pexton wrote:
Saying that one is always more significant than the other is
far too much of an oversimplification.
I just thought, with the presence of structs in D, things are
not that
Am 03.07.2014 17:33, schrieb Johannes Pfau:
Hi,
std.math.internal.gammafunction is the last module with failing
unittest on ARM, simply because it assumes that reals are always in
x86 extended precision format which is obviously not true on ARM.
OT question:
can you also check big endian
On 03/07/2014 4:16 PM, Wanderer wrote:
On Thursday, 3 July 2014 at 11:30:57 UTC, Alix Pexton wrote:
and how it is stored (all in a single page of memory vs across
multiple networked disks vs in immutable memory such that each swap
actually duplicate the whole dataset).
And how much of that
On Thu, Jul 03, 2014 at 09:52:35AM +, bearophile via Digitalmars-d wrote:
[...]
void main() {
import std.stdio, std.typecons;
alias RGB = Tuple!(ubyte,R, ubyte,G, ubyte,B);
const arr = [RGB(1, 2, 3), RGB(4, 5, 6), RGB(7, 8, 9)];
writeln(arr);
}
It prints:
On 3 July 2014 17:09, dennis luehring via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Am 03.07.2014 17:33, schrieb Johannes Pfau:
Hi,
std.math.internal.gammafunction is the last module with failing
unittest on ARM, simply because it assumes that reals are always in
x86 extended
Am Thu, 03 Jul 2014 18:09:41 +0200
schrieb dennis luehring dl.so...@gmx.net:
OT question:
can you also check big endian behavior with your ARM system
(and maybe maybe unaligned accesses) if possible -
I sometimes test on an armv5te as unaligned accesses corrupt data on
these systems. I found
On Thursday, 3 July 2014 at 15:35:35 UTC, Johannes Pfau wrote:
Hi,
std.math.internal.gammafunction is the last module with failing
unittest on ARM, simply because it assumes that reals are
always in
x86 extended precision format which is obviously not true on
ARM.
I haven't got the required
Am Thu, 03 Jul 2014 16:47:41 +
schrieb John Colvin john.loughran.col...@gmail.com:
testing the latest gdc release, writeln and friends are broken
for 64bit reals. Use core.stdc.stdio.printf with %lf instead.
Actually mixing code compiled with -mlong-double-64 and code compiled
without it
On Thursday, 3 July 2014 at 14:44:06 UTC, Wyatt wrote:
Very nice; thank you. Though, having thought on it some more,
I would suggest the capital D and the two moons are the most
important aspect in terms of a distinctive mark.
The red background is currently an element of the logo design,
Also the current colour scheme is equally as important.
On 3 July 2014 18:02, Johannes Pfau via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Am Thu, 03 Jul 2014 16:47:41 +
schrieb John Colvin john.loughran.col...@gmail.com:
testing the latest gdc release, writeln and friends are broken
for 64bit reals. Use core.stdc.stdio.printf with %lf
On 3 July 2014 18:27, Iain Buclaw ibuc...@gdcproject.org wrote:
On 3 July 2014 18:02, Johannes Pfau via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Am Thu, 03 Jul 2014 16:47:41 +
schrieb John Colvin john.loughran.col...@gmail.com:
testing the latest gdc release, writeln and friends
On Thursday, 3 July 2014 at 17:03:51 UTC, Johannes Pfau wrote:
Am Thu, 03 Jul 2014 16:47:41 +
schrieb John Colvin john.loughran.col...@gmail.com:
testing the latest gdc release, writeln and friends are broken
for 64bit reals. Use core.stdc.stdio.printf with %lf instead.
Actually mixing
On Thursday, 3 July 2014 at 13:16:34 UTC, Chris wrote:
[I haven't had time to follow the entire thread, but] I like
the design, it's a good starting point. Especially the
integration of the logo. Nice and clean. (The current logo is
just too bulky and clumsy, imo*)
However, my experience
On Thursday, 3 July 2014 at 15:35:35 UTC, Johannes Pfau wrote:
Hi,
std.math.internal.gammafunction is the last module with failing
unittest on ARM, simply because it assumes that reals are
always in
x86 extended precision format which is obviously not true on
ARM.
I haven't got the required
On Thursday, 3 July 2014 at 17:54:17 UTC, John Colvin wrote:
On Thursday, 3 July 2014 at 15:35:35 UTC, Johannes Pfau wrote:
Hi,
std.math.internal.gammafunction is the last module with failing
unittest on ARM, simply because it assumes that reals are
always in
x86 extended precision format
On Thursday, 3 July 2014 at 17:08:12 UTC, Gary Willoughby wrote:
I completely disagree. The logo is the whole and provides
recognition using not only form but also in colour. The red
background is essential and the planet horizon make this logo
what it is. Removing those elements decrease
On Thursday, 3 July 2014 at 19:06:42 UTC, Wyatt wrote:
Actually, stepping back a bit: maybe you can explain,
concretely, why you believe the horizon line is essential to
the point that removing it fundamentally alters the form? That
may be more productive.
-Wyatt
I think i've already
On Thursday, 3 July 2014 at 19:06:42 UTC, Wyatt wrote:
Actually, stepping back a bit: maybe you can explain,
concretely, why you believe the horizon line is essential to
the point that removing it fundamentally alters the form? That
may be more productive.
I don't agree with Gary that the
On 03/07/2014 6:38 PM, w0rp wrote:
* Run it all with D to tick a official D site made in D checkbox.
The powered by Python banner gave me an idea...
In a nod to Walter's self confessed petrol-headedness, I thought we
could incorporate the logo into a D under the hood or D in the tank
On 03/07/2014 8:30 PM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Thursday, 3 July 2014 at 19:06:42 UTC, Wyatt wrote:
Actually, stepping back a bit: maybe you can explain, concretely, why
you believe the horizon line is essential to the point that removing
it
On 7/3/2014 8:36 AM, Sean Kelly wrote:
Per the D spec, 'real' will be the longest type supported by the native
hardware.
It's not necessary that real be long double - but it is necessary that long
double be callable from D.
Case in point: long double on Win64 is accessible with D's double,
On 7/3/2014 3:49 AM, Jonathan M Davis via Digitalmars-d wrote:
I don't think that there's anything unclear about that. The problem is that if
real is supposed to be the largest hardware supported floating point type,
then that doesn't necessarily match long double. It happens to on x86 and
On Thursday, 3 July 2014 at 07:29:42 UTC, Wanderer wrote:
Nobody, never, measures sort algorithms by amount of swaps.
Maybe not in swaps, but I have seen sorting algorithms measured
similarly using reads and writes. As others have stated, it can
be a useful metric if you're sorting a range
On 7/3/2014 4:40 AM, Alix Pexton wrote:
I agree!
I started working on this little document last night while angry and tired,
maybe it should find its way to the wiki.
https://docs.google.com/document/d/1Sb4xnZUbzVRIicsfnxBFhTvRH4EOYq88wZexAuGcnaE/edit
Its the last time I'm going to post any
On Thursday, 3 July 2014 at 19:47:32 UTC, Walter Bright wrote:
On 7/3/2014 8:36 AM, Sean Kelly wrote:
Per the D spec, 'real' will be the longest type supported by
the native hardware.
It's not necessary that real be long double - but it is
necessary that long double be callable from D.
On Thu, 03 Jul 2014 12:45:17 -0700
Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote:
On 7/3/2014 3:49 AM, Jonathan M Davis via Digitalmars-d wrote:
I don't think that there's anything unclear about that. The problem
is that if real is supposed to be the largest hardware
On Thursday, 3 July 2014 at 19:46:18 UTC, Alix Pexton wrote:
I agree, it may be a happy accident that a shape that was meant
to be part of the glossy sheen on the image got interpreted as
the distant Martian horizon, but the D and moons look
unbalanced without it.
Yep, I think it is a
On Thursday, 3 July 2014 at 21:01:43 UTC, Jonathan M Davis via
Digitalmars-d wrote:
I'm fine with real varying from platform to platform depending
on what makes sense for that platform, but I think that it
should be clear what real is generally supposed to be (e.g. the
largest floating point
On Thursday, 3 July 2014 at 21:02:53 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 3 July 2014 at 19:46:18 UTC, Alix Pexton wrote:
I agree, it may be a happy accident that a shape that was
meant to be part of the glossy sheen on the image got
interpreted as the distant Martian horizon, but the
On Wednesday, 2 July 2014 at 21:45:41 UTC, Walter Bright wrote:
On 7/2/2014 5:24 AM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
D is not even production ready,
Of course it is.
Not by my definition of production ready:
1. Not stable or up to date language spec.
2.
Experience has shown that using allocators can drastically
improve the execution time of D programs. It has also shown that
the biggest issue with allocators is that unless you are very
careful, the GC will start freeing your live memory.
I think that we need to define the behavior of
On Thu, Jul 03, 2014 at 09:42:48PM +, Tofu Ninja via Digitalmars-d wrote:
On Thursday, 3 July 2014 at 21:02:53 UTC, Ola Fosheim Grøstad wrote:
On Thursday, 3 July 2014 at 19:46:18 UTC, Alix Pexton wrote:
I agree, it may be a happy accident that a shape that was meant to
be part of the
On 3 July 2014 22:43, via Digitalmars-d digitalmars-d@puremagic.com wrote:
On Wednesday, 2 July 2014 at 21:45:41 UTC, Walter Bright wrote:
On 7/2/2014 5:24 AM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
D is not even production ready,
Of course it is.
Not by my
On Sunday, 22 June 2014 at 06:59:31 UTC, Jonathan M Davis via
Digitalmars-d wrote:
On Sat, 21 Jun 2014 15:39:03 -0700
Andrei Alexandrescu via Digitalmars-d
digitalmars-d@puremagic.com
wrote:
On 6/19/14, 3:27 PM, Andrej Mitrovic via Digitalmars-d wrote:
I claimed a bounty recently, and I
On Thursday, 3 July 2014 at 21:53:25 UTC, Brian Schott wrote:
I think that the only sane way to solve this is to define in
the specs for core.memory that GC.addRange will only ever store
one entry per pointer, and that the length will be the value of
sz from the most recent call to addRange.
On Thu, Jul 03, 2014 at 09:43:38PM +, via Digitalmars-d wrote:
On Wednesday, 2 July 2014 at 21:45:41 UTC, Walter Bright wrote:
On 7/2/2014 5:24 AM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
D is not even production ready,
Of course it is.
Not by my definition of
On Thursday, 3 July 2014 at 21:55:52 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Thu, Jul 03, 2014 at 09:42:48PM +, Tofu Ninja via
Digitalmars-d wrote:
On Thursday, 3 July 2014 at 21:02:53 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 3 July 2014 at 19:46:18 UTC, Alix Pexton wrote:
I agree,
On Thu, Jul 03, 2014 at 10:10:04PM +, Tofu Ninja via Digitalmars-d wrote:
On Thursday, 3 July 2014 at 21:55:52 UTC, H. S. Teoh via Digitalmars-d
wrote:
On Thu, Jul 03, 2014 at 09:42:48PM +, Tofu Ninja via Digitalmars-d
wrote:
On Thursday, 3 July 2014 at 21:02:53 UTC, Ola Fosheim
On Thursday, 3 July 2014 at 21:02:53 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 3 July 2014 at 19:46:18 UTC, Alix Pexton wrote:
I agree, it may be a happy accident that a shape that was
meant to be part of the glossy sheen on the image got
interpreted as the distant Martian horizon, but the
On Friday, 4 July 2014 at 00:11:25 UTC, Brad Anderson wrote:
[...]
I've had this .svg of the flat version of the logo around for a
few years that is a bit cleaner than the one you quickly put
together (sharper edges, and I think your bottom is truncated a
bit). Feel free to use it.
On 7/3/2014 2:43 PM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
Would you use D for building software to ship with hardware appliances?
Yes.
I would not.
The issues you presented are subjective and a matter of opinion. Regardless of
the state of D, I'm not the type
On 7/3/2014 1:30 PM, Tofu Ninja wrote:
On Thursday, 3 July 2014 at 19:47:32 UTC, Walter Bright wrote:
On 7/3/2014 8:36 AM, Sean Kelly wrote:
Per the D spec, 'real' will be the longest type supported by the native
hardware.
It's not necessary that real be long double - but it is necessary
Am Thu, 03 Jul 2014 18:13:45 +
schrieb John Colvin john.loughran.col...@gmail.com:
On Thursday, 3 July 2014 at 17:54:17 UTC, John Colvin wrote:
On Thursday, 3 July 2014 at 15:35:35 UTC, Johannes Pfau wrote:
Hi,
std.math.internal.gammafunction is the last module with failing
On Fri, Jul 04, 2014 at 01:17:37AM +, Brad Anderson via Digitalmars-d wrote:
[...]
Here's some variations made from the original SVG by just
deleting paths but leaving them all unaltered:
https://drive.google.com/folderview?id=0Bx3n3LnLsNBzNngyZ055eDhTbGsusp=sharing
[...]
Hmm. I actually
On Thursday, 3 July 2014 at 04:46:02 UTC, K.K. wrote:
Is the only thing I'm missing the .dll's?
Thanks!
Yes, everything went fine, and you find the missing DLL here:
https://www.libsdl.org/download-2.0.php
Derelict contains bindings to other libraries, not these
libraries themselves. dub downloads only these bindings, not
original libraries (since they are written in C, not D, and not
included in dub repositories). You should manually get necessary
libraries and put them in folder where .exe
Hi,
Is there a source transformation for D available?
Could someone please point me to it?
If not, I'd like to work on one - I'd appreciate any pointers on
getting started. I am considering writing the whole thing in D
and not relying the lexer/parser in C that is already there.
Regards,
1 - 100 of 158 matches
Mail list logo
