Re: Why typeof(template) is void?

[mogu via Digitalmars-d-learn]

On Wednesday, 20 July 2016 at 01:50:37 UTC, Adam D. Ruppe wrote:

On Wednesday, 20 July 2016 at 01:14:05 UTC, mogu wrote:

Why S's type isn't something like `S: (T) -> S`?


Because S isn't a type... think of a template as being like a 
function that returns a type.


int foo(int) { return 0; }

There, you wouldn't expect typeof(foo) to be int, no, 
typeof(foo) is a function that returns an int.


The template is the same thing - it isn't a type, it is a 
template that returns a type.


So it's a higher kinded type aka type class in Haskell. But D's 
reflection cannot get enough information about template's kind. 
Only a `void` given. It may be inconvenient in distinction 
between an alias of template and void. The only solution AFAIK is 
by string of the type property .stringof.

Re: How to search for an enum by values and why enum items aren't unique

[Jonathan M Davis via Digitalmars-d-learn]

On Wednesday, July 20, 2016 04:03:23 stunaep via Digitalmars-d-learn wrote:
> How can I search for an enum by its values? For example I have
>
> >struct TestTraits {
> >
> > int value1;
> > string value2;
> >
> >}
> >
> >enum Test : TestTraits {
> >
> > TEST = TestTraits(1, "test1"),
> > TESTING = TestTraits(5, "test5")
> >
> >}
>
> and I have the int 5 and need to find TESTING with it.
>
> In java I would create a SearchableEnum interface, make all
> searchable enums implement it and use this method to find them.
>
> >public static  T find(T[] vals, int
> >id) {
> >
> > for (T val : vals) {
> >
> > if (id == val.getId()) {
> >
> > return val;
> >
> > }
> >
> > }
> > return null;
> >
> >}
>
> But the way enums work in D doesn't seem to permit this.

If you want the list of members in an enum, then use std.traits.EnumMembers
and you'll get a compile-time list of them. It can be made into a runtime
list by being put into an array literal.

For instance, if we take std.datetime.Month, we can look for the enum
with the value 10 in it like so.

auto found = [EnumMembers!Month].find(10);
assert(found = [Month.oct, Month.nov, Month.dec]);

So, if you had your TestTraits struct as the type for an enum, you could do
something like

auto found = [EnumMembers!TestTraits].find!(a => a.value1 == 5)();
if(found.empty)
{
// there is no TestTraits which matches
}
else
{
// found.front is the match
}

> And why on earth are different enum items with the same values
> equal to each other? Say I have an enum called DrawableShape

Because they have the same value. The fact that they're enums doesn't change
how they're compared. That's determined by what type they are. All you're
really getting with an enum is a list of named constants that are grouped
together which implicitly convert to their base type but which are not
converted to implicitly from their base type. The only stuff that's going to
treat an enum member differently from any other value of that type is
something that specifically operates on enums - e.g. by taking the enum type
explicitly, or because it has is(T == enum) and does something different for
enums (quite a few traits do that in std.traits), or because it uses a final
switch. Most code is just going to treat them like any other value of the
enum's base type. They aren't magically treated as unique in some way just
because they're in an enum.

- Jonathan M Davis

Re: Dynamic code generation

[ag0aep6g via Digitalmars-d-learn]

On 07/20/2016 06:36 AM, Rufus Smith wrote:

Does D offer any solutions to generate code dynamically?


I don't think so.


I would like to
order based on optimal strategies. This requires effectively hard coding
the execution path.

A simple example,

if (x == true)
foo();
else
bar();

can be recoded to be foo() or bar() while x is fixed, in my case x is
fixed for long periods and therefor the check is unnecessary. I also
know when x changes in all cases. This is just a simple example, of
course. I would not want to resort to assembly programming to accomplish
this.


Just an idea:


void main()
{
setX(true);
f(); /* calls foo */
setX(false);
f(); /* calls bar */
}

void function() f;

void setX(bool x)
{
if (x) f = !true;
else f = !false;
}

void impl(bool x)()
{
static if (x) foo();
else bar();
}

void foo() { import std.stdio; writeln("foo"); }
void bar() { import std.stdio; writeln("bar"); }


Of course, if this is for optimization purposes, measure first if 
hard-coded is actually faster than the branch.

Re: What is the current progress on "Safety and Memory Management"?

[tsbockman via Digitalmars-d]

On Tuesday, 19 July 2016 at 13:01:23 UTC, maik klein wrote:

I don't want to implement any memory safety at all,


If you don't care about memory safety, I expect that your efforts 
to modify Phobos for that purpose will be unwelcome. The D 
leadership are actively working on non-GC memory management, but 
safety is a high priority.


A third-party library for unsafe memory management might see some 
adoption - but it also risks being made irrelevant when and if 
the official project for safe memory management finally bears 
fruit.

Dynamic code generation

[Rufus Smith via Digitalmars-d-learn]

Does D offer any solutions to generate code dynamically? I would 
like to order based on optimal strategies. This requires 
effectively hard coding the execution path.


A simple example,

if (x == true)
   foo();
else
   bar();

can be recoded to be foo() or bar() while x is fixed, in my case 
x is fixed for long periods and therefor the check is 
unnecessary. I also know when x changes in all cases. This is 
just a simple example, of course. I would not want to resort to 
assembly programming to accomplish this.

How to search for an enum by values and why enum items aren't unique

[stunaep via Digitalmars-d-learn]

How can I search for an enum by its values? For example I have

struct TestTraits {
int value1;
string value2;
}

enum Test : TestTraits {
TEST = TestTraits(1, "test1"),
TESTING = TestTraits(5, "test5")
}


and I have the int 5 and need to find TESTING with it.

In java I would create a SearchableEnum interface, make all 
searchable enums implement it and use this method to find them.
public static  T find(T[] vals, int 
id) {

for (T val : vals) {
if (id == val.getId()) {
return val;
}
}
return null;
}

But the way enums work in D doesn't seem to permit this.

And why on earth are different enum items with the same values 
equal to each other? Say I have an enum called DrawableShape



struct DrawableShapeTraits {
bool useAlpha;
int sideCount;
}

enum DrawableShape : DrawableShapeTraits {
RECTANGLE = DrawableShapeTraits(true, 4),
DIAMOND = DrawableShapeTraits(true, 4),
}


Now say I have some code that does this


if(shape == DrawableShape.DIAMOND)
... render a diamond
else if(shape == DrawableShape.RECTANGLE)
... render a rectangle


Now even if shape is a DrawableShape.RECTANGLE it's going to 
render a DrawableShape.DIAMOND unless I add a dummy value to 
differentiate them.

Re: Template arguments produce unidentified identifier

[Rufus Smith via Digitalmars-d-learn]

On Wednesday, 20 July 2016 at 01:48:31 UTC, Adam D. Ruppe wrote:

Take a read of this:

http://stackoverflow.com/a/32621854/1457000

The short of it is don't mixin stringof. Instead, mixin the 
actual template itself.


The functionLinkage might need to be string, but the types 
should remain literal. So try this:


