Re: DUB Bash Completion
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-Language/dub/commit/6d4a387c62b0be271d6acf9e16cf81511077a67f Thanks again!
Re: Dconf 2014 Day 2 Talk 5: Tooling: Bringing Developers and Development Together by Brad Roberts
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 archive.org. From youtube, the same video clip takes around two minutes. -- /Jacob Carlborg
Re: hap.random: a new random number library for D
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
potential upgrade issues. Breakage would force users to notice
the change and (hopefully) deal with it appropriately.
I don't personally see it as a big deal either way, though.
Sorry for taking so long to follow up on this, it's been a busy
period ...
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. That means that
there's some measure of responsibility on the library to offer a
sane default style of allocation, as appropriate for the expected
use-cases and performance requirements.
Now, apart from the random number generators, all of the
remaining library functionality already has helper functions
which can handle this. Currently they just new stuff, but
there's no reason this can't be adapted as needed, possibly with
the option for some kind of templating around different
allocation strategies.
However, RNGs themselves don't have any corresponding helper
functions, and manually writing them out would fast become
annoying (imagine having to create, say, xorshift, xorshift32,
xorshift64, ... etc. as helper functions to create Xorshift,
Xorshift32, Xorshift64, etc., instances).
opCall provides a natural way of implementing such construction
helper functions that is likely very general purpose, and
encouraging it as the default use-case has a further benefit of
encouraging the user to always seed their RNGs, if opCall has a
form like this:
static typeof(this) opCall(Seed)(Seed seed)
{
return new typeof(this)(seed);
}
It _could_ be done as a temporary measure, deprecated from the
start, to allow drop-in replacement but encourage appropriate
adaptation. But it could also be a way to serve the user with
sensible default allocation strategies that minimize the
potential performance impacts of the switch to classes.
Re: hap.random: a new random number library for D
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
Re: hap.random: a new random number library for D
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 generator can't be @nogc? Bye, bearophile std.typecons.scoped _should_ still work - I actually suggest adding unit tests for this as it is quite an important use case.
Re: hap.random: a new random number library for D
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 not, I think this would be less of a problem, as in general things like RNG instances can be expected to be allocated high up in the program and passed down into the inner parts where @nogc becomes a concern. 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, cover, etc.) need to be rewritten at some point with this in mind. It's not a problem I propose to solve for the 1.0.0 release, but it is a problem that needs addressing in the long run. Out of curiosity, do you have any ideas or suggestions for how to address the requirement for RNGs and related functionality to be reference types, together with the wish to support @nogc ... ? Preferably in a way that avoids the user having to explicitly indicate destruction?
Re: hap.random: a new random number library for D
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:
// confirm scoped allocation is @nogc
void scopedRNG(T)(T seed) @nogc
{
auto gen = scoped!UniformRNG(seed);
}
scopedRNG(unpredictableSeed);
... fails to compile with the error,
Error: @nogc function
'hap.random.generator.__unittestL91_27.scopedRNG!uint.scopedRNG'
cannot call non-@nogc function
'std.typecons.scoped!(LinearCongruentialEngine!(uint, 16807u, 0u,
2147483647u)).scoped!(uint).scoped'
... even if the constructor of the RNG in question is marked
@nogc together with all that it calls.
Is this possibly an issue with 'scoped'? Was it only quite
recently patched to support @nogc? I'll update my installed
compiler if so.
Re: hap.random: a new random number library for D
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 joke if it is true :)
Re: hap.random: a new random number library for D
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, cover, etc.) need to be rewritten at some point with this in mind. I think @nogc is a good improvement for D, despite Walter and other people (and I think Don) were very sceptical about it, because it's like a new lens that allows me to see important things about my code that I wasn't able to see before. Phobos has to be modified in many places to allow both usage patterns for people that want to write short clean code (that allocates automatically and lets the GC free), and performance-conscious people that need to avoid most or all heap allocations. What's unfortunate is that the @nogc attribute was not present for lot of time of development of Phobos, so several Phobos things now need to be modified and some old APIs could give problems. std.random2 should offers ways to be used as much as possible from @nogc code, see below. It's not a problem I propose to solve for the 1.0.0 release, but it is a problem that needs addressing in the long run. 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. do you have any ideas or suggestions for how to address the requirement for RNGs and related functionality to be reference types, together with the wish to support @nogc ... ? Preferably in a way that avoids the user having to explicitly indicate destruction? If you are not using the GC, and you don't want to indicate destruction, you have to use RAII and perhaps RefCounted. You can allocate on the C heap manually, or on the stack, or you can allocate on the stack or C heap using one of Andrei's future allocators. Bye, bearophile
Re: hap.random: a new random number library for D
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 inside the static struct Scoped you have a private Scoped_store together with a public alias_this. This would normally clash with https://issues.dlang.org/show_bug.cgi?id=10996 -- I'm guessing the reason it doesn't in this case is because it's all wrapped up in the scoped() template, so that the Scoped struct is actually created in the same module (the same scope even!) as all the places it will actually be used?
Re: hap.random: a new random number library for D
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 scoped() method itself is templated, so whether it can be @nogc or not obviously depends on its arguments and has to be inferred. The trouble is with the destructor ~this() which is in no way dependent on template parameters, but in calling the destructor of the scoped payload, depends on the payload's own destructor for whether it can be @nogc or not.
Re: hap.random: a new random number library for D
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 for use with dmd 2.065+ which precludes unqualified use of @nogc for now, but that will be addressed after 2.066 is released and ldc/gdc upgrade their frontend/Phobos dependencies. If you are not using the GC, and you don't want to indicate destruction, you have to use RAII and perhaps RefCounted. You can allocate on the C heap manually, or on the stack, or you can allocate on the stack or C heap using one of Andrei's future allocators. Stack allocation is arguably appropriate for stuff like Sample, however, the created entity needs to be able to escape the scope of the helper function which allocates it.
Re: hap.random: a new random number library for D
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 use @nogc, but to no avail where hap.random is concerned :-(
Re: DConf 2014 Day 2 Talk 4: Reducing D Bugs by Vladimir Panteleev
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.
Re: DConf 2014 Day 2 Talk 4: Reducing D Bugs by Vladimir Panteleev
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 reverted by Digger before building. 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\bin\make AR=\c:/l/vc10/bin64/lib.exe\ LIB=..\lib64\phobos64.lib
Re: hap.random: a new random number library for D
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/ac820f27f635e0a88790f6c344de5d40752704da Hey, I have 111 commits! :-D
Re: DConf 2014 Day 2 Talk 4: Reducing D Bugs by Vladimir Panteleev
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\bin\make AR=\c:/l/vc10/bin64/lib.exe\ LIB=..\lib64\phobos64.lib Isn't the make call hardcoded in Digger?
Re: DConf 2014 Day 2 Talk 4: Reducing D Bugs by Vladimir Panteleev
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\vc10\bin64\cl.exe\ MAKE=c:\l\dmc\bin\make AR=\c:/l/vc10/bin64/lib.exe\ LIB=..\lib64\phobos64.lib Isn't the make call hardcoded in Digger? I don't know, never used digger so far. I just remembered the problem with win64.mak.
Coloring terminal output.
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
Re: DUB Bash Completion
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 great. Thanks for writing this! 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.
Re: DUB Bash Completion
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?
Re: DUB Bash Completion
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 by dub -h Is it a sub command flag? Yeah it's a build subcommand. But you have to use dub describe to do the completion (it depends on the project file).
Re: DConf 2014 Day 2 Talk 6: Debugging in D by Iain Buclaw
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 environment remains the single most significant hurdle to confident and practical adoption of D in industry. It brings me to the interesting realisation (which I already knew, I have just been denying), that for D to proceed on Windows, MSVC will have to go... and I don't know how to go about this :/ MS's debugger will presumably never support these features, but the de facto Windows toolchain emit's PDB for use with the MS tools. I wonder if there are competing debuggers that support PDB which could support unofficial extensions to PDB which may express D better? On 12 July 2014 04:15, Iain Buclaw via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 11 July 2014 16:48, Andrei Alexandrescu via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: Upvote!! http://www.reddit.com/r/programming/comments/2afm4x/dconf_2014_day_2_talk_6_debugging_in_d_by_iain/ https://www.facebook.com/dlang.org/posts/882826745064341 https://twitter.com/D_Programming/status/487623887187083264 Andrei Thanks for spelling my name right this year. :)
Re: DConf 2014 Day 2 Talk 6: Debugging in D by Iain Buclaw
On 14 July 2014 06:19, Manu via Digitalmars-d-announce digitalmars-d-announce@puremagic.com 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 in the D ecosystem yet this year, and for me, I think the debugging environment remains the single most significant hurdle to confident and practical adoption of D in industry. Thanks Manu. I guess I'll be having trouble finding the next most important work in the D ecosystem next year. ;) It brings me to the interesting realisation (which I already knew, I have just been denying), that for D to proceed on Windows, MSVC will have to go... and I don't know how to go about this :/ MS's debugger will presumably never support these features, but the de facto Windows toolchain emit's PDB for use with the MS tools. I wonder if there are competing debuggers that support PDB which could support unofficial extensions to PDB which may express D better? Zerobugs was aimed at D users back when it was a commercial product. It has since been released under a boost licensed for a couple years now, but has into gone into obscurity (I think?). Link: http://zerobugs.codeplex.com Couple of clones on github too: https://github.com/search?q=zerobugs Being written against GTK, it's UI should be cross-platform to Windows, so it *could* be a good base project to start from, then build Windows debugging support into it. Someone else will need to do initial reviewing and triaging of this stuff (we need a new Lieutenant!) Regards Iain.
