On 12/21/2016 7:57 PM, Chris Wright wrote:
You can implement write barriers as runtime calls, but omit them in @nogc
code.
@nogc code is code that doesn't allocate from the gc. It can still write to gc
allocated objects, however, so that idea won't work.
However, this would be costly -- it
On 12/21/2016 6:50 AM, thedeemon wrote:
Have you seen this one?
http://www.infognition.com/blog/2014/the_real_problem_with_gc_in_d.html
Although I had called them write gates, write barriers are the same thing. Yes,
that's the problem with implementing a generational collector in D.
I once t
On 12/21/2016 3:36 AM, thedeemon wrote:
Bad news: without complete redesign of the language and turning into one more
C++/CLI (where you have different kinds of pointers in the language for GC and
non-GC), having C performance and Go-style low-pause GC is not really possible.
You have to choose o
On 12/21/2016 9:43 AM, Johannes Pfau wrote:
You need some kind of linker support to do this to provide the
start/end symbols.
That's partially correct. I've done this for decades by having the compiler
itself emit those symbols.
There are other tricks one can do, such as putting the pointers
On Wednesday, 21 December 2016 at 23:33:50 UTC, Jonathan M Davis
wrote:
Definitely. It is almost always the case that building a
program with dmd is much faster than building with gdc or ldc.
The tradeoff is that gdc and ldc do a much better job
optimizing the resultant binary. So, with dmd, yo
> Library Standardization:
>
>
> Some of the proposals sounds very correct. The library needs to be
> split. Every module needs its own GIT. People need to be able to add
> standard modules ( after approval ).
I can't agree with you there. There are a lot of dependencies
On Mon, 19 Dec 2016 09:58:28 +, default0 wrote:
> On Monday, 19 December 2016 at 08:30:07 UTC, Stefan Koch wrote:
>> If you are prepending # you might as well prepend _
>
> That doesn't solve the complications this introduces if you want to
> serialize to/from members with these names, as seen
On Thursday, 22 December 2016 at 03:57:10 UTC, Chris Wright wrote:
You can implement write barriers as runtime calls, but omit
them in @nogc code.
That means redefining what @nogc means. Currently it basically
means "does not GC-allocate" and you want to change it to "does
not mutate GC-allo
On Wed, 21 Dec 2016 11:36:14 +, thedeemon wrote:
> Bad news: without complete redesign of the language and turning into one
> more C++/CLI (where you have different kinds of pointers in the language
> for GC and non-GC), having C performance and Go-style low-pause GC is
> not really possible. Y
On Tue, 20 Dec 2016 08:20:32 +, LiNbO3 wrote:
> And have the patch wait in the PR queue until the end of time,
> not even acknowledged at all ?
When I've put in PRs for doc improvements, they've been reviewed
relatively quickly.
On Thursday, 22 December 2016 at 03:18:42 UTC, Jerry wrote:
Not using AliasSeq if that's what you mean. I don't know if the
"tupleof" for a struct would be considered the same as "T..."
but basically what I was doing:
foreach(ref field; myLargeStruct.tupleof)
{
}
Yes that is a compiler-tup
On Thursday, 22 December 2016 at 02:34:48 UTC, Stefan Koch wrote:
On Thursday, 22 December 2016 at 02:32:30 UTC, Jerry wrote:
On Thursday, 22 December 2016 at 01:57:55 UTC, safety0ff wrote:
On Thursday, 22 December 2016 at 01:30:44 UTC, Andrei
Alexandrescu wrote:
Must be a pathological case w
On Thursday, 22 December 2016 at 02:32:30 UTC, Jerry wrote:
Yup looks like that was the cause. Removed some of the
functions that did a "foreach()" over some large tuples. Down
to 26 seconds with that removed.
Also: https://issues.dlang.org/show_bug.cgi?id=2396
On Thursday, 22 December 2016 at 02:32:30 UTC, Jerry wrote:
On Thursday, 22 December 2016 at 01:57:55 UTC, safety0ff wrote:
On Thursday, 22 December 2016 at 01:30:44 UTC, Andrei
Alexandrescu wrote:
Must be a pathological case we should fix anyway. -- Andrei
Likely related bug has been open 5
On Thursday, 22 December 2016 at 01:57:55 UTC, safety0ff wrote:
On Thursday, 22 December 2016 at 01:30:44 UTC, Andrei
Alexandrescu wrote:
Must be a pathological case we should fix anyway. -- Andrei
Likely related bug has been open 5 years minus 1 day:
https://issues.dlang.org/show_bug.cgi?id
On Thursday, 22 December 2016 at 01:30:44 UTC, Andrei
Alexandrescu wrote:
Must be a pathological case we should fix anyway. -- Andrei
Likely related bug has been open 5 years minus 1 day:
https://issues.dlang.org/show_bug.cgi?id=7157
On Thursday, December 22, 2016 00:59:27 hardreset via Digitalmars-d wrote:
> On Wednesday, 21 December 2016 at 18:33:52 UTC, Brad Anderson
> >> Moving the reference compiler to LLVM as was suggested in the
> >> list.
> >
> > I've never been able to understand why it matters.
>
> Cause people think
On 12/21/16 7:09 PM, Jerry wrote:
On Wednesday, 21 December 2016 at 21:27:57 UTC, Jack Stouffer wrote:
On Wednesday, 21 December 2016 at 21:12:07 UTC, Jerry wrote:
Any other backend would be better. DMD with -O takes over an hour for
my project to compile. In comparison LDC with -O3 takes less
On 12/21/16 6:40 PM, Timothee Cour via Digitalmars-d wrote:
Andrei: ping on this? (especially regarding allowing `:`)
I think "lazy" is a bit too cute. "with" is so close to what's actually
needed, it would be a waste to not use it.
Generally I'm weary of the use of ":" (never liked it - it
On Wednesday, 21 December 2016 at 18:33:52 UTC, Brad Anderson
wrote:
On Wednesday, 21 December 2016 at 16:41:56 UTC, hardreset wrote:
On Wednesday, 21 December 2016 at 16:30:15 UTC, bachmeier
wrote:
On Wednesday, 21 December 2016 at 10:15:26 UTC, hardreset
wrote:
On Tuesday, 20 December 2016 at
On Wednesday, December 21, 2016 18:49:43 Johannes Pfau via Digitalmars-d
wrote:
> Am Wed, 21 Dec 2016 08:18:48 -0500
>
> schrieb Andrei Alexandrescu :
> > On 12/20/16 6:08 PM, Andrei Alexandrescu wrote:
> > > Hello, a few engineers at Red Hat are taking a look at using the D
> > > language on the
On Wednesday, December 21, 2016 15:46:19 Gerald via Digitalmars-d wrote:
> Given that DMD is a non-starter for Linux packages, how feasible
> is it to simply deprecate GDC and declare LDC as the
> reference/production compiler for D? DMD could become the
> experimental/future facing compiler used t
On Wednesday, 21 December 2016 at 21:27:57 UTC, Jack Stouffer
wrote:
On Wednesday, 21 December 2016 at 21:12:07 UTC, Jerry wrote:
Any other backend would be better. DMD with -O takes over an
hour for my project to compile. In comparison LDC with -O3
takes less than a minute and produces a faste
On Mon, Dec 19, 2016 at 9:33 PM, Timothee Cour
wrote:
> what about using `lazy` instead of `with`:
>
> `with(import foo)`
> =>
> `lazy(import foo)`
>
> advantages:
> * avoids confusion regarding usual scoping rules of `with` ;
> * conveys that the import is indeed lazy
>
> Furthermore (regardless
On Wednesday, December 21, 2016 22:05:32 Yuxuan Shui via Digitalmars-d
wrote:
> On Wednesday, 21 December 2016 at 21:12:07 UTC, Jerry wrote:
> > On Wednesday, 21 December 2016 at 16:41:58 UTC, Jesse Phillips
> >
> > wrote:
> >> On Wednesday, 21 December 2016 at 16:30:15 UTC, bachmeier
> >>
> >> wr
On Monday, 19 December 2016 at 10:28:31 UTC, Basile B. wrote:
On Monday, 19 December 2016 at 09:58:28 UTC, default0 wrote:
That doesn't solve the complications this introduces if you
want to serialize to/from members with these names, as seen in
the Examples section of the DIP.
Yes it does. S
On 12/20/2016 09:31 AM, Dmitry Olshansky wrote:
On 12/13/16 11:33 PM, Andrei Alexandrescu wrote:
Destroy.
https://github.com/dlang/DIPs/pull/51/files
Andrei
Just a thought but with all of proliferation of imports down to each
declaration comes the pain that e.g. renaming a module cascades t
On 12/21/2016 04:42 PM, Johan Engelen wrote:
On Wednesday, 21 December 2016 at 21:34:04 UTC, Andrei Alexandrescu wrote:
On 12/21/2016 03:04 PM, Johan Engelen wrote:
Super contrived, but I hope you get my drift:
```
int *awesome() pure {
static if (ohSoAwesome) {
return new int;
} else
On Wednesday, 21 December 2016 at 21:12:07 UTC, Jerry wrote:
On Wednesday, 21 December 2016 at 16:41:58 UTC, Jesse Phillips
wrote:
On Wednesday, 21 December 2016 at 16:30:15 UTC, bachmeier
wrote:
[...]
People that want to use D, want to use the latest and
greatest. The reference compiler mov
On Wednesday, 21 December 2016 at 21:34:04 UTC, Andrei
Alexandrescu wrote:
On 12/21/2016 03:04 PM, Johan Engelen wrote:
Super contrived, but I hope you get my drift:
```
int *awesome() pure {
static if (ohSoAwesome) {
return new int;
} else {
return null;
}
}
```
Where does oh
On Wednesday, 21 December 2016 at 21:34:04 UTC, Andrei
Alexandrescu wrote:
On 12/21/2016 03:04 PM, Johan Engelen wrote:
```
I don't know what "required to honor all calls" means, but I
guess it means
```
auto a = foo(); // int* foo() pure;
auto b = foo();
```
cannot be transformed to
```
auto
On 12/21/2016 03:59 PM, John Colvin wrote:
On Wednesday, 21 December 2016 at 15:40:42 UTC, Andrei Alexandrescu wrote:
On 12/20/2016 05:49 PM, Andrei Alexandrescu wrote:
https://github.com/dlang/dlang.org/pull/1528 -- Andrei
Dropped the void functions. On to the next scandal:
A function that
On 12/21/2016 03:10 PM, Johan Engelen wrote:
On Wednesday, 21 December 2016 at 20:04:04 UTC, Johan Engelen wrote:
"Any `pure` function that is not strongly pure _may not be assumed
to be_ memoizable."
That version of mine is also not correct :(
How about: "A strongly pure function can be a
On Wednesday, 21 December 2016 at 21:12:07 UTC, Jerry wrote:
Any other backend would be better. DMD with -O takes over an
hour for my project to compile. In comparison LDC with -O3
takes less than a minute and produces a faster binary. It
doesn't really make sense to increase the workload maint
On 12/21/2016 03:04 PM, Johan Engelen wrote:
On Wednesday, 21 December 2016 at 15:40:42 UTC, Andrei Alexandrescu wrote:
On 12/20/2016 05:49 PM, Andrei Alexandrescu wrote:
https://github.com/dlang/dlang.org/pull/1528 -- Andrei
Dropped the void functions. On to the next scandal:
I think you s
On Wednesday, 21 December 2016 at 16:41:58 UTC, Jesse Phillips
wrote:
On Wednesday, 21 December 2016 at 16:30:15 UTC, bachmeier wrote:
On Wednesday, 21 December 2016 at 10:15:26 UTC, hardreset
wrote:
Is moving to LLVM backend or LDC something that is on the
roadmap?
What does it mean to "move
On Wednesday, 21 December 2016 at 15:40:42 UTC, Andrei
Alexandrescu wrote:
On 12/20/2016 05:49 PM, Andrei Alexandrescu wrote:
https://github.com/dlang/dlang.org/pull/1528 -- Andrei
Dropped the void functions. On to the next scandal:
A function that accepts only parameters without mutable
ind
On Wednesday, December 21, 2016 15:49:35 Stefan Koch via Digitalmars-d
wrote:
> On Wednesday, 21 December 2016 at 15:40:42 UTC, Andrei
>
> Alexandrescu wrote:
> > On 12/20/2016 05:49 PM, Andrei Alexandrescu wrote:
> >> https://github.com/dlang/dlang.org/pull/1528 -- Andrei
> >
> > Dropped the void
On Wednesday, 21 December 2016 at 20:04:04 UTC, Johan Engelen
wrote:
"Any `pure` function that is not strongly pure _may not be
assumed to be_ memoizable."
That version of mine is also not correct :(
How about: "A strongly pure function can be assumed to be
memoizable. For a not strongly
On Wednesday, 21 December 2016 at 15:40:42 UTC, Andrei
Alexandrescu wrote:
On 12/20/2016 05:49 PM, Andrei Alexandrescu wrote:
https://github.com/dlang/dlang.org/pull/1528 -- Andrei
Dropped the void functions. On to the next scandal:
I think you should be very careful in making sure that `pur
On 2016-12-21 18:43, Johannes Pfau wrote:
Back to topic: I'd really love to see a generalization of RTInfo/mixin
templates in D:
I implemented RTInfo for modules a couple of years ago [1].
Unfortunately it was rejected because it had the same problem as RTInfo,
it only works inside object.d.
On 12/21/2016 6:24 AM, Mark wrote:
I do not think that this would be a bad use of the
foundation's funds.
That is one of the purposes of the Foundation.
On 12/21/2016 12:49 PM, Johannes Pfau wrote:
We're at 2.068.2 now.
Johannes, are you personally involved with gdc? If so please email me.
Thanks! -- Andrei
On Wednesday, 21 December 2016 at 18:33:52 UTC, Brad Anderson
wrote:
On Wednesday, 21 December 2016 at 16:41:56 UTC, hardreset wrote:
On Wednesday, 21 December 2016 at 16:30:15 UTC, bachmeier
wrote:
On Wednesday, 21 December 2016 at 10:15:26 UTC, hardreset
wrote:
On Tuesday, 20 December 2016 at
On Wed, Dec 21, 2016 at 06:33:52PM +, Brad Anderson via Digitalmars-d wrote:
[...]
> In theory the backend should be completely divorced from the frontend
> and people would be editing a libd repo or something and there
> wouldn't be a need for a reference compiler.
Isn't our plan to eventuall
On Wednesday, 21 December 2016 at 16:41:56 UTC, hardreset wrote:
On Wednesday, 21 December 2016 at 16:30:15 UTC, bachmeier wrote:
On Wednesday, 21 December 2016 at 10:15:26 UTC, hardreset
wrote:
On Tuesday, 20 December 2016 at 23:08:28 UTC, Andrei
Alexandrescu wrote:
Hello, a few engineers at R
On 12/20/2016 10:36 PM, Walter Bright wrote:
> On 12/20/2016 11:05 AM, Dicebot wrote:
>> Yes, pretty much. What ways do you have in mind? I am only aware of two:
>>
>> 1) ModuleInfo
>> 2) https://dlang.org/spec/traits.html#getUnitTests
>
>
> Put pointers to them in a special segment.
Oh, so you
On Wednesday, 21 December 2016 at 17:49:43 UTC, Johannes Pfau
wrote:
We're at 2.068.2 now. Still old, but good enough to run the
latest vibe.D release.
Just a quick heads up (and maybe motivation): the upcoming 0.8.0
release will drop the support for 2.068 ;-)
https://github.com/rejectedsoft
Am Wed, 21 Dec 2016 15:46:19 +
schrieb Gerald :
> Given that DMD is a non-starter for Linux packages, how feasible
> is it to simply deprecate GDC and declare LDC as the
> reference/production compiler for D?
Hey, GDC is still in active development ;-) We need some more time to
catch up but
On Wednesday, 21 December 2016 at 14:50:31 UTC, thedeemon wrote:
On Wednesday, 21 December 2016 at 11:54:35 UTC, Ilya Yaroshenko
wrote:
On Wednesday, 21 December 2016 at 11:36:14 UTC, thedeemon
wrote:
On Tuesday, 20 December 2016 at 10:18:12 UTC, Kelly Sommers
wrote:
[...]
Bad news: without
Am Wed, 21 Dec 2016 08:18:48 -0500
schrieb Andrei Alexandrescu :
> On 12/20/16 6:08 PM, Andrei Alexandrescu wrote:
> > Hello, a few engineers at Red Hat are taking a look at using the D
> > language on the desktop and have reached out to us. They have
> > created a list of issues. We are on the to
Am Tue, 20 Dec 2016 12:36:53 -0800
schrieb Walter Bright :
> On 12/20/2016 11:05 AM, Dicebot wrote:
> > Yes, pretty much. What ways do you have in mind? I am only aware of
> > two:
> >
> > 1) ModuleInfo
> > 2) https://dlang.org/spec/traits.html#getUnitTests
>
>
> Put pointers to them in a spec
On Wednesday, 21 December 2016 at 16:41:56 UTC, hardreset wrote:
Moving the reference compiler to LLVM as was suggested in the
list.
LDC is the only compiler on Fedora/CentOS anyway!
On Wednesday, 21 December 2016 at 13:01:53 UTC, Benjiro wrote:
Just check the socket code and there is a small feature missing:
enum SocketOption: int
{
DEBUG =SO_DEBUG,/// Record
debugging information
BROADCAST =SO_BROADCAST,/// Allow
tra
On Wednesday, 21 December 2016 at 16:30:15 UTC, bachmeier wrote:
On Wednesday, 21 December 2016 at 10:15:26 UTC, hardreset wrote:
Is moving to LLVM backend or LDC something that is on the
roadmap?
What does it mean to "move" to LDC? Why can't you use LDC now?
People that want to use D, want
On Wednesday, 21 December 2016 at 16:30:15 UTC, bachmeier wrote:
On Wednesday, 21 December 2016 at 10:15:26 UTC, hardreset wrote:
On Tuesday, 20 December 2016 at 23:08:28 UTC, Andrei
Alexandrescu wrote:
Hello, a few engineers at Red Hat are taking a look at using
the D language on the desktop a
On 12/21/2016 11:32 AM, hardreset wrote:
On Wednesday, 21 December 2016 at 16:20:31 UTC, Jack Stouffer wrote:
On Wednesday, 21 December 2016 at 10:15:26 UTC, hardreset wrote:
Is moving to LLVM backend or LDC something that is on the roadmap?
Nope.
So whats the solution to the "DMD compiler
On Wednesday, 21 December 2016 at 16:20:31 UTC, Jack Stouffer
wrote:
On Wednesday, 21 December 2016 at 10:15:26 UTC, hardreset wrote:
Is moving to LLVM backend or LDC something that is on the
roadmap?
Nope.
So whats the solution to the "DMD compiler issues" listed?
On Wednesday, 21 December 2016 at 10:15:26 UTC, hardreset wrote:
On Tuesday, 20 December 2016 at 23:08:28 UTC, Andrei
Alexandrescu wrote:
Hello, a few engineers at Red Hat are taking a look at using
the D language on the desktop and have reached out to us. They
have created a list of issues. We
On Wednesday, 21 December 2016 at 10:15:26 UTC, hardreset wrote:
Is moving to LLVM backend or LDC something that is on the
roadmap?
Nope.
On Wednesday, 21 December 2016 at 15:46:19 UTC, Gerald wrote:
Given that DMD is a non-starter for Linux packages, how
feasible is it to simply deprecate GDC and declare LDC as the
reference/production compiler for D? DMD could become the
experimental/future facing compiler used to evolve D as a
On Wednesday, 21 December 2016 at 15:40:42 UTC, Andrei
Alexandrescu wrote:
On 12/20/2016 05:49 PM, Andrei Alexandrescu wrote:
https://github.com/dlang/dlang.org/pull/1528 -- Andrei
Dropped the void functions. On to the next scandal:
A function that accepts only parameters without mutable
ind
On Tuesday, 20 December 2016 at 23:08:28 UTC, Andrei Alexandrescu
wrote:
Hello, a few engineers at Red Hat are taking a look at using
the D language on the desktop and have reached out to us. They
have created a list of issues. We are on the top-level ones,
and of course would appreciate any co
On 12/20/2016 05:49 PM, Andrei Alexandrescu wrote:
https://github.com/dlang/dlang.org/pull/1528 -- Andrei
Dropped the void functions. On to the next scandal:
A function that accepts only parameters without mutable indirections and
returns a result that has mutable indirections is called a $(I
On 2016-12-21 15:58, Madaz Hill wrote:
I'd like to add that the windows version would require another change so
that DMD becomes true FOSS. Unless the 32 bit version get dropped away,
the standard C library, snn.lib, is even not open-sourced (which is a
worst than the backend situation) !
A. T
On 12/21/2016 05:08 AM, Timon Gehr wrote:
On 21.12.2016 01:58, Andrei Alexandrescu wrote:
On 12/20/16 7:40 PM, Timon Gehr wrote:
On 20.12.2016 23:49, Andrei Alexandrescu wrote:
https://github.com/dlang/dlang.org/pull/1528 -- Andrei
Good, except:
"$(P `pure` functions returning `void` will b
On 12/20/2016 11:32 PM, Joakim wrote:
On Tuesday, 20 December 2016 at 20:51:54 UTC, Andrei Alexandrescu wrote:
Thanks for this analysis of the remaining dependency graph, it is worth
looking at. Allow me to poke some holes in it.
To begin with, the amount of scoping that has been done is overst
On Wednesday, 21 December 2016 at 13:26:14 UTC, ixid wrote:
On Tuesday, 20 December 2016 at 23:08:28 UTC, Andrei
Alexandrescu wrote:
Hello, a few engineers at Red Hat are taking a look at using
the D language on the desktop and have reached out to us. They
have created a list of issues. We are
On Wednesday, 21 December 2016 at 14:50:31 UTC, thedeemon wrote:
On Wednesday, 21 December 2016 at 11:54:35 UTC, Ilya Yaroshenko
wrote:
On Wednesday, 21 December 2016 at 11:36:14 UTC, thedeemon
wrote:
[...]
If this is true, a blog post about it with more details is
very welcome --Ilya
Have
On Wednesday, 21 December 2016 at 11:54:35 UTC, Ilya Yaroshenko
wrote:
On Wednesday, 21 December 2016 at 11:36:14 UTC, thedeemon wrote:
On Tuesday, 20 December 2016 at 10:18:12 UTC, Kelly Sommers
wrote:
[...]
Bad news: without complete redesign of the language and
turning into one more C++/C
On Tuesday, 20 December 2016 at 16:22:43 UTC, Walter Bright wrote:
D is quite a bit less formal, but still, if you want action
consider that you aren't going to get it with any organization
unless you're willing to:
1. pay others to do it
2. convince others that your important issues are more
On Wednesday, 21 December 2016 at 13:18:48 UTC, Andrei
Alexandrescu wrote:
On 12/20/16 6:08 PM, Andrei Alexandrescu wrote:
Hello, a few engineers at Red Hat are taking a look at using
the D
language on the desktop and have reached out to us. They have
created a
list of issues. We are on the top
On Tuesday, 20 December 2016 at 23:08:28 UTC, Andrei Alexandrescu
wrote:
Hello, a few engineers at Red Hat are taking a look at using
the D language on the desktop and have reached out to us. They
have created a list of issues. We are on the top-level ones,
and of course would appreciate any co
On 12/20/16 6:08 PM, Andrei Alexandrescu wrote:
Hello, a few engineers at Red Hat are taking a look at using the D
language on the desktop and have reached out to us. They have created a
list of issues. We are on the top-level ones, and of course would
appreciate any community help as well.
http
On Wednesday, 21 December 2016 at 13:01:53 UTC, Benjiro wrote:
I don't think this needs weeks of discussion ;)
No discussion needed at all. You could simply file an issue here:
https://issues.dlang.org/, or submit a PR.
Just check the socket code and there is a small feature missing:
enum SocketOption: int
{
DEBUG =SO_DEBUG,/// Record
debugging information
BROADCAST =SO_BROADCAST,/// Allow
transmission of broadcast messages
REUSEADDR =SO_REU
On Wednesday, 21 December 2016 at 11:54:35 UTC, Ilya Yaroshenko
wrote:
On Wednesday, 21 December 2016 at 11:36:14 UTC, thedeemon wrote:
On Tuesday, 20 December 2016 at 10:18:12 UTC, Kelly Sommers
wrote:
[...]
Bad news: without complete redesign of the language and
turning into one more C++/C
On Wednesday, 21 December 2016 at 11:36:14 UTC, thedeemon wrote:
On Tuesday, 20 December 2016 at 10:18:12 UTC, Kelly Sommers
wrote:
[...]
Bad news: without complete redesign of the language and turning
into one more C++/CLI (where you have different kinds of
pointers in the language for GC a
On Tuesday, 20 December 2016 at 10:18:12 UTC, Kelly Sommers wrote:
What I really want is what C++ wanted to deliver but it
doesn't. I want something better than writing C but with the
same performance as C and the ability to interface with C
without the performance loss and with easily composab
On Wednesday, 21 December 2016 at 09:35:31 UTC, Andrey wrote:
On Wednesday, 21 December 2016 at 07:47:08 UTC, O-N-S wrote:
On Monday, 19 December 2016 at 23:02:59 UTC, Benjiro wrote:
I split this from the "Re: A betterC modular standard
library?" topic because my response is will be too much
o
On Tuesday, 20 December 2016 at 23:08:28 UTC, Andrei Alexandrescu
wrote:
Hello, a few engineers at Red Hat are taking a look at using
the D language on the desktop and have reached out to us. They
have created a list of issues. We are on the top-level ones,
and of course would appreciate any co
On 21.12.2016 01:58, Andrei Alexandrescu wrote:
On 12/20/16 7:40 PM, Timon Gehr wrote:
On 20.12.2016 23:49, Andrei Alexandrescu wrote:
https://github.com/dlang/dlang.org/pull/1528 -- Andrei
Good, except:
"$(P `pure` functions returning `void` will be always called even if it
is strongly `pur
On Wednesday, 21 December 2016 at 07:47:08 UTC, O-N-S wrote:
On Monday, 19 December 2016 at 23:02:59 UTC, Benjiro wrote:
I split this from the "Re: A betterC modular standard
library?" topic because my response is will be too much
off-topic but the whole thread is irking me the wrong way. I
se
On Tuesday, 20 December 2016 at 23:08:28 UTC, Andrei Alexandrescu
wrote:
Hello, a few engineers at Red Hat are taking a look at using
the D language on the desktop and have reached out to us. They
have created a list of issues. We are on the top-level ones,
and of course would appreciate any co
https://www.packtpub.com/books/content/modelling-rpg-d/
Maybe worth linking on reddit etc.?
(Just picking out a random item from the list at [1] and showing
the current progress and giving a good point on where to start.
Maybe we can do this with the entire list?)
The assert statement is "dumb" in a way that it doesn't show me
what data it actually compared, making using pure-assert
86 matches
Mail list logo