mixin("alias Func = extern("~functionLinkage!Q~") 
(ReturnType!Q) function (Erase!(Parameters!Q));");



or something like that - don't concatenate strings of those, 
just make the string itself still say ReturnType!Q etc when you 
mix in. Then the scope will be correct.


Thanks, it did work with some modification:

mixin("alias Func = extern("~functionLinkage!Q~") ReturnType!Q 
function(Erase!(Parameters!Q));");


No parenthesis around ReturnType or strange errors happen.

Re: Why typeof(template) is void?

[Adam D. Ruppe via Digitalmars-d-learn]

On Wednesday, 20 July 2016 at 01:14:05 UTC, mogu wrote:

Why S's type isn't something like `S: (T) -> S`?


Because S isn't a type... think of a template as being like a 
function that returns a type.


int foo(int) { return 0; }

There, you wouldn't expect typeof(foo) to be int, no, typeof(foo) 
is a function that returns an int.


The template is the same thing - it isn't a type, it is a 
template that returns a type.

simple sax-style xml parser

[ketmar via Digitalmars-d-announce]

i wrote a simple sax-style xml parser[1][2] for my own needs, and 
decided to share it. it has two interfaces: `xmparse()` function 
which simply calls callbacks without any validation or encoding 
conversion, and `SaxyEx` class, which does some validation, 
converts content to utf-8 (from anything std.encoding supports), 
and calls callbacks when the given path is triggered.


it can parse any `char` input range, or std.stdio.File. parsing 
files is probably slightly faster than parsing ranges.


internally it is extensively reusing memory buffers it allocated, 
so it should not create a big pressure on GC.


you are expected to copy any data you need in callbacks (not just 
slice, but .dup!).


so far i'm using it to parse fb2 files, and it parsing 8.5 
megabyte utf-8 file (and creating internal reader structures, 
including splitting text to words and some other housekeeping) in 
one second on my i3 (with dmd -O, even without -inline and 
-release).


it is not really documented, but i think it is "intuitive". there 
are also some comments in source code; please, read those! ;-)


p.s. it decodes standard xml entities (

Re: Template arguments produce unidentified identifier

[Adam D. Ruppe via Digitalmars-d-learn]

Take a read of this:

http://stackoverflow.com/a/32621854/1457000

The short of it is don't mixin stringof. Instead, mixin the 
actual template itself.


The functionLinkage might need to be string, but the types should 
remain literal. So try this:


mixin("alias Func = extern("~functionLinkage!Q~") (ReturnType!Q) 
function (Erase!(Parameters!Q));");



or something like that - don't concatenate strings of those, just 
make the string itself still say ReturnType!Q etc when you mix 
in. Then the scope will be correct.

[Issue 15925] -transition=[check]imports ignores import declaration from mixin templates

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15925

--- Comment #21 from Steven Schveighoffer  ---
To add to this, I think the use case being held as the example that shows why
this was done is:

a.d:
module a;

struct S {}
void foo() {}

void m(S s) {}

// uncomment to hijack!
// void bar() {}

b.d:
module b;

class Foo
{
   import a;
   S s;
}

c.d:
module c;
void bar() {}

d.d:
module d;
import b;
import c;

foo();

class Bar : Foo
{
   void x() {
 foo();
 bar();
 s.m();
   }  
}

So x calling foo calls local foo. That's fine, with new import rules, nothing
outside of d.d can change that. The fix is to avoid calling a.bar if it was
added at a later time.

But what about the prevention of Bar from seeing m? Surely, when we want to
include an S member, we want to include it's entire interface. Now if some
other module defines an m that accepts an S, then s.m means something different
in Bar than it does in Foo! This can't be the right solution, can it?

This seems like it was broken before, and is broken in a different way now.
It's impossible to tell what the original code "wanted" to do. But it seems
pretty clear to me that Foo has a certain view of what an S API looks like, and
it meant to forward that view to its subclasses.

I can at least document the change in my blog article, because even if this
decision is reversed, 2.071 is already out there.

--

Re: Template arguments produce unidentified identifier

[Rufus Smith via Digitalmars-d-learn]

If it's not clear, I have to import the proper identifiers but 
every use of the template would require the user to add their 
import. Obviously not the way to go.

Template arguments produce unidentified identifier

[Rufus Smith via Digitalmars-d-learn]

I have complex template that uses a mixin to solve some problems. 
The mixin produces the error.  I thought template's were added in 
to the scope of the call? I guess the mixin is inserted before 
this happens. That isn't good ;/


Here is one place the error happens

	mixin("alias Func = extern("~functionLinkage!Q~") 
"~(ReturnType!Q).stringof~" 
function"~(Erase!(Parameters!Q)).stringof~";");


The mixin is required to get the proper linkage, as no other 
method has been found to do that. Everything works with built in 
types.


I saw somewhere that vibe.d had some way around this but the 
links are dead.

Why typeof(template) is void?

[mogu via Digitalmars-d-learn]

```
struct S(T) {}

static assert(is (typeof(S) == void));
```

Why S's type isn't something like `S: (T) -> S`?

[Issue 15925] -transition=[check]imports ignores import declaration from mixin templates

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15925

--- Comment #20 from Steven Schveighoffer  ---
(In reply to Mathias Lang from comment #18)
> Feel free to reach out to me by email if not.

In the interest of keeping the discussion public, I'll just reply here.

> Now there is something special about 'mixin template' and 'class' /
> 'interface' declaration: they are the only remote (as in, outside of the
> module) symbol one can inherit it's scope from. 
> 
> But inheriting the imports leads to the same issues 10378 describe: you can
> end up in a situation where adding a symbol to module 'foo' which is
> 'protected import' of class 'A' will suddenly change which symbol is
> selected in subclass 'B : A'. However, if you have both imports at the same
> level, you'll get a conflict.

I think what you are saying is that a mixed in template could affect existing
*imports*, right? But an import can already do that! Ignoring imports with
mixins doesn't fix this problem.

The mixin could not hijack local symbols, right? I thought that was the larger
point -- you are referring to class/local symbols, or even module functions,
and suddenly that changes through a hijacked import.

I get that it's good to prevent hijacking as much as possible. But this doesn't
disallow hijacking to any further degree than is already disallowed. In other
words, preventing mixins from hijacking imported symbols doesn't remove the
problem, and just makes the language inconsistent.

> The only kind of hijacking I can think of ATM is when an import which is
> more nested than another one introduce an already-used symbol.
> 
> E.g. if this class used 'b.myFunc' before and a new library introduce
> 'd.myFunc':

Right, but this still exists. Why prevent it in the case of a mixin?

For example, d could public import x. x could define myFunc. This is pretty
much equivalent to the mixin case.

--

[Issue 16291] phobosinit fails to register encodings on individual tests

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16291

--- Comment #19 from Ketmar Dark  ---
>But maybe your idea of registering on demand is worth considering even with 
>that
>update.
if you'll decide that it worth keeping, then just drop a note in 16298, i can
rewrite the patch to use CT reflection instead. if you don't want to create
your own patch from scratch, of course. ;-)

>Sorry about the strife!
no problems. ;-)

--

[Issue 16291] phobosinit fails to register encodings on individual tests

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16291

--- Comment #18 from Steven Schveighoffer  ---
(In reply to Ketmar Dark from comment #17)
> p.s. if it works, please, close my ER in issue 16298 then.

Sure. I personally hate the way std.encoding registers all the encodings, so
I'd like to fix that anyway (but by using compile-time reflection, not strings
and object.factory). But maybe your idea of registering on demand is worth
considering even with that update.

Sorry about the strife! Cycles in D suck. Hopefully we can make the whole thing
more pleasant.

--

[Issue 16282] Partial permutation/nextPermutation in std.algorithm

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16282

--- Comment #3 from greenify  ---
> It looks about how I had envisioned it, but I'm not really
jazzed about the idea of installing an entire mathematics package for a one-off
script I was expecting to take fifteen minutes.

Do you know about the new inline dub header? At least that's the tradeoff I am
taking at the moment.

#!/usr/bin/env dub
/+ dub.sdl:
name "foo"
dependency "mir" version="0.15.3"
+/

In any case I recommend making a bit of fuzz at the NG (forum.dlang.org) as
this thread isn't monitored by many people. D developers are actually quite
responsive to constructive feedback :)

> As for the reasoning, I just figured this was obvious?

Yes, when I needed it I was shocked too and thus wrote the small combinatorics
module :/

--

[Issue 16291] phobosinit fails to register encodings on individual tests

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16291

--- Comment #17 from Ketmar Dark  ---
p.s. if it works, please, close my ER in issue 16298 then.

--

[Issue 16291] phobosinit fails to register encodings on individual tests

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16291

--- Comment #16 from Ketmar Dark  ---
how did you dare to make my great patch unnecessary?! ;-))

--

[Issue 15925] -transition=[check]imports ignores import declaration from mixin templates

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15925

--- Comment #19 from det <2k...@gmx.net> ---
(In reply to Mathias Lang from comment #18)
> The rationale is that this behavior allowed symbol hijacking.
> 
> The behavior of the compiler was changed to perform 2 passes for symbol
> resolution, the first one on local symbol, the second one on imports.
> ...
> See https://issues.dlang.org/show_bug.cgi?id=10378 for the actual issue.

i think the problem steve and i have is that the communicated changes that came
with 2.071 are the following two
1) don't be able to use symbols that are not visible (which is of course
according to specs but was not enforced beforehand)
2) change in lookup sequence to prevent hijacking

(2) relates to your examples in c18 and
https://issues.dlang.org/show_bug.cgi?id=10378

however, the issue here WRT mixin templates is the following:
it is NOT just (2) at work, i.e. a change in lookup sequence - which would be
straightforward. but rather, whole module imports mixed in are completely
ignored. why such an enforcement? it seems overly excessive and restrictive as
just an application of (2) would have prevented hijacking.

and unlike the well communicated changes (1) and (2) this new behavior is NOT
supported by the current language specs and has so far not been officially
communicated anywhere.

when ppl's code fails (as happened to me), they search the specs, find nothing,
search the bug tracker/issues, find this very example of the problem, and see
it is marked as fixed - in contradiction to the issue being persistent. yes,
the changed subject gives a hint but i still favor a split into a 2 issues:
o this one being 'resolved invalid'
o a new 'see also' linked issue that is 'resolved fixed'
and of course official documentation/specs that reflect the changes in
behavior.

--

[Issue 16291] phobosinit fails to register encodings on individual tests

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16291

--- Comment #15 from Steven Schveighoffer  ---
I'm going to have to take back what I said. I added back in the static ctors,
and there is no cycle, even with my patch that fixes cycle detection. It's
probably all the work on trimming out unnecessary imports that has helped this.

I'll "revert" what I did by moving the static ctors back into std.encoding.

--

[Issue 16282] Partial permutation/nextPermutation in std.algorithm

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16282

--- Comment #2 from Wyatt  ---
I guess it might?  It looks about how I had envisioned it, but I'm not really
jazzed about the idea of installing an entire mathematics package for a one-off
script I was expecting to take fifteen minutes.

As for the reasoning, I just figured this was obvious? I mean, there probably
isn't an introductory text on permutation that doesn't cover the constrained
case.

--

Re: Atila Neves: "C IS NOT MAGICALLY FAST, PART 2"

[Jakob Bornecrantz via Digitalmars-d]

On Tuesday, 19 July 2016 at 16:13:21 UTC, Atila Neves wrote:
On Tuesday, 19 July 2016 at 16:01:01 UTC, Lodovico Giaretta 
wrote:

On Tuesday, 19 July 2016 at 15:48:26 UTC, Atila Neves wrote:

Small string optimization should _help_ std::string, no?

Atila


Small string optimization will make the struct bigger, thus 
making swapping slower. If the struct is no bigger than 2 
pointers, swapping it is ultra fast.


Interesting. Read up on it and tried changing the strings to be 
~50 chars long. C++/std::string gets better, but C++/const 
char* still beats D by a small margin:


C: 1.852s
C++/std::string: 1.489s
C++/const char*: 1.034s
D: 1.188s

Could be the cost of swapping the "fat" in "fat pointer", in 
which case: worth it.


You are swapping different amount of data.
For C++/const char* vs D, you are swapping 75% more data.
For D vs C++/std::string, you are swsapping 129% more data.

I would expect you getting the same numbers if you did 
"const(char)*" version in D?


And if you used a inline sort[1] in the C version it would 
probably be just as fast as the C++/const char* version.


Also it was a bit hard to find out what N you where using.

Cheers, Jakob.


[1] http://www.corpit.ru/mjt/qsort.html

[Issue 13537] Unions may break immutability

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13537

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 13537] Unions may break immutability

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13537

--- Comment #5 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/09ed87c973fbcb777806506f7e05fbed30a3f355
fix Issue 13537 - Unions may break immutability

https://github.com/dlang/dmd/commit/72077372aec4aa77899885fc5cffbdbc5d289021
Merge pull request #5940 from WalterBright/fix13537

fix Issue 13537 - Unions may break immutability

--

[Issue 16299] New: Documentation for Phobos needs to warn about autodecoding

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16299

  Issue ID: 16299
   Summary: Documentation for Phobos needs to warn about
autodecoding
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: wyatt@gmail.com

Problem:
The anomalous effects of autodecoding for Phobos functions are _effectively_
undocumented.  This means an innocent user has no warning that something like
std.algorithm.iteration.permutations will fail on an array of char[] (a very
common built-in type).  This is bad.

Possible fixes:
- Add warnings (with text _and_ links) that using char[] is going to screw
users:
If using a char[] is going to break something, that should be mentioned in
the documentation for it.  There at least needs to be a generic warning that
stands out visually and links to further information on the autodecoding
problem and how to work around it.

- Add examples that show affected templates used on char[] and dchar[]:
Most of the examples are conscripted unit tests using integers.

- Have the compiler explain the actual problem:
Ugly? Maybe. Special casing is bad? Sure. But the current error is really
obtuse when you can do exactly what the example does only with a different type
and get "cannot deduce function from argument types".  That's way out of left
field.

- Make it actually work like it should:
Especially if the input is known at compile time, autodecoding shouldn't
even be a problem.  But even at runtime, this should just work without fuss. 
Users shouldn't have to hunt down the documentation for template constraints if
they're not writing range types of their own; we made them grey because most
people _can_ ignore them.

See Also: 
Comments on issue #16263

--

Re: Is there a way to "see" source code generated by templates after a compile?

[WhatMeWorry via Digitalmars-d-learn]

On Sunday, 17 July 2016 at 05:57:52 UTC, WhatMeWorry wrote:



