Customization of DUB build=DDOX output
Hello, I'm trying to use DDOX to generate documentation pages for my library (dlangui). dub --build=ddox produces nice output with navigation by modules, but I cannot find out how to embed some custom navigation pane on all pages. E.g. put links to some additional pages like downloads, screenshots, github... Is it possible to do it using dub+ddox build? Best regards, Vadim
Re: mixin template and const property qualifier?
On Monday, 15 December 2014 at 23:21:05 UTC, anonymous wrote:
On Monday, 15 December 2014 at 23:14:30 UTC, aldanor wrote:
Could someone please explain why the following doesn't compile
with "const" qualifier while it does work without it?
/* test.d */
module test;
mixin template Foo() {
mixin("@property int bar() const { return foo; }");
}
int foo = 1;
mixin Foo;
unittest {
assert(foo == bar);
}
rdmd -main -unittest test.d
test.d-mixin-4(4): Error: function test.Foo!().bar without
'this' cannot be const
test.d(9): Error: mixin test.Foo!() error instantiating
Has nothing to do with mixin. This produces the same error
message:
@property int bar() const { return foo; }
int foo = 1;
unittest {assert(foo == bar);}
The thing is, free functions cannot be const. In a const method,
what's const is `this`. A free function doesn't have `this`, so
it cannot be const.
Indeed... thanks!
Re: Odd Error Message
On Monday, 15 December 2014 at 22:20:53 UTC, ketmar via
Digitalmars-d-learn wrote:
On Mon, 15 Dec 2014 22:09:28 +
CraigDillabaugh via Digitalmars-d-learn
wrote:
Given the following program:
import std.string;
import std.stdio;
void main()
{
File file = File("blah.txt", "r");
while( !(file.eof()) && count > 10 ) { //line 8
//
}
}
I get the error message:
line(8): Error: void has no value
If I comment out the import std.string; then I get an error I
would expect.
line(8): Error: undefined identifier count
There is no 'count' symbol that I can see in std.string.
there is public import from std.algorithm inside std.string, so
what
you see is about std.algorithm.count.
Would this error message be considered a compiler bug?
i don't think so. compiler tries to instantiate
std.algorithm.count and
failed doing that, so it tries to tell you about that failure.
newer
compiler will tell you this:
z00.d(8): Error: void has no value
z00.d(8): Error: incompatible types for ((count(alias pred = "a
== b", Range, E)(Range haystack, E needle)
if (isInputRange!Range && !isInfinite!Range &&
is(typeof(binaryFun!pred(haystack.front, needle)) : bool))) >
(10)): 'void' and 'int'
this is slightly better, albeit still cryptic. template
instantiation
error messages are of the most noisy and hard to understand
ones. alas.
but poor compiler at least tries to help you. ;-)
Thanks Ketmar and Bearophile.
UDA and mixins
I want to write mixin template, what past and/or change some code
in class. Mixin must get all functions with user defined
attribute and past fields for example. It should looks like this
struct FooPasted(Args...){}
class A
{
mixin foo;
void func1() @mark { ... }
void func2( int x, string a ) @mark { ... }
}
Question 1:
I get members with @mark via this template:
template filterMembers(alias F,T,string[] list=[])
if( is( T == class ) || is( T == struct ) )
{
static if( list.length > 0 ) enum filterMembers = impl!list;
else enum filterMembers = impl!([__traits(allMembers,T)]);
string[] impl(string[] names)() @property
{
static if( names.length == 0 ) return [];
else static if( names.length == 1 )
{
enum n = names[0];
static if( __traits(compiles,__traits(getMember,T,n))
)
return F!(__traits(getMember,T,n)) ? [n] : [];
else return [];
}
else return impl!(names[0..$/2]) ~ impl!(names[$/2..$]);
}
}
an easier way to do this exists? something like
__traits(UDAMembers,T,mark)
Question 2:
Can i change or remove exists code via mixin?
definition
class X
{
mixin foo;
void func() @impl;
}
change to
class X
{
void func() { ... implement by foo ... }
}
Re: UDA and mixins
struct FooPasted(Args...){}
class A
{
mixin foo;
void func1() @mark { ... }
void func2( int x, string a ) @mark { ... }
}
must change to:
class A
{
void func1() @mark { ... }
void func2( int x, string a ) @mark { ... }
FooPasted!() func1_mark;
FooPasted!(int,string) func2_mark;
}
Re: Asssociative Array by Key-Value-Pair
so it will be documented? that was the rhetorical question. Does it need to be? I don't see a reason for anyone to go out of their way to make the implementation inconsistent. Do you? At least I would prefer not to rely on undefined behaviour. If we ever do change the AA implementation in an inconsistent way, it will at least prevent the "but this code was broken all along"-argument. On the other hand adding just one sentence to the documentation would cost us nothing.
Re: Asssociative Array by Key-Value-Pair
On 12/16/14 10:33 AM, Tobias Pankrath wrote: so it will be documented? that was the rhetorical question. Does it need to be? I don't see a reason for anyone to go out of their way to make the implementation inconsistent. Do you? At least I would prefer not to rely on undefined behaviour. If we ever do change the AA implementation in an inconsistent way, it will at least prevent the "but this code was broken all along"-argument. On the other hand adding just one sentence to the documentation would cost us nothing. I can never ever see a reason to implement 2 different ways to traverse the elements, just to piss off people? If you make a PR that adds that to documentation, I will pull it if it makes you feel better. I don't think it hurts, but don't think it's worth my time to make such a PR. -Steve
Re: Asssociative Array by Key-Value-Pair
On Monday, 15 December 2014 at 23:21:44 UTC, bearophile wrote: Nordlöw: BTW: Why doesn't aa.byKey.map work? It currently works. Bye, bearophile My mistake. Now both are at https://github.com/nordlow/justd/blob/master/range_ex.d#L527
Re: Asssociative Array by Key-Value-Pair
On Tuesday, 16 December 2014 at 16:08:09 UTC, Steven Schveighoffer wrote: I can never ever see a reason to implement 2 different ways to traverse the elements, just to piss off people? If you make a PR that adds that to documentation, I will pull it if it makes you feel better. I don't think it hurts, but don't think it's worth my time to make such a PR. -Steve I can do PR for adding https://github.com/nordlow/justd/blob/master/range_ex.d#L527 to Phobos. Were should I put it/them?
Re: Asssociative Array by Key-Value-Pair
On 12/16/14 11:47 AM, "Nordlöw" wrote: On Tuesday, 16 December 2014 at 16:08:09 UTC, Steven Schveighoffer wrote: I can never ever see a reason to implement 2 different ways to traverse the elements, just to piss off people? If you make a PR that adds that to documentation, I will pull it if it makes you feel better. I don't think it hurts, but don't think it's worth my time to make such a PR. -Steve I can do PR for adding https://github.com/nordlow/justd/blob/master/range_ex.d#L527 to Phobos. Were should I put it/them? I think to be clear, the PR I said I will pull is for the documentation update. A doc change has no effect on the code. I will certainly review one that adds iteration of both key and value (as that is pretty much a free addition given the existing code), but it will have to go through normal review process. Note, the range you have referenced would not be accepted as it requires an unnecessary AA lookup for the value, and it requires access to phobos (this should be added to druntime). Take a look at object.di and see how the byKey and byValue ranges work. It would be trivial to add a byPair range (don't really like that name). The large controversy is regarding how it returns the "front" element. It would have to satisfy 3 requirements I think: 1. I should be able to do foreach(k, v; r) on it. 2. I should be able to access both key and value separately for each element. 3. It cannot depend on phobos. -Steve
Re: Asssociative Array by Key-Value-Pair
On Tuesday, 16 December 2014 at 16:56:20 UTC, Steven Schveighoffer wrote: I can do PR for adding https://github.com/nordlow/justd/blob/master/range_ex.d#L527 to Phobos. Were should I put it/them? I think to be clear, the PR I said I will pull is for the documentation update. A doc change has no effect on the code. I will certainly review one that adds iteration of both key and value (as that is pretty much a free addition given the existing code), but it will have to go through normal review process. Note, the range you have referenced would not be accepted as it requires an unnecessary AA lookup for the value, and it requires access to phobos (this should be added to druntime). Take a look at object.di and see how the byKey and byValue ranges work. It would be trivial to add a byPair range (don't really like that name). The large controversy is regarding how it returns the "front" element. It would have to satisfy 3 requirements I think: 1. I should be able to do foreach(k, v; r) on it. 2. I should be able to access both key and value separately for each element. 3. It cannot depend on phobos. -Steve Got it.
Re: Asssociative Array by Key-Value-Pair
On Tue, Dec 16, 2014 at 11:56:20AM -0500, Steven Schveighoffer via Digitalmars-d-learn wrote: > On 12/16/14 11:47 AM, "Nordlöw" wrote: > >On Tuesday, 16 December 2014 at 16:08:09 UTC, Steven Schveighoffer wrote: > >>I can never ever see a reason to implement 2 different ways to > >>traverse the elements, just to piss off people? > >> > >>If you make a PR that adds that to documentation, I will pull it if it > >>makes you feel better. I don't think it hurts, but don't think it's > >>worth my time to make such a PR. > >> > >>-Steve > > > >I can do PR for adding > > > >https://github.com/nordlow/justd/blob/master/range_ex.d#L527 > > > >to Phobos. > > > >Were should I put it/them? > > I think to be clear, the PR I said I will pull is for the > documentation update. A doc change has no effect on the code. > > I will certainly review one that adds iteration of both key and value > (as that is pretty much a free addition given the existing code), but > it will have to go through normal review process. > > Note, the range you have referenced would not be accepted as it > requires an unnecessary AA lookup for the value, and it requires > access to phobos (this should be added to druntime). Take a look at > object.di and see how the byKey and byValue ranges work. It would be > trivial to add a byPair range (don't really like that name). The large > controversy is regarding how it returns the "front" element. > > It would have to satisfy 3 requirements I think: > > 1. I should be able to do foreach(k, v; r) on it. > 2. I should be able to access both key and value separately for each > element. > 3. It cannot depend on phobos. [...] This has already been implemented, btw, but it was rejected because it did not use Phobos' Tuple type for .front. The code is here: https://github.com/D-Programming-Language/druntime/pull/574 One possibility is that we resurrect this PR and also add a new Phobos PR that wraps around .front to return Tuple instead (perhaps also rename byPair to something else in the process). T -- One Word to write them all, One Access to find them, One Excel to count them all, And thus to Windows bind them. -- Mike Champion
Re: detaching a thread from druntime <2.067
On Tuesday, 16 December 2014 at 04:56:10 UTC, Ellery Newcomer wrote: If I have a thread that I need to detach from druntime, I can call thread_detachInstance, but for 2.066, this function does not exist. Is there any way to do this in 2.066? I notice there is a thread_detachByAddr, but I'm not sure how to get a ThreadAddr out of a Thread.. thread_detachThis?
Re: Asssociative Array by Key-Value-Pair
On Tuesday, 16 December 2014 at 17:47:18 UTC, H. S. Teoh via Digitalmars-d-learn wrote: also rename byPair to something else in the process). What about by Python's byItem() and items()?
Referring to alias parameters in a mixin template
Would something like this be possible at all? A hypothetical
mixin template
mixin template makeProperty(T, string name, alias func) {
...
}
that could be called like this:
makeProperty!(int, "foo", f)
and would generate code like
int @property foo() { return f(); }
This is a very simplified example of what I'm trying to do, but
I'm a bit stuck at this point -- if I'm generating the code as a
string, how do I know how to refer to "func" alias (traits
identifier / fullyQualifiedName just don't cut it for a lot of
cases)? For one, thing, it could be an anonymous delegate like {
return 0; } or symbol from another module or anything else. This
is obviously doable if "func" is a string that gets mixed in, but
what if it is an alias?
Without the "name" part, one could sure use a simple template:
template makeUnnamedProperty(T, alias func) {
T makeUnnamedProperty() @property { return func(); }
}
and then this works...
alias foo = makeUnnamedProperty!(int, f);
However, how does the one go about templating this when "foo" is
a (compile-time) string?
Wonder if I'm missing something...
Thanks.
Re: detaching a thread from druntime <2.067
On 12/16/2014 10:41 AM, Sean Kelly wrote: On Tuesday, 16 December 2014 at 04:56:10 UTC, Ellery Newcomer wrote: If I have a thread that I need to detach from druntime, I can call thread_detachInstance, but for 2.066, this function does not exist. Is there any way to do this in 2.066? I notice there is a thread_detachByAddr, but I'm not sure how to get a ThreadAddr out of a Thread.. thread_detachThis? the thread I want to detach isn't currently running.
Re: Referring to alias parameters in a mixin template
A partial solution would be something like this:
mixin template makeProperty(T, string name, alias func) {
enum p = makeUnnamedProperty!(T, func);
mixin("enum %s = p;".format(name)); // or alias
}
however now the parent namespace is polluted with "p", is there
any way to hide it away and/or avoid it?
I may be wrong, but I guess the whole thing boils down to a
question whether it's possible to have a mixin template with
signature 'bind(string name, alias symbol)' which generates 'enum
foo = bar;' when called as 'mixin bind!("foo", bar)'?
Re: Referring to alias parameters in a mixin template
On Wednesday, 17 December 2014 at 01:14:36 UTC, aldanor wrote:
A partial solution would be something like this:
mixin template makeProperty(T, string name, alias func) {
enum p = makeUnnamedProperty!(T, func);
mixin("enum %s = p;".format(name)); // or alias
}
however now the parent namespace is polluted with "p", is there
any way to hide it away and/or avoid it?
The polution isn't too bad. Mixed-in symbols are second class. A
symbol not from a mixin would win, and multiple mixed-in `p`s
would only conflict on use.
But if you want to avoid `p`, just do the substitution:
mixin template makeProperty(T, string name, alias func) {
mixin("enum %s = makeUnnamedProperty!(T,
func);".format(name)); // or alias
}
Binding non-trivial C++ structs
To make my C++ binding life easier, I wrote a small string structure [1]
in C++ to use instead of std::string and produced the D declarations for
some of it [2]. (It's not that complicated, I promise.) The important
properties of this struct are that it has a non-trivial copy constructor
and a destructor. These properties mean that the ABI for returning a
binding::string are different than just a plain value [3]. Calling a
C++ function from D that returns a string does not obey the changed ABI.
How do I indicate to dmd that the C++ string should have the different
ABI? Well I should add a copy constructor or destructor, right? Copy
constructors on structs don't exist because we have blitting, so I can't
do that. When I add a destructor, linking fails with:
undefined reference to `_D6binding6binding6string6__dtorMFZv'
So that doesn't work either.
Now for the questions:
1) Is this supported?
2) If so, how do I actually do it?
Thanks
Paul O'Neil
[1] C++:
namespace binding {
class string
{
char * buffer;
size_t length;
public:
string();
string(const string& other);
string(string&&);
string(const char * str);
string(const char * str, unsigned long len);
string(const char * start, const char * end);
string(size_t len);
~string();
size_t size();
char * begin();
char * end();
bool operator==(const string& other) const;
bool operator!=(const string& other) const;
const char * c_str();
const char * c_str() const;
string operator+(const string& other) const;
string& operator=(const string& other);
string& operator=(string&& other);
void operator+=(const string& other);
};
}
[2] D:
extern(C++, binding) struct string
{
private char * buffer;
private size_t length;
public size_t size();
public char * begin();
public char * end();
public char * begin();
public char * end();
public char * c_str();
this(ref const(binding.string));
this(const(char)* str);
this(const(char)* str, size_t len);
this(const(char)* start, const(char)* end);
this(size_t len);
this(ref const(binding.string));
~this();
}
[3] http://mentorembedded.github.io/cxx-abi/abi.html#normal-call
--
Paul O'Neil
Github / IRC: todayman
Re: Referring to alias parameters in a mixin template
On Wednesday, 17 December 2014 at 01:39:07 UTC, anonymous wrote:
But if you want to avoid `p`, just do the substitution:
mixin template makeProperty(T, string name, alias func) {
mixin("enum %s = makeUnnamedProperty!(T,
func);".format(name)); // or alias
}
Thanks, that looks exactly like what I need -- I figured
something like this would compile, but I guess it's slightly
counterintuitive that you can access "T" and 'func" this way.
Wonder if this is doable within a single mixin template without
using makeUnnamedProperty?
Re: Referring to alias parameters in a mixin template
On Wednesday, 17 December 2014 at 01:49:14 UTC, aldanor wrote:
Wonder if this is doable within a single mixin template without
using makeUnnamedProperty?
Sure, straight forward:
mixin template makeProperty(T, string name, alias func) {
mixin("T %s() @property { return func();
}".format(name));
}
Re: Referring to alias parameters in a mixin template
On Wednesday, 17 December 2014 at 02:12:52 UTC, anonymous wrote:
Sure, straight forward:
mixin template makeProperty(T, string name, alias func) {
mixin("T %s() @property { return func();
}".format(name));
}
Indeed... thanks! Just one thing that I find confusing here -- how
exactly do T and func resolve when this template is mixed in?
What if there was another local symbol named "func" in the target
scope?
eraseInPlace (eg using memmove)?
Is there a phobos way to do eraseInPlace (eg with optimization using memmove where appropriate) ? (akin to insertInPlace)
Re: eraseInPlace (eg using memmove)?
Here's what I'd like in phobos:
void eraseInPlace(T)(ref T a, size_t index, size_t n=1)
if(isArray!T){
enum s=typeof(a[0]).sizeof;
auto ptr=a.ptr+index;
import core.stdc.string:memmove;
memmove(ptr,ptr+n,(a.length-(index+n))*s);
a.length-=n;
}
unittest{
auto a=[0,1,2,3,4,5,6];
a.eraseInPlace(1,2);
import std.conv:text;
assert(a==[0,3,4,5,6], text(a));
}
(obviously it assumes no aliasing)
On Tue, Dec 16, 2014 at 6:59 PM, Timothee Cour
wrote:
>
> Is there a phobos way to do eraseInPlace (eg with optimization using
> memmove where appropriate) ? (akin to insertInPlace)
>
