On Thursday, 10 August 2017 at 15:36:54 UTC, Wild wrote:
And of course congratulations for becoming a TU! :)
Thanks, and while I have you here, is there any reason why all
the dtools programs have 'dtools-' as a prefix?
Some of them have very common names (like "detab") and I was
concerned
On Thursday, 10 August 2017 at 14:42:43 UTC, Wild wrote:
On Thursday, 10 August 2017 at 14:26:41 UTC, Jacob Carlborg
wrote:
That's great. Do you want to maintain the package for DStep as
well as Dicebot did?
I could do that, but what I can see Dicebot still maintains it
https://github.com/dlang/DIPs/pull/63
On Thursday, 11 May 2017 at 17:35:31 UTC, Nick Sabalausky
(Abscissa) wrote:
It is already addressed in the DIP. FQNs only help if they are
used and
current idiomatic D code tends to rely on unqualified
imports/names.
I didn't see that. Certainly not in the "Existing solutions"
section. It
On Thursday, 11 May 2017 at 03:46:55 UTC, Nick Sabalausky
(Abscissa) wrote:
1. Why are FQNs alone (assume they still worked like they're
supposed to) not good enough? Needs to be addressed in DIP.
Currently isn't.
It is already addressed in the DIP. FQNs only help if they are
used and
On Thursday, 11 May 2017 at 00:04:52 UTC, Steven Schveighoffer
wrote:
I prefer the first one. The reason is simply because it doesn't
require any new grammar. The override requirement is already a
protection against changing base class. In this case, we have
two possible outcomes:
1. The
On Tuesday, 25 April 2017 at 12:33:44 UTC, Steven Schveighoffer
wrote:
Actually, that brings up a problem with this, what is the
mechanism to say "maybe override"? Let's say you have:
// in imported library
class Base
{
void foo() @future;
}
// in user library
class Derived : Base
{
On Thursday, 2 February 2017 at 10:01:04 UTC, qznc wrote:
In another thread [0] Snap packages are discussed. What is the
view of Arch? If Snap wins, there would be only one package to
maintain for all distros.
[0]
https://forum.dlang.org/post/mzklrdgeyymuwmtqz...@forum.dlang.org
There is
On Wednesday, 1 February 2017 at 18:32:48 UTC, Rory McGuire wrote:
I use arch and D every day. I'm willing to volunteer. I keep up
to date with all releases and keep multiple dmd versions. If
I'm maintaining the packages I'd use them (if I can still
switch versions of dmd).
Are you familiar
As I have previously announced
(http://forum.dlang.org/post/o6fbbu$1qli$1...@digitalmars.com), I am
stepping down from maintaining Arch Linux packages for D.
That means there are 3 possibilities:
- No one will adopt them and all packages will be moved to AUR
- Some existing Trusted User decided
On 01/30/2017 12:38 AM, Walter Bright wrote:
> ...
Please, don't waste your time. You mentioned being curious about what is
wrong with that PR - I have explained. Let's just stop here before you
write another 20 posts presuming that I only disagree with your
development methodology because I
On Friday, 27 January 2017 at 19:12:37 UTC, Walter Bright wrote:
On 1/27/2017 3:12 AM, Dicebot wrote:
And also stuff like https://github.com/dlang/druntime/pull/1740
I'm curious what is wrong with that?
You have been pushing for premature merged of `return scope`
under a premise that it
On 01/27/2017 01:29 PM, Nordlöw wrote:
> On Friday, 27 January 2017 at 11:12:22 UTC, Dicebot wrote:
>> And also stuff like https://github.com/dlang/druntime/pull/1740 - I
>> think the story behind `return scope` is the critical point for me. It
>> is worst technical disaster that has happened to
And also stuff like https://github.com/dlang/druntime/pull/1740 -
I think the story behind `return scope` is the critical point for
me. It is worst technical disaster that has happened to compiler
in years, and I am going to blame Walter personally for it.
https://issues.dlang.org/show_bug.cgi?id=17123
Can I have my "I told you so" badge please?
On Sunday, 22 January 2017 at 12:45:26 UTC, Russel Winder wrote:
The "problem" here is the role of the D Tools repository. Is it
solely for DMD, or is it supposed to be something that can be
packaged independent of a particular D compiler. As it is I am
not sure it can be the unit of
On Sunday, 22 January 2017 at 13:24:48 UTC, Andrei Alexandrescu
wrote:
It's also the simplest to solve. Should be Boost. Please create
a PR copying the Boost license (from e.g. Phobos itself) to the
tools repo. Thanks. -- Andrei
RDMD does have license statement already
On 01/20/2017 07:47 AM, Jacob Carlborg wrote:
> On 2017-01-19 16:46, Jack Stouffer wrote:
>
>> Or, you can mark that unit test block as @system and have @safe tests in
>> another block.
>
> No, this is for when the framework is catching the exception. It needs
> to wrap _all_ unit test blocks in
On Sunday, 15 January 2017 at 13:14:45 UTC, Dmitry Olshansky
wrote:
I could have wasted time by creating nodes and assigning values
in the map functions but if you just want the result of
calculation it's all moot.
Thanks for explanation! This is indeed very promising and much in
spirit of D
Sounds intriguing!
On 01/15/2017 01:26 AM, Dmitry Olshansky wrote:
> - versatility, generating some goofy parse tree is not a goal, the goal
> is extraction of data the way the user specifies
Can you show an example of what you have in mind for this?
signature.asc
Description: OpenPGP
On Sunday, 8 January 2017 at 09:18:19 UTC, Suliman wrote:
Simply picking a worker thread + worker fiber when task is
assigned and sticking to it until finished should work good
enough. It is also important to note though that "fiber" is
not the same as "task". Former is execution context
On Sunday, 18 September 2016 at 01:44:10 UTC, Ryan wrote:
I think it works because each time you call dispose it tells
the GC to mark that memory as available, without the GC needing
to do a collection sweep. This could be a really useful tip in
the allocators section, as I see converting to
On Saturday, 31 December 2016 at 01:14:23 UTC, Arun
Chandrasekaran wrote:
On Saturday, 19 November 2016 at 21:16:15 UTC, Dicebot wrote:
DIP 1003 is merged to the queue and open for public informal
feedback.
PR: https://github.com/dlang/DIPs/pull/48
Initial merged document:
On Tuesday, 27 December 2016 at 14:24:11 UTC, Steven
Schveighoffer wrote:
Missing from the changelog is the cycle detection deprecation
path that I added here:
https://github.com/dlang/druntime/pull/1720
This should give people more breathing room to remove detected
cycles by next release.
After some tweaking and playing have finally uploaded Arch Linux
packages for GDC using 6.2.1 gcc base and
https://github.com/D-Programming-GDC/GDC/releases/tag/v2.068.2_gcc6
Now also includes new "libpghobos" package providing shared library only
(though I haven't tested this part).
On 12/25/2016 09:41 PM, Johannes Pfau wrote:
> Happy holidays everybody,
>
> I'm happy to finally announce the release of new GDC binaries at
> https://gdcproject.org/downloads . GDC is the GNU D Compiler, a D
> compiler using GCC as the compiler backend.
A lot of great stuff! Got few questions
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 12/20/2016 08:33 PM, Walter Bright wrote:
> On 12/20/2016 12:01 AM, Dicebot wrote:
>> We rely on ModuleInfo for custom test runner in ocean
>> (https://github.com/sociomantic-tsunami/ocean/blob/v2.x.x/src/ocean/core/UnitTestRunner.d).
>>
>> Static introspection can't provide same functionality
On 12/20/2016 05:17 PM, Benjiro wrote:
> On Tuesday, 20 December 2016 at 14:09:45 UTC, Dibyendu Majumdar wrote:
>>
>> Apologies for being one of those who offers advice but no action.
>
> Don't be Dibyendu ...
>
> We "ranters" are actually D's "client base". There seem to be the wrong
>
On 12/20/2016 12:48 PM, Benjiro wrote:
> Actually, i did not vent any anger until this morning when i noticed the
> wiseass response. All the points i wrote yesterday are items that
> actually bother a lot more people. But those same people who complain
> about it, always get shutdown with that
On 12/18/2016 11:26 AM, Ilya Yaroshenko wrote:
> Hi,
>
> Who is interested in betterC _modular_* standard library?
> I am planing to make libmir org a community for it.
> Thought and concerns?
I also consider Phobos a lost cause only suitable for scripting
purposes. However what you try to do
On 12/18/2016 06:53 PM, Andrei Alexandrescu wrote:
> Compulsive ModuleInfo generation seems to be a drag. I'm not very
> familiar with the particulars but my understanding is ModuleInfo is
> needed for (a) Object.factory and (b) finding and running unittests.
>
> Walter and I think Object.factory
On Tuesday, 13 December 2016 at 22:33:24 UTC, Andrei Alexandrescu
wrote:
Destroy.
https://github.com/dlang/DIPs/pull/51/files
Andrei
Proposed functionality does feel useful but syntax options
mentioned in the DIP all seem lacking to me. Most importantly,
the one suggested as primary
On Thursday, 1 December 2016 at 19:14:51 UTC, Dicebot wrote:
On Thursday, 1 December 2016 at 18:56:36 UTC, qznc wrote:
That is an interesting idea. Afaik, D does not allow to limit
closure like this?
void i_only_accept_immutable_context (void delegate ()
immutable closure);
NB: it may have
On Thursday, 1 December 2016 at 18:56:36 UTC, qznc wrote:
That is an interesting idea. Afaik, D does not allow to limit
closure like this?
void i_only_accept_immutable_context (void delegate () immutable
closure);
One minor nitpick - please avoid calling postblit constructor a
"copy constructor", it tends to mislead developers with C++
origins into expecting copy constructor they are used to - and
disappointment when it proves to not be the case.
On 11/29/2016 12:04 PM, Arafel wrote:
> I think I might be a bit late to the party, and I'm still quite new in
> D... but wouldn't a variadic template constructor work? The usual rules
> of templates would still let you override a constructor if needed.
>
> ---
> class A {
> this() { }
>
On 11/28/2016 04:57 AM, rikki cattermole wrote:
> On 28/11/2016 3:38 PM, Dicebot wrote:
>> DIP 1004 is merged to the queue and open for public informal feedback.
>>
>> PR: https://github.com/dlang/DIPs/pull/42
>>
>> Initial merged document:
>>
DIP 1004 is merged to the queue and open for public informal feedback.
PR: https://github.com/dlang/DIPs/pull/42
Initial merged document:
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1004.md
If you want the change to be approved and have ideas how to improve it
to better match on
On 11/24/2016 05:29 PM, WM.H wrote:
> On Saturday, 19 November 2016 at 21:16:15 UTC, Dicebot wrote:
>> DIP 1003 is merged to the queue and open for public informal feedback.
>>
>> PR: https://github.com/dlang/DIPs/pull/48
>> Initial merged document:
>>
On 11/21/2016 01:33 PM, Sönke Ludwig wrote:
> For this whole proposal to work out, though, I think the old syntax will
> have to stay supported without deprecations, because the amount of
> breakage (the deprecation path won't change that) will otherwise
> probably be huge. Making "body" optional
On 11/18/2016 06:09 PM, pineapple wrote:
> There should be no need for me to repeat the arguments against the DIP
> process already made by others. I will be submitting no more DIPs or
> engaging in the process in any way unless and until it is significantly
> changed.
There seems to be a
DIP 1003 is merged to the queue and open for public informal
feedback.
PR: https://github.com/dlang/DIPs/pull/48
Initial merged document:
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md
If you want the change to be approved and have ideas how to
improve it to better match on
On 11/17/2016 04:36 PM, Andrei Alexandrescu wrote:
> On 11/17/2016 09:16 AM, Dicebot wrote:
>> 2) It is a regular update. In that case revision number is simply git
>> history. For example DIP1002 is currently at revision 7 (git log
>> --pretty=oneline DIPs/DIP1002.md | wc -l).
>>
>> Same goes for
On Thursday, 17 November 2016 at 15:26:21 UTC, John Colvin wrote:
Regardless of the outcome, I just want to commend whoever wrote
the rejection text* on doing such a clear and comprehensive
job. I'm sure it must be disappointing for a DIP author to have
it rejected, but detailed, constructive
On 11/17/2016 03:20 PM, Andrei Alexandrescu wrote:
> On 11/17/2016 06:37 AM, Dicebot wrote:
>> Disposition: REJECT. A proposal for a similar or identical feature would
>> need to be include qualitatively new motivation/evidence of usefulness.
>>
>> Please follow the link for the full review text /
Disposition: REJECT. A proposal for a similar or identical feature would
need to be include qualitatively new motivation/evidence of usefulness.
Please follow the link for the full review text / rationale:
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1002.md#review
signature.asc
Disposition: REJECT. A proposal for a similar or identical feature would
need to be include qualitatively new motivation/evidence of usefulness.
Please follow the link for the full review text / rationale:
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1001.md#review
signature.asc
On 11/15/2016 07:05 PM, Stefan Koch wrote:
>> When doing so, try to forget that static analysis is the intended
>> goal. It has to be naturally usable for any other purpose too,
>> focusing on one specific application case is likely only harm design
>> decisions.
>
> It's a compiler frontend.
On 11/15/2016 06:46 PM, Stefan Koch wrote:
> On Tuesday, 15 November 2016 at 16:39:22 UTC, Dicebot wrote:
>> [ ]
>> But I'd sincerely advise against any ad-hoc solution that is built
>> into DMD itself.
>
> It seems I did not clearly state this.
> I mean to provide the general plumbing that
On 11/15/2016 04:57 PM, Stefan Koch wrote:
> On Tuesday, 15 November 2016 at 14:45:29 UTC, Stefan Koch wrote:
>> Hi Guys,
>>
>> I was wondering how much interest in static analysis exists in this
>> community .
>> DMD already has rudimentary support for these kinds of things.
I'd put it in a
On 11/12/2016 12:34 PM, Sönke Ludwig wrote:
> Not sure if this is common knowledge already, but it was new for me. If
> you click the edit button at the top of a pull request on GitHub, you
> now get a drop down to change the base branch to which the request will
> be pulled. Really handy for PRs
On 11/13/2016 10:40 AM, Stefan Koch wrote:
> On Saturday, 12 November 2016 at 10:26:53 UTC, Stefan Koch wrote:
>> Hi Guys,
>>
>> I have written a small utility called dmd-ast-tool.
>> It can be used to quickly generate boilerplate code for dmd-ast-visitors.
>> Originally it was only written for my
On 11/11/2016 09:36 PM, Nick Sabalausky wrote:
> On 11/11/2016 08:30 AM, Dicebot wrote:
>> On Friday, 11 November 2016 at 13:21:40 UTC, Nick Sabalausky wrote:
>>> Run the new dmd. If it fails, either fix your code or go temporarily
>>> go back to the old dmd until you can fix your code.
>>
>> D
On 11/12/2016 02:20 PM, Basile B. wrote:
> On Monday, 31 October 2016 at 01:27:08 UTC, Martin Nowak wrote:
>> Glad to announce D 2.072.0.
>>
>> http://dlang.org/download.html
>>
>> This is the release ships with the latest version of dub (v1.1.0), comes
>> with lots of phobos additions and native
On 11/11/2016 03:46 PM, Steven Schveighoffer wrote:
>> ... or one can spend one extra hour to implement deprecation path and
>> the issue disappears completely.
>
> There is a misunderstanding that the new cycle detection is an "upgrade"
> of some kind. It's a bug fix.
There is no difference
On Friday, 11 November 2016 at 13:21:40 UTC, Nick Sabalausky
wrote:
Run the new dmd. If it fails, either fix your code or go
temporarily go back to the old dmd until you can fix your code.
D will never be considered production ready as pong as this
attiude remaind. Your described scenario in
On Thursday, 10 November 2016 at 16:20:33 UTC, Johan Engelen
wrote:
Hi all,
Yesterday I merged LTO capability into LDC.
Here a short article about it:
https://johanengelen.github.io/ldc/2016/11/10/Link-Time-Optimization-LDC.html
For the folks building LDC themselves: let me know your issues
On 11/05/2016 06:04 AM, Soulsbane wrote:
> On Monday, 31 October 2016 at 01:27:08 UTC, Martin Nowak wrote:
>> Glad to announce D 2.072.0.
>>
>> http://dlang.org/changelog/2.072.0.html
>>
>> -Martin
>
> I've run into a problem with code using ctRegex that fails to compile
> only in release build.
On Thursday, 10 November 2016 at 13:58:56 UTC, Steven
Schveighoffer wrote:
This is not possible. Old behavior DID detect some cycles. The
new algorithm detects ALL cycles, and handles them all in the
same way. What you are asking is for cycles detected by old
algorithm to fail, but ones that
On 11/10/2016 06:07 AM, Nick Sabalausky wrote:
> On 11/08/2016 02:11 PM, Antonio Corbi wrote:
>>
>> Maybe this one is useful for you:
>>
>> http://eagain.net/articles/git-for-computer-scientists/
> On 11/08/2016 03:01 PM, H. S. Teoh via Digitalmars-d wrote:
>> Nothing immediately comes to mind,
On 11/03/2016 05:51 PM, Steven Schveighoffer wrote:
> On 11/3/16 10:49 AM, Johan Engelen wrote:
>> On Wednesday, 2 November 2016 at 15:13:43 UTC, anonymous wrote:
>>> On Wednesday, 2 November 2016 at 15:08:26 UTC, anonymous wrote:
I confirm, dmd 2.072 can't build dmd 2.071.2, same error,
Sadly, because of overwhelming project breakage I have to revert Arch
Linux dmd package version back to 2.071.2 until 2.072.1 is out :(
Going to look into known regressions later this week, at least some of
them look easily fixable to become deprecations.
signature.asc
Description: OpenPGP
On Monday, 7 November 2016 at 13:24:20 UTC, Timon Gehr wrote:
On 07.11.2016 12:38, Dicebot wrote:
On 11/07/2016 08:40 AM, Stefan Koch wrote:
Why not make it a plain identifier ? We give identifier
special
meaning in various places, like scope(exit).
If I am not mistaken we do not need body
On 11/07/2016 08:40 AM, Stefan Koch wrote:
>> Why not make it a plain identifier ? We give identifier special
>> meaning in various places, like scope(exit).
>
> If I am not mistaken we do not need body ay at all.
It is matter of how smooth deprecation phase is. Completely removal of
`body` is
On 10/31/2016 03:27 AM, Martin Nowak wrote:
> Glad to announce D 2.072.0.
NB: Current release notes are outdated and wrong about
`-transition=safe` flag. It was completely repurposed in stable branch
(https://github.com/dlang/dmd/pull/6183) but somehow changes to release
notes there do not
On Tuesday, 1 November 2016 at 06:04:41 UTC, Laeeth Isharc wrote:
On Monday, 31 October 2016 at 09:52:55 UTC, Dicebot wrote:
On 10/30/2016 06:35 PM, Laeeth Isharc wrote:
But what I meant was LLVM will have a wasm backend.
Yes, but it is developed so slowly and conservatively, that
coming up
Thank you and keep doing awesome stuff ;)
signature.asc
Description: OpenPGP digital signature
On 10/30/2016 06:35 PM, Laeeth Isharc wrote:
> But what I meant was LLVM will have a wasm backend.
Yes, but it is developed so slowly and conservatively, that coming up
with own proof-of-concept backend may be a chance to win early interest.
They may speed up greatly though when WebAssembly
On 10/30/2016 07:53 AM, Walter Bright wrote:
> On 10/29/2016 10:30 PM, Dicebot wrote:
>> At the same time intended wasm spec
>> (https://github.com/WebAssembly/design) is
>> much more simple than machine code for something like x86_64. If
>> Walter gets
>> interested, that may be a feasible path
On 10/30/2016 11:19 PM, Stefan Koch wrote:
> Oh shoot!
> I did not enable the new call system :(
> This computed by the old interpreter.
>
> The new engine fails :(
Stefan, would you mind creating a dedicated topic in main D newsgroup to
report your development progress? Bumping the thread in
On Saturday, 29 October 2016 at 21:46:37 UTC, Laeeth Isharc wrote:
Any thoughts on how much work is involved to port the runtime?
And what other changes might be involved? The chap that used
the C backend for LLVM wrote a little mini runtime but I guess
didn't have to worry about the version
On 10/27/2016 07:12 PM, Laeeth Isharc wrote:
> On Thursday, 27 October 2016 at 16:01:26 UTC, Chris wrote:
>> On Thursday, 27 October 2016 at 15:54:59 UTC, Jonathan M Davis wrote:
>>> On Thursday, October 27, 2016 15:42:53 Chris via Digitalmars-d wrote:
Not easy to be smart with Javascript ;)
On 10/27/2016 11:24 AM, qznc wrote:
> I'm unsure about Linus' version. For this example, I agree that it is
> elegant. It is fine in this specific case, because everything is local
> within a single function. In general, the trick to use a pointer to the
> element probably not a good idea.
>
>
On 10/24/2016 11:06 PM, Jeff Thompson wrote:
> ...
If I really had to do something like that and there was no other way,
I'd most likely resort to auto-generating such module names during build
pipeline.
signature.asc
Description: OpenPGP digital signature
On 10/26/2016 12:53 AM, Walter Bright wrote:
> It's a small bit, but the idea here is to eliminate if conditionals
> where possible:
>
> https://medium.com/@bartobri/applying-the-linus-tarvolds-good-taste-coding-requirement-99749f37684a#.nhth1eo4e
I find it both funny and saddening how many
On Tuesday, 25 October 2016 at 15:08:14 UTC, Dmitry Olshansky
wrote:
Hi, have you found a review manager yet?
No, the NG was rather silent, so sill looking for one.
As it is a runtime module and not Phobos, I'd be willing to
volunteer - but only quite some time later (probably about 1
On 10/17/2016 05:44 AM, deadalnix wrote:
> On Monday, 17 October 2016 at 02:08:44 UTC, Dicebot wrote:
>> Listen, I understand you are not interested in spending loads of time
>> on boring polishing of formalities. We all do this in our spare time
>> so that is to be expected.
>>
>
> I spent fuck
On 10/18/2016 02:40 AM, David Soria Parra wrote:
> On Monday, 17 October 2016 at 21:52:32 UTC, Andrei Alexandrescu wrote:
>> Thanks, David. Hope you're doing well! I was curious about one thing -
>> is there some scrutiny going into the PIPs before Guido reviews them?
>> Right now we seem to have
On 10/17/2016 12:57 AM, Timon Gehr wrote:
> On 16.10.2016 14:18, Dicebot wrote:
>> This issue has been discussed before in context of custom containers and
>> AFAIK so far no one was able to come up with even theoretical concept of
>> how it can be possibly addressed.
>
> Actually, I did propose
Listen, I understand you are not interested in spending loads of
time on boring polishing of formalities. We all do this in our
spare time so that is to be expected.
But what you say here only shows that process is working as
intended - and that it is not suitable for you. Quote from
readme:
On 10/16/2016 11:36 AM, Ilya Yaroshenko wrote:
> Hi,
>
> Extern precompiled Mir GLAS requires additional API changes.
> Reduced example:
>
> ```d
> struct S(T)
> {
> size_t len;
> T ptr;
> }
>
> auto foo(S!(const(double)*) sl)
> {
> }
>
> S!(double*) a;
> const S!(double*) b;
>
> foo(a);
On 10/14/2016 06:01 PM, Chris Wright wrote:
> On Fri, 14 Oct 2016 09:13:16 -0400, Andrei Alexandrescu wrote:
>
>> https://issues.dlang.org/show_bug.cgi?id=5051 -- Andrei
>
> For the love of potatoes, please take a few seconds to tell us the gist
> of it here.
>
> The requested tool is a
On 10/11/2016 04:13 PM, Joakim wrote:
> On Monday, 10 October 2016 at 08:47:54 UTC, Robert burner Schadek wrote:
>> http://code.dlang.org/packages/dstatsd
>>
>> StatsD allows to collect statistics about any application by using
>> counters, gauges and more through UDP.
>>
>> Usage:
>>
>> auto s =
On Sunday, 9 October 2016 at 22:01:31 UTC, Martin Nowak wrote:
On Sunday, 9 October 2016 at 14:36:49 UTC, Dicebot wrote:
Which branch changelog content is generated from?
Stable, the changelog is also included in the docs that are in
the packages.
I do merge stable back into master to
Which branch changelog content is generated from?
On Thursday, 6 October 2016 at 16:56:26 UTC, Nordlöw wrote:
Is there a way to do this, or do we need something similar to
`collect` in Phobos? Something like
import std.container.array : Array;
0.iota(n).collect!Array
You mean semantics like this?
Container collect(Container, Range) (Range
On Thursday, 6 October 2016 at 14:32:44 UTC, Nordlöw wrote:
Is there a concept in D similar to Rust's `collect`:
https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.collect
If not, I'm eager to implement it to support D-style containers.
What would the desired interface look like?
On Monday, 3 October 2016 at 13:50:26 UTC, John Colvin wrote:
The problem is that function pointers in "is" expressions don't
match "function" or "delegate".
static assert (is(void delegate() == delegate)); //passes
static assert (is(void function() == function)); //fails
static assert
On Monday, 3 October 2016 at 13:41:13 UTC, Manu wrote:
I'm finding this rather annoying:
struct S
{
static @property int p() { return 10; }
}
pragma(msg, typeof()); // prints: int function() @property
pragma(msg, is(typeof() == function)); // prints: false
It looks like a function... but I
On Sunday, 2 October 2016 at 21:05:25 UTC, A D dev wrote:
One last point:
If that was always the behavior (in all versions from 2010 - or
earlier), i.e. -o- generates neither .OBJ nor .EXE, then what
is the purpose of the option? does it act as just a syntax
check?
Purpose is to skip code
On Saturday, 1 October 2016 at 15:06:44 UTC, Stefan Koch wrote:
On Saturday, 1 October 2016 at 10:19:21 UTC, Dicebot wrote:
On 09/29/2016 07:02 PM, David Nadlinger wrote:
[...]
What are the issues with fullyQualifiedName in that context? I
mean other than Voldemort types of course. I'd
On Saturday, 1 October 2016 at 19:32:08 UTC, Andrei Alexandrescu
wrote:
Not like this is real security concern in dmd case but
guidelines like
"don't make /tmp/ path predictable" exist exactly so that one
can have
simple safe default and not worry about possibilities.
This may be a
On Saturday, 1 October 2016 at 18:24:07 UTC, Andrei Alexandrescu
wrote:
Granted, no contest. Seems to me we could be a better denizen
of said junkyard. What I noticed other apps do is create one
directory in /tmp and then place their junk in there. -- Andrei
Yeah, it is both common and
On Saturday, 1 October 2016 at 17:45:30 UTC, Dicebot wrote:
On Saturday, 1 October 2016 at 17:35:29 UTC, Andrei
Alexandrescu wrote:
I think /tmp/ is mounted per user so we should be good.
Anyhow... care to send a PR upstream? -- Andrei
You can't make any assumptions about how /tmp/ is
On Saturday, 1 October 2016 at 17:35:29 UTC, Andrei Alexandrescu
wrote:
I think /tmp/ is mounted per user so we should be good.
Anyhow... care to send a PR upstream? -- Andrei
You can't make any assumptions about how /tmp/ is mounted, it is
completely up to distro/administrator.
On 10/01/2016 03:33 PM, Andrei Alexandrescu wrote:
> I was looking for the PR that changed iota.length and it took me longer
> than it could have. I googled for
>
> iota length dlang
>
> and among the top results I found the changelog PR:
> https://github.com/dlang/phobos/pull/4220, but it was
On 09/29/2016 07:02 PM, David Nadlinger wrote:
> On Thursday, 29 September 2016 at 13:58:44 UTC, Eugene Wissner wrote:
>> Any chance to get this one working:
>>
>> import std.typecons;
>>
>> enum Stuff
>> {
>> asdf,
>> }
>>
>> void main()
>> {
>> BitFlags!Stuff a;
>>
On 09/28/2016 09:47 AM, Andrei Alexandrescu wrote:
> ...
I have added references to both your and Walter comments to DIP1002
review section: https://github.com/dlang/DIPs/pull/44
signature.asc
Description: OpenPGP digital signature
On 09/28/2016 01:17 PM, pineapple wrote:
> On Wednesday, 28 September 2016 at 07:47:32 UTC, Andrei Alexandrescu wrote:
>> * Please remove colloquialisms. Characterizations such as
>> "fantastically useful" are unlikely to be a convincing motivator and
>> have no place in a DIP.
>>
>> * The
1 - 100 of 2167 matches
Mail list logo