I don't suppose there's a way to "see" source code generated by 
templates after a compile but before execution?  Or does the 
compiler generate it to a lower level on the fly; thus losing 
the source code?


I'm assuming no because if there were a way, I'd of come across 
it by now :)






I've just stumbled across this on dmd documentation. Haven't had 
time to play with it yet.


-allinst

generate code for all template instantiations

[Issue 15925] -transition=[check]imports ignores import declaration from mixin templates

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15925

--- Comment #17 from Steven Schveighoffer  ---
(In reply to Mathias Lang from comment #16)
> The details of the bug were wrong (it should be ignored unlike what I
> originally believed)

While this has your attention, can you point me at the rationale to why this is
so? See my earlier comment 14.

BTW, we shouldn't rename or repurpose bugs like this.

--

Re: Atila Neves: "C IS NOT MAGICALLY FAST, PART 2"

[Ali Çehreli via Digitalmars-d]

On 07/19/2016 12:00 PM, Ali Çehreli wrote:
> On 07/19/2016 10:41 AM, deadalnix wrote:

>> if(i < other.i) return -1;
>> if(i > other.i) return 1;
>>
>> Should be
>>
>> (i > other.i) - (i < other.i)
>>
>> Surprisingly, LLVM was unable to optimize one into the other in my 
tests.


If you mean the following, it's slower with ldc:

const r = (i > other.i) - (i < other.i) ;
if (r) return r;

> Additionally, the string may be traversed twice in opCmp. The following
> change makes D example faster:
>
>  import std.algorithm : cmp;
>  return cmp(s, other.s);
> //return s < other.s
> //? -1
> //: (s > other.s ? 1 : 0);

Faster with dmd but has no difference with ldc.

Ali

Re: Atila Neves: "C IS NOT MAGICALLY FAST, PART 2"

[Ali Çehreli via Digitalmars-d]

On 07/19/2016 10:41 AM, deadalnix wrote:

On Tuesday, 19 July 2016 at 10:07:11 UTC, Atila Neves wrote:

On Tuesday, 19 July 2016 at 02:54:37 UTC, Saurabh Das wrote:


Posted on Atila's blog yesterday:

https://atilanevesoncode.wordpress.com/2016/07/18/c-is-not-magically-fast-part-2/



So, about D vs C++ there... last night for reasons I forget I tried
replacing std::string with const char* in the C++ version, and then it
got faster than D. I don't know why.

At first I thought std::string was being copied instead of being
moved, but some static_asserts made me doubt that. Either way, there's
no good reason I can think of for C++ to magically speed up for const
char*. Hmm :(

Atila


What compiler are you using ? If it is LLVM based, could you post IR ?

Also:

if(i < other.i) return -1;
if(i > other.i) return 1;

Should be

(i > other.i) - (i < other.i)

Surprisingly, LLVM was unable to optimize one into the other in my tests.


Additionally, the string may be traversed twice in opCmp. The following 
change makes D example faster:


import std.algorithm : cmp;
return cmp(s, other.s);
//return s < other.s
//? -1
//: (s > other.s ? 1 : 0);

Ali

Re: Autotesting dub packages with dmd nightly

[vladdeSV via Digitalmars-d-announce]

On Saturday, 16 July 2016 at 20:34:49 UTC, Sebastiaan Koppe wrote:
Just to let you guys know - and to be sure no one is doing the 
same - I decided to go ahead and *start* writing an autotester 
that will fetch dmd nightly and unittest each dub package.


It will be using a classic master-worker architecture and will 
leverage docker containers.


I am aiming really low at first, but will eventually add things 
like memory usage, history, notifications, etc.


Nice :)

Re: Our docs should be more beautiful

[Wyatt via Digitalmars-d]

On Monday, 18 July 2016 at 15:56:29 UTC, Andrei Alexandrescu 
wrote:


* My pet dream was to work on a project with a beautiful 
justified and hyphenated website. After endless debates, 
ugliness has won - I'm looking at a eye-scratching ragged right 
edge.


I just want to point out that Firefox will sporadically justify 
incredibly poorly, leaving huge spaces between words (In one 
extreme case, I caught it making something like 3cm gaps).  It 
looks really bad, and isn't actually easier to read when the line 
length is long.


-Wyatt

Re: Allowing "fall through" of attributes

[Rufus Smith via Digitalmars-d-learn]

On Tuesday, 19 July 2016 at 17:10:35 UTC, Lodovico Giaretta wrote:

On Tuesday, 19 July 2016 at 17:05:55 UTC, Rufus Smith wrote:
On Tuesday, 19 July 2016 at 16:59:48 UTC, Lodovico Giaretta 
wrote:

On Tuesday, 19 July 2016 at 16:50:56 UTC, Rufus Smith wrote:
On Tuesday, 19 July 2016 at 16:09:38 UTC, Lodovico Giaretta 
wrote:

[...]


But this doesn't create a function with all the attributes 
of the original? Just one that has the same return type and 
parameters. What if Fun is pure or extern(C) or some other 
attributes? I'd like to create a function that is exactly 
the same in all regards as the original.


Sorry, I misunderstood your question.
With the method I showed you, if the function is @safe, pure, 
@nogc or nothrow, foo will infer those attributes. But only 
if the operations you do in foo (apart from calling bar) are 
themselves @safe, pure, @nogc or nothrow.
For other things, like extern(C), I don't think there's a 
simple solution; but I'm not an expert, so I hope someone 
else will give you a better answer.


What is strange is I cannot even pass an extern(C) function to 
foo.


void foo(R, A...)(R function(A) bar);

extern(C) void bar();

foo()

fails. Remove extern and it passes. I have not figured out how 
to allow for extern(C) functions to be passed.


That's because an extern function must be called with a 
different code. So it cannot be cast to a non-extern(C) 
function pointer, which is what your foo accepts. If you follow 
my advice, and make the entire function type a parameter of 
foo, then foo will at least accept your extern(C) function, but 
it will not be extern(C) itself.


I don't want it to be cast to a non-extern function. What I want 
to do is create the exact same type of function that is passed to 
the template except modify the arguments.


If I use a general parameter for the function, it accepts 
extern(C), but I can't construct a function with it.


mixin("alias F = extern("~functionLinkage!Q~") 
"~(ReturnType!Q).stringof~" 
function"~(Parameters!Q).stringof~";");


gives me a type that looks to be what I want but I can't really 
use it unless I want to declare the function that does the work 
inside foo as mixin string.


One can't do extern(functionLinkage!Q) void baz() to create baz 
with the proper linkage ;/


It looks like I might have to go the mixin way ;/ Going to be 
messy ;/

[Issue 16291] phobosinit fails to register encodings on individual tests

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16291

Jack Stouffer  changed:

   What|Removed |Added

   Hardware|x86_64  |All
 OS|Linux   |All

--

[Issue 16291] phobosinit fails to register encodings on individual tests

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16291

Jack Stouffer  changed:

   What|Removed |Added

 CC||j...@jackstouffer.com
   Severity|enhancement |regression

--- Comment #14 from Jack Stouffer  ---
Because this broke code I am raising this to a regression.

--

[Issue 16298] [ER] lazily register standard codecs from std.encoding

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16298

Ketmar Dark  changed:

   What|Removed |Added

 CC||ket...@ketmar.no-ip.org

--

[Issue 16291] phobosinit fails to register encodings on individual tests

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16291

--- Comment #13 from Ketmar Dark  ---
did it: https://issues.dlang.org/show_bug.cgi?id=16298

--

[Issue 16298] New: [ER] lazily register standard codecs from std.encoding

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16298

  Issue ID: 16298
   Summary: [ER] lazily register standard codecs from std.encoding
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: ket...@ketmar.no-ip.org

Created attachment 1604
  --> https://issues.dlang.org/attachment.cgi?id=1604=edit
lazily registers standard codecs

the attached patch seems to work ok with my system. it registers standard
codecs when on first call to `EncodingScheme.create()`, and it also exposes
`EncodingScheme.registerStandardCodecs()` function, which can be called to
manually register standard codecs if it is necessary in some other module ctor.

it is safe to call `EncodingScheme.registerStandardCodecs()` multiple times,
and from multiple threads.

this patch solves issue 16291 for the time being, until the proper fix for
cycle detection in module ctors isn't complete.

--

[Issue 16291] phobosinit fails to register encodings on individual tests

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16291

--- Comment #12 from Steven Schveighoffer  ---
Ketmar, thanks for the patch. I think you should open a new bug report with it
so it doesn't get lost. I have to fix the phobosinit code anyway, which will
close this.

--

[Issue 16291] phobosinit fails to register encodings on individual tests

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16291

--- Comment #11 from Ketmar Dark  ---
p.s. we probably can enumerate all std.encoding module symbols with CTFE
reflection instead, but i don't think that it makes huge difference here.
paying small fee at program startup looks better for me than paying this fee
each time we compiling the code that imports std.encoding. while CTFE time is
small in this case, i prefer it this way.

but if you think that we should use compile-time reflection instead, feel free
to say that, and i'll rework the patch. ;-)

--

Re: Our docs should be more beautiful

[bitwise via Digitalmars-d]

On Tuesday, 19 July 2016 at 17:02:34 UTC, Andrei Alexandrescu 
wrote:

On 7/19/16 12:39 PM, bitwise wrote:
On Tuesday, 19 July 2016 at 01:37:20 UTC, Andrei Alexandrescu 
wrote:

On 07/18/2016 06:13 PM, bitwise wrote:
Any chance of getting one definition or overload-set per 
page?


Been like that for a while, my comments refer to the old 
styling. --

Andrei


Why talk about the old style though? I don't see any of the 
problems

you've mentioned in the new beta docs

http://dlang.org/library/std/algorithm/searching/balanced_parens.html

Bit


The two coexist. -- Andrei


Ok, I was under the impression the old ones would eventually be 
removed.


Thanks,
Bit

[Issue 16291] phobosinit fails to register encodings on individual tests

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16291

--- Comment #10 from Ketmar Dark  ---
Created attachment 1603
  --> https://issues.dlang.org/attachment.cgi?id=1603=edit
lazy standard codec registration

the attached patch seems to work ok with my system. it registers standard
codecs when user is first trying to use `EncodingScheme.create()`, and it also
exposes `EncodingScheme.registerStandardCodecs()` function, which can be called
to manually register standard codecs if it is necessary in some other module
ctor.

it is safe to call `EncodingScheme.registerStandardCodecs()` multiple times,
and from multiple threads.

--

Re: Atila Neves: "C IS NOT MAGICALLY FAST, PART 2"

[deadalnix via Digitalmars-d]

On Tuesday, 19 July 2016 at 10:07:11 UTC, Atila Neves wrote:

On Tuesday, 19 July 2016 at 02:54:37 UTC, Saurabh Das wrote:


Posted on Atila's blog yesterday:

https://atilanevesoncode.wordpress.com/2016/07/18/c-is-not-magically-fast-part-2/


So, about D vs C++ there... last night for reasons I forget I 
tried replacing std::string with const char* in the C++ 
version, and then it got faster than D. I don't know why.


At first I thought std::string was being copied instead of 
being moved, but some static_asserts made me doubt that. Either 
way, there's no good reason I can think of for C++ to magically 
speed up for const char*. Hmm :(


Atila


What compiler are you using ? If it is LLVM based, could you post 
IR ?


Also:

if(i < other.i) return -1;
if(i > other.i) return 1;

Should be

(i > other.i) - (i < other.i)

Surprisingly, LLVM was unable to optimize one into the other in 
my tests.

[Issue 16291] phobosinit fails to register encodings on individual tests

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16291

--- Comment #9 from Steven Schveighoffer  ---
(In reply to Ketmar Dark from comment #8)
> yes, i know. but std.encoding seems to not import anything that may
> indirectly import it back, and it *seems* to not break anything for my
> system.

That's because you don't have proper cycle detection on your system :) I
manually verified the cycle did exist. I don't remember the exact cycle
modules.

Note that there really aren't any cycles in terms of std.encoding requiring
some other module ctor to work correctly, but the runtime doesn't do a proper
job of sorting the order of the ctors, and when that is fixed, it can't solve
the ordering.

My fix that I pushed was not right -- the dependency is lost, and now may
result in incorrect ordering still.

--

[Issue 16291] phobosinit fails to register encodings on individual tests

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16291

--- Comment #8 from Ketmar Dark  ---
>I should tell you that cycle detection is currently broken
yes, i know. but std.encoding seems to not import anything that may indirectly
import it back, and it *seems* to not break anything for my system.

i'm not insisting on that solution, though. maybe we can use some kind of "lazy
initialization" scheme instead, by writing a weird hack: on the first call to
`EncodingScheme.create()` we can find std.encoding in module list, and register
every encoder it has. i think this *may* work (if linker will not throw away
"unused classes"). i probably will try to write such code to see if it will
work.

--

Re: How to get the "this" ptr of a lambda inside the lambda?

[Steven Schveighoffer via Digitalmars-d-learn]

On 7/19/16 1:03 PM, Rufus Smith wrote:

On Tuesday, 19 July 2016 at 16:58:12 UTC, Steven Schveighoffer wrote:

On 7/19/16 12:52 PM, Rufus Smith wrote:

On Tuesday, 19 July 2016 at 15:58:49 UTC, Steven Schveighoffer wrote:

[...]


Yes, but then this = null. I matters not for my use case.


'this' is not null in either case. There is no 'this'.



Please stop saying that:

https://en.wikipedia.org/wiki/This_(computer_programming)

this is more general than you think.


The compiler knows about the context pointer, your delegate has no name 
for it. And in a lambda that does not need one, there is no context 
pointer, it's not a pointer that's set to null.


I fully understand what you're looking for. In D, 'this' means the 
object/struct that a method is being called with. If you don't have an 
object delegate, then you don't have a 'this' reference (and by that I 
mean a named parameter to the member function called 'this' or any other 
name).


-Steve

[Issue 16291] phobosinit fails to register encodings on individual tests

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16291

--- Comment #7 from Steven Schveighoffer  ---
(In reply to Ketmar Dark from comment #4)
> for now, easy fix is to move that thing back to "std.encoding", as it seems
> to not conflict with anything now. and probably create a new issue that
> documents this behavior.

This would bring back the cycle that it fixed. I should tell you that cycle
detection is currently broken, see issue 16211. I was getting cycle errors with
the fix for that issue until this fix was in place.

--

Re: Allowing "fall through" of attributes

[Lodovico Giaretta via Digitalmars-d-learn]

On Tuesday, 19 July 2016 at 17:05:55 UTC, Rufus Smith wrote:
On Tuesday, 19 July 2016 at 16:59:48 UTC, Lodovico Giaretta 
wrote:

On Tuesday, 19 July 2016 at 16:50:56 UTC, Rufus Smith wrote:
On Tuesday, 19 July 2016 at 16:09:38 UTC, Lodovico Giaretta 
wrote:

[...]


But this doesn't create a function with all the attributes of 
the original? Just one that has the same return type and 
parameters. What if Fun is pure or extern(C) or some other 
attributes? I'd like to create a function that is exactly the 
same in all regards as the original.


Sorry, I misunderstood your question.
With the method I showed you, if the function is @safe, pure, 
@nogc or nothrow, foo will infer those attributes. But only if 
the operations you do in foo (apart from calling bar) are 
themselves @safe, pure, @nogc or nothrow.
For other things, like extern(C), I don't think there's a 
simple solution; but I'm not an expert, so I hope someone else 
will give you a better answer.


What is strange is I cannot even pass an extern(C) function to 
foo.


void foo(R, A...)(R function(A) bar);

extern(C) void bar();

foo()

fails. Remove extern and it passes. I have not figured out how 
to allow for extern(C) functions to be passed.


That's because an extern function must be called with a different 
code. So it cannot be cast to a non-extern(C) function pointer, 
which is what your foo accepts. If you follow my advice, and make 
the entire function type a parameter of foo, then foo will at 
least accept your extern(C) function, but it will not be 
extern(C) itself.

[Issue 16291] phobosinit fails to register encodings on individual tests

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16291

Steven Schveighoffer  changed:

   What|Removed |Added

   Assignee|nob...@puremagic.com|schvei...@yahoo.com

--- Comment #6 from Steven Schveighoffer  ---
Hm... I also realized just now that what I did is not correct. There's a chance
that some other static ctor depends on std.encoding registry having been set
up. But the link between encoding and phobosinit isn't there, so the ordering
will be wrong.

I'll fix this in a PR.

--

Re: Passing a single tuple or multiple values

[jmh530 via Digitalmars-d-learn]

On Tuesday, 19 July 2016 at 15:40:20 UTC, Lodovico Giaretta wrote:


You can find this out from the error, which says that you can't 
expand an object of type `(Tuple!(int, int))`. Note the 
surrounding parenthesis: they tell you that what you have is 
not a Tuple, but an AliasSeq whose only member is a Tuple. If 
you do `[0]` on it, you obtain the correct type, i.e. 
`Tuple!(int, int)`, without the parenthesis.


Ah.

[Issue 16291] phobosinit fails to register encodings on individual tests

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16291

--- Comment #5 from Ketmar Dark  ---
p.s. i think that vibe.d works 'cause it passes all it's files to dmd instead
of creating .a library. then dmd generating single object file with everything
necessary inside, including module ctors. but for .a libraries, dmd is writing
alot of object files (one per function, i believe) to allow smartlinking.

so passing all phobos .d files to dmd should work as expected, but using .a
isn't. and i believe that vibe.d will have the same issue if it will be
complied as .a library.

--

Re: Allowing "fall through" of attributes

[Rufus Smith via Digitalmars-d-learn]

On Tuesday, 19 July 2016 at 16:59:48 UTC, Lodovico Giaretta wrote:

On Tuesday, 19 July 2016 at 16:50:56 UTC, Rufus Smith wrote:
On Tuesday, 19 July 2016 at 16:09:38 UTC, Lodovico Giaretta 
wrote:

[...]


But this doesn't create a function with all the attributes of 
the original? Just one that has the same return type and 
parameters. What if Fun is pure or extern(C) or some other 
attributes? I'd like to create a function that is exactly the 
same in all regards as the original.


Sorry, I misunderstood your question.
With the method I showed you, if the function is @safe, pure, 
@nogc or nothrow, foo will infer those attributes. But only if 
the operations you do in foo (apart from calling bar) are 
themselves @safe, pure, @nogc or nothrow.
For other things, like extern(C), I don't think there's a 
simple solution; but I'm not an expert, so I hope someone else 
will give you a better answer.


What is strange is I cannot even pass an extern(C) function to 
foo.


void foo(R, A...)(R function(A) bar);

extern(C) void bar();

foo()

fails. Remove extern and it passes. I have not figured out how to 
allow for extern(C) functions to be passed.

[Issue 16291] phobosinit fails to register encodings on individual tests

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16291

--- Comment #4 from Ketmar Dark  ---
as nothing directly referring to module ctors, linker just doesn't know that it
should not optimize 'em away. maybe we can fix that by emiting some flag for .o
files, but i don't really know -- i never even read about dwarf object file
format, so i'm not sure if such flag exists.

that is, linker really does it's work here: if nothing directly using the
symbol from object file, that object file is not linked to the final binary.
tbh, i don't know how can we solve this: if we will mark all module ctors as
"include always" (if it's possible), we will have alot of unnecessary (and
probably unused) code linked to the final binary. it doesn't hurt much, but
still...

for now, easy fix is to move that thing back to "std.encoding", as it seems to
not conflict with anything now. and probably create a new issue that documents
this behavior.

maybe we can introduce some UDA to mark modules that should not be optimized
away by smartlinking, or something like that, 'cause i guess that similar
issues are very possible in the future, as phobos becomes more and more
complex, with complex interdependencies.

--

Re: Our docs should be more beautiful

[Andrei Alexandrescu via Digitalmars-d]

On 7/19/16 12:39 PM, bitwise wrote:

On Tuesday, 19 July 2016 at 01:37:20 UTC, Andrei Alexandrescu wrote:

On 07/18/2016 06:13 PM, bitwise wrote:

Any chance of getting one definition or overload-set per page?


Been like that for a while, my comments refer to the old styling. --
Andrei


Why talk about the old style though? I don't see any of the problems
you've mentioned in the new beta docs

http://dlang.org/library/std/algorithm/searching/balanced_parens.html

Bit


The two coexist. -- Andrei

Re: How to get the "this" ptr of a lambda inside the lambda?

[Rufus Smith via Digitalmars-d-learn]

On Tuesday, 19 July 2016 at 16:58:12 UTC, Steven Schveighoffer 
wrote:

On 7/19/16 12:52 PM, Rufus Smith wrote:
On Tuesday, 19 July 2016 at 15:58:49 UTC, Steven Schveighoffer 
wrote:

[...]


Yes, but then this = null. I matters not for my use case.


'this' is not null in either case. There is no 'this'.



Please stop saying that:

https://en.wikipedia.org/wiki/This_(computer_programming)

this is more general than you think.

Re: Allowing "fall through" of attributes

[Lodovico Giaretta via Digitalmars-d-learn]

On Tuesday, 19 July 2016 at 16:50:56 UTC, Rufus Smith wrote:
On Tuesday, 19 July 2016 at 16:09:38 UTC, Lodovico Giaretta 
wrote:

On Tuesday, 19 July 2016 at 15:55:02 UTC, Rufus Smith wrote:
I have some functions that take other functions. I would like 
the attributes to be able to "fall" through so I get overload 
like behavior. I only care that I am passing a function, not 
if it is shared, extern(C), pure, @nogc, etc.


void foo(R, A...)(R function(A) bar)
{
   alias type = typeof(bar);
   pragma(msg, type);
   // does magic with bar
}

foo never uses the attributes of bar explicitly. It uses type 
to instantiate other functions like bar. I have to create a 
foo for each attribute combination, which is not worth while. 
The code seems to break only for extern, the best I can tell, 
most attributes do pass through. But type does not contain 
these attributes.


You shall do something like this (please note that I didn't 
check the docs while writing this; you shall definitely have a 
look at std.traits and consider the following as pseudo-code 
and not actual D):


void foo(Fun)(Fun bar)
if (isSomeFunction!Fun)   // your constraint that bar is a 
function

{
// how to get your R and A types, if you need them:
alias R = ReturnType!bar;
alias A = Parameters!bar;

alias type = Fun;
pragma(msg, type);

// do some magic
}


But this doesn't create a function with all the attributes of 
the original? Just one that has the same return type and 
parameters. What if Fun is pure or extern(C) or some other 
attributes? I'd like to create a function that is exactly the 
same in all regards as the original.


Sorry, I misunderstood your question.
With the method I showed you, if the function is @safe, pure, 
@nogc or nothrow, foo will infer those attributes. But only if 
the operations you do in foo (apart from calling bar) are 
themselves @safe, pure, @nogc or nothrow.
For other things, like extern(C), I don't think there's a simple 
solution; but I'm not an expert, so I hope someone else will give 
you a better answer.

Re: How to get the "this" ptr of a lambda inside the lambda?

[Steven Schveighoffer via Digitalmars-d-learn]

On 7/19/16 12:52 PM, Rufus Smith wrote:

On Tuesday, 19 July 2016 at 15:58:49 UTC, Steven Schveighoffer wrote:

On 7/19/16 11:25 AM, Rufus Smith wrote:

[...]


I think what Mike may be alluding to is that there is no name for the
stack frame pointer you can use. There is no 'this' pointer that you
can get at (even though it can be passed).

Also note that lambdas are not necessarily delegates, they could be
straight function pointers if they don't need a context:

void main()
{
int a;
pragma(msg, typeof((int b) => b * 2)); // int function(int b) pure
nothrow @nogc @safe
pragma(msg, typeof(() => a * 2)); // int delegate() pure nothrow
@nogc @safe
}



Yes, but then this = null. I matters not for my use case.


'this' is not null in either case. There is no 'this'.

There is probably a way to get the stack pointer. Take a look at the 
code in std.functional.toDelegate. 
http://dlang.org/phobos/std_functional.html#toDelegate


-Steve

Re: How to get the "this" ptr of a lambda inside the lambda?

[Rufus Smith via Digitalmars-d-learn]

On Tuesday, 19 July 2016 at 15:58:49 UTC, Steven Schveighoffer 
wrote:

On 7/19/16 11:25 AM, Rufus Smith wrote:

[...]


I think what Mike may be alluding to is that there is no name 
for the stack frame pointer you can use. There is no 'this' 
pointer that you can get at (even though it can be passed).


Also note that lambdas are not necessarily delegates, they 
could be straight function pointers if they don't need a 
context:


void main()
{
int a;
pragma(msg, typeof((int b) => b * 2)); // int function(int 
b) pure nothrow @nogc @safe
pragma(msg, typeof(() => a * 2)); // int delegate() pure 
nothrow @nogc @safe

}



Yes, but then this = null. I matters not for my use case.


A question to ask is, why do you need it?


Magic my friend! Magic!!!

Re: Allowing "fall through" of attributes

[Rufus Smith via Digitalmars-d-learn]

On Tuesday, 19 July 2016 at 16:09:38 UTC, Lodovico Giaretta wrote:

On Tuesday, 19 July 2016 at 15:55:02 UTC, Rufus Smith wrote:
I have some functions that take other functions. I would like 
the attributes to be able to "fall" through so I get overload 
like behavior. I only care that I am passing a function, not 
if it is shared, extern(C), pure, @nogc, etc.


void foo(R, A...)(R function(A) bar)
{
   alias type = typeof(bar);
   pragma(msg, type);
   // does magic with bar
}

foo never uses the attributes of bar explicitly. It uses type 
to instantiate other functions like bar. I have to create a 
foo for each attribute combination, which is not worth while. 
The code seems to break only for extern, the best I can tell, 
most attributes do pass through. But type does not contain 
these attributes.


You shall do something like this (please note that I didn't 
check the docs while writing this; you shall definitely have a 
look at std.traits and consider the following as pseudo-code 
and not actual D):


void foo(Fun)(Fun bar)
if (isSomeFunction!Fun)   // your constraint that bar is a 
function

{
// how to get your R and A types, if you need them:
alias R = ReturnType!bar;
alias A = Parameters!bar;

alias type = Fun;
pragma(msg, type);

// do some magic
}


But this doesn't create a function with all the attributes of the 
original? Just one that has the same return type and parameters. 
What if Fun is pure or extern(C) or some other attributes? I'd 
like to create a function that is exactly the same in all regards 
as the original.

[Issue 16291] phobosinit fails to register encodings on individual tests

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16291

--- Comment #3 from Steven Schveighoffer  ---
(In reply to Ketmar Dark from comment #2)
> aha. i see.
> 
> the thing is that std.internal.phobosinit is not imported from anywhere, so
> linker simply not including it in resulting executable!
> 

Well... That's weird.

I assumed module ctors would still be included, even if not imported. How the
hell does vibe.d work, where everything is set up in a module ctor?

> 
> i.e. we have to do "import std.internal.phobosinit;" in "std.encoding". but
> that defeats the purpose of moving the whole thing to separate module, i
> guess.

Yes, it does. I purposely removed all imports of phobosinit (was called
processinit, and std.process imported it) to avoid cycles.

> what was the idea behind moving that initialization to separate module? it
> seems that leaving it in std.encoding is not conflicting with anything: not
> one of phobos modules that imports "std.encoding" has module ctors.

There was a cycle between std.encoding and something else. The easiest thing to
do was to remove the constructors.

--

Re: Our docs should be more beautiful

[bitwise via Digitalmars-d]

On Tuesday, 19 July 2016 at 01:37:20 UTC, Andrei Alexandrescu 
wrote:

On 07/18/2016 06:13 PM, bitwise wrote:

Any chance of getting one definition or overload-set per page?


Been like that for a while, my comments refer to the old 
styling. -- Andrei


Why talk about the old style though? I don't see any of the 
problems you've mentioned in the new beta docs


http://dlang.org/library/std/algorithm/searching/balanced_parens.html

Bit

Re: Atila Neves: "C IS NOT MAGICALLY FAST, PART 2"

[Steven Schveighoffer via Digitalmars-d]

On 7/19/16 11:48 AM, Atila Neves wrote:

On Tuesday, 19 July 2016 at 15:28:45 UTC, Johan Engelen wrote:

On Tuesday, 19 July 2016 at 10:07:11 UTC, Atila Neves wrote:

[...]


Very interested to hear why one is faster than the other.


[...]


The strings seem a little short, e.g. "foo1234foo" if I understand
correctly.
Could there be a performance hit in C++ due to small-string
optimization ? (Don't know if it is done at all, nor what the
threshold is)



Small string optimization should _help_ std::string, no?


You can use strncmp, or strcmp and ensure a null terminator is always 
there in your C++ version.


That will use std::string semantics for swapping, but strcmp for comparison.

-Steve

Re: Atila Neves: "C IS NOT MAGICALLY FAST, PART 2"

[Atila Neves via Digitalmars-d]

On Tuesday, 19 July 2016 at 16:01:01 UTC, Lodovico Giaretta wrote:

On Tuesday, 19 July 2016 at 15:48:26 UTC, Atila Neves wrote:

Small string optimization should _help_ std::string, no?

Atila


Small string optimization will make the struct bigger, thus 
making swapping slower. If the struct is no bigger than 2 
pointers, swapping it is ultra fast.


Interesting. Read up on it and tried changing the strings to be 
~50 chars long. C++/std::string gets better, but C++/const char* 
still beats D by a small margin:


C: 1.852s
C++/std::string: 1.489s
C++/const char*: 1.034s
D: 1.188s

Could be the cost of swapping the "fat" in "fat pointer", in 
which case: worth it.


Atila

Re: Our docs should be more beautiful

[Mattcoder via Digitalmars-d]

On Tuesday, 19 July 2016 at 01:38:54 UTC, Andrei Alexandrescu 
wrote:

...

http://i.imgur.com/UTLpK42.png

PS: Click to see the full image.


I like the styling on the right - the vertical spacing between 
paragraph is ridiculous in the left version, and the "Jump to:" 
box is too tall. -- Andrei


This is why I don't go through this and help on this matter, I 
mean the layout is too subjective, I think the left version 
(Which was changed by my friend) is much better to read than the 
version on the right.


Another thing: using "font-weight" or "bold" sometimes looks 
weird on high resolutions, which was avoided on the left, maybe 
is not too visible here but anyway...


And finally: Keep in mind that some folks (like myself) use 
Tablet to read manuals, and the font size matters a lot on tiny 
screens.


By the way, this is not a rant, :) I'm just saying that making 
layout for others is something that I don't like because the 
different tastes.


Mattcoder.

Re: Allowing "fall through" of attributes

[Lodovico Giaretta via Digitalmars-d-learn]

On Tuesday, 19 July 2016 at 15:55:02 UTC, Rufus Smith wrote:
I have some functions that take other functions. I would like 
the attributes to be able to "fall" through so I get overload 
like behavior. I only care that I am passing a function, not if 
it is shared, extern(C), pure, @nogc, etc.


void foo(R, A...)(R function(A) bar)
{
   alias type = typeof(bar);
   pragma(msg, type);
   // does magic with bar
}

foo never uses the attributes of bar explicitly. It uses type 
to instantiate other functions like bar. I have to create a foo 
for each attribute combination, which is not worth while. The 
code seems to break only for extern, the best I can tell, most 
attributes do pass through. But type does not contain these 
attributes.


You shall do something like this (please note that I didn't check 
the docs while writing this; you shall definitely have a look at 
std.traits and consider the following as pseudo-code and not 
actual D):


void foo(Fun)(Fun bar)
if (isSomeFunction!Fun)   // your constraint that bar is a 
function

{
// how to get your R and A types, if you need them:
alias R = ReturnType!bar;
alias A = Parameters!bar;

alias type = Fun;
pragma(msg, type);

// do some magic
}

Re: Atila Neves: "C IS NOT MAGICALLY FAST, PART 2"

[Lodovico Giaretta via Digitalmars-d]

On Tuesday, 19 July 2016 at 15:48:26 UTC, Atila Neves wrote:

Small string optimization should _help_ std::string, no?

Atila


Small string optimization will make the struct bigger, thus 
making swapping slower. If the struct is no bigger than 2 
pointers, swapping it is ultra fast.

Re: strange bug: (not) calling module ctors; help with "master" needed

[ketmar via Digitalmars-d-learn]

On Tuesday, 19 July 2016 at 15:18:20 UTC, Steven Schveighoffer 
wrote:

Please add what you can to the report.


ok, i found why it doesn't work with static libs. not sure what 
to do next, though... added the info to bugzilla.

Re: How to get the "this" ptr of a lambda inside the lambda?

[Steven Schveighoffer via Digitalmars-d-learn]

On 7/19/16 11:25 AM, Rufus Smith wrote:

On Tuesday, 19 July 2016 at 06:46:44 UTC, Mike Parker wrote:

On Tuesday, 19 July 2016 at 06:32:32 UTC, Rufus Smith wrote:

Error: 'this' is only defined in non-static member functions, not
__lambda2

Lambda's are delegates and delegates have a "this" type of pointer. I
would like to get at it inside the lambda to check for some things.
I'm doing some funky stuff. I'm not concerned about the scope or what
this actually pointers to or anything like that, just need it's value
for debugging.



No, delegates do not have a "this" type of pointer. "this" is an
implicit function parameter in a class or struct member function.
Delegates have no such thing. The only generic way I know of to get at
a delegate's function pointer inside the implementation is to
explicitly add the pointer type to the parameter list as part of the
declaration and pass it as an argument when you call the delegate.


Delegates do have a this, they have a context pointer that is implicitly
passed and used to access the outside context. It is no different than
methods. Just because the explicit implementation details are different
does not change the underlying meaning.



I think what Mike may be alluding to is that there is no name for the 
stack frame pointer you can use. There is no 'this' pointer that you can 
get at (even though it can be passed).


Also note that lambdas are not necessarily delegates, they could be 
straight function pointers if they don't need a context:


void main()
{
int a;
pragma(msg, typeof((int b) => b * 2)); // int function(int b) pure 
nothrow @nogc @safe
pragma(msg, typeof(() => a * 2)); // int delegate() pure nothrow 
@nogc @safe

}

A question to ask is, why do you need it?

-Steve

Allowing "fall through" of attributes

[Rufus Smith via Digitalmars-d-learn]

I have some functions that take other functions. I would like the 
attributes to be able to "fall" through so I get overload like 
behavior. I only care that I am passing a function, not if it is 
shared, extern(C), pure, @nogc, etc.


void foo(R, A...)(R function(A) bar)
{
   alias type = typeof(bar);
   pragma(msg, type);
   // does magic with bar
}

foo never uses the attributes of bar explicitly. It uses type to 
instantiate other functions like bar. I have to create a foo for 
each attribute combination, which is not worth while. The code 
seems to break only for extern, the best I can tell, most 
attributes do pass through. But type does not contain these 
attributes.

Re: Atila Neves: "C IS NOT MAGICALLY FAST, PART 2"

[Atila Neves via Digitalmars-d]

On Tuesday, 19 July 2016 at 15:28:45 UTC, Johan Engelen wrote:

On Tuesday, 19 July 2016 at 10:07:11 UTC, Atila Neves wrote:

[...]


Very interested to hear why one is faster than the other.


[...]


The strings seem a little short, e.g. "foo1234foo" if I 
understand correctly.
Could there be a performance hit in C++ due to small-string 
optimization ? (Don't know if it is done at all, nor what the 
threshold is)



Small string optimization should _help_ std::string, no?

Atila

Re: Atila Neves: "C IS NOT MAGICALLY FAST, PART 2"

[Atila Neves via Digitalmars-d]

On Tuesday, 19 July 2016 at 14:39:54 UTC, Sönke Ludwig wrote:

Am 19.07.2016 um 12:07 schrieb Atila Neves:

On Tuesday, 19 July 2016 at 02:54:37 UTC, Saurabh Das wrote:


Posted on Atila's blog yesterday:

https://atilanevesoncode.wordpress.com/2016/07/18/c-is-not-magically-fast-part-2/



So, about D vs C++ there... last night for reasons I forget I 
tried
replacing std::string with const char* in the C++ version, and 
then it

got faster than D. I don't know why.

At first I thought std::string was being copied instead of 
being moved,
but some static_asserts made me doubt that. Either way, 
there's no good
reason I can think of for C++ to magically speed up for const 
char*. Hmm :(


Atila


One thing that the D version does and the others don't is 
comparing UTF code points instead of bytes.


I considered that too so I cast them to ubyte[]. No difference.

Re: Atila Neves: "C IS NOT MAGICALLY FAST, PART 2"

[Atila Neves via Digitalmars-d]

On Tuesday, 19 July 2016 at 10:39:26 UTC, Jakob Bornecrantz wrote:

On Tuesday, 19 July 2016 at 10:07:11 UTC, Atila Neves wrote:

On Tuesday, 19 July 2016 at 02:54:37 UTC, Saurabh Das wrote:


Posted on Atila's blog yesterday:

https://atilanevesoncode.wordpress.com/2016/07/18/c-is-not-magically-fast-part-2/


So, about D vs C++ there... last night for reasons I forget I 
tried replacing std::string with const char* in the C++ 
version, and then it got faster than D. I don't know why.


At first I thought std::string was being copied instead of 
being moved, but some static_asserts made me doubt that. 
Either way, there's no good reason I can think of for C++ to 
magically speed up for const char*. Hmm :(


Atila


What is the sizeof(Foo) for all of the cases?


C and C++ const char*: 16
C++ std::string: 64
D: 24



What does "charPtr < charPtr" do in C++ compared to std::string?


I used strcmp for const char* in C++.

Atila

Re: Atila Neves: "C IS NOT MAGICALLY FAST, PART 2"

[Andrei Alexandrescu via Digitalmars-d]

On 07/18/2016 10:54 PM, Saurabh Das wrote:


Posted on Atila's blog yesterday:

https://atilanevesoncode.wordpress.com/2016/07/18/c-is-not-magically-fast-part-2/


https://www.reddit.com/r/programming/comments/4tlqyc/c_is_not_magically_fast_twopart_article/


Andrei

Re: Passing a single tuple or multiple values

[Lodovico Giaretta via Digitalmars-d-learn]

On Tuesday, 19 July 2016 at 15:36:42 UTC, Lodovico Giaretta wrote:
As you have to do `isTuple!(T[0])`, you also have to do 
`x[0].expand`.
That's because T... works "as if" it was an array of types, and 
x, being of type T, it works "as if" it was an array of values. 
So you have to use an index in both cases.


You can find this out from the error, which says that you can't 
expand an object of type `(Tuple!(int, int))`. Note the 
surrounding parenthesis: they tell you that what you have is not 
a Tuple, but an AliasSeq whose only member is a Tuple. If you do 
`[0]` on it, you obtain the correct type, i.e. `Tuple!(int, 
int)`, without the parenthesis.

Re: Passing a single tuple or multiple values

[Lodovico Giaretta via Digitalmars-d-learn]

On Tuesday, 19 July 2016 at 13:33:41 UTC, jmh530 wrote:

On Tuesday, 19 July 2016 at 07:23:52 UTC, John wrote:


auto bar(T...)(T x)
{
  static if (T.length == 1 && isTuple!(T[0]))
return foo(x.expand);
  else
return foo(x);
}



Hmm, this actually doesn't seem to be resolving my issue. I'm 
still getting the error about not being able to expand x.


I tried it like below and got the same error.

auto bar(T...)(T x)
{
static if (T.length > 1)
{
return foo(x);
}
else static if (T.length == 1 && isTuple!(T))
{
return foo(x.expand);
}
}


As you have to do `isTuple!(T[0])`, you also have to do 
`x[0].expand`.
That's because T... works "as if" it was an array of types, and 
x, being of type T, it works "as if" it was an array of values. 
So you have to use an index in both cases.

Re: Atila Neves: "C IS NOT MAGICALLY FAST, PART 2"

[Johan Engelen via Digitalmars-d]

On Tuesday, 19 July 2016 at 10:07:11 UTC, Atila Neves wrote:

On Tuesday, 19 July 2016 at 02:54:37 UTC, Saurabh Das wrote:


Posted on Atila's blog yesterday:

https://atilanevesoncode.wordpress.com/2016/07/18/c-is-not-magically-fast-part-2/


So, about D vs C++ there... last night for reasons I forget I 
tried replacing std::string with const char* in the C++ 
version, and then it got faster than D. I don't know why.


Very interested to hear why one is faster than the other.

At first I thought std::string was being copied instead of 
being moved, but some static_asserts made me doubt that. Either 
way, there's no good reason I can think of for C++ to magically 
speed up for const char*. Hmm :(


The strings seem a little short, e.g. "foo1234foo" if I 
understand correctly.
Could there be a performance hit in C++ due to small-string 
optimization ? (Don't know if it is done at all, nor what the 
threshold is)

Re: strange bug: (not) calling module ctors; help with "master" needed

[ketmar via Digitalmars-d-learn]

On Tuesday, 19 July 2016 at 15:18:20 UTC, Steven Schveighoffer 
wrote:

It's affecting phobos devs too, we are aware of the issue:

https://issues.dlang.org/show_bug.cgi?id=16291


i see, thank you. my searching foo failed to find that issue.

i guess i have to use digger to find the commit that broke 
that... oh...

Re: How to get the "this" ptr of a lambda inside the lambda?

[Rufus Smith via Digitalmars-d-learn]

On Tuesday, 19 July 2016 at 06:46:44 UTC, Mike Parker wrote:

On Tuesday, 19 July 2016 at 06:32:32 UTC, Rufus Smith wrote:
Error: 'this' is only defined in non-static member functions, 
not __lambda2	


Lambda's are delegates and delegates have a "this" type of 
pointer. I would like to get at it inside the lambda to check 
for some things. I'm doing some funky stuff. I'm not concerned 
about the scope or what this actually pointers to or anything 
like that, just need it's value for debugging.




No, delegates do not have a "this" type of pointer. "this" is 
an implicit function parameter in a class or struct member 
function. Delegates have no such thing. The only generic way I 
know of to get at a delegate's function pointer inside the 
implementation is to explicitly add the pointer type to the 
parameter list as part of the declaration and pass it as an 
argument when you call the delegate.


Delegates do have a this, they have a context pointer that is 
implicitly passed and used to access the outside context. It is 
no different than methods. Just because the explicit 
implementation details are different does not change the 
underlying meaning.

[Issue 16291] phobosinit fails to register encodings on individual tests

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16291

Ketmar Dark  changed:

   What|Removed |Added

 CC||ket...@ketmar.no-ip.org

--- Comment #1 from Ketmar Dark  ---
it seems that at least for x86 GNU/Linux ctor is called if i'm using
libphobos2.so instead of libphobos2.a. i inserted printf there, and yes: with
static phobos ctor is skipped, but with .so phobos it is called.

i found this not with test, but in my own app, which mysteriously stopped
working when i linked it with static phobos.

--

Re: Vision for the D language - stabilizing complexity?

[Andrew Godfrey via Digitalmars-d]

On Tuesday, 19 July 2016 at 09:49:50 UTC, Chris wrote:

On Monday, 18 July 2016 at 18:03:49 UTC, Mathias Lang wrote:
2016-07-18 15:48 GMT+02:00 Andrew Godfrey via Digitalmars-d < 
digitalmars-d@puremagic.com>:








I've never seen a definitive "No" to breaking changes.
We do breaking changes all the time. Did everyone already 
forget what the
latest release (2.071.0) was about ? Revamping the import 
system, one of

the core component of the language.
But it took a lot of time, and experience, to do it. It did 
deprecate
patterns people were using for a long time before (e.g. 
inheriting
imports), but its a (almost) consistent and principled 
implementation.


Although it can be a PITA, people accept breaking changes, if 
they really make sense.


Way too often I see suggestions for a change with one (or 
more) of the

following mistakes:
- Want to bring a specific construct in the language rather 
than achieve a

goal
- Only consider the pros of such a proposal and completely 
skip any cons

analysis
- Focus on one single change without considering how it could 
affect the

whole language


That's also my impression. Given that D is open source I'm 
surprised that nobody has grabbed it and come up with a 
prototype of D3 or whatever. How else could you prove your 
case? After all the onus of proof is on the one who proposes a 
change. Don't just sit and wait until Walter says "Go ahead", 
knowing full well that the core devs are in no position to 
dedicate time to D3 at the moment - that's too easy and it gets 
us nowhere.


But I've never seen someone willing to put the effort in a 
proposal to

improve the language be turned away.
In fact, our review process for language change was recently 
updated as
well to make it more accessible and save everyone's time. If 
it's not a
commitment for continuous improvement of the language, I don't 
know what it

is.


We all seem to be in agreement that people often make 
breaking-change proposals without considering the impact 
properly. I have seen this many times on the forums and not once 
(so far) has the reply been simply, "please go and read the 
section of our vision doc that talks about breaking changes".


I'm suggesting that is what should happen. Instead, I have seen 
each time a disussion thread that explores only parts of the 
topic of breaking changes, and does so badly. Just like earlier 
in this thread, where I mentined dfixable breaking changes and 
Walter implied that even though a would cause people to have to 
manually rewrite.


(This example is a specific bias I have noticed in other threads: 
arguing about a breaking change without evaluating whether it is 
dfixable).

Re: Atila Neves: "C IS NOT MAGICALLY FAST, PART 2"

[Jack Stouffer via Digitalmars-d]

On Tuesday, 19 July 2016 at 15:05:30 UTC, Kagamin wrote:

On Tuesday, 19 July 2016 at 14:39:54 UTC, Sönke Ludwig wrote:
One thing that the D version does and the others don't is 
comparing UTF code points instead of bytes.


Are you sure? Autodecoding is a phobos feature, but here 
druntime is used for string comparison, and it usually doesn't 
provide autodecoding.


Yeah, auto-decoding isn't at play here.

Re: strange bug: (not) calling module ctors; help with "master" needed

[Steven Schveighoffer via Digitalmars-d-learn]

On 7/19/16 11:08 AM, ketmar wrote:

i'm using git master (updated daily), and recently found very strange
thing.

when i'm linking my programs with libphobos2.a, module ctor from
"std.internal.phobosinit" is not called, but when i'm linking with .so,
everything is ok.

it is easy to check: `EncodingScheme.create("utf-8")` will fail if ctor
is not called (as all that ctor does currently is registering codecs
from std.encoding).

i guess that not many people is using that, so it may slip unnoticed for
some time. that, or something is very wrong with my local system (which
is possible too, of course).

so please, if somebody can build dmd master and check it to confirm (i
hope ;-) the results, i'd be very grateful.

my system is 32-bit GNU/Linux, with gold linker.

switching between libs is done in dmd.conf, with:
DFLAGS=-defaultlib=libphobos2.a
or
DFLAGS=-defaultlib=libphobos2.so


It's affecting phobos devs too, we are aware of the issue:

https://issues.dlang.org/show_bug.cgi?id=16291

Please add what you can to the report.

-Steve

Re: Battle-plan for CTFE

[Stefan Koch via Digitalmars-d-announce]

On Sunday, 17 July 2016 at 16:43:18 UTC, Rory McGuire wrote:


Nice, so I'll be able to see separate improvements in my CTFE 
stuff vs the pegged template stuff once structs,  classes, 
etc.. are handled in your new ctfe.


Yes.
Btw while working on printing template-instantiations I 
discovered that ctfe improvements will most likely have a much 
higher impact in template heavy code then I fist expected.

Re: Atila Neves: "C IS NOT MAGICALLY FAST, PART 2"

[Kagamin via Digitalmars-d]

On Tuesday, 19 July 2016 at 14:39:54 UTC, Sönke Ludwig wrote:
One thing that the D version does and the others don't is 
comparing UTF code points instead of bytes.


Are you sure? Autodecoding is a phobos feature, but here druntime 
is used for string comparison, and it usually doesn't provide 
autodecoding.

strange bug: (not) calling module ctors; help with "master" needed

[ketmar via Digitalmars-d-learn]

i'm using git master (updated daily), and recently found very 
strange thing.


when i'm linking my programs with libphobos2.a, module ctor from 
"std.internal.phobosinit" is not called, but when i'm linking 
with .so, everything is ok.


it is easy to check: `EncodingScheme.create("utf-8")` will fail 
if ctor is not called (as all that ctor does currently is 
registering codecs from std.encoding).


i guess that not many people is using that, so it may slip 
unnoticed for some time. that, or something is very wrong with my 
local system (which is possible too, of course).


so please, if somebody can build dmd master and check it to 
confirm (i hope ;-) the results, i'd be very grateful.


my system is 32-bit GNU/Linux, with gold linker.

switching between libs is done in dmd.conf, with:
DFLAGS=-defaultlib=libphobos2.a
or
DFLAGS=-defaultlib=libphobos2.so

Re: Atila Neves: "C IS NOT MAGICALLY FAST, PART 2"

[Sönke Ludwig via Digitalmars-d]

Am 19.07.2016 um 12:07 schrieb Atila Neves:

On Tuesday, 19 July 2016 at 02:54:37 UTC, Saurabh Das wrote:


Posted on Atila's blog yesterday:

https://atilanevesoncode.wordpress.com/2016/07/18/c-is-not-magically-fast-part-2/



So, about D vs C++ there... last night for reasons I forget I tried
replacing std::string with const char* in the C++ version, and then it
got faster than D. I don't know why.

At first I thought std::string was being copied instead of being moved,
but some static_asserts made me doubt that. Either way, there's no good
reason I can think of for C++ to magically speed up for const char*. Hmm :(

Atila


One thing that the D version does and the others don't is comparing UTF 
code points instead of bytes.

Re: Atila Neves: "C IS NOT MAGICALLY FAST, PART 2"

[bigsandwich via Digitalmars-d]

On Tuesday, 19 July 2016 at 10:07:11 UTC, Atila Neves wrote:

On Tuesday, 19 July 2016 at 02:54:37 UTC, Saurabh Das wrote:


Posted on Atila's blog yesterday:

https://atilanevesoncode.wordpress.com/2016/07/18/c-is-not-magically-fast-part-2/


So, about D vs C++ there... last night for reasons I forget I 
tried replacing std::string with const char* in the C++ 
version, and then it got faster than D. I don't know why.


At first I thought std::string was being copied instead of 
being moved, but some static_asserts made me doubt that. Either 
way, there's no good reason I can think of for C++ to magically 
speed up for const char*. Hmm :(


Atila


C++ Swap may be specialized for POD.

Re: new cpuid is ready for comments

[Guillaume Chatelet via Digitalmars-d-announce]

On Monday, 11 July 2016 at 16:30:44 UTC, Ilya Yaroshenko wrote:

Hello :-)

`cpuid` package is core.cpuid analog.
It would be used by future D BLAS implementation.

Why it is better?
See
https://github.com/libmir/cpuid#api-features
https://github.com/libmir/cpuid#implementation-features
https://issues.dlang.org/show_bug.cgi?id=16028

Please report your CPU (GitHub/Gist):

```
dub fetch cpuid
dub test cpuid
```
... AMD was not tested at all and I hope to see your reports.

ARM contributors are wanted!

Destroy!

Best regards,
Ilya


Docs: http://docs.cpuid.dlang.io
GitHub: https://github.com/libmir/cpuid
Dub: cpuid


Also: Intel(R) Atom(TM) CPU 230 @ 1.60GHz
https://gist.github.com/gchatelet/d3d347e4630ec2567eae7fe0391a9316

Re: returning constant references from class methods

[celavek via Digitalmars-d-learn]

On Tuesday, 19 July 2016 at 12:33:53 UTC, ag0aep6g wrote:


final const(ulong[char]) nucleotide_counts () const
{
return cached_counts;
}


OMG! I'm so blind.
Never thought of trying the obvious way.

Thank you

Re: Phobos doc anchors not friendly for keyboard-centric browsers

[rcorre via Digitalmars-d]

On Tuesday, 19 July 2016 at 13:33:28 UTC, Jack Stouffer wrote:

On Tuesday, 19 July 2016 at 13:27:37 UTC, qznc wrote:
I don't understand, the anchor link doesn't go anywhere. It's 
to provide a perma-link to that piece of documentation so you 
can direct link to it somewhere else.


My guess: "every clickable element has a series of keys shown 
above it". The permalinks are not clickable unless you hover 
above, thus no "hinting", thus not useable by keyboard-centric 
browsers.


Maybe have it always visible and float to the right?


I know why he can't click them, I don't understand why it's a 
problem.


Suppose I want to link someone to a function doc. I'd go to the 
doc page, press ';y' (which activates hint yank mode), and then 
the keys for the anchor. This would yank the anchor URL to my 
clipboard so i could paste it in my answer. But this won't work 
because the anchor isn't shown unless I hover it with the mouse, 
which breaks my flow.


It's a small thing and I'm probably in a minority who work like 
this, but it would be nice to have unless there's a good reason 
to hide the anchors. I seem to remember before that you could 
click the function name to get an anchor link.

Re: counting characters

[celavek via Digitalmars-d-learn]

Thank you!

That clarified a lot of things for me.

Re: LDC with ARM backend

[Claude via Digitalmars-d-learn]

On Friday, 15 July 2016 at 15:24:36 UTC, Kai Nacke wrote:
There is a reason why we do not distribute a binary version of 
LDC with all LLVM targets enabled. LDC still uses the real 
format of the host. This is different on ARM (80bit on 
Linux/x86 vs. 64bit on Linux/ARM). Do not expect that 
applications using real type work correctly.
(The Windows version of LDC uses 64bit reals. The binary build 
has the ARM target enabled.)


Regards,
Kai


Hello Kai,

Thanks for your answer.

From the link https://wiki.dlang.org/Build_LDC_for_Android , I 
did exactly the same steps described in section "Compile LLVM" 
(patch applied).


At section "Build ldc for Android/ARM", I did it quite the same. 
I applied the patch ldc_1.0.0_android_arm, but changed 
runtime/CMakeList.txt, instead of using Android specific stuff, I 
did:



Line 15:
set(D_FLAGS   -w;-mtriple=arm-none-linux-gnueabi  
  CACHE STRING  "Runtime build flags, separated by ;")


Line 505:
#
# Set up build targets.
#
set(RT_CFLAGS "-g")
set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_C_COMPILER 
/opt/arm-2009q1/bin/arm-none-linux-gnueabi-gcc)
set(CMAKE_CXX_COMPILER 
/opt/arm-2009q1/bin/arm-none-linux-gnueabi-c++)




On the command line, I aliased DMD to /usr/bin/dmd and runt cmake 
as described...


Afterwards, I ran make for ldc2, phobos2-ldc an druntime-ldc, but 
I did not apply the patches on phobos and runtime. It looked like 
the path introduced some static compilation towards Android, so I 
thought it would not apply to my needs.


So here' what I get if I do a "ldc2 -version":


LDC - the LLVM D compiler (1.0.0):
  based on DMD v2.070.2 and LLVM 3.8.1
  built with DMD64 D Compiler v2.071.1
  Default target: x86_64-unknown-linux-gnu
  Host CPU: westmere
  http://dlang.org - http://wiki.dlang.org/LDC

  Registered Targets:
arm - ARM
armeb   - ARM (big endian)
thumb   - Thumb
thumbeb - Thumb (big endian)



I can strictly compile a "hello world" program:
./bin/ldc2 -mtriple=arm-none-linux-gnueabi test.d

I get the expected "test.o"

But I don't know how to link it. I don't have "clang". I tried to 
link it with the gcc from the gnu ARM toolchain with 
libdruntime-ldc.a, libldc.a and libphobos2-ldc.a, but it fails 
miserably: many undefined symbols (pthread, and some other os 
related stuff).

Re: counting characters

[Jonathan M Davis via Digitalmars-d-learn]

On Tuesday, July 19, 2016 12:23:11 celavek via Digitalmars-d-learn wrote:
> On Tuesday, 19 July 2016 at 09:57:27 UTC, Lodovico Giaretta wrote:
> > On Tuesday, 19 July 2016 at 09:42:40 UTC, celavek wrote:
> >
> > Works for me:
> >
> > size_t[char] counts;
> > const string dna_chain =
> > "AGCCATTCTGACTGCAACGGGCAATATGTCTCTGTGTGGATTAAAGAGTGTCTGATAGCAGC";
> > counts['A'] = countchars(dna_chain, "A");
>
> It was failing for me as I was using "countchars!". I thought
> that I should use the "!" in order to instantiate a template in
> D. I'm still confused why it is working without the "!". Anyway
> the compiler message was not very helpful.

! is required for explicit template instantiation, but with functions, you
have use IFTI - Implicit Function Template Instantiation. So, when you have
a function like

auto foo(T)(T bar) {...}

and you call it without a template argument

foo(42);

the compiler infers the type. You can also explicitly instantiate it if you
want to

foo!int(42);

Many functions in Phobos have a template argument which is expected to be
explicit (one which is not the type of any of the function's parameters)
whereas all of the ones associated with the function's parameters are
inferred. e.g.

auto result = map!(a => a % 5)([12, 14, 15]);

map takes a template argument for the function that it calls on each of the
elements in the range it's given, and it takes a function argument that is
the range that's being operated on, and while the type of that range is
indeed a template argument, it's inferred by the compiler rather than being
explicitly given by the programmer. You _could_ give it explicitly, but
there really isn't a reason to, and the code is a lot uglier if you do.

In the case of countchars, you attempted to give the function arguments as
template arguments

size_t countchars(S, S1)(S s, in S1 pattern) @safe pure @nogc
if (isSomeString!S && isSomeString!S1)
{...}

If you do

countchars!(dna_chain, 'A')

then S and S1 are then the template arguments, and they're used as the types
of the function parameters, which doesn't work, since they're not types;
they don't pass the template constraint either (since neither of them is a
type which is a string - they're an actual string and a character, not
types). And to make matters worse, there are then no function arguments. So,
countchars is being given bogus types, the template arguments fail the
template constraint, and it's not being given the function arguments that it
needs.

So, the error is definitely telling you what's going wrong (or at least part
of it) - that the template arguments don't match the template constraint -
but your understanding of D's templates seems to be low enough that I
suppose that it's no surprise that the error message is confusing. I expect
that the reason that it's specifically the template constraints which are
complained about rather than the lack of function arguments or that the
template arguments aren't even types when they're then used as types for the
function parameters is because when you declare

size_t countchars(S, S1)(S s, in S1 pattern) @safe pure @nogc
if (isSomeString!S && isSomeString!S1)
{...}

the compiler lowers it to

template countchars(S, S1)
if (isSomeString!S && isSomeString!S1)
{
size_t countchars(S s, in S1 pattern) @safe pure @nogc
{...}
}

and that's going to fail to compile at the template constraint before it
even looks at the function, because isSomeString is not true for either
dna_chain or 'A' (even if it would be true for the _type_ of dna_chain, it's
not true for dna_chain itself).

If you haven't already, I would suggest that you read

http://ddili.org/ders/d.en/index.html

I expect that the section

http://ddili.org/ders/d.en/templates.html

would be the most relevant to this discussion, but the book a as a whole
would be good to read if you're new to D.

- Jonathan M Davis

Re: Phobos doc anchors not friendly for keyboard-centric browsers

[Jack Stouffer via Digitalmars-d]

On Tuesday, 19 July 2016 at 13:27:37 UTC, qznc wrote:
I don't understand, the anchor link doesn't go anywhere. It's 
to provide a perma-link to that piece of documentation so you 
can direct link to it somewhere else.


My guess: "every clickable element has a series of keys shown 
above it". The permalinks are not clickable unless you hover 
above, thus no "hinting", thus not useable by keyboard-centric 
browsers.


Maybe have it always visible and float to the right?


I know why he can't click them, I don't understand why it's a 
problem.

Re: counting characters

[Steven Schveighoffer via Digitalmars-d-learn]

On 7/19/16 8:23 AM, celavek wrote:

On Tuesday, 19 July 2016 at 09:57:27 UTC, Lodovico Giaretta wrote:

On Tuesday, 19 July 2016 at 09:42:40 UTC, celavek wrote:

Works for me:

size_t[char] counts;
const string dna_chain =
"AGCCATTCTGACTGCAACGGGCAATATGTCTCTGTGTGGATTAAAGAGTGTCTGATAGCAGC";
counts['A'] = countchars(dna_chain, "A");


It was failing for me as I was using "countchars!". I thought that I
should use the "!" in order to instantiate a template in D. I'm still
confused why it is working without the "!". Anyway the compiler message
was not very helpful.


https://dlang.org/spec/template.html#function-templates

Check out the section a little bit down that talks about implicitly 
deduced template parameters.


-Steve

Re: Passing a single tuple or multiple values

[jmh530 via Digitalmars-d-learn]

On Tuesday, 19 July 2016 at 07:23:52 UTC, John wrote:


auto bar(T...)(T x)
{
  static if (T.length == 1 && isTuple!(T[0]))
return foo(x.expand);
  else
return foo(x);
}



Hmm, this actually doesn't seem to be resolving my issue. I'm 
still getting the error about not being able to expand x.


I tried it like below and got the same error.

auto bar(T...)(T x)
{
static if (T.length > 1)
{
return foo(x);
}
else static if (T.length == 1 && isTuple!(T))
{
return foo(x.expand);
}
}

Re: Phobos doc anchors not friendly for keyboard-centric browsers

[qznc via Digitalmars-d]

On Tuesday, 19 July 2016 at 13:16:52 UTC, Jack Stouffer wrote:

On Tuesday, 19 July 2016 at 11:38:20 UTC, rcorre wrote:
Keyboard-centric browsers (e.g. qutebrowser [1], dwb [2], 
ect.) generally let you click on links via 'hinting'. You 
press a button (e.g. 'f' for 'follow'), every clickable 
element has a series of keys shown above it, and you press 
those keys to follow that link (just look at some of the 
screenshots for the linked browsers).


The (kinda) new anchor links in the phobos docs don't work 
well with this, as they require me to mouse over the element 
for them to show up (and having to use the mouse defeats the 
purpose of a keyboard-centric browser).


Is there any reason for this design? Would it hurt to show the 
anchor all the time? If nothing else it would make the anchors 
more discoverable.


I don't understand, the anchor link doesn't go anywhere. It's 
to provide a perma-link to that piece of documentation so you 
can direct link to it somewhere else.


My guess: "every clickable element has a series of keys shown 
above it". The permalinks are not clickable unless you hover 
above, thus no "hinting", thus not useable by keyboard-centric 
browsers.


Maybe have it always visible and float to the right?

Re: Phobos doc anchors not friendly for keyboard-centric browsers

[Jack Stouffer via Digitalmars-d]

On Tuesday, 19 July 2016 at 11:38:20 UTC, rcorre wrote:
Keyboard-centric browsers (e.g. qutebrowser [1], dwb [2], ect.) 
generally let you click on links via 'hinting'. You press a 
button (e.g. 'f' for 'follow'), every clickable element has a 
series of keys shown above it, and you press those keys to 
follow that link (just look at some of the screenshots for the 
linked browsers).


The (kinda) new anchor links in the phobos docs don't work well 
with this, as they require me to mouse over the element for 
them to show up (and having to use the mouse defeats the 
purpose of a keyboard-centric browser).


Is there any reason for this design? Would it hurt to show the 
anchor all the time? If nothing else it would make the anchors 
more discoverable.


I don't understand, the anchor link doesn't go anywhere. It's to 
provide a perma-link to that piece of documentation so you can 
direct link to it somewhere else.

Re: returning constant references from class methods

[Kagamin via Digitalmars-d-learn]

On Tuesday, 19 July 2016 at 12:30:49 UTC, celavek wrote:

final ulong[char] nucleotide_counts () const
{
return cached_counts;
}


BTW you can find enumap useful 
https://forum.dlang.org/post/hloitwqnisvtgfoug...@forum.dlang.org 
if you want to have small associative arrays with enum keys.