On 14 July 2014 15:58, Iain Buclaw via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:
> On 14 July 2014 06:19, Manu via Digitalmars-d-announce
> wrote:
> > I finally watched it (I failed to survive the long over-nighters until
> 10am
> > to watch this one live >_<).
> >
> >
On 14 July 2014 06:19, Manu via Digitalmars-d-announce
wrote:
> I finally watched it (I failed to survive the long over-nighters until 10am
> to watch this one live >_<).
>
> I want to offer congratulation and thanks to Iain for this work!
> For me, this is perhaps the single most important work i
I finally watched it (I failed to survive the long over-nighters until 10am
to watch this one live >_<).
I want to offer congratulation and thanks to Iain for this work!
For me, this is perhaps the single most important work in the D ecosystem
yet this year, and for me, I think the debugging envir
On Sunday, 13 July 2014 at 22:11:17 UTC, Nordlöw wrote:
On Sunday, 13 July 2014 at 20:15:06 UTC, w0rp wrote:
I suppose one extra step you could go would be to somehow
complete --config= too, so you could tab complete --config=foo
and --config=bar or something.
--config
is not documented
On Sunday, 13 July 2014 at 20:15:06 UTC, w0rp wrote:
I suppose one extra step you could go would be to somehow
complete --config= too, so you could tab complete --config=foo
and --config=bar or something.
--config
is not documented by
dub -h
Is it a sub command flag?
On Monday, 7 July 2014 at 09:22:41 UTC, Nordlöw wrote:
So I put together something that works in the majority of cases
even for sub command specific flags including package
completion:
https://github.com/nordlow/scripts/blob/master/dub-completion.bash
Feedback appreciated!
This is pretty gr
Hello all :)
I've made a simple port of ruby's colorize library for D.
I'd greatly appreciate any feedback. Windows isn't supported,
yet.
Links:
http://code.dlang.org/packages/colorize
https://github.com/yamadapc/d-colorize
https://github.com/fazibear/colorize
On 13.07.2014 20:43, Trass3r wrote:
You can add the compiler to the make command line with some magic
quoting.
My build script calls
druntime:
make -f win64.mak DMD=../windows/bin/dmd.exe
"CC=\"c:\l\vc10\bin64\cl.exe\"" target
phobos:
make -f win64.mak DMD=../windows/bin/dmd.exe
"CC=\"c:\l\v
You can add the compiler to the make command line with some
magic quoting.
My build script calls
druntime:
make -f win64.mak DMD=../windows/bin/dmd.exe
"CC=\"c:\l\vc10\bin64\cl.exe\"" target
phobos:
make -f win64.mak DMD=../windows/bin/dmd.exe
"CC=\"c:\l\vc10\bin64\cl.exe\"" MAKE=c:\l\dmc\b
On Sunday, 13 July 2014 at 15:34:31 UTC, Dicebot wrote:
std.typecons.scoped _should_ still work - I actually suggest
adding unit tests for this as it is quite an important use case.
Unittest at least for scoped _without_ @nogc:
https://github.com/WebDrake/hap/commit/ac820f27f635e0a88790f6c344de
On 13.07.2014 19:35, Trass3r wrote:
Digger is awesome. Have never heard of it before this talk.
Unfortunately it's a huge PITA to get a Win64 build with it cause of
those stupid hardcoded "\Program Files (x86)\Microsoft Visual Studio
10.0\VC" paths. The modified makefiles etc are always revert
Digger is awesome. Have never heard of it before this talk.
Unfortunately it's a huge PITA to get a Win64 build with it cause
of those stupid hardcoded "\Program Files (x86)\Microsoft Visual
Studio 10.0\VC" paths. The modified makefiles etc are always
reverted by Digger before building.
On Sunday, 13 July 2014 at 16:29:11 UTC, Joseph Rushton Wakeling
wrote:
Anyway, the actual scoped() method itself is templated, so
whether it can be @nogc or not obviously depends on its
arguments and has to be inferred.
Hmm, I tried patching up what I could of the Scoped struct's
methods to
On Sunday, 13 July 2014 at 16:24:29 UTC, bearophile wrote:
Even if the 1.0.0 release of std.random2 is not much @nogc, in
my opinion it needs to have an API designed to allow it to be
retrofitted cleanly and nicely for @nogc usages too.
Completely agree. Incidentally the library is intended f
On Sunday, 13 July 2014 at 16:20:12 UTC, Joseph Rushton Wakeling
wrote:
I'm guessing the reason it doesn't in this case is because it's
all wrapped up in the scoped() template
... no, it's because the private Scoped_store is passed out via
the Scoped_payload property.
Anyway, the actual scop
On Sunday, 13 July 2014 at 16:12:16 UTC, Dicebot wrote:
Quite likely it has not been updated to @nogc at all - which
makes scoped kind of joke if it is true :)
Seems to be the case, looking at current scoped() code in Phobos
(I just updated my dmd/druntime/phobos install:-)
BTW I note that i
Joseph Rushton Wakeling:
What really matters to me is stuff like Sample and Cover, where
we can readily expect that they may be called in inner loops of
the program, and so having lots of allocations via "new" would
be a big problem. So, it follows that the current helper
functions (sample,
On Sunday, 13 July 2014 at 16:01:11 UTC, Joseph Rushton Wakeling
wrote:
Is this possibly an issue with 'scoped'? Was it only quite
recently patched to support @nogc? I'll update my installed
compiler if so.
Quite likely it has not been updated to @nogc at all - which
makes scoped kind of jo
On Sunday, 13 July 2014 at 15:34:31 UTC, Dicebot wrote:
std.typecons.scoped _should_ still work - I actually suggest
adding unit tests for this as it is quite an important use case.
std.typecons.scoped works per se (I'm adding unittests as we
speak) but using my current dmd, this:
// con
On Sunday, 13 July 2014 at 15:31:51 UTC, bearophile wrote:
So creating a random number generator can't be @nogc?
I think even as things are there is nothing stopping the user
from manually allocating and using "emplace" to create an RNG
instance without relying on the GC. However, even if no
On Sunday, 13 July 2014 at 15:31:51 UTC, bearophile wrote:
Joseph Rushton Wakeling:
Anyway, here's my thinking behind the opCall idea. One of the
major shifts of the move to classes is that, suddenly, all of
these entities have to be explicitly allocated.
So creating a random number generat
Joseph Rushton Wakeling:
Anyway, here's my thinking behind the opCall idea. One of the
major shifts of the move to classes is that, suddenly, all of
these entities have to be explicitly allocated.
So creating a random number generator can't be @nogc?
Bye,
bearophile
On Friday, 20 June 2014 at 18:15:49 UTC, Nick Sabalausky wrote:
I'm on the fence:
Pro: Upgrade paths and backwards compatibility are great,
especially for Phobos.
Con: If any semantics are changed (default ref/value passing is
the only one that comes to mind), then maybe it would mask
poten
On 2014-07-12 22:43, John Colvin wrote:
Even bearing in mind that archive.org is so slow that a simple download
of the mp4 version of a talk can talk almost 2 hours? archive.org's
per-connection bandwidth limit is very unusually low.
Yeah, it takes at least an hour for me to download from arch
Am 10.07.2014 11:06, schrieb "Nordlöw":
On Wednesday, 9 July 2014 at 16:12:01 UTC, Sönke Ludwig wrote:
Shall I just commit the file (with you as the author of course), or do
you want to open a pull request?
You can commit the file. That's ok with me :)
https://github.com/D-Programming-Langu
25 matches
Mail list logo