On Friday, November 23, 2018 11:22:24 PM MST Neia Neutuladh via Digitalmars-
d-learn wrote:
> On Fri, 23 Nov 2018 21:43:01 -0700, Jonathan M Davis wrote:
> > A solution like that might work reasonably well, but you still
> > have the problem of what to do when a symbol is documented in multiple
>
On Fri, 23 Nov 2018 21:43:01 -0700, Jonathan M Davis wrote:
> A solution like that might work reasonably well, but you still
> have the problem of what to do when a symbol is documented in multiple
> version blocks, and having almost all the documentation in one version
> block and a few pieces of
On Friday, November 23, 2018 11:13:24 AM MST H. S. Teoh via Digitalmars-d-
learn wrote:
> All in all, though, the fact that we're complaining about extra seconds
> in compilation times still does show just how fast D compilation can be.
> In the old days, compiling large C++ codebases usually
On Friday, November 23, 2018 7:55:04 PM MST H. S. Teoh via Digitalmars-d-
learn wrote:
> Adam does have a very good point about showing all alternatives to docs,
> though. Arguably, that's what ddoc *should* do. If the programmer
> wrote a ddoc comment in the code, it probably should be
On Friday, November 23, 2018 2:47:51 PM MST Tony via Digitalmars-d-learn
wrote:
> In std.compiler there is this code:
>
> /// Which vendor produced this compiler.
> version(StdDdoc) Vendor vendor;
> else version(DigitalMars) Vendor vendor = Vendor.digitalMars;
> else
Hi all,
anyone know how to iterate getSymbolsByUDA ?
I try this code:
enum Attr;
struct A
{
@Attr int a;
int b;
}
//---
//1. Error: need `this` for `a` of type `int`
foreach(sym; getSymbolsByUDA!(A, Attr)){
writeln(sym.stringof);
}
On Saturday, 24 November 2018 at 02:55:04 UTC, H. S. Teoh wrote:
But then that would be reinventing what Adam has already done,
right? :-D
Precisely, I already do all that. And people are even actually
using it!
On Sat, Nov 24, 2018 at 02:09:22AM +, Neia Neutuladh via
Digitalmars-d-learn wrote:
> On Fri, 23 Nov 2018 17:21:25 -0800, H. S. Teoh wrote:
> > Ddoc may have its stink points, but in this case, the stuff inside
> > version(Windows) blocks simply isn't compiled, so you can't expect
> > ddoc to
On Fri, 23 Nov 2018 17:21:25 -0800, H. S. Teoh wrote:
> Ddoc may have its stink points, but in this case, the stuff inside
> version(Windows) blocks simply isn't compiled, so you can't expect ddoc
> to do much about it. You can't just arbitrarily ddoc everything inside
> version blocks, because
On Saturday, 24 November 2018 at 01:21:25 UTC, H. S. Teoh wrote:
Ddoc may have its stink points, but in this case, the stuff
inside version(Windows) blocks simply isn't compiled
That is why I call it "poorly designed" and a major reason why I
dropped it entirely and created my own doc
On Sat, Nov 24, 2018 at 12:51:36AM +, Adam D. Ruppe via Digitalmars-d-learn
wrote:
> On Friday, 23 November 2018 at 23:13:04 UTC, H. S. Teoh wrote:
> > There are a few cases where this is needed, e.g., to generate docs
> > for Windows-specific modules, since the website script is run on
> >
On Friday, 23 November 2018 at 23:13:04 UTC, H. S. Teoh wrote:
There are a few cases where this is needed, e.g., to generate
docs for Windows-specific modules, since the website script is
run on Posix and the Windows APIs would not be compiled at all,
leading to empty docs.
Note that that is
On Friday, 23 November 2018 at 21:35:57 UTC, Andre Pany wrote:
On Friday, 23 November 2018 at 21:27:26 UTC, Kagamin wrote:
You don't need to initialize runtime because it's initialized
by standard D startup code, but you need to attach threads
that are not created by D or static constructors
On Fri, Nov 23, 2018 at 09:53:59PM +, Adam D. Ruppe via Digitalmars-d-learn
wrote:
> On Friday, 23 November 2018 at 21:47:51 UTC, Tony wrote:
> > What is the situation in which the identifier StdDoc is set?
>
> When the phobos website is being compiled, its own makefile sets that.
>
> It is
On Friday, 23 November 2018 at 21:47:51 UTC, Tony wrote:
What is the situation in which the identifier StdDoc is set?
When the phobos website is being compiled, its own makefile sets
that.
It is basically a hack for website display.
In std.compiler there is this code:
/// Which vendor produced this compiler.
version(StdDdoc) Vendor vendor;
else version(DigitalMars) Vendor vendor = Vendor.digitalMars;
else version(GNU) Vendor vendor = Vendor.gnu;
else version(LDC) Vendor vendor =
On Saturday, 17 November 2018 at 17:58:54 UTC, John Chapman wrote:
The following code doesn't compile because the generated type
name needs to be available inside the mixin's scope, whereas
it's actually in another module.
auto makeWith(string className, Args…)(auto ref Args args) {
On Friday, 23 November 2018 at 21:27:26 UTC, Kagamin wrote:
You don't need to initialize runtime because it's initialized
by standard D startup code, but you need to attach threads that
are not created by D or static constructors won't be run and
only C-level code would work there.
Thank
You don't need to initialize runtime because it's initialized by
standard D startup code, but you need to attach threads that are
not created by D or static constructors won't be run and only
C-level code would work there.
On Wednesday, 21 November 2018 at 15:05:31 UTC, Kagamin wrote:
Start vibe in another thread and return from ServiceMain, see
https://docs.microsoft.com/en-us/windows/desktop/Services/service-servicemain-function also ideally you should report running state only after vibe initialized, opened
On Fri, Nov 23, 2018 at 05:37:46PM +, Adam D. Ruppe via Digitalmars-d-learn
wrote:
> On Friday, 23 November 2018 at 17:21:46 UTC, H. S. Teoh wrote:
> > Are you using template-heavy Phobos functions?
>
> Merely importing a Phobos module is liable to cost you a quarter
> second or more of
On Friday, 23 November 2018 at 17:21:46 UTC, H. S. Teoh wrote:
Are you using template-heavy Phobos functions?
Merely importing a Phobos module is liable to cost you a quarter
second or more of compile time.
I just got my gui lib (22,000 lines of raw source, dscanner -sloc
reports 12,000)
On Fri, Nov 23, 2018 at 08:57:57AM +, Chris Katko via Digitalmars-d-learn
wrote:
> Any time I see people mention the benefits of D, I see "compile times"
> "compile times" "compile times" over and over.
D is extremely fast at compilation ... of C-like code. :-D
Anything involving heavy use
On Friday, 23 November 2018 at 14:33:40 UTC, berni wrote:
I've got the following code, which works, but obviously
contains duplication. Is there a way to move that
"dissection_available?...:..." to the place, where it should be?
return dissection_available
?solution.dup
I've got the following code, which works, but obviously contains
duplication. Is there a way to move that
"dissection_available?...:..." to the place, where it should be?
return dissection_available
?solution.dup
.transposed.map!(a=>a.map!(b=>"?#."[b]).array)
On Friday, 23 November 2018 at 08:57:57 UTC, Chris Katko wrote:
Any time I see people mention the benefits of D, I see "compile
times" "compile times" "compile times" over and over.
[...]
If you can share the code privately I can use my custom profiling
build of dmd to analyze the problem.
__traits(compiles...) does not call your function so it is not evaluate
twice only once, so there is no need to use memoize
On Fri, Nov 23, 2018 at 11:35 AM John Chapman via Digitalmars-d-learn <
digitalmars-d-learn@puremagic.com> wrote:
> I'm doing a fair amount of repeatedly checking if a
On Friday, 23 November 2018 at 11:29:24 UTC, Nicholas Wilson
wrote:
No, std.functional.memoize uses a hashtable to cache the
runtime results of calls to expensive functions.
assuming that the example is not oversimplified and
generateFunc1 and generateFunc2 are functions, the compiler
On Friday, 23 November 2018 at 10:34:11 UTC, John Chapman wrote:
I'm doing a fair amount of repeatedly checking if a function
compiles with __traits(compiles...), executing the function if
so, erroring out if not, like this:
static if (__traits(compiles, generateFunc1())) {
return
On Fri, Nov 23, 2018 at 10:00 AM Chris Katko via Digitalmars-d-learn <
digitalmars-d-learn@puremagic.com> wrote:
> Any time I see people mention the benefits of D, I see "compile
> times" "compile times" "compile times" over and over.
>
> I'm using very modest amounts of templates, for a fairly
I'm doing a fair amount of repeatedly checking if a function
compiles with __traits(compiles...), executing the function if
so, erroring out if not, like this:
static if (__traits(compiles, generateFunc1())) {
return generateFunc1();
} static if (__traits(compiles, generateFunc2())) {
On Thursday, 22 November 2018 at 16:27:08 UTC, Eduard Staniloiu
wrote:
So I had a go at this and I have a working solution.
https://run.dlang.io/is/oaH6Ib
At first, I tried to do everything in the mixin, as you can see
with the `failedAttempt` function. The idea was that this
should have
On Friday, 23 November 2018 at 08:57:57 UTC, Chris Katko wrote:
Any time I see people mention the benefits of D, I see "compile
times" "compile times" "compile times" over and over.
I'm using very modest amounts of templates, for a fairly small
sized program (very early work toward a game),
On Thursday, 22 November 2018 at 23:10:06 UTC, Per Nordlöw wrote:
With emphasis on _incremental_ additions to the compiler for
covering more and more positives without introducing any
_false_ negatives whatsoever. Without loosing compilation
performance.
BTW, should such a compiler checking
Any time I see people mention the benefits of D, I see "compile
times" "compile times" "compile times" over and over.
I'm using very modest amounts of templates, for a fairly small
sized program (very early work toward a game), and I'm hitting
~15 seconds compile time in LDC and ~7 seconds in
35 matches
Mail list logo
