Re: Picking function templates with __traits(getOverloads, ..., true)
On Thursday, 30 July 2020 at 00:27:49 UTC, user1234 wrote: On Wednesday, 29 July 2020 at 23:57:21 UTC, Jean-Louis Leroy wrote: This works: [...] I may be missing the obvious...or it's a compiler bug??? Yes and it's just been fixed, see https://github.com/dlang/dmd/pull/11431. So uncommenting the second times works on ~master. Ah thanks! In the meantime I realized that picking the overload at index 1 works. That's the difference between 'foo' and 'times'. Then I was 80% sure it was a bug.
Picking function templates with __traits(getOverloads, ..., true)
This works:
module test;
void foo(T)(T a, T b) {}
void foo(T)(char a, T b) {}
template InstantiateTemplateAt(alias Module, string name, int
index, T...) {
alias Template = __traits(getOverloads, test, name,
true)[index];
alias InstantiateTemplateAt = Template!(T);
}
pragma(msg, typeof(InstantiateTemplateAt!(test, "foo", 1, int)));
// pure nothrow @nogc @safe void(char a, int b)
class Matrix(T) {}
Matrix!T times(T)(Matrix!T a, T b);
// Matrix!T times(T)(T a, Matrix!T b); // <-- second 'times'
overload
pragma(msg, typeof(InstantiateTemplateAt!(test, "times", 0,
int)));
// Matrix!int(Matrix!int a, int b)
But if I uncomment the second 'times' function template, I get an
error:
templateoverloads.d(8): Error: template `test.times` matches more
than one template declaration:
templateoverloads.d(16): `times(T)(Matrix!T a, T b)`
and
templateoverloads.d(17): `times(T)(T a, Matrix!T b)`
templateoverloads.d(19): Error: template instance
`test.InstantiateTemplateAt!(test, "times", 0, int)` error
instantiating
_error_
I may be missing the obvious...or it's a compiler bug???
(not sure if this belongs to the Learn section either)
Upcoming refraction module in bolts [was: DUB project type support for Emacs Projectile]
On Monday, 15 June 2020 at 16:03:08 UTC, jmh530 wrote: On Monday, 15 June 2020 at 13:17:11 UTC, Jean-Louis Leroy wrote: [snip] Nah, I saw it. Well. My take on it has been ready for months but I had to wait for my employer's permission to publish it. They are very open-source friendly, and as a consequence there is a glut of requests for open-sourcing personal projects. I guess I am going to cancel my request... Ah. I suppose that depends implementation/performance/feature differences... No, it's just that they are essentially equivalent. I spent some time supporting InterfaceValues to immutable and const classes and objects. Not sure if he has that, I haven't played with tardy yet. OTOH I didn't bother with allocator support. On the bright side, I just got authorized to contribute my work on function refraction (currently part of openmethods) to bolts. You can see it here: https://github.com/aliak00/bolts/pull/10 I saw when you mentioned it earlier. Though it hasn't been something I've needed as yet, it's good to know that it's there. This allows the function mixins to work when they are in different modules, right? I don't see a test for that, but it might be useful to include such an example (I'm pretty sure You mean an example with two modules? I plan to write a D blog entry that walks through the pitfalls of cross-module mixing. Atila's tardy makes use of a similar functionality when they are in different modules). Actually we were in contact (and with Ali of course). I pointed him to the part of openmethods that creates functions. He has a 'refraction.d' too. I coined the term 'refraction'. ;-) It's interesting that many of the examples for refract are like refract!(F, "F") or refract!(answer, "answer"). Would something like Function refract(alias fun, string localSymbol = __traits(identifier, fun))() work for you? Not at all :-D That would return a name in the caller module. In the mixture you want to use only local names, and navigate from there. Maybe I should change all the examples, including the unit tests, to avoid giving the impression that the original function name is a good default for the localSymbol. In most cases it's not.
Re: DUB project type support for Emacs Projectile
On Sunday, 14 June 2020 at 18:49:01 UTC, jmh530 wrote: On Sunday, 14 June 2020 at 17:19:05 UTC, Jean-Louis Leroy wrote: [snip] In case you missed it, I thought you would find this interesting https://forum.dlang.org/thread/dytpsnkqnmgzniiwk...@forum.dlang.org Nah, I saw it. Well. My take on it has been ready for months but I had to wait for my employer's permission to publish it. They are very open-source friendly, and as a consequence there is a glut of requests for open-sourcing personal projects. I guess I am going to cancel my request... On the bright side, I just got authorized to contribute my work on function refraction (currently part of openmethods) to bolts. You can see it here: https://github.com/aliak00/bolts/pull/10
Re: DUB project type support for Emacs Projectile
On Sunday, 14 June 2020 at 16:04:32 UTC, Jean-Louis Leroy wrote:
On Sunday, 14 June 2020 at 09:11:58 UTC, Andre Pany wrote:
On Saturday, 13 June 2020 at 19:27:53 UTC, Jean-Louis Leroy
wrote:
On Monday, 18 November 2019 at 23:06:14 UTC, Per Nordlöw
wrote:
Have anybody written support for DUB project types in Emacs'
projectile?
See:
https://www.projectile.mx/en/latest/projects/#adding-custom-project-types
Normally it should be as easy as this:
(projectile-register-project-type
'dub '("dub.json" "dub.sdl")
:compile "dub compile"
:test "dub test"
:run "dub run")
But it doesn't work for me and I cannot figure out why.
The command is `dub build` which will build the project from
the current work dir. You can set another work dir with arg
`--root FOLDER` if needed. Same for `dub test` and `dub run`.
Kind regards
Andre
`dub build` - right, sorry for that. But the real problem (and
the reason why I never noticed the compile/build mistake) is
that projectile deigns not recognize the project type. Yet I
did try it in directories containing a dub project, IOW a
`dub.json` was present. I just lived with it, entering the
commands manually when I need to restart emacs (which happens
maybe once in a week). I should debug this, maybe I'll do that
today...
OK, projectile checks for the presence of *all* the files in the
list. So there:
(defun projectile-dub-project-p ()
"Check if a project contains a dub.json or dub.sdl file."
(or (projectile-verify-file "dub.json")
(projectile-verify-file "dub.sdl")))
(projectile-register-project-type
'dub #'projectile-dub-project-p
:compile "dub build"
:test "dub test"
:run "dub run")
Re: DUB project type support for Emacs Projectile
On Sunday, 14 June 2020 at 09:11:58 UTC, Andre Pany wrote:
On Saturday, 13 June 2020 at 19:27:53 UTC, Jean-Louis Leroy
wrote:
On Monday, 18 November 2019 at 23:06:14 UTC, Per Nordlöw wrote:
Have anybody written support for DUB project types in Emacs'
projectile?
See:
https://www.projectile.mx/en/latest/projects/#adding-custom-project-types
Normally it should be as easy as this:
(projectile-register-project-type
'dub '("dub.json" "dub.sdl")
:compile "dub compile"
:test "dub test"
:run "dub run")
But it doesn't work for me and I cannot figure out why.
The command is `dub build` which will build the project from
the current work dir. You can set another work dir with arg
`--root FOLDER` if needed. Same for `dub test` and `dub run`.
Kind regards
Andre
`dub build` - right, sorry for that. But the real problem (and
the reason why I never noticed the compile/build mistake) is that
projectile deigns not recognize the project type. Yet I did try
it in directories containing a dub project, IOW a `dub.json` was
present. I just lived with it, entering the commands manually
when I need to restart emacs (which happens maybe once in a
week). I should debug this, maybe I'll do that today...
Re: DUB project type support for Emacs Projectile
On Monday, 18 November 2019 at 23:06:14 UTC, Per Nordlöw wrote:
Have anybody written support for DUB project types in Emacs'
projectile?
See:
https://www.projectile.mx/en/latest/projects/#adding-custom-project-types
Normally it should be as easy as this:
(projectile-register-project-type
'dub '("dub.json" "dub.sdl")
:compile "dub compile"
:test "dub test"
:run "dub run")
But it doesn't work for me and I cannot figure out why.
Re: Aliasing current function template instance
On Friday, 1 May 2020 at 21:05:17 UTC, Adam D. Ruppe wrote: On Friday, 1 May 2020 at 20:28:58 UTC, Jean-Louis Leroy wrote: Something I have overlooked? Any ideas? There's an old rule, that I can't find in the spec anymore but I'm still pretty sure it is there, where taking the address of a template inside a template yields the current instantiation. Then you can fetch the type of that and do some reflection off. So try this in your test rig: pragma(msg, Parameters!(typeof())); This rule was in there to ease callbacks and recursive functions iirc but it can also work with you thanks to typeof turning the runtime address back into a compile time alias. It looks like it does the trick. Thanks! Trying to add support for method templates to openmethods.
Re: Aliasing current function template instance
On Friday, 1 May 2020 at 20:43:05 UTC, Steven Schveighoffer wrote:
On 5/1/20 4:28 PM, Jean-Louis Leroy wrote:
Something I have overlooked? Any ideas?
This trick works. No idea who came up with it:
alias thisFunction = __traits(parent, {});
-Steve
I think I get the idea. Alas it doesn't work inside a function
template, because it returns the template, not the instance:
void foo(T)(lazy T)
{
alias thisFunction = __traits(parent, {});
pragma(msg, thisFunction.stringof);
//pragma(msg, Parameters!thisFunction); // later
}
void main()
{
foo(0);
foo("");
}
prints:
foo(T)(lazy T)
foo(T)(lazy T)
Uncommenting the line that is (more or less) my real goal:
aliasthisfunction.d(7): Error: template instance
`std.traits.Parameters!(foo)` does not match template declaration
`Parameters(func...)`
with `func = (foo(T)(lazy T))`
must satisfy the following constraint:
` isCallable!func`
Aliasing current function template instance
Is it possible, inside a function template, to create an alias to
the instantiated function? IOW the equivalent of __FUNCTION__,
but yielding an alias?
The closest I came is:
import std.string;
import std.traits;
void foo(T)(lazy T)
{
mixin(
"alias thisFunction = ",
__FUNCTION__[0..__FUNCTION__.lastIndexOf('.')],
";");
pragma(msg, Parameters!thisFunction);
}
void main()
{
foo(0);
foo("");
}
dmd -c aliasthisfunction.d
(lazy int)
(lazy string)
...but (unsurprisingly) this fails in presence of overloads. I.e.
if I throw in:
void foo(T)(int, T);
...then I get:
aliasthisfunction.d(6): Error: template `aliasthisfunction.foo`
matches more than one template declaration:
aliasthisfunction.d(4): `foo(T)(lazy T)`
and
aliasthisfunction.d(20): `foo(T)(int, T)`
...
Something I have overlooked? Any ideas?
Function aliasing problem
I can alias a function template:
T f(T)(T x) { return x; }
alias g = f;
int a = g(42);
I can alias a static function:
struct S
{
static int f(int i) { return i; }
}
alias sf = S.f;
int b = sf(42);
I can alias to a static function in a template instance:
struct SS(T)
{
static T f(T i) { return i; }
}
alias ssi = SS!int.f;
int c = ssi(42);
Of course an alias can be templatized:
alias SSS(T) = SS!T;
I would like to combine them all, e.g.:
alias sst(T) = SS!T.f;
int d = sst(42); // <=> SS!int.f(42)
But it fails like this:
aliasstaticfunction.d(23): Error: template
`aliasstaticfunction.sst` cannot deduce function from argument
types `!()(int)`, candidates are:
aliasstaticfunction.d(22):`sst(T)`
In fact this simpler attempt fails in the same fashion:
alias g2(X) = f!X;
int e = g(42);
aliasstaticfunction.d(25): Error: template
`aliasstaticfunction.g2` cannot deduce function from argument
types `!()(int)`, candidates are:
aliasstaticfunction.d(24):`g2(X)`
I tried with an eponymous template declaring an alias, in place
of the alias template. Unsurprisingly, I get the same error (the
latter is lowered to the former isn't it?).
I also tried std.meta.Alias, to no avail.
Is there a solution, other than building a templatized forwarder
function, e.g.:
T sst(T)(T i) { return SS!T.f(i); }
int d = sst(42);
(and this is not good anyway, as it drops function attributes,
parameter storage classes, UDAs etc).
Re: Extracting user defined attributes on function parameters
On Friday, 17 April 2020 at 18:05:39 UTC, Jean-Louis Leroy wrote: Interesting example, but all hope is not lost. `a` could (should?) be passed as an alias in __parameters. Okay I take this back...
Re: Extracting user defined attributes on function parameters
On Friday, 17 April 2020 at 17:48:06 UTC, Adam D. Ruppe wrote:
On Friday, 17 April 2020 at 17:31:32 UTC, Jean-Louis Leroy
wrote:
Well, can't do. I need this purely at compile time, and
cross-module.
And the CTFE engine gets weird with it too dmd will have to
fix this.
But default parameters might not be possible in general at CT
anyway... it is actually possible to define it to a variable.
Observe:
int a;
void f(int arg = a) { // default arg is to use the global...
import std.stdio; writeln(arg);
}
void main() {
f(); // 0 this time
a = 4; // and it can be changed at runtime!
f(); // will now say 4
}
Interesting example, but all hope is not lost. `a` could
(should?) be passed as an alias in __parameters.
Re: Extracting user defined attributes on function parameters
On Friday, 17 April 2020 at 16:54:42 UTC, Adam D. Ruppe wrote:
void main() {
import std.stdio;
writeln(ParameterDefaults!f.stringof);
}
and it is fine.
Well, can't do. I need this purely at compile time, and
cross-module. That's for supporting UDAs and default parameter
values in openmethods. If you want a peek at what I am up to, see
here:
https://github.com/jll63/openmethods.d/blob/bolts-reflection/source/bolts/reflection/metafunction.d
Re: Extracting user defined attributes on function parameters
Alas the presence of parameter UDAs breaks std.traits.ParameterDefaults: import std.traits; struct attr; void f(@attr int); pragma(msg, ParameterDefaults!f.stringof); Error: dmd -c bug.d bug.d(4): Error: undefined identifier `attr`, did you mean variable `ptr`? /home/jll/dlang/dmd-2.090.1/linux/bin64/../../src/phobos/std/traits.d(1526): Error: template instance `std.traits.ParameterDefaults!(f).Get!0LU` error instantiating /home/jll/dlang/dmd-2.090.1/linux/bin64/../../src/phobos/std/traits.d(1529): instantiated from here: `Impl!0LU` bug.d(6):instantiated from here: `ParameterDefaults!(f)` bug.d(6):while evaluating `pragma(msg, ParameterDefaults!(f).stringof)` I filed a bug report (20744). And examined the code of ParameterDefaults. I think I understand how it works, for the most part, but I haven't been able to find a fix yet. I'd like to understand why taking a slice of __parameters vs fetching the first element matters. What is the (meta?) type of __parameters[0..1]? I think I'd need to make a copy of it, minus the UDAs tucked at the beginning. But I haven't found a way of splitting it into smaller components. I tried using indexation and variadic template parameters, but it always collapses into a string. Makes me think of wave functions in quantum mechanics ;-)
Re: Extracting user defined attributes on function parameters
Thanks to both of you! As part of implementing full support for attributes in openmethods, I am developing a reflection library. That helped a lot. is() is a bit weird, but I described it in my "D Cookbook" to some success... I am going to order it...even though it is not available on Kindle ;-)
Re: Extracting user defined attributes on function parameters
On Tuesday, 14 April 2020 at 21:44:51 UTC, Adam D. Ruppe wrote: On Tuesday, 14 April 2020 at 21:35:12 UTC, Jean-Louis Leroy wrote: I can see them: There's some weird tricks to it. Check out my old blog sidebar about it here: http://dpldocs.info/this-week-in-d/Blog.Posted_2019_02_11.html#how-to-get-uda-on-a-function-param O.kay. It looks like `is` is D's Swiss army chainsaw. Yeah I never read the `is` doc properly. Now I am beginning to understand how `std.traits.Parameters` works. Thanks!
Extracting user defined attributes on function parameters
I can see them:
import std.traits;
struct foo;
struct bar;
void f(@foo int, @foo @bar @("baz") real);
pragma(msg, Parameters!f);
// (@(foo) int, @(tuple(tuple(foo), tuple(bar)),
tuple("baz")) real)
...but I cannot find how to get hold of them:
pragma(msg, (Mystery!f)[0]); // foo
pragma(msg, __traits(mystery, f)[0]); // foo
And besides the structure looks weird for the second argument.
It's as if the UDAs were applied to one another, from left to
right.
I did search the documentation and google for 1/2 hour.
Is-expression and immutable interface
How comes?
immutable struct Foo
{
}
pragma(msg, is(Foo == immutable)); // true
immutable interface Bar
{
}
pragma(msg, is(Bar == immutable)); // false
Going from string to identifier
Here's what I am trying to do:
mixin template MakeFun(string ID, int X)
{
int mixin(ID)() { return X; }
}
mixin MakeFun!("one", 1); // int one() { return 1; }
Alas I get:
makefunc.d(3): Error: no identifier for declarator `int`
makefunc.d(3): Error: found `{` when expecting `;`
makefunc.d(3): Error: declaration expected, not `return`
makefunc.d(4): Error: unrecognized declaration
Is there a shorter way than building the entire function
definition as a string mixin? As in:
mixin template MakeFun(string ID, int X)
{
import std.format;
mixin(format("int %s() { return %s; }", ID, X));
}
mixin MakeFun!("one", 1);
Re: Alias vs templates
On Wednesday, 21 February 2018 at 20:27:29 UTC, Steven
Schveighoffer wrote:
On 2/21/18 1:46 PM, Jean-Louis Leroy wrote:
[...]
I think because one is a function, which is allowed to be
overloaded, the other is a symbol.
But clearly, there are some liberties taken when you are
overloading function templates, as overloading them works just
fine. I think this may have been a patch at some point (you
didn't use to be able to overload template functions with
normal functions).
It seems like a reasonable request that this code should work.
I just discovered that this works:
int baz(T)();
struct Baz {
static int baz(T)(T x) { return x; }
}
alias baz(T) = Baz.baz!T;
Alias vs templates
I am trying to figure out a crispier syntax for templatized open
methods. I am stumbling on this (see comments):
// dmd -run conflict.d
int foo();
struct Foo {
static int foo(int x) { return x; }
}
alias foo = Foo.foo; // overload with an alias - OK
int bar(T)();
int bar(T)(T x) { return x; } // overloaded function templates -
OK
int baz(T)();
struct Baz {
static int baz(T)(T x) { return x; }
}
//alias baz = Baz.baz; // Error: alias conflict.baz conflicts
with template conflict.baz(T)() at conflict.d(11)
void main()
{
import std.stdio;
writeln(foo(42)); // 42
writeln(bar(666)); // 666
}
Why?
Re: nested module problem
On Sunday, 24 December 2017 at 22:17:23 UTC, Luís Marques wrote: On Saturday, 2 September 2017 at 20:03:48 UTC, Jean-Louis Leroy wrote: jll@ORAC:~/dev/d/tests/modules$ tree . ├── foo │ └── bar.d └── foo.d I think that shouldn't be allowed. You have a package foo, but use a normal module instead of foo/package.d. I'm going to file a bug on that. Monkey testing haha!
Re: nested module problem
On Saturday, 2 September 2017 at 21:42:59 UTC, Moritz Maxeiner wrote: On Saturday, 2 September 2017 at 21:24:19 UTC, Jean-Louis Leroy wrote: [...] Yes, these now both fail because you cannot have a module `foo` and a package `foo` at the same time (they share a namespace), I forgot about that. [...] (same as before, no issue here) [...] You created the 'foo' package by specifying `module foo.bar` in foo/bar.d. [...] AFAIK you can't; consider: -- baz.d --- import foo; in the same directory as foo.d. If foo/package.d exists (with `module foo` inside), what should baz.d import? foo.d or foo/package.d? The point being that we could have either used foo/package.d or foo.d for a package file, but not both (as that would allow ambiguity) and package.d was chosen. [1] https://dlang.org/spec/module.html#package-module Hmmm I see...I was thinking of spinning the runtime part of my openmethods library into its own module (like here https://github.com/jll63/openmethods.d/tree/split-runtime/source/openmethods) but it looks like a bad idea...
Re: nested module problem
On Saturday, 2 September 2017 at 20:48:22 UTC, Moritz Maxeiner wrote: So the compiler wants you to import it by the name it has inferred for you (The fix being either specifying the module name in foo/bar.d as `module foo.bar`, or importing it as via `import bar;` in foo.d). [1] https://dlang.org/spec/module.html I thought of doing that, it merely changed the error. OK now I have: in foo.d: module foo; import foo.bar; in foo/bar.d: module foo.bar; $ dmd -c foo.d foo/bar.d foo/bar.d(1): Error: package name 'foo' conflicts with usage as a module name in file foo.d If I compile separately: jll@ORAC:~/dev/d/tests/modules$ dmd -I. -c foo.d foo/bar.d(1): Error: package name 'foo' conflicts with usage as a module name in file foo.d jll@ORAC:~/dev/d/tests/modules$ dmd -I. -c foo/bar.d It believes that 'foo' is a package...because there is a 'foo' directory? I see that a workaround is to move foo.d to foo/package.d but I would like to avoid that.
nested module problem
So I have: jll@ORAC:~/dev/d/tests/modules$ tree . ├── foo │ └── bar.d └── foo.d foo.d contains: import foo.bar; bar.d is empty. Now I try compiling: jll@ORAC:~/dev/d/tests/modules$ dmd -c foo.d jll@ORAC:~/dev/d/tests/modules$ dmd -c foo/bar.d So far so good. Now I try it the way dub does it: jll@ORAC:~/dev/d/tests/modules$ dmd -c foo.d foo/bar.d foo.d(1): Error: module bar from file foo/bar.d must be imported with 'import bar;' What's up?
dub and hierarchies of packages
Hi, I am quite happy with dub, the little package manager that could :) Now two questions or suggestions. I have a package hierarchy (here https://github.com/jll63/openmethods.d/blob/master/dub.sdl) and I would like to 'dub run' or 'dub test' everything. Is there a recursive mode that I've missed? Secondly, I have buildTypes that I would like to use in all the packages (like here https://github.com/jll63/openmethods.d/blob/master/tests/misc/dub.sdl#L9). I would like to avoid repeating it in every dub.sdl. I tried putting the buildTypes in the root dub.sdl and defining my subpackages there (in spite of the warning against doing that) in the hope that the buildTypes would be globally available, but no. Is there a way of making the subpackages inherit stuff from their parent? Or some sort of sdl #include or 'import'?
Re: Adding flags to dub build
On Tuesday, 18 July 2017 at 20:12:13 UTC, Jean-Louis Leroy wrote: On Tuesday, 18 July 2017 at 20:00:48 UTC, Guillaume Piolat wrote: On Tuesday, 18 July 2017 at 19:49:35 UTC, Jean-Louis Leroy wrote: Hi, I want to add a few flags while building with dub. I tried: DFLAGS='-d-version=explain' dub test ... ...but DFLAGS does not seem to be honored. In fact I wouldn't mind adding a builtType to my dub.sdl (but then will it be inherited by the subpackages) but I don't see how to specify flags there either...maybe because it tries to hide variations in compiler switches? J-L Use "dflags" or "lflags" (linker) It doesn't work either... The Source holds all the answers ;-) DFLAGS='-d-version=explain' dub test openmethods:benchmarks --build '$DFLAGS' ... Performing "$DFLAGS" build using ldc2 for x86_64. ...
Re: Adding flags to dub build
On Tuesday, 18 July 2017 at 20:00:48 UTC, Guillaume Piolat wrote: On Tuesday, 18 July 2017 at 19:49:35 UTC, Jean-Louis Leroy wrote: Hi, I want to add a few flags while building with dub. I tried: DFLAGS='-d-version=explain' dub test ... ...but DFLAGS does not seem to be honored. In fact I wouldn't mind adding a builtType to my dub.sdl (but then will it be inherited by the subpackages) but I don't see how to specify flags there either...maybe because it tries to hide variations in compiler switches? J-L Use "dflags" or "lflags" (linker) It doesn't work either... dflags='-d-version=explain' dub --vverbose test openmethods:benchmarks --build release --force Using dub registry url 'http://code.dlang.org/' Refreshing local packages (refresh existing: true)... Looking for local package map at /var/lib/dub/packages/local-packages.json Looking for local package map at /home/jleroy/.dub/packages/local-packages.json Determined package version using GIT: openmethods 0.0.1+commit.5.g94ad5a9 Refreshing local packages (refresh existing: false)... Looking for local package map at /var/lib/dub/packages/local-packages.json Looking for local package map at /home/jleroy/.dub/packages/local-packages.json Collecting dependencies for openmethods Building package openmethods:benchmarks in /home/jleroy/dev/d/methods.d/benchmarks/ Refreshing local packages (refresh existing: false)... Looking for local package map at /var/lib/dub/packages/local-packages.json Looking for local package map at /home/jleroy/.dub/packages/local-packages.json Collecting dependencies for openmethods:benchmarks Adding local /home/jleroy/dev/d/methods.d/ Found dependency openmethods >=0.0.0 @../ Collecting dependencies for openmethods Checking for missing dependencies. Configurations used for dependency resolution: openmethods (0): [invalid, 0.0.1+commit.5.g94ad5a9] Interation (ci=0) openmethods invalid (C) Interation (ci=-1) openmethods 0.0.1+commit.5.g94ad5a9 Refreshing local packages (refresh existing: false)... Looking for local package map at /var/lib/dub/packages/local-packages.json Looking for local package map at /home/jleroy/.dub/packages/local-packages.json Collecting dependencies for openmethods:benchmarks Adding local /home/jleroy/dev/d/methods.d/ Found dependency openmethods >=0.0.0 @../ Collecting dependencies for openmethods Checking for upgrades. Using cached upgrade results... Package methods can be installed with version 0.0.1. Use "dub upgrade" to perform those changes. Add config openmethods library Add config openmethods:benchmarks Including openmethods:benchmarks -> openmethods library openmethods:benchmarks -> openmethods library Using configuration 'library' for openmethods Using configuration '' for openmethods:benchmarks Add config openmethods library Add config openmethods:benchmarks application Including openmethods:benchmarks application -> openmethods library openmethods:benchmarks application -> openmethods library Using configuration 'library' for openmethods Using configuration 'application' for openmethods:benchmarks Creating build generator. Add config openmethods:benchmarks application Add config openmethods library Including openmethods:benchmarks application -> openmethods library openmethods:benchmarks application -> openmethods library Using configuration 'application' for openmethods:benchmarks Using configuration 'library' for openmethods Gathering build settings for openmethods:benchmarks (application) Fixing relative path: /home/jleroy/dev/d/methods.d/benchmarks/ ~ source/benchmarks.d Fixing relative path: /home/jleroy/dev/d/methods.d/benchmarks/ ~ source/ Executable configuration "application" of package openmethods:benchmarks defines no main source file, this may cause certain build modes to fail. Add an explicit "mainSourceFile" to the package description to fix this. Gathering build settings for openmethods (library) Fixing relative path: /home/jleroy/dev/d/methods.d/ ~ source/ Configuration 'application' does not output a library. Falling back to "dub -b unittest -c application". Add config openmethods:benchmarks application Add config openmethods library Including openmethods:benchmarks application -> openmethods library openmethods:benchmarks application -> openmethods library Using configuration 'application' for openmethods:benchmarks Using configuration 'library' for openmethods Fixing relative path: /home/jleroy/dev/d/methods.d/ ~ source/openmethods.d Fixing relative path: /home/jleroy/dev/d/methods.d/ ~ source/ Fixing relative path: /home/jleroy/dev/d/methods.d/ ~ . Fixing relative path: /home/jleroy/dev/d/methods.d/benchmarks/ ~ source/benchmarks.d Fixing relative path: /home/jleroy/dev/d/methods.d/benchmarks/ ~ source/ Fixing relative path: /home/jleroy/dev/d/methods.d/benchmarks/ ~ . Fixing relative path: /home/jleroy/dev/d/methods.d/benchmarks/ ~ source/benchmarks.d Fixing relative path:
Adding flags to dub build
Hi, I want to add a few flags while building with dub. I tried: DFLAGS='-d-version=explain' dub test ... ...but DFLAGS does not seem to be honored. In fact I wouldn't mind adding a builtType to my dub.sdl (but then will it be inherited by the subpackages) but I don't see how to specify flags there either...maybe because it tries to hide variations in compiler switches? J-L
Re: ddox filters out my doc
On Saturday, 15 July 2017 at 08:55:41 UTC, Mike Parker wrote: On Saturday, 15 July 2017 at 08:29:52 UTC, Jean-Louis Leroy wrote: My module has a name in dub.sdl. No, it does not. That's the name of the DUB project. The module in this case is source/methods.d. I've never used ddox, but based on what I see in the readme and on looking at the ddox source where that specific error message is displayed, if I were you my first attempt at resolving this would be to add a module declaration to the top of methods.d and try again: module methods; import std.traits; import... Aaaah yes that fixed it. I suspected it was something *that* simple. Thanks a bunch. J-L
ddox filters out my doc
I began to write documentation for my open method library. After googling around quite a bit, I came across the incantation: dub build -b ddox Problem is, it generates no doc. And I believe that it actually says so: Performing "ddox" build using dmd for x86_64. methods ~genesis: building configuration "library"... Performing "debug" build using dmd for x86_64. [...] Running ../../../.dub/packages/ddox-0.16.2/ddox/ddox filter --min-protection=Protected --only-documented docs.json Reading doc file... Parsing JSON... Filtering modules... No name for module source/methods.d - ignoring Writing filtered docs... My module has a name in dub.sdl. After running ddox I see that an empty docs.json has been created in my root dir. Maybe I must put things in there? But I haven't found such a file in several dlang projects I have sought inspiration from... Project is here: https://github.com/jll63/meth.d/tree/genesis and the exact snapshot I am using is here: https://github.com/jll63/meth.d/tree/28b3419a6f5f9936fb95e906fc990e00568a32f8
Anything like quote?
I want to create a string while making sure it qualifies as an
identifier. Like this:
struct quote
{
static @property string opDispatch(string str)() { return str; }
}
unittest
{
assert(quote.foo == "foo");
}
Does it already exist somewhere in the language or the library?
J-L
Re: Cannot dup an associative array but why?
On Tuesday, 11 July 2017 at 21:23:28 UTC, Ali Çehreli wrote:
Default template and function arguments are resolved at
instantiation site, which means __MODULE__ would resolve
automatically to the caller's module. For example, if you have
this module:
__MODULE__ is a string so I cannot pass it to
__traits(allMembers). I worked around it via a string mixin that
creates an alias for the module:
template RegisterMethods()
{
import std.array;
mixin("alias MODULE = " ~ __MODULE__ ~ ";");
auto RegisterMethods() {
string[] s;
foreach (m; __traits(allMembers, MODULE)) {
// do stuff
}
return join(s, "");
}
}
mixin(RegisterMethods);
I wonder if there is a better way.
Also, I am using the outer string mixin (as opposed to a plain
mixin) because I will need to produce a series of aliases:
mixin(RegisterMethods);
// injects:
// alias add = Method!("add", Matrix, virtual!Matrix,
virtual!Matrix).dispatcher
// alias add = Method!("add", Matrix, virtual!Matrix,
virtual!Matrix).discriminator;
// alias kick = Method!("kick", Animal).dispatcher
// alias kick = Method!("kick", Animal).discriminator
// etc
The only way I can see is with a string mixin.
I thought about the new syntax since yesterday, and hit some
problems and some solutions. At this point maybe we should
continue that discussion elsewhere than the Learn forum...
Re: Cannot dup an associative array but why?
On Tuesday, 11 July 2017 at 17:20:33 UTC, Ali Çehreli wrote:
@Virtual("t", "d", "w")
string fight(Character t, Dragon d, Hands w) {
return "you just killed a dragon with your bare hands.
Incredible isn't it?";
[...]
mixin ProcessMethods();
Great suggestion! I think this could work:
string fight(virtual!Character, virtual!Creature,
virtual!Device); // declares method
// define implemention:
string fight(Character t, Dragon d, Hands w);
mixin ProcessMethods();
How do you find the current module inside ProcessMethods?
There's a problem with the catch-all method though:
string fight(Character a, Creature b, Device c) { }
This won't work because string fight(Character a, Creature b,
Device c) is the method itself - it's generated by the library.
We'll have to come up with a special syntax for it.
J-L
Re: Cannot dup an associative array but why?
On Tuesday, 11 July 2017 at 17:20:33 UTC, Ali Çehreli wrote:
That's some serious code you've written there and you must be
happy that 'virtual' is not a keyword in D. ;)
Thanks. Haha I would have used virtual_ like I did in C++ ;-)
Maybe others can come up with ideas on a better syntax.
When it is presentable (I'm almost there) I plan to ask a review.
I would welcome suggestions about the syntax - which is not too
bad as it is now, I have been happily surprised with what is
feasible. It even supports overloading methods.
The thing that annoys me most is having to pass a string to
'method'. And attributes are not allowed on arguments. I wish I
would make something like this work:
mixin method!(fight, string, virtual!Character,
virtual!Creature, virtual!Device);
// or:
mixin method!(fight, string, @virtual Character, @virtual
Creature, @virtual Device);
// even better
mixin method!(fight, function string(@virtual Character,
@virtual Creature, @virtual Device));
// and if there is a catch-all implementation:
mixin method!(fight, function string(@virtual Character,
@virtual Creature, @virtual Device) {
// body
}
I tried to get inspiration from Yes and No, considered using
opDispatch, but I haven't found a way yet.
Just to get the conversation going and without thinking it
through, how about something like the following?
struct Virtual(Args...) {
// ...
}
@Virtual("t", "d", "w")
string fight(Character t, Dragon d, Hands w) {
return "you just killed a dragon with your bare hands.
Incredible isn't it?";
}
The 'virtual' qualifier applies to the arguments in the method
declaration, not the specializations. Also, I prefer to keep the
qualifiers stuck to the argument. It's clearer. Interesting idea
though.
Then, something like the following which would parse the module
to do its magic:
mixin ProcessMethods();
Very interesting. I don't like the repetition of 'mixin' in front
of each 'method' and 'implementation'.
Hmmm...if ProcessMethods() can find @Virtual(...) functions can't
it find functions that have virtual! parameters?
Re: Cannot dup an associative array but why?
On Monday, 10 July 2017 at 19:11:37 UTC, Ali Çehreli wrote:
On 07/10/2017 11:46 AM, Jean-Louis Leroy wrote:
> Is there something special about ClassInfo that confuses?
Look at this
> example:
>
> struct Foo
> {
>
> }
>
> class Bar
> {
> }
>
> void main()
> {
> Foo*[Bar] a;
> auto aa = a.dup; // OK
> Foo*[ClassInfo] b; // Error: static assert "cannot call
> Foo*[TypeInfo_Class].dup because Foo* is not copyable"
I think you're hitting the same TypeInfo.init issue again. :/
This is the assert that fails inside object.dup:
static assert(is(typeof({ V v = aa[K.init]; })),
"cannot call " ~ T.stringof ~ ".dup because " ~
V.stringof ~ " is not copyable");
Jean-Louis, a little more patience please. :) Hopefully this
will be resolved with 2.075, which you should be able to test
yourself already. (?) 2.075 is in its fourth beta release.
Ali
Howdy Ali ;-)
Aaaah...those rough edges you were talking about at CppNow?
FYI, having a lot of fun. See
https://github.com/jll63/meth.d/blob/experiments/source/meth/examples/adventure.d
At the time being, I'm hijacking ClassInfo.deallocator. I hope it
will live through the next iteration of D.
Cannot dup an associative array but why?
Is there something special about ClassInfo that confuses? Look at
this example:
struct Foo
{
}
class Bar
{
}
void main()
{
Foo*[Bar] a;
auto aa = a.dup; // OK
Foo*[ClassInfo] b; // Error: static assert "cannot call
Foo*[TypeInfo_Class].dup because Foo* is not copyable"
auto bb = b.dup; // instantiated from here:
dup!(Foo*[TypeInfo_Class], TypeInfo_Class, Foo*)}
}
'Foo*' is not copyable? Except that it is if the key is something
else than ClassInfo? ClassInfo and Bar are both reference types
though...
Is runtime info in shared memory?
When I look at ldc2's object.d I have the impression it's thread local. I may be wrong though, just beginning to learn about 'shared'.
Re: Append to 'map' result
On Wednesday, 5 July 2017 at 01:43:46 UTC, Ali Çehreli wrote:
On 07/04/2017 05:52 PM, Jean-Louis Leroy wrote:
On Wednesday, 5 July 2017 at 00:28:01 UTC, Ali Çehreli wrote:
On 07/04/2017 04:57 PM, Jean-Louis Leroy wrote:
[...]
No time to dig deeper but this is because the two ranges that
chain()
receives do not have a common type. (Rather, that type is
'void'):
[...]
This is related to TypeInfo.init, which unfortunately is *not*
the .init property in this case. :( Luckily, it will be fixed
in 2.075. This is what object.d has:
[...]
So, unfortunately, most Phobos range functions cannot be used
with TypeInfo as they would invariably touch ElementType. Here
is a halfway workaround that uses each() instead of map(): :/
Aaah, so I was not doing anything wrong ;-)
I was trying to factor this code:
foreach (i; k.interfaces) {
if (i.classinfo in classMap) {
v.bases ~= classMap[i.classinfo];
}
}
if (k.base in classMap) {
v.bases ~= classMap[k.base];
}
i.e. process the class base along with the interfaces in the same
loop. I dwelled on it because my goal with this project is to
learn (and evaluate) D.
Anyway, I am building my own graph of enriched ClassInfo objects;
once that is done, I won't be impacted with the bug anymore.
Thanks for the diagnostic...
J-L
Re: Append to 'map' result
On Wednesday, 5 July 2017 at 00:28:01 UTC, Ali Çehreli wrote: On 07/04/2017 04:57 PM, Jean-Louis Leroy wrote: [...] No time to dig deeper but this is because the two ranges that chain() receives do not have a common type. (Rather, that type is 'void'): [...] I suspect that that is the reason, although I checked in several ways that I had ClassInfo elements on both sides. Ok, I'll keep looking tomorrow with a fresh eye...
Re: Append to 'map' result
On Tuesday, 4 July 2017 at 23:26:28 UTC, H. S. Teoh wrote: On Tue, Jul 04, 2017 at 11:27:25PM +, Jean-Louis Leroy via Digitalmars-d-learn wrote: I want to create a range that consists of the result of a map() followed by a value, e.g.: int[] x = [ 1, 2, 3]; auto y = map!(x => x * x)(x); auto z = y ~ 99; // how??? I have tried several variations: convert 99 to a dynamic array, to a range, convert range to dynamic array (couldn't even figure that one); to no avail. [...] Try: auto z = chain(y, only(99)); Thanks! However, when I try to use this construct in my real code, I still have a problem: // k is a ClassInfo chain(map!(i => i.classinfo)(k.interfaces), only(k.base)) meth.d(311): Error: template std.range.chain cannot deduce function from argument types !()(MapResult!(__lambda3, Interface[]), OnlyResult!(TypeInfo_Class, 1LU)), candidates are: /usr/include/d/std/range/package.d(795): std.range.chain(Ranges...)(Ranges rs) if (Ranges.length > 0 && allSatisfy!(isInputRange, staticMap!(Unqual, Ranges)) && !is(CommonType!(staticMap!(ElementType, staticMap!(Unqual, Ranges))) == void))
Append to 'map' result
I want to create a range that consists of the result of a map() followed by a value, e.g.: int[] x = [ 1, 2, 3]; auto y = map!(x => x * x)(x); auto z = y ~ 99; // how??? I have tried several variations: convert 99 to a dynamic array, to a range, convert range to dynamic array (couldn't even figure that one); to no avail. Help please...
Re: Finding all the interfaces and their inheritance relationships at runtime
On Monday, 3 July 2017 at 22:34:51 UTC, FoxyBrown wrote:
On Monday, 3 July 2017 at 20:45:19 UTC, bauss wrote:
On Monday, 3 July 2017 at 13:54:42 UTC, Jean-Louis Leroy wrote:
I know how to find all the classes:
foreach (mod; ModuleInfo) {
foreach (c; mod.localClasses) {
// use c.base to construct inheritance graph
}
}
Can I do the same with all the interfaces? Looking at
object.d gives no clue...
Is there a reason you need to do it with runtime and can't use
__traits?
He didn't say *with* runtime but *at*. Changes the whole
meaning ;)
It's OK I found how to achieve what I want. I'll enumerate the
classes an dfrom there work my way down via ClassInfo.interfaces.
It turns out that Interface.classinfocontains the interface's
inherited interfaces; the 'classinfo' name is a bit misleading
though...
Finding all the interfaces and their inheritance relationships at runtime
I know how to find all the classes:
foreach (mod; ModuleInfo) {
foreach (c; mod.localClasses) {
// use c.base to construct inheritance graph
}
}
Can I do the same with all the interfaces? Looking at object.d
gives no clue...
Transforming an argument list
Another meta-programming question ;-)
Inside a variadic function template that takes a list of
arguments, I want to call another function and pass it the
arguments run through another function. In C++ it would look like
this:
template
T double_int(T val) { return val; }
int double_int(int val) { return 2 * val; }
template
void double_ints(void F(T...), T... args) {
F(double_int(args)...);
}
void test(const char* str, int val) {
cout << str << " = " << val << "\n";
}
int main() {
double_ints(test, "1 + 2", 3); // 1 + 2 = 6
return 0;
}
I tried this in D:
void test(string name, int val)
{
writefln("%s = %d", name, val);
}
template DoubleInt(A...)
{
static if (A.length == 0)
alias DoubleInt = AliasSeq!();
else static if (is(typeof(A[0]) == int))
alias DoubleInt = AliasSeq!(2 * A[0], DoubleInt!(A[1..$]));
else
alias DoubleInt = AliasSeq!(A[0], DoubleInt!(A[1..$]));
}
void double_ints(F, A...)(F f, A args)
{
f(DoubleInt!args);
}
void main()
{
double_ints(, "1 + 2", 3);
}
...but ldc2 complains that "variable __args_field_1 cannot be
read at compile time". Yeah, I understand...
I also tried a solution similar to C++:
A DoubleInt(A)(A a)
if (!is(typeof(A) == int))
{
return a;
}
A DoubleInt(A)(A a)
if (is(typeof(A) == int))
{
return 2 * a;
}
void double_ints(F, A...)(F f, A args)
{
f(DoubleInt!(args));
}
...but I get: "template instance callas.double_ints!(void
function(string, int), string, int) error instantiating". The
difference with C++ is that I don't get to control the expansion
of the argument pack: "f(DoubleInt!(args))" is interpreted as
"f(DoubleInt!(args...))", not "f(DoubleInt!(args))...".
Any ideas? Thanks...
Re: AliasSeq of AliasSeq, or meta-functions that take multiple lists
On Monday, 19 June 2017 at 20:59:33 UTC, Ali Çehreli wrote:
On 06/19/2017 12:54 PM, Jean-Louis Leroy wrote:
I need to process two sequences in parallel (select some
elements of
sequence A depending of the corresponding element of sequence
B). How
can I pass two sequences to a meta-function? I tried nesting
AliasSeqs
but I get Perl4 style flattening:
AliasSeq!(AliasSeq!(int, float),
AliasSeq!(char, double))
-> (int,float,char,double)
I worked around the problem by passing a single AliasSeq to my
meta-function and using indexation to access the two sub-lists
but now I
need to process three sequences in parallel and I am looking
for a
cleaner solution.
Hi Jean-Louis! :)
One option is to nest templates:
template foo(Args1...) {
void bar(Args2...)() {
}
}
void main() {
foo!(int, float).bar!(char, double)();
}
Ali
Hi Ali :)
Thanks! It works perfectly for my purpose, which is to manipulate
lists of types or values based on a list of types, e.g.:
alias ParTypes = AliasSeq!(virtual!A, int, virtual!B);
Signature!(ParTypes).UnqualArgs -> AliasSeq!(A, int, B)
Signature!(ParTypes).VirtualArgs -> AliasSeq!(A, B)
Signature!(ParTypes).Filter!(AliasSeq!(A, int, B)) ->
AliasSeq!(A, B)
J-L
AliasSeq of AliasSeq, or meta-functions that take multiple lists
I need to process two sequences in parallel (select some elements of sequence A depending of the corresponding element of sequence B). How can I pass two sequences to a meta-function? I tried nesting AliasSeqs but I get Perl4 style flattening: AliasSeq!(AliasSeq!(int, float), AliasSeq!(char, double)) -> (int,float,char,double) I worked around the problem by passing a single AliasSeq to my meta-function and using indexation to access the two sub-lists but now I need to process three sequences in parallel and I am looking for a cleaner solution.
