On 30.10.2014 04:02, Martin Nowak wrote:
On Wednesday, 8 October 2014 at 18:25:00 UTC, Rainer Schuetze wrote:
I'm benchmarking my Windows version of a concurrent GC with it. It
does quite a lot of allocations, and this is causing some serious
trouble because marking cannot compete with the
On Friday, 17 October 2014 at 11:30:48 UTC, Marc Schütz wrote:
Marginally related: Page fault handling in user space.
http://lwn.net/Articles/615086/
Maybe this can be used as an alternative to forking.
Definitely good news for moving GCs.
On Wednesday, 8 October 2014 at 18:25:00 UTC, Rainer Schuetze
wrote:
I'm benchmarking my Windows version of a concurrent GC with it.
It does quite a lot of allocations, and this is causing some
serious trouble because marking cannot compete with the rate of
allocation, causing some tests to
This means, the program should link with object file instead of a
library. Alternatively it can be pulled eagerly by the proposed
`init` function if it will explicitly depend on a symbol from a
gc library - the linker could resolve the symbol early.
On Thursday, 23 October 2014 at 15:53:19 UTC, Sean Kelly wrote:
We could experiment with separately linking the GC. It
wouldn't be hard to do, though the link line might be a bit
weird, since core, rt, and gc are all interdependent in terms
of link dependencies.
Can't it work like any other
On Friday, 24 October 2014 at 06:50:05 UTC, Kagamin wrote:
On Thursday, 23 October 2014 at 15:53:19 UTC, Sean Kelly wrote:
We could experiment with separately linking the GC. It
wouldn't be hard to do, though the link line might be a bit
weird, since core, rt, and gc are all interdependent in
On Tuesday, 7 October 2014 at 20:06:43 UTC, Walter Bright wrote:
On 10/6/2014 9:51 AM, Dicebot wrote:
https://github.com/D-Programming-Language/druntime/pull/985
Thank you. This is great progress!
I understand the caveats, but can this be put into a shape
where it can be pulled despite
On Friday, 17 October 2014 at 17:53:18 UTC, Andrej Mitrovic via
Digitalmars-d-announce wrote:
I've come to even hate anything GUI (except maybe the
editor), I'd hate to even think about browsing the file system
with a
mouse anymore.
Yes, you can: Windows Explorer does support keyboard input
On Thu, 23 Oct 2014 07:12:25 +
Kagamin via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com wrote:
On Friday, 17 October 2014 at 17:53:18 UTC, Andrej Mitrovic via
Digitalmars-d-announce wrote:
I've come to even hate anything GUI (except maybe the
editor), I'd hate to even
On Thursday, 23 October 2014 at 07:09:04 UTC, Kagamin wrote:
On Tuesday, 7 October 2014 at 20:06:43 UTC, Walter Bright wrote:
On 10/6/2014 9:51 AM, Dicebot wrote:
https://github.com/D-Programming-Language/druntime/pull/985
Thank you. This is great progress!
I understand the caveats, but can
On Thursday, 23 October 2014 at 08:46:46 UTC, Dicebot wrote:
Currently druntime is packaged as part of Phobos library binary
so I don't see easy way to do it. It could be possible to do
the replacement at the startup using GC Proxy instrastructure
but CDGC does not currently support it (though
On Thursday, 23 October 2014 at 09:53:44 UTC, Kagamin wrote:
On Thursday, 23 October 2014 at 08:46:46 UTC, Dicebot wrote:
Currently druntime is packaged as part of Phobos library
binary so I don't see easy way to do it. It could be possible
to do the replacement at the startup using GC Proxy
On Thursday, 23 October 2014 at 09:57:38 UTC, Dicebot wrote:
Uh, what will it link to? extern(C) function like gc_malloc?
druntime links to those statically itself so you will get
application that links to different GC than druntime itself.
The reason is CDGC provides symbols like gc_malloc
On Thursday, 23 October 2014 at 11:03:35 UTC, Kagamin wrote:
On Thursday, 23 October 2014 at 09:57:38 UTC, Dicebot wrote:
Uh, what will it link to? extern(C) function like gc_malloc?
druntime links to those statically itself so you will get
application that links to different GC than druntime
On Thursday, 23 October 2014 at 13:13:06 UTC, Mathias LANG wrote:
It will clash at best, or just ignore cdgc, as objects are
considered as a whole, in link order.
At best, they won't clash :)
If the default GC is not pulled by the linker, why should they
clash?
Now, if druntime defines
Regan Heath, el 22 de October a las 10:41 me escribiste:
NO, this is completely false, and why I think you are not entirely
familiar with env vars in posix. LD_PRELOAD and LD_LIBRARY_PATH affects
ALL, EACH and EVERY program for example. D or not D. Every single
dynamically linked program.
On Thursday, 23 October 2014 at 14:02:33 UTC, Kagamin wrote:
On Thursday, 23 October 2014 at 13:13:06 UTC, Mathias LANG
wrote:
It will clash at best, or just ignore cdgc, as objects are
considered as a whole, in link order.
At best, they won't clash :)
If the default GC is not pulled by the
On Thu, 23 Oct 2014 15:27:50 +0100, Leandro Lucarella l...@llucax.com.ar
wrote:
Regan Heath, el 22 de October a las 10:41 me escribiste:
NO, this is completely false, and why I think you are not entirely
familiar with env vars in posix. LD_PRELOAD and LD_LIBRARY_PATH affects
ALL, EACH and
Regan Heath, el 23 de October a las 17:24 me escribiste:
On Thu, 23 Oct 2014 15:27:50 +0100, Leandro Lucarella
l...@llucax.com.ar wrote:
Regan Heath, el 22 de October a las 10:41 me escribiste:
NO, this is completely false, and why I think you are not entirely
familiar with env vars in
On Tue, 21 Oct 2014 23:52:22 +0100, Leandro Lucarella l...@llucax.com.ar
wrote:
The runtime is not platform independent AT ALL.
^ implementation
Why should you provide a platform agnostic way to configure it?
Because it makes life easier for developers and cross platform
On Mon, 20 Oct 2014 18:19:33 +0100, Sean Kelly s...@invisibleduck.org
wrote:
On Monday, 20 October 2014 at 10:39:28 UTC, Regan Heath wrote:
Sure, but past/current env vars being used are used *privately* to a
single program. What you're suggesting here are env vars which will
affect
Regan Heath, el 20 de October a las 11:39 me escribiste:
On Fri, 17 Oct 2014 17:54:55 +0100, Leandro Lucarella
l...@llucax.com.ar wrote:
Regan Heath, el 17 de October a las 15:43 me escribiste:
I think you've mistook my tone. I am not religious about this. I
just think it's a bad idea for a
On Fri, 17 Oct 2014 17:54:55 +0100, Leandro Lucarella l...@llucax.com.ar
wrote:
Regan Heath, el 17 de October a las 15:43 me escribiste:
I think you've mistook my tone. I am not religious about this. I
just think it's a bad idea for a program to alter behaviour based on
a largely invisible
On Monday, 20 October 2014 at 10:39:28 UTC, Regan Heath wrote:
Sure, but past/current env vars being used are used *privately*
to a single program. What you're suggesting here are env vars
which will affect *all* D programs that see them. If D takes
over the world as we all hope it will
On Friday, 17 October 2014 at 08:28:23 UTC, Martin Nowak wrote:
On Friday, 17 October 2014 at 05:38:05 UTC, thedeemon wrote:
Gentlemen, do I understand correctly that you're trying to
find a Windows-friendly switch to something that will never
see the light on Windows (because of being based
On Friday, 17 October 2014 at 05:38:05 UTC, thedeemon wrote:
Gentlemen, do I understand correctly that you're trying to find
a Windows-friendly switch to something that will never see the
light on Windows (because of being based on fork)?
No we want general runtime configuration, not only for
On Fri, 17 Oct 2014 00:01:39 +0100, Leandro Lucarella l...@llucax.com.ar
wrote:
Regan Heath, el 14 de October a las 11:11 me escribiste:
I still don't understand why wouldn't we use environment variables for
what they've been created for, it's foolish :-)
As mentioned this is not a very
Regan Heath, el 17 de October a las 10:55 me escribiste:
Regan Heath, el 14 de October a las 11:11 me escribiste:
I still don't understand why wouldn't we use environment variables for
what they've been created for, it's foolish :-)
As mentioned this is not a very windows friendly/like
Marginally related: Page fault handling in user space.
http://lwn.net/Articles/615086/
Maybe this can be used as an alternative to forking.
Regan Heath, el 17 de October a las 15:43 me escribiste:
You've got it backwards. I'm looking for a *better* solution than
environment variables, which are a truly horrid way to control
runtime behaviour IMHO.
OK, then this is now a holly war. So I'll drop it here.
I think you've mistook
On 10/17/14, Leandro Lucarella via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com wrote:
In all the years I've been working in Linux I never, EVER came across
problems with environment variables being accidentally set. I find it
very hard to believe this is a real problem. On the
Wouldn't it be more generally useful to have another function
like main() called init() which if present (optional) is called
before/during initialisation. It would be passed the command
line arguments. Then a program can chose to implement it, and
can use it to configure the GC in any
On Thu, 16 Oct 2014 08:10:38 +
Dylan Knutson via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com wrote:
I'm sure there's a cross platform way to retrieve
them without bring passed them directly
there isn't.
signature.asc
Description: PGP signature
On Thursday, 16 October 2014 at 10:56:49 UTC, ketmar via
Digitalmars-d-announce wrote:
On Thu, 16 Oct 2014 08:10:38 +
Dylan Knutson via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com wrote:
I'm sure there's a cross platform way to retrieve them without
bring passed them
On Thu, 16 Oct 2014 09:10:38 +0100, Dylan Knutson tcdknut...@gmail.com
wrote:
Wouldn't it be more generally useful to have another function like
main() called init() which if present (optional) is called
before/during initialisation. It would be passed the command line
arguments.
On Thu, 16 Oct 2014 13:54:25 +
Sean Kelly via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com wrote:
I'm sure there's a cross platform way to retrieve them without
bring passed them directly
there isn't.
Runtime.args?
it's good, but it isn't modifiable. so programmer must
Dylan Knutson, el 16 de October a las 08:10 me escribiste:
Wouldn't it be more generally useful to have another function like
main() called init() which if present (optional) is called
before/during initialisation. It would be passed the command line
arguments. Then a program can chose to
Regan Heath, el 14 de October a las 11:11 me escribiste:
I still don't understand why wouldn't we use environment variables for
what they've been created for, it's foolish :-)
As mentioned this is not a very windows friendly/like solution.
As mentioned you don't have to use a unique
Gentlemen, do I understand correctly that you're trying to find a
Windows-friendly switch to something that will never see the
light on Windows (because of being based on fork)?
On Sat, 11 Oct 2014 01:45:48 +0100, Leandro Lucarella l...@llucax.com.ar
wrote:
Walter Bright, el 9 de October a las 17:28 me escribiste:
On 10/9/2014 7:25 AM, Dicebot wrote:
At the same time I don't see what real benefit such runtime options
brings to
the table. This is why in my PR
On 12.10.2014 05:41, Walter Bright wrote:
On 10/11/2014 4:23 PM, Leandro Lucarella wrote:
It basically defines a bunch of environment variables and run the
binary. This is a super common practice in posix systems. We are not
inventing anything here. I don't know how windows or other OSs deal
On 2014-10-12 10:30, Rainer Schuetze wrote:
C# programs also use app.exe.config files alongside the executable to
setup the application. Maybe we could do something similar.
I just found this in msbuild/14.0/bin/csc.exe.config:
configuration
runtime
gcServer enabled=true /
Walter Bright, el 11 de October a las 16:39 me escribiste:
On 10/11/2014 3:59 PM, Leandro Lucarella wrote:
You can use different mechanisms in different OSs. There is no need to
force a runtime to be OS-independent. If that were the case, then we
should close the concurrent GC pull request
Walter Bright, el 11 de October a las 20:41 me escribiste:
On 10/11/2014 4:23 PM, Leandro Lucarella wrote:
It basically defines a bunch of environment variables and run the
binary. This is a super common practice in posix systems. We are not
inventing anything here. I don't know how windows or
Rainer Schuetze, el 12 de October a las 10:30 me escribiste:
On 12.10.2014 05:41, Walter Bright wrote:
On 10/11/2014 4:23 PM, Leandro Lucarella wrote:
It basically defines a bunch of environment variables and run the
binary. This is a super common practice in posix systems. We are not
On 10/12/14, Leandro Lucarella via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com wrote:
Also, completely unflexible, so to run 2 instances of the same program
with different configuration you have to run one, modify the config file
and then run the seconds?
Perhaps there would be
Am 11.10.2014 um 06:43 schrieb dennis luehring:
Am 11.10.2014 06:25, schrieb Andrei Alexandrescu:
On 10/10/14, 7:54 PM, Walter Bright wrote:
On 10/10/2014 5:45 PM, Leandro Lucarella wrote:
I still don't understand why wouldn't we use environment variables for
what they've been created for,
On 10/11/2014 3:59 PM, Leandro Lucarella wrote:
You can use different mechanisms in different OSs. There is no need to
force a runtime to be OS-independent. If that were the case, then we
should close the concurrent GC pull request now.
I still don't see why it can't use a special argument to
Andrei Alexandrescu, el 10 de October a las 21:25 me escribiste:
On 10/10/14, 7:54 PM, Walter Bright wrote:
On 10/10/2014 5:45 PM, Leandro Lucarella wrote:
I still don't understand why wouldn't we use environment variables for
what they've been created for, it's foolish :-)
Because using
On 10/11/2014 4:23 PM, Leandro Lucarella wrote:
It basically defines a bunch of environment variables and run the
binary. This is a super common practice in posix systems. We are not
inventing anything here. I don't know how windows or other OSs deal with
defining environment variables in a
On 10.10.2014 02:30, Walter Bright wrote:
On 10/9/2014 11:25 AM, Rainer Schuetze wrote:
Martin is very much against this, one reason is that it does not work
with
druntime in a shared library.
I can understand that, but I also don't know what a reasonable use case
would be for sharing a
On 09.10.2014 21:38, David Nadlinger wrote:
On Thursday, 9 October 2014 at 18:33:25 UTC, Rainer Schuetze wrote:
This is a gcc extension, which isn't supported under Windows by dmd.
Can you add this attribute in GDC/LDC as part of a D file aswell?
On 09.10.2014 21:46, Jacob Carlborg wrote:
On 2014-10-09 20:33, Rainer Schuetze wrote:
This is a gcc extension, which isn't supported under Windows by dmd.
It seems to be possible in Visual Studio [1], but that still leaves OMF.
[1]
On 10/10/2014 12:37 AM, Rainer Schuetze wrote:
It was my impression that phobos in a shared library would soon become the
default on linux, i.e. any application would use it by default. In that case,
all supported GCs might actually have to be included in the shared library.
The options to
On Friday, 10 October 2014 at 07:37:49 UTC, Rainer Schuetze wrote:
It was my impression that phobos in a shared library would soon
become the default on linux, i.e. any application would use it
by default. In that case, all supported GCs might actually have
to be included in the shared
Walter Bright, el 9 de October a las 17:28 me escribiste:
On 10/9/2014 7:25 AM, Dicebot wrote:
At the same time I don't see what real benefit such runtime options brings to
the table. This is why in my PR garbage collector is currently chosen during
compilation time.
Choosing at compile
On 10/10/14, 5:45 PM, Leandro Lucarella wrote:
I still don't understand why wouldn't we use environment variables for
what they've been created for, it's foolish:-)
I, too, think envvars are quite appropriate here. -- Andrei
On 10/10/2014 5:45 PM, Leandro Lucarella wrote:
I still don't understand why wouldn't we use environment variables for
what they've been created for, it's foolish :-)
Because using environment variables to tune program X will also affect programs
A-Z.
On 10/10/14, 7:54 PM, Walter Bright wrote:
On 10/10/2014 5:45 PM, Leandro Lucarella wrote:
I still don't understand why wouldn't we use environment variables for
what they've been created for, it's foolish :-)
Because using environment variables to tune program X will also affect
programs
On 10/10/2014 9:25 PM, Andrei Alexandrescu wrote:
On 10/10/14, 7:54 PM, Walter Bright wrote:
On 10/10/2014 5:45 PM, Leandro Lucarella wrote:
I still don't understand why wouldn't we use environment variables for
what they've been created for, it's foolish :-)
Because using environment
Am 11.10.2014 06:25, schrieb Andrei Alexandrescu:
On 10/10/14, 7:54 PM, Walter Bright wrote:
On 10/10/2014 5:45 PM, Leandro Lucarella wrote:
I still don't understand why wouldn't we use environment variables for
what they've been created for, it's foolish :-)
Because using environment
On 08/10/14 22:47, Rainer Schuetze wrote:
C main is no longer under user control, because it is auto-generated
with D main. I never liked that change, we've just discovered another
reason.
All platforms have API's to access the command line arguments passed to
main. On OS X that would be
On 09.10.2014 08:29, Jacob Carlborg wrote:
On 08/10/14 22:47, Rainer Schuetze wrote:
C main is no longer under user control, because it is auto-generated
with D main. I never liked that change, we've just discovered another
reason.
All platforms have API's to access the command line
On 10/8/2014 11:43 PM, Rainer Schuetze wrote:
Yes, but the problem is not to access command line arguments, but to run code
before the GC initialization i.e. before _d_run_main is executed.
If we can assume a C++ backend, using static initialization of a C++ global
could work:
static bool
On 09/10/14 08:43, Rainer Schuetze wrote:
Yes, but the problem is not to access command line arguments, but to run
code before the GC initialization i.e. before _d_run_main is executed.
If we can assume a C++ backend, using static initialization of a C++
global could work:
static bool
On Wednesday, 8 October 2014 at 17:39:46 UTC, Walter Bright wrote:
On 10/8/2014 12:43 AM, Leandro Lucarella wrote:
I think this is an unjustified fear, there are already many
environment
variables that can affect your program. That's why they are
called...
environment variables :)
Being on
On Thursday, 9 October 2014 at 14:20:07 UTC, Sean Kelly wrote:
Back when Druntime was called Ares, it was possible to choose
the GC at link time. Do we really need to defer the decision
to run time? If so, switching GCs after the app has started
should work in most cases, though I'm not sure
On 09.10.2014 10:18, Walter Bright wrote:
On 10/8/2014 11:43 PM, Rainer Schuetze wrote:
Yes, but the problem is not to access command line arguments, but to
run code
before the GC initialization i.e. before _d_run_main is executed.
If we can assume a C++ backend, using static initialization
On 09.10.2014 15:31, Jacob Carlborg wrote:
On 09/10/14 08:43, Rainer Schuetze wrote:
Yes, but the problem is not to access command line arguments, but to run
code before the GC initialization i.e. before _d_run_main is executed.
If we can assume a C++ backend, using static initialization of
On Thursday, 9 October 2014 at 18:33:25 UTC, Rainer Schuetze
wrote:
This is a gcc extension, which isn't supported under Windows by
dmd. Can you add this attribute in GDC/LDC as part of a D file
aswell?
On 2014-10-09 20:33, Rainer Schuetze wrote:
This is a gcc extension, which isn't supported under Windows by dmd.
It seems to be possible in Visual Studio [1], but that still leaves OMF.
[1]
http://stackoverflow.com/questions/1113409/attribute-constructor-equivalent-in-vc
--
/Jacob
On 10/9/2014 7:25 AM, Dicebot wrote:
At the same time I don't see what real benefit such runtime options brings to
the table. This is why in my PR garbage collector is currently chosen during
compilation time.
Choosing at compile time is probably best.
On 10/9/2014 11:25 AM, Rainer Schuetze wrote:
Martin is very much against this, one reason is that it does not work with
druntime in a shared library.
I can understand that, but I also don't know what a reasonable use case would be
for sharing a library yet using different GC's - it sounds
On Wednesday, 8 October 2014 at 00:18:16 UTC, Walter Bright wrote:
On 10/7/2014 3:27 PM, Leandro Lucarella wrote:
Walter Bright, el 7 de October a las 13:06 me escribiste:
On 10/6/2014 9:51 AM, Dicebot wrote:
That's a good idea, but I hate environment variables affecting
all D executables.
I like the on/off at runtime idea. Less scary to try on important code. We
can just disable the concurrent gc if we notice dodgy things happening.
On Wed, Oct 8, 2014 at 8:09 AM, eles via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com wrote:
On Wednesday, 8 October 2014 at
On Monday, 6 October 2014 at 17:29:23 UTC, Dicebot wrote:
No, I didn't get to running any perf test so far. Did PR as
soon as test suite passes and commits looked sane. Will do
eventually. Any specific project you are interested in?
I'd love to see the impact on vibe.d but it is subject to
On Tue, 07 Oct 2014 17:18:18 -0700
Walter Bright via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com wrote:
That's a good idea, but I hate environment variables affecting all D
executables. They always wind up being inadvertently being left on,
or off, or set for some unrelated
On Wednesday, 8 October 2014 at 06:58:36 UTC, ketmar via
Digitalmars-d-announce wrote:
On Tue, 07 Oct 2014 17:18:18 -0700
Walter Bright via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com wrote:
i assume that not everyone are ready to build dmd from sources,
Digger? What can be
On Wed, 08 Oct 2014 07:14:29 +
Paolo Invernizzi via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com wrote:
i assume that not everyone are ready to build dmd from sources,
Digger? What can be easier?
i've never used Digger, so i can't tell anything about it. ;-)
signature.asc
On Wed, 08 Oct 2014 07:14:29 +
Paolo Invernizzi via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com wrote:
i assume that not everyone are ready to build dmd from sources,
Digger? What can be easier?
p.s. i mean that it will be good to have Digger mentioned somewhere at
the
On 10/8/2014 2:55 AM, Vladimir Panteleev wrote:
On Wednesday, 8 October 2014 at 00:18:16 UTC, Walter Bright wrote:
Sort of like:
user: need to fix this on the website
n.g.: thanks! fixed now!
user: no it isn't
n.g.: looks good to me
[lots of fruitless back and forth]
n.g.: did you
On Wed, 8 Oct 2014 20:47:09 +0300
ketmar via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com wrote:
p.s. i believe that there shouldn't be any flags that turns off range
checking. if someone wants to do it fast, he can use pointer
arithmetics (this is exactly the same as using arrays
On 08.10.2014 19:39, Walter Bright wrote:
On 10/8/2014 12:43 AM, Leandro Lucarella wrote:
I think this is an unjustified fear, there are already many environment
variables that can affect your program. That's why they are called...
environment variables :)
Being on the front lines of tech
On Wednesday, 8 October 2014 at 17:39:46 UTC, Walter Bright wrote:
Being on the front lines of tech support for 30 years, it is
not an unjustified fear nor a hypothetical problem.
What you could do is propose a secret switch to all dmd
generated programs that the druntime switch checks before
On 06.10.2014 19:29, Dicebot wrote:
On Monday, 6 October 2014 at 17:23:55 UTC, Andrei Alexandrescu wrote:
On 10/6/14, 9:51 AM, Dicebot wrote:
https://github.com/D-Programming-Language/druntime/pull/985
This is awesome. I recall Don had some solid performance numbers for
it in his talk, do
On 08.10.2014 22:10, Walter Bright wrote:
On 10/8/2014 11:19 AM, Rainer Schuetze wrote:
There is no perfect plan how an application can change the default
options that
are used without arguments, though. Doing this in main() is too late
for some
parameters (e.g. precise), because the GC will
On Mon, 06 Oct 2014 16:51:06 +
Dicebot via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com wrote:
https://github.com/D-Programming-Language/druntime/pull/985
Here is initial port result available for early experiments. It
can be compiled with make -f posix.mak
On Monday, 6 October 2014 at 16:51:07 UTC, Dicebot wrote:
https://github.com/D-Programming-Language/druntime/pull/985
Here is initial port result available for early experiments. It
can be compiled with make -f posix.mak GC_TYPE=concurrent and
passes the test suite with only shared library
On 10/6/14, 9:51 AM, Dicebot wrote:
https://github.com/D-Programming-Language/druntime/pull/985
This is awesome. I recall Don had some solid performance numbers for it
in his talk, do you have any in the context of D2? -- Andrei
On Monday, 6 October 2014 at 17:23:55 UTC, Andrei Alexandrescu
wrote:
On 10/6/14, 9:51 AM, Dicebot wrote:
https://github.com/D-Programming-Language/druntime/pull/985
This is awesome. I recall Don had some solid performance
numbers for it in his talk, do you have any in the context of
D2? --
On 10/6/14, 10:29 AM, Dicebot wrote:
On Monday, 6 October 2014 at 17:23:55 UTC, Andrei Alexandrescu wrote:
On 10/6/14, 9:51 AM, Dicebot wrote:
https://github.com/D-Programming-Language/druntime/pull/985
This is awesome. I recall Don had some solid performance numbers for
it in his talk, do
91 matches
Mail list logo
