On Friday, 19 February 2016 at 06:39:53 UTC, Walter Bright wrote:
On 2/18/2016 9:46 PM, Jonathan M Davis wrote:
On Thursday, 18 February 2016 at 22:40:32 UTC, Walter Bright
wrote:
On 2/18/2016 4:16 AM, Jonathan M Davis wrote:
headconst may solve the extern(C++) problem, but it really
doesn't s
On Thu, 2016-02-18 at 17:27 +, Chris Wright via Digitalmars-d
wrote:
> […]
>
> I would like to look into D's GC and parallelism more. I've started
> on
> mark/sweep parallelism but haven't made any worthwhile progress.
> I'll
> take this as my next task. It's more awkward because it requires
On Thursday, 18 February 2016 at 21:09:15 UTC, Stefan Koch wrote:
I am planing to open-source my native-sqlite database driver.
(well currently it just reads them).
However it works fully at CTFE.
Interesting... I'd almost want a page with the ddoc information
to glance over the API, and a
On 2/18/2016 9:46 PM, Jonathan M Davis wrote:
On Thursday, 18 February 2016 at 22:40:32 UTC, Walter Bright wrote:
On 2/18/2016 4:16 AM, Jonathan M Davis wrote:
headconst may solve the extern(C++) problem, but it really doesn't solve the
problems we have with const.
'mutable' doesn't really so
On Fri, 19 Feb 2016 05:29:20 +, Ola Fosheim Grøstad wrote:
> On Thursday, 18 February 2016 at 23:42:11 UTC, Chris Wright wrote:
>> There are damages for patent infringement. There are higher damages for
>> willful infringement.
>
> Iff you use it as a means for production. There is nothing il
On Friday, 19 February 2016 at 05:33:54 UTC, Doc wrote:
On Thursday, 18 February 2016 at 11:57:59 UTC, Jonathan M Davis
wrote:
The more I look at it, the more I'm inclined to think that
introducing @mutable for member variables with a
corresponding, required attribute on the struct or class
On Thursday, 18 February 2016 at 22:40:32 UTC, Walter Bright
wrote:
On 2/18/2016 4:16 AM, Jonathan M Davis wrote:
headconst may solve the extern(C++) problem, but it really
doesn't solve the
problems we have with const.
'mutable' doesn't really solve a problem, it just means that
C++ 'const'
On Thursday, 18 February 2016 at 11:57:59 UTC, Jonathan M Davis
wrote:
The more I look at it, the more I'm inclined to think that
introducing @mutable for member variables with a corresponding,
required attribute on the struct or class it's in (e.g.
@has_mutable) is really what we need to b
On Thursday, 18 February 2016 at 23:42:11 UTC, Chris Wright wrote:
You testify it under oath, and you hope you look honest. You
can show a lack of GCC source code on your home computer,
possibly.
If they actually have a strong case it will be highly unlikely
that you have arrived at it indepe
On Thursday, 18 February 2016 at 18:20:48 UTC, Eugene Wissner
wrote:
On Wednesday, 17 February 2016 at 18:28:08 UTC, Suliman wrote:
Hello, I wrote pretty good FAQ about D on Russian language. I
need help with translation it to English and Germany and
possible to other languages.
http://dlang.
On Thursday, 18 February 2016 at 10:18:18 UTC, Robert burner
Schadek wrote:
On Thursday, 18 February 2016 at 04:34:13 UTC, Alex Vincent
wrote:
I'm looking for a status update. DUB doesn't seem to have
many options posted. I was thinking about starting a
SAXParser implementation.
I'm working
On Thursday, 18 February 2016 at 20:28:41 UTC, David Nadlinger
wrote:
You can use rdmd with ldmd2 just as well (and presumably gdmd
too).
First I'm hearing of it.
On Thursday, 18 February 2016 at 03:39:30 UTC, Kapps wrote:
On Thursday, 18 February 2016 at 03:38:42 UTC, Kapps wrote:
This is what I did with OpenGL for my own bindings. It had
some nice benefits like having the documentation be (mostly)
accessible.
Unfortunately, turns out the spec conta
On 2/18/16 6:52 PM, Chad Joan wrote:
Steve: My apologies in advance if I a misunderstood any of the
functionality of your IO library. I haven't read any of the
documentation, just this thread, and I my time is over-committed as usual.
Understandable.
Anyhow...
I believe that when I am deal
On 02/18/2016 04:09 PM, Stefan Koch wrote:
Hello,
It is not quite ready to post in Announce,
but I would like to inform you that I am planing to open-source my
native-sqlite database driver. (well currently it just reads them).
However it works fully at CTFE.
so if you want to you can extract s
On 18.02.2016 21:57, H. S. Teoh via Digitalmars-d wrote:
>If you want to verify guarantees, @safe should be specified by
>inclusion and ideally, type safety should be proved formally (after
>applying a few fixes).
>This first requires a formal language semantics.
>That's already a lot of effort,
On 2/18/2016 6:04 AM, Marc Schütz wrote:
Rule 2 only forbids _static immutables_ with @mutable members, precisely because
those could end up in read-only memory. I don't see how allocators are affected
at all. An allocator would be mutable, or at least manage mutable memory.
You could create a
On Wednesday, 17 February 2016 at 06:45:41 UTC, Steven
Schveighoffer wrote:
It's no secret that I've been looking to create an updated io
library for phobos. In fact, I've been working on one on and
off since 2011 (ouch).
...
Hi everyone, it's been a while.
I wanted to chime in on the strea
On Thu, 18 Feb 2016 22:41:46 +, Ola Fosheim Grøstad wrote:
> On Thursday, 18 February 2016 at 22:22:57 UTC, Chris Wright wrote:
>> With copyright, the fact that you created yours on your own is
>> sufficient defense, assuming the courts agree. If by sheer coincidence
>> you come up with code i
On Thu, 18 Feb 2016 19:17:27 +, Era Scarecrow wrote:
> On Thursday, 18 February 2016 at 18:41:25 UTC, Steven Schveighoffer
> wrote:
>> On 2/18/16 1:30 PM, Timon Gehr wrote:
>>> No problem here. There is no way to assign to a void[] without doing
>>> 2.
>>
>> foo(void[] arr)
>> {
>>void[] a
Just come across Kotlin today, and found some interesting ideas
skimming through its tutorial:
1) Null check
Kotlin has Optional types, suffixed with a '?'. Like 'Int?', same
as in Swift. But instead of explicitly unwrapping them (e.g. var!
in Swift, or var.unwrap() in Rust), Kotlin let you d
On Thursday, 18 February 2016 at 22:48:01 UTC, Walter Bright
wrote:
struct A { int* pi; }
and *pi will be mutable even though pi is __const.
Here's the big deal: when you have started on an implementation
with constness in, and then evolve the codebase and have to turn
some fields mutable or
On Thursday, 18 February 2016 at 21:09:15 UTC, Stefan Koch wrote:
Hello,
It is not quite ready to post in Announce,
but I would like to inform you that I am planing to open-source
my native-sqlite database driver. (well currently it just reads
them).
However it works fully at CTFE.
so if you
On Thursday, 18 February 2016 at 20:18:14 UTC, David Nadlinger
wrote:
On Wednesday, 17 February 2016 at 22:57:20 UTC, Márcio Martins
wrote:
[…]
On a completely unrelated note, you aren't by any chance the
Márcio Martins who is giving a talk at ETH in a couple of days,
are you?
— David
N
On 2/18/2016 4:18 AM, Andrei Alexandrescu wrote:
On 02/17/2016 05:44 PM, Walter Bright wrote:
It would seem that implementing headconst as a type constructor would
let people who wanted mutable members have their way, without
introducing backdoors in const.
Doesn't seem that way to me, viz:
s
On Thursday, 18 February 2016 at 22:33:15 UTC, Iain Buclaw wrote:
On 18 February 2016 at 22:23, Jonathan M Davis via
Digitalmars-d < digitalmars-d@puremagic.com> wrote:
[...]
Actually, I'm sure this is a great way to let bugs in. There's
no saying what could happen if you switch compiler a
On 2/18/2016 10:22 AM, Timon Gehr wrote:
He wanted to embed a mutable reference count literally within a const object.
Not a headconst object.
I know. I pointed out how it could be done in a way to achieve the same effect.
BTW, shared_ptr<> uses a pointer to the ref count.
On Thursday, 18 February 2016 at 22:22:57 UTC, Chris Wright wrote:
With copyright, the fact that you created yours on your own is
sufficient defense, assuming the courts agree. If by sheer
coincidence you come up with code identical to what's in GCC,
but you can show that you didn't take the co
On 2/18/2016 4:16 AM, Jonathan M Davis wrote:
headconst may solve the extern(C++) problem, but it really doesn't solve the
problems we have with const.
'mutable' doesn't really solve a problem, it just means that C++ 'const' is a
documentation aid, not a guarantee.
On Thu, Feb 18, 2016 at 03:20:58PM -0500, Steven Schveighoffer via
Digitalmars-d wrote:
> On 2/18/16 2:53 PM, Wyatt wrote:
> >On Thursday, 18 February 2016 at 18:35:40 UTC, Steven Schveighoffer wrote:
>
> >>But the concept of what constitutes an "item" in a stream may not be
> >>the "element type
On 18 February 2016 at 22:23, Jonathan M Davis via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On Thursday, 18 February 2016 at 20:28:41 UTC, David Nadlinger wrote:
>
>> On Thursday, 18 February 2016 at 17:56:32 UTC, Jonathan M Davis wrote:
>>
>>> […] if you want to be writing scripts in
On Thu, 18 Feb 2016 21:39:45 +, Ola Fosheim Grøstad wrote:
> On Thursday, 18 February 2016 at 21:30:29 UTC, Jonathan M Davis wrote:
>> It's not a strawman. Walter has state previously that he's explicitly
>> avoided looking at the source code for other compilers like gcc,
>> because he doesn't
On Thursday, 18 February 2016 at 18:28:10 UTC, Alex Vincent wrote:
Regarding control characters: If you give me a complete sample
file, I can run it through Mozilla's UTF stream conversion
and/or XML parsing code (via either SAX or DOMParser) to tell
you how that reacts as a reference. Mozill
On Thursday, 18 February 2016 at 20:24:18 UTC, H. S. Teoh wrote:
On Thu, Feb 18, 2016 at 07:25:16PM +, Jonathan M Davis via
Digitalmars-d wrote:
On Thursday, 18 February 2016 at 18:58:56 UTC, H. S. Teoh
wrote:
>On Thu, Feb 18, 2016 at 06:50:34PM +, Jonathan M Davis
>via Digitalmars-d wr
On Thursday, 18 February 2016 at 21:30:29 UTC, Jonathan M Davis
wrote:
It's not a strawman. Walter has state previously that he's
explicitly avoided looking at the source code for other
compilers like gcc, because he doesn't want anyone to be able
to accuse him of stealing code, copyright infri
On 2/18/16 4:02 PM, H. S. Teoh via Digitalmars-d wrote:
On Thu, Feb 18, 2016 at 03:20:58PM -0500, Steven Schveighoffer via
Digitalmars-d wrote:
On 2/18/16 2:53 PM, Wyatt wrote:
On Thursday, 18 February 2016 at 18:35:40 UTC, Steven Schveighoffer wrote:
But the concept of what constitutes an
On Thursday, 18 February 2016 at 20:24:31 UTC, David Nadlinger
wrote:
On Thursday, 18 February 2016 at 11:12:57 UTC, Jonathan M Davis
wrote:
And actually, he'd risk legal problems if he did, because he
doesn't want anyone to be able to accuse him of taking code
from gcc or llvm.
That's a sill
On Thursday, 18 February 2016 at 20:28:41 UTC, David Nadlinger
wrote:
On Thursday, 18 February 2016 at 17:56:32 UTC, Jonathan M Davis
wrote:
[…] if you want to be writing scripts in D (which is really
useful), you need rdmd, which means using dmd
You can use rdmd with ldmd2 just as well (and p
Hello,
It is not quite ready to post in Announce,
but I would like to inform you that I am planing to open-source
my native-sqlite database driver. (well currently it just reads
them).
However it works fully at CTFE.
so if you want to you can extract sourceCode out of a
sql-database and make
On Thu, Feb 18, 2016 at 08:23:24PM +0100, Timon Gehr via Digitalmars-d wrote:
> On 18.02.2016 19:41, H. S. Teoh via Digitalmars-d wrote:
[...]
> > void breakSafety(void[] data) @safe
> > {
> > union U {
> > void[] d;
> > int[] arr;
> >
On Thursday, 18 February 2016 at 10:42:33 UTC, Márcio Martins
wrote:
On Thursday, 18 February 2016 at 10:16:40 UTC, Radu wrote:
[...]
Walter doesn't have to give up working on DMD, right? Everyone
could continue working on DMD, perhaps a few people could help
on all three, I don't know... It
On Thu, Feb 18, 2016 at 07:28:16PM +, Kagamin via Digitalmars-d wrote:
> On Thursday, 18 February 2016 at 16:37:10 UTC, H. S. Teoh wrote:
> >(*ahem*std.socket*cough*) liberally sprinkle @trusted on every function
> >without regard to whether it's truly justified (e.g., see
> >https://issues.dla
On 18.02.2016 21:24, David Nadlinger wrote:
But please don't make up argument trying to rationalize whatever
personal decision somebody else made. You could literally copy LLVM
source code into your application and sell it as a closed-source product
without risking any copyright problems (if you
On Thursday, 18 February 2016 at 17:56:32 UTC, Jonathan M Davis
wrote:
[…] if you want to be writing scripts in D (which is really
useful), you need rdmd, which means using dmd
You can use rdmd with ldmd2 just as well (and presumably gdmd
too).
New users are frequently impressed by how fast
On Thu, Feb 18, 2016 at 07:25:16PM +, Jonathan M Davis via Digitalmars-d
wrote:
> On Thursday, 18 February 2016 at 18:58:56 UTC, H. S. Teoh wrote:
> >On Thu, Feb 18, 2016 at 06:50:34PM +, Jonathan M Davis via
> >Digitalmars-d wrote:
> >>On Thursday, 18 February 2016 at 18:41:25 UTC, Steven
On Thursday, 18 February 2016 at 11:12:57 UTC, Jonathan M Davis
wrote:
And actually, he'd risk legal problems if he did, because he
doesn't want anyone to be able to accuse him of taking code
from gcc or llvm.
That's a silly strawman, and you should know better than putting
that forward as an
On Thursday, 18 February 2016 at 15:36:42 UTC, Jonathan M Davis
wrote:
On Thursday, 18 February 2016 at 14:23:12 UTC, Márcio Martins
wrote:
I agree, but I don't see why this would have to change. It
shouldn't change. Frontend development could happen on DMD as
the *reference* compiler.
And wh
On 2/18/16 2:53 PM, Wyatt wrote:
On Thursday, 18 February 2016 at 18:35:40 UTC, Steven Schveighoffer wrote:
But the concept of what constitutes an "item" in a stream may not be
the "element type". That's what I'm getting at.
Hmm, I guess I'm not seeing it. Like, what even is an "item" in a
On Wednesday, 17 February 2016 at 22:57:20 UTC, Márcio Martins
wrote:
[…]
On a completely unrelated note, you aren't by any chance the
Márcio Martins who is giving a talk at ETH in a couple of days,
are you?
— David
On 2/18/16 2:25 PM, H. S. Teoh via Digitalmars-d wrote:
On Thu, Feb 18, 2016 at 01:58:24PM -0500, Steven Schveighoffer via
Digitalmars-d wrote:
On 2/18/16 11:37 AM, H. S. Teoh via Digitalmars-d wrote:
While @safe is a good idea in principle, the current implementation
is rather lackluster.
I
On Thursday, 18 February 2016 at 18:58:24 UTC, Steven
Schveighoffer wrote:
And implicit casts to void[] should be disallowed.
We could strike a sane medium: in a @safe function or when
calling a @safe function, implicit conversions of any array WITH
REFERENCES is not allowed, while other arr
On Thursday, 18 February 2016 at 19:28:16 UTC, Kagamin wrote:
On Thursday, 18 February 2016 at 16:37:10 UTC, H. S. Teoh wrote:
(*ahem*std.socket*cough*) liberally sprinkle @trusted on every
function without regard to whether it's truly justified (e.g.,
see https://issues.dlang.org/show_bug.cgi?
On Thu, Feb 18, 2016 at 01:58:24PM -0500, Steven Schveighoffer via
Digitalmars-d wrote:
> On 2/18/16 11:37 AM, H. S. Teoh via Digitalmars-d wrote:
> >While @safe is a good idea in principle, the current implementation
> >is rather lackluster.
>
> IMO, I think safe code should disallow casting tha
On Thursday, 18 February 2016 at 11:41:26 UTC, Kai Nacke wrote:
LLVM has about 2.5 million code lines. I am anything than sure
if it is easy to improve compilation speed.
I think you are a tad too pessimistic here. First, don't forget
that there are some big LLVM customers for which low compil
On Thursday, 18 February 2016 at 18:35:40 UTC, Steven
Schveighoffer wrote:
On 2/18/16 12:08 PM, Wyatt wrote:
I hadn't thought of this before, but if we accept that a
stream is raw,
untyped data, it may be best _not_ to provide a range interface
directly. It's easy enough to
alias source = s
On Thursday, 18 February 2016 at 17:52:10 UTC, Kai Nacke wrote:
On Thursday, 18 February 2016 at 12:16:49 UTC, Radu wrote:
As a casual user of the language I see that there is a
fragmentation of resources and a waste in this regard with
people developing in mainline, then some of you LDC guys
On Thursday, 18 February 2016 at 12:23:18 UTC, Jonathan M Davis
wrote:
if the dmd backend were dropped, […] that would further slow
down the development of the frontend and not necessarily
improve things overall.
How would that be?
— David
Well, ok, getprotobyname indeed looks thread unsafe for some
reason, but this can happen for any function.
On Thursday, 18 February 2016 at 16:37:10 UTC, H. S. Teoh wrote:
(*ahem*std.socket*cough*) liberally sprinkle @trusted on every
function without regard to whether it's truly justified (e.g.,
see https://issues.dlang.org/show_bug.cgi?id=15672)
How is bug 15672 related to std.socket? From quick
On 18.02.2016 20:17, Era Scarecrow wrote:
On Thursday, 18 February 2016 at 18:41:25 UTC, Steven Schveighoffer wrote:
On 2/18/16 1:30 PM, Timon Gehr wrote:
No problem here. There is no way to assign to a void[] without doing 2.
foo(void[] arr)
{
void[] arr2 = [1234, 5678, 91011];
arr[] =
On Thursday, 18 February 2016 at 18:58:56 UTC, H. S. Teoh wrote:
On Thu, Feb 18, 2016 at 06:50:34PM +, Jonathan M Davis via
Digitalmars-d wrote:
On Thursday, 18 February 2016 at 18:41:25 UTC, Steven
Schveighoffer wrote:
[...]
>foo(void[] arr)
>{
> void[] arr2 = [1234, 5678, 91011];
> a
On 18.02.2016 19:41, H. S. Teoh via Digitalmars-d wrote:
On Thu, Feb 18, 2016 at 07:30:34PM +0100, Timon Gehr via Digitalmars-d wrote:
On 18.02.2016 17:37, H. S. Teoh via Digitalmars-d wrote:
[...]
1) Casting an array of elements with indirections (in this case
Object[]) to void[] is questiona
On Thursday, 18 February 2016 at 18:41:25 UTC, Steven
Schveighoffer wrote:
On 2/18/16 1:30 PM, Timon Gehr wrote:
No problem here. There is no way to assign to a void[] without
doing 2.
foo(void[] arr)
{
void[] arr2 = [1234, 5678, 91011];
arr[] = arr2[0 .. arr.length];
}
Since void thr
On Thursday, 18 February 2016 at 17:52:10 UTC, Kai Nacke wrote:
I really like the compiler diversity. What I miss (hint!) is a
program to verify the compiler/backend correctness. Just
generate a random D program, compile with all 3 compilers and
compare the output. IMHO we could find a lot of b
On 2/18/16 1:50 PM, Jonathan M Davis wrote:
On Thursday, 18 February 2016 at 18:41:25 UTC, Steven Schveighoffer wrote:
foo(void[] arr)
{
void[] arr2 = [1234, 5678, 91011];
arr[] = arr2[0 .. arr.length];
}
Well, I'm not sure that that's actually not @safe. It's trying to
interpret the voi
On Thu, Feb 18, 2016 at 06:55:18PM +, Jonathan M Davis via Digitalmars-d
wrote:
> On Thursday, 18 February 2016 at 18:41:58 UTC, H. S. Teoh wrote:
[...]
> >It's only one of many culprits. As long as there is any way around
> >@safe, the entire system of guarantees breaks down.
>
> Of course,
On Thu, Feb 18, 2016 at 06:50:34PM +, Jonathan M Davis via Digitalmars-d
wrote:
> On Thursday, 18 February 2016 at 18:41:25 UTC, Steven Schveighoffer wrote:
[...]
> >foo(void[] arr)
> >{
> > void[] arr2 = [1234, 5678, 91011];
> > arr[] = arr2[0 .. arr.length];
> >}
>
> Well, I'm not sure
On 2/18/16 11:37 AM, H. S. Teoh via Digitalmars-d wrote:
While @safe is a good idea in principle, the current implementation is
rather lackluster.
IMO, I think safe code should disallow casting that doesn't involve a
runtime function that verifies safety (such as casting an object to
another
On Thursday, 18 February 2016 at 18:41:58 UTC, H. S. Teoh wrote:
On Thu, Feb 18, 2016 at 07:30:34PM +0100, Timon Gehr via
Digitalmars-d wrote:
No problem here. There is no way to assign to a void[] without
doing 2.
Sure there is:
void breakSafety(void[] data) @safe
{
On Thursday, 18 February 2016 at 18:41:25 UTC, Steven
Schveighoffer wrote:
On 2/18/16 1:30 PM, Timon Gehr wrote:
On 18.02.2016 17:37, H. S. Teoh via Digitalmars-d wrote:
While @safe is a good idea in principle, the current
implementation is
rather lackluster. Consider, for example:
void r
On 18.02.2016 19:41, Steven Schveighoffer wrote:
On 2/18/16 1:30 PM, Timon Gehr wrote:
On 18.02.2016 17:37, H. S. Teoh via Digitalmars-d wrote:
While @safe is a good idea in principle, the current implementation is
rather lackluster. Consider, for example:
void readData(void[] buffer) @saf
On Thu, Feb 18, 2016 at 07:30:34PM +0100, Timon Gehr via Digitalmars-d wrote:
> On 18.02.2016 17:37, H. S. Teoh via Digitalmars-d wrote:
[...]
> >1) Casting an array of elements with indirections (in this case
> >Object[]) to void[] is questionable at best, outright unsafe at
> >worst, as shown her
On 2/18/16 1:30 PM, Timon Gehr wrote:
On 18.02.2016 17:37, H. S. Teoh via Digitalmars-d wrote:
While @safe is a good idea in principle, the current implementation is
rather lackluster. Consider, for example:
void readData(void[] buffer) @safe
{
ubyte[] buf = cast(ubyte[]) buffer
On 2/18/16 12:08 PM, Wyatt wrote:
On Thursday, 18 February 2016 at 15:44:00 UTC, Steven Schveighoffer wrote:
On 2/17/16 5:54 AM, John Colvin wrote:
On Wednesday, 17 February 2016 at 07:15:01 UTC, Steven Schveighoffer
wrote:
On 2/17/16 1:58 AM, Rikki Cattermole wrote:
A few things:
https://gi
On 18.02.2016 17:37, H. S. Teoh via Digitalmars-d wrote:
While @safe is a good idea in principle, the current implementation is
rather lackluster. Consider, for example:
void readData(void[] buffer) @safe
{
ubyte[] buf = cast(ubyte[]) buffer;
buf[0
On Thursday, 18 February 2016 at 17:26:30 UTC, Adam D. Ruppe
wrote:
On Thursday, 18 February 2016 at 16:56:08 UTC, Robert burner
Schadek wrote:
unix file says it is a utf8 encoded file, but not BOM is
present.
the hex dump is "3C 66 6F 6F 3E C2 80 3C 2F 66 6F 6F 3E"
Gah, I should have read t
On 2/18/16 12:16 PM, Wyatt wrote:
On Thursday, 18 February 2016 at 16:36:37 UTC, Steven Schveighoffer wrote:
Note, asInputRange may not do what you want here. If multiple
zmqPollItems come in at once (I'm not sure how your socket works), the
input range's front will provide the entire window of
On Thursday, 18 February 2016 at 15:58:14 UTC, Nick Sabalausky
wrote:
but for the second group, a language that's fast like C/C++
but not nearly as unproductive IS appealing, and even seems to
be something they're often on the lookout for.
I would agree with you if you could write D code usin
On 18.02.2016 13:03, Walter Bright wrote:
On 2/18/2016 2:47 AM, Timon Gehr wrote:
On 18.02.2016 10:24, Walter Bright wrote:
On 2/17/2016 11:58 PM, Timon Gehr wrote:
const(headconst(T)) is the same as const(T), no?
Er, yes?
Jonathan wanted to embed a mutable reference count within a const o
On Wednesday, 17 February 2016 at 18:28:08 UTC, Suliman wrote:
Hello, I wrote pretty good FAQ about D on Russian language. I
need help with translation it to English and Germany and
possible to other languages.
http://dlang.ru/Why-D-is-Better
I hope it people will like it, it will help to att
On Thursday, 18 February 2016 at 16:14:09 UTC, Chris wrote:
Just to say that the copyright notice on the vibe.d website
should be updated. In the API it still says
"Copyright © 2012-2015 RejectedSoftware e.K."
In the license it still says "Copyright (c) 2012-2014,
rejectedsoftware e.K." and R
On Thursday, 18 February 2016 at 17:56:32 UTC, Jonathan M Davis
wrote:
Honestly, I think that dmd _should_ be the goto compiler. [snip]
I agree with your response.
That being said, it can't hurt to make things a bit more clear
for new users. If you go to the download page, there is a more
i
On Thursday, 18 February 2016 at 10:18:18 UTC, Robert burner
Schadek wrote:
If you want to on some XML stuff, please join me. It is
properly more productive working together than creating two
competing implementations.
Oh, I absolutely agree, independent implementation is a bad
thing. (Someon
On Thursday, 18 February 2016 at 17:52:10 UTC, Kai Nacke wrote:
I really like the compiler diversity. What I miss (hint!) is a
program to verify the compiler/backend correctness. Just
generate a random D program, compile with all 3 compilers and
compare the output. IMHO we could find a lot of b
On Thursday, 18 February 2016 at 16:47:16 UTC, Márcio Martins
wrote:
On Thursday, 18 February 2016 at 15:36:42 UTC, Jonathan M Davis
wrote:
On Thursday, 18 February 2016 at 14:23:12 UTC, Márcio Martins
wrote:
I agree, but I don't see why this would have to change. It
shouldn't change. Frontend
On Thursday, 18 February 2016 at 17:23:09 UTC, rsw0x wrote:
On Thursday, 18 February 2016 at 11:41:26 UTC, Kai Nacke wrote:
On Thursday, 18 February 2016 at 10:45:54 UTC, Márcio Martins
wrote:
I suppose it's a lot easier to address the compilation speed
issue in LDC/GDC, than to improve and mai
On Thursday, 18 February 2016 at 12:16:49 UTC, Radu wrote:
As a casual user of the language I see that there is a
fragmentation of resources and a waste in this regard with
people developing in mainline, then some of you LDC guys
catching up.
As Iain already pointed out the main problem is (u
On Wednesday, 17 February 2016 at 21:20:09 UTC, Jeremy DeHaan
wrote:
On Wednesday, 17 February 2016 at 20:56:27 UTC, Rishub Nagpal
wrote:
Qtd hasn't been updated in 3 years
Does anyone know of anactively maintained qt library?
I think QML bindings exists, but as far as I know direct Qt
bindin
On Thu, 18 Feb 2016 13:00:12 +, Witek wrote:
> So, the question is, why is D / DMD allocator so slow under heavy
> multithreading?
It's a global GC, possibly with a little per-thread pool.
As part of the abortive Amber language project, I was looking into ways
to craft per-thread GC. You nee
On Thursday, 18 February 2016 at 16:56:08 UTC, Robert burner
Schadek wrote:
unix file says it is a utf8 encoded file, but not BOM is
present.
the hex dump is "3C 66 6F 6F 3E C2 80 3C 2F 66 6F 6F 3E"
Gah, I should have read this before replying... well, that does
appear to be valid utf-8
On Thursday, 18 February 2016 at 11:41:26 UTC, Kai Nacke wrote:
On Thursday, 18 February 2016 at 10:45:54 UTC, Márcio Martins
wrote:
I suppose it's a lot easier to address the compilation speed
issue in LDC/GDC, than to improve and maintain DMD's backend
to the expected levels, right?
LLVM ha
On Thursday, 18 February 2016 at 16:54:10 UTC, Robert burner
Schadek wrote:
It does not, it has no prolog and therefore no EncodingInfo.
In that case, it needs to be valid UTF-8 or valid UTF-16 and it
is a fatal error if there's any invalid bytes:
https://www.w3.org/TR/REC-xml/#charencoding
On Thursday, 18 February 2016 at 16:36:37 UTC, Steven
Schveighoffer wrote:
On 2/18/16 11:07 AM, Wyatt wrote:
This looks pretty all-right so far. Would something like this
work?
foreach(pollItem; zmqSocket.bufferedInput
.as!(zmqPollItem)
.asInputRange)
Yes, that is the intent. All
On Thursday, 18 February 2016 at 15:44:00 UTC, Steven
Schveighoffer wrote:
On 2/17/16 5:54 AM, John Colvin wrote:
On Wednesday, 17 February 2016 at 07:15:01 UTC, Steven
Schveighoffer wrote:
On 2/17/16 1:58 AM, Rikki Cattermole wrote:
A few things:
https://github.com/schveiguy/iopipe/blob/mast
On Thursday, 18 February 2016 at 16:54:10 UTC, Robert burner
Schadek wrote:
unix file says it is a utf8 encoded file, but not BOM is
present.
the hex dump is "3C 66 6F 6F 3E C2 80 3C 2F 66 6F 6F 3E"
On Thursday, 18 February 2016 at 16:47:35 UTC, Adam D. Ruppe
wrote:
On Thursday, 18 February 2016 at 16:41:52 UTC, Robert burner
Schadek wrote:
for instance, quick often I find <80> in tests that are
supposed to be valid xml 1.0. they are invalid xml 1.1 though
What char encoding does the docu
On Thursday, 18 February 2016 at 16:41:52 UTC, Robert burner
Schadek wrote:
for instance, quick often I find <80> in tests that are
supposed to be valid xml 1.0. they are invalid xml 1.1 though
What char encoding does the document declare itself as?
On Thursday, 18 February 2016 at 15:36:42 UTC, Jonathan M Davis
wrote:
On Thursday, 18 February 2016 at 14:23:12 UTC, Márcio Martins
wrote:
I agree, but I don't see why this would have to change. It
shouldn't change. Frontend development could happen on DMD as
the *reference* compiler.
And wh
for instance, quick often I find <80> in tests that are supposed
to be valid xml 1.0. they are invalid xml 1.1 though
While @safe is a good idea in principle, the current implementation is
rather lackluster. Consider, for example:
void readData(void[] buffer) @safe
{
ubyte[] buf = cast(ubyte[]) buffer;
buf[0] = 0xFF;
}
void main() @safe
{
1 - 100 of 170 matches
Mail list logo
