Re: How to test templates for equality?
template isMyInstanceOf(alias Templ, alias Inst)
{
alias Args = ???; //I don't have idea how to get it
enum bool isMyInstanceOf = __traits(isSame, Templ!(Args),
Inst);
}
Do you have any idea how to solve this? May be standad library
could be improved with such type of test for template instance?
Is new compiler trait is needed for solving this like
alias Args = __traits(getTemplateArgumentList, Inst);
or it could be solved with existing tools?
Re: Visual D: Settings to Improve compil and link process
On 05.07.2014 16:05, ParticlePeter wrote: Hello Community, I thought there's a separate forum for VisualD. It did exist when VisualD was on DSource, so why not add it here as well? Or am I to blind to see? The forum digitalmars.D.ide is probably the best fit. Anyway, this thread is an addition to my previous one in this forum: http://forum.dlang.org/thread/wkkuvzkzeupyfdpwe...@forum.dlang.org I noticed increasing compile times in my projects. As I use only VisualD I would like to understand how I would shorten compile time with this tool. Brief description to my setup, more details can be fond in the other post. I have one Lib, called MyLib consisting of around 15 modules, one class per module, zero to two template methods per class with one type parameter each. All my projects use MyLib, and call the template methods with different types. Most of the compile time of any of theses projects is spent in rebuilding MyLib. I am not sure why and where so much time is spent, but is there a way to profile my COMPILE time with VisualD? The longer compile time is very likely caused by the compiler. You could check Verbose compile (command line option -v) to see what templates are expanded and what functions are compiled. This might give you a hint where the compiler spends the time. There are several VisualD project properties which I do not understand fully, but hope that they might help, namely: Configuration Properties - General - Files to clean Configuration Properties - Compiler - Output - Multiple Object Files Configuration Properties - Compiler - Output - Keep Path From Source File Could not cleaning some files improve compilation ? No. Could Multiple Object Files be used to separately compile non-template and template code blocks ? No. This option exposes an undocumented command line option that splits a module into multiple object files as if dmd creates a library. Do not use it. What does Keep Path From Source File do at all ? This instructs dmd to not strip the path components from module source file name when generating the object file name. This avoids troubles if you build to multiple object files, but there are modules with identical names in different packages. It is possible to remove the template methods from my classes, create free functions instead and use them in a UFCS way. Unfortunately I have not figured out UFCS properly, as my approaches do not work ( guess due to UFCS restrictions ). That would not help, templates are instantiated and compiled when they are used, not when they are declared. Anyway, would it help ( and is it possible at all ) to put the template functions in a separate module so that only the corresponding object file requires a recompile ? I am asking in the context of the Multiple Object Files setting. Incremental building of single object files is not well supported by dmd, there are too many troubles with instantiating templates in different object files. I tried to not build MyLib at all, and use the sources directly, but the project setup is kind of confusing. Again, there is a setting which I seem to not understand fully. So one project, lets say MyProject, has only its own module files added to the VisualD project. I want the compiler to also use the MyLib source files, but do not want to add them to MyProject, reasoning bellow. There is one entry in the project properties, which should make this behavior possible, but it doses not. Why ? Configuration Properties - Compiler - General - Additional Imports As far as I understand this setting, I am supposed to enter module search paths. This is correct. But I do get linker errors when I do not add either MyLib.lib to the linker settings or all the source files of MyLib to MyProject. You should add a dependency in the Project - Project Dependencies dialog. This will ensure proper rebuilds and add the library to the command line of dependent projects. Reasoning why I do not want to do this: I have one solution file with the MyLib project and ten projects like MyProject using MyLib. I would need to add all the source files to all the projects, they would be reachable and editable at 11 different location within my solution file. This does not not seem to be a clean way to set it up. Any advice to any or all the thoughts and issues ? Thanks in advance. Cheers, ParticlePeter
Re: dependency graph
If you compile your project with the -deps flag, the compiler will output import dependencies. With -deps=filename, the output will go into filename. From there, you'll have to parse and create the graph, though. Maybe have a look into rdmd source, to see how the dependency extraction is done there?
Re: What exactly module in D means?
On Sat, Jul 5, 2014 at 6:35 PM, Andre Tampubolon via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: I've been reading the newsgroup for a while, and it seems that one of the reason folks like D is because it supports module. My question is: what does module mean? A quick google pointed my this page: http://dlang.org/module.html. Still cannot understand it, though :) How does it differ from the old C's #include? Well, module are 'more first-class' in D than in C. By this, I mean that they have an identity: a name, members, symbols. You can see them as a enormous struct/class. You can use introspection to obtain the symbols defined in a module, query their types, etc. Heck, in some cases, module names can even by used as arguments for templates. As others said, a D module is a unit of encapsulation: inside a module, functions, structs and classes can freely call one other and access their internal fields. Outside the module, only what's not private is visible. Thus, you can create complex, interdependent structures inside your module, but export only some parts for public access. This way, you control a module 'interface', its external frontier. Importing a module in D means the public symbols defined in the module become accessible in the importer. There is no need to import all visible symbols in your current scope: you can restrict your import to only one or two symbols, rename them, etc. That's much more powerful than C when it comes to name clashes. Different 'downstream' modules can import the same 'upstream' module, and choose to import different symbols. No need to do a big 'import everything in the current scope'. symbols names are also defined on a per-module basis: two different modules can have members with a similar name, without clash: just prefix the names with the module name to differentiate them (or rename one while importing). Also, `import foo;` is a statement, you can put it everywhere a statement is legit. That's a recent addition (ie, 1-2 year?), that Andrei likes to call 'Turtles all the way down' and is quickly becoming a D idiom: import a symbol near its use place: inside a function, a method, even inside an if branch: that avoid scope pollution and nicely documents where a symbol is necessary.
Re: implib and system dlls, oh my
You may want to spearhead the effort to get Win32 support of MSVC into D, if you care enough about it. Rainer has done most of the work, you'd just have to turn his patches into pull requests, shepherd them through the review process, and maybe add some polish: http://forum.dlang.org/thread/mailman.1560.1323886804.24802.digitalmar...@puremagic.com?page=9#post-llldfc:242q6p:241:40digitalmars.com Let me see what I can do for time. There's the above, it's also possible to link mixed coff and omf with jwlink (http://www.japheth.de/JWlink/JWlink.htm). There's a couple of paths and while win32 isn't leading edge, I think enhancing it is a worthwhile project for lesser lights like myself.
Re: Problem Linking Phobos git master
Do you have an DFLAGS environment variable set on your system? It looks like the environment variable is used instead of the make file variable while compiling. Yep, the DFLAGS parameter was given to the make call. Removing it... Thx!
dmd dub from git master
Trying to use dub git master with dmd git master fails as[per:/home/per] master(+20/-466) ± dub init vibtest vibe.d Successfully created an empty project in '/home/per/vibtest'. [per:/home/per] master(+20/-466) ± cd vibtest/ /home/per/vibtest [per:/home/per/vibtest] $ dub Fetching vibe-d 0.7.20 (getting selected version)... Placing vibe-d 0.7.20 to /home/per/.dub/packages/... Building vibe-d 0.7.20 configuration libevent, build type debug. Running dmd... ../.dub/packages/vibe-d-0.7.20/source/vibe/templ/parsertools.d(12): Error: module metastrings is in file 'std/metastrings.d' which cannot be read import path[0] = ../.dub/packages/vibe-d-0.7.20/source/ import path[1] = ../.dub/packages/libevent-master import path[2] = ../.dub/packages/openssl-master import path[3] = /home/per/opt/x86_64-unknown-linux-gnu/dmd/bin/../lib import path[4] = /home/per/opt/x86_64-unknown-linux-gnu/dmd/bin/../include/d2 import path[5] = /home/per/opt/x86_64-unknown-linux-gnu/dmd/bin/../import FAIL ../.dub/packages/vibe-d-0.7.20/.dub/build/libevent-debug-linux.posix-x86_64-dmd-7D4E6F7D7874CAC10CFE2C8A1AA191A2/ vibe-d staticLibrary Error executing command run: dmd failed with exit code 1. Should I use a specific release of vibe.d instead? If so should I give a specific version to dub init or to dub ?
Re: dmd dub from git master
What is the syntax for specifying a specific package version (in my case ~master) when calling dub init?
Re: dmd dub from git master
On Sunday, 6 July 2014 at 09:54:11 UTC, Nordlöw wrote: I believe I need git master instead of latest release because of https://github.com/rejectedsoftware/vibe.d/commits/master If I change vibe-d: ~0.7.19 to vibe-d: ~master followed by dub upgrade and dub I instead get Package vibe-d can be upgraded from ~master to 0.7.20. Use dub upgrade to perform those changes. WARNING: A deprecated branch based version specification is used for the dependency vibe-d. Please use numbered versions instead. Also note that you can still use the dub.selections.json file to override a certain dependency to use a branch instead. Building vibe-d ~master configuration libevent, build type debug. Running dmd... ../.dub/packages/vibe-d-master/source/vibe/core/drivers/libevent2.d(461): Deprecation: function core.time.Duration.fracSec is deprecated - Please use split instead. ../.dub/packages/vibe-d-master/source/vibe/core/drivers/libevent2_tcp.d(110): Deprecation: function core.time.Duration.fracSec is deprecated - Please use split instead. ../.dub/packages/vibe-d-master/source/vibe/core/drivers/libevent2_tcp.d(269): Deprecation: function core.time.Duration.fracSec is deprecated - Please use split instead. ../.dub/packages/vibe-d-master/source/vibe/inet/message.d(186): Deprecation: constructor std.datetime.SimpleTimeZone.this is deprecated - Please use the overload which takes a Duration. ../.dub/packages/vibe-d-master/source/vibe/utils/memory.d(193): Warning: calling std.exception.enforceEx!(OutOfMemoryError).enforceEx!bool.enforceEx without side effects discards return value of type bool, prepend a cast(void) if intentional FAIL ../.dub/packages/vibe-d-master/.dub/build/libevent-debug-linux.posix-x86_64-dmd-7D4E6F7D7874CAC10CFE2C8A1AA191A2/ vibe-d staticLibrary Error executing command run: dmd failed with exit code 1.
Re: dependency graph
On Saturday, 5 July 2014 at 15:33:51 UTC, Vlad Levenfeld wrote: A colleague of mine had asked me if I could produce some kind of object/module dependency type of graph for a D project I've got. I'm not sure what these are called but I've seen them before for inheritance hierarchies in C++ projects. (I don't tend to use inheritance so I suspect something exactly like this would not be terribly helpful in my case but some kind of general layout of symbol dependencies would be). Is there any utility out there for building a visual representation of my project? This may be what you're looking for: http://code.dlang.org/packages/duml
Re: dmd dub from git master
I hit this myself also. I was trying to use the master branch DMD, druntime, and phobos with a recent vibe.d for building the documentation with ddox, and I ran into the reliance on std.metastrings.
[dmd 2.066] Is scope with nothrow regression?
```
void bar()
{
throw new Exception();
}
void foo() nothrow
{
scope(failure) {}
bar();
}
void main() {}
```
Doesn't compile with 2.066:
```
source/app.d(9): Error: 'app.bar' is not nothrow
source/app.d(6): Error: function 'app.foo' is nothrow yet may
throw
```
Re: [dmd 2.066] Is scope with nothrow regression?
On Sunday, 6 July 2014 at 12:31:42 UTC, NCrashed wrote:
```
void bar()
{
throw new Exception();
}
void foo() nothrow
{
scope(failure) {}
bar();
}
void main() {}
```
Doesn't compile with 2.066:
```
source/app.d(9): Error: 'app.bar' is not nothrow
source/app.d(6): Error: function 'app.foo' is nothrow yet may
throw
```
This is not an error. `scope(failure)` doesn't swallow the
exceptions it catches, it rethrows them when it's done.
MmFile.unmap() errs on empty file
I just spent two hours tracking down a bug caused by the fact that MmFile's ctor gladly accepts mapping an empty file but its member function unmap() will not. Is this a known issue?
Problem building vibe.d in test project
I've setup a test project for vibe.d using dub at https://github.com/nordlow/vibe-test but when I type dub It err as follows: [per:/home/per/vibtest] 5s 2 $ dub WARNING: A deprecated branch based version specification is used for the dependency vibe-d. Please use numbered versions instead. Also note that you can still use the dub.selections.json file to override a certain dependency to use a branch instead. Building vibe-d ~master configuration libevent, build type debug. Running dmd... ../.dub/packages/vibe-d-master/source/vibe/core/drivers/libevent2.d(461): Deprecation: function core.time.Duration.fracSec is deprecated - Please use split instead. ../.dub/packages/vibe-d-master/source/vibe/core/drivers/libevent2_tcp.d(110): Deprecation: function core.time.Duration.fracSec is deprecated - Please use split instead. ../.dub/packages/vibe-d-master/source/vibe/core/drivers/libevent2_tcp.d(269): Deprecation: function core.time.Duration.fracSec is deprecated - Please use split instead. ../.dub/packages/vibe-d-master/source/vibe/inet/message.d(186): Deprecation: constructor std.datetime.SimpleTimeZone.this is deprecated - Please use the overload which takes a Duration. ../.dub/packages/vibe-d-master/source/vibe/utils/memory.d(193): Warning: calling std.exception.enforceEx!(OutOfMemoryError).enforceEx!bool.enforceEx without side effects discards return value of type bool, prepend a cast(void) if intentional FAIL ../.dub/packages/vibe-d-master/.dub/build/libevent-debug-linux.posix-x86_64-dmd-7D4E6F7D7874CAC10CFE2C8A1AA191A2/ vibe-d staticLibrary Error executing command run: dmd failed with exit code 1. What's wrong? I'm sitting on 64-bit Ubuntu 14.04.
Re: How to test templates for equality?
On 07/05/2014 10:33 PM, Uranuz wrote:
I have another question about testing if given symbol is instance of the
given template and geting it's template arguments.
Applying Rene Zwanenburg's message... It is not complete because
integral template parameters don't work yet.
import std.typetuple;
template instanceArgsOf(alias S, T)
{
import std.traits : isInstanceOf;
static if (isInstanceOf!(S, T))
{
static if (is(T == S!Args, Args...)) {
alias instanceArgsOf = Args;
} else {
alias instanceArgsOf = void;
}
} else {
alias instanceArgsOf = void;
}
}
unittest
{
// Adapting the unittests of std.traits.isInstanceOf
static struct Foo(T...) { }
static struct Bar(T...) { }
static struct Doo(T) { }
static struct ABC(int x) { }
static assert(is (instanceArgsOf!(Foo, Foo!(int, double)) ==
TypeTuple!(int, double)));
static assert(is (instanceArgsOf!(Foo, Bar!int) == void));
static assert(is (instanceArgsOf!(Foo, int) == void));
static assert(is (instanceArgsOf!(Doo, Doo!int) == TypeTuple!(int)));
/*
* The following needs more work because what comes back is something
* called a 'tuple(1)' (Yes, in lowercase.)
*
* static assert(is (instanceArgsOf!(ABC, ABC!1) == TypeTuple!(1)));
*/
static assert(!__traits(compiles, instanceArgsOf!(Foo, Foo)));
}
void main()
{}
Ali
Re: Visual D: Settings to Improve compil and link process
On Sunday, 6 July 2014 at 08:09:07 UTC, Rainer Schuetze wrote: On 05.07.2014 16:05, ParticlePeter wrote: ... It is possible to remove the template methods from my classes, create free functions instead and use them in a UFCS way. Unfortunately I have not figured out UFCS properly, as my approaches do not work ( guess due to UFCS restrictions ). That would not help, templates are instantiated and compiled when they are used, not when they are declared. Hence the idea of splitting the class. After the split, the class has only non-template methods and is part of MyLib. Template UFCS functions working with this class are in another module, and not part of the lib. With this approach MyLib does not need to recompile, only the UFCS functions module needs to recompile due to different instantiations. UFCS works now for me btw. I tried to not build MyLib at all, and use the sources directly, but the project setup is kind of confusing. Again, there is a setting which I seem to not understand fully. So one project, lets say MyProject, has only its own module files added to the VisualD project. I want the compiler to also use the MyLib source files, but do not want to add them to MyProject, reasoning bellow. There is one entry in the project properties, which should make this behavior possible, but it doses not. Why ? Configuration Properties - Compiler - General - Additional Imports As far as I understand this setting, I am supposed to enter module search paths. This is correct. But I do get linker errors when I do not add either MyLib.lib to the linker settings or all the source files of MyLib to MyProject. You should add a dependency in the Project - Project Dependencies dialog. This will ensure proper rebuilds and add the library to the command line of dependent projects. The idea is to NOT create a lib, but just use the source code from MyLib in MyProject as additional includes. No project dependencies. I was hoping that some .obj files are still available from last builds, and do not need to recompile, as they are up to date ( reason for question about not cleaning files ). The modules form MyProject do import the MyLib modules properly, I do not get compiler errors. However, the compiler should create Object files from MyLib modules, and the linker should link them. But he does not. On the other hand, when I add MyLib modules to MyProject ( Rightclick MyProject - add - existing item... MyLib source files ) then linking works. I do not understand why the later step is necessary.
Re: How to test templates for equality?
Seeing his example, the OP wants a solution that works even for templates:
template Test1(T) {}
pragma(msg, instanceArgsOf!(Test1, Test1!int));
which fails because Test1!int is not a type (std.traits.isInstanceOf
fails also, for the same reason).
And is(symbol == Name!Args, Args...) does not work if Name!Args and
symbol are not types.
In this particular case, the only solution I know of is an awful hack:
using .stringof and __traits(identifier, x) and then parse the
strings:
Name!(int, double[string]) and Name(T, U[V], U, V)
and then the fun begins: in the general case, you must then equate the
arguments lists (recursively).
Philippe
Re: Visual D: Settings to Improve compil and link process
On 06.07.2014 19:51, ParticlePeter wrote: On Sunday, 6 July 2014 at 08:09:07 UTC, Rainer Schuetze wrote: On 05.07.2014 16:05, ParticlePeter wrote: ... It is possible to remove the template methods from my classes, create free functions instead and use them in a UFCS way. Unfortunately I have not figured out UFCS properly, as my approaches do not work ( guess due to UFCS restrictions ). That would not help, templates are instantiated and compiled when they are used, not when they are declared. Hence the idea of splitting the class. After the split, the class has only non-template methods and is part of MyLib. Template UFCS functions working with this class are in another module, and not part of the lib. With this approach MyLib does not need to recompile, only the UFCS functions module needs to recompile due to different instantiations. UFCS works now for me btw. Ok, that allows separate compilation of the class, but templates are still compiled with the rest of the program. I thought the templates were the part that cause the slow compilation. I tried to not build MyLib at all, and use the sources directly, but the project setup is kind of confusing. Again, there is a setting which I seem to not understand fully. So one project, lets say MyProject, has only its own module files added to the VisualD project. I want the compiler to also use the MyLib source files, but do not want to add them to MyProject, reasoning bellow. There is one entry in the project properties, which should make this behavior possible, but it doses not. Why ? Configuration Properties - Compiler - General - Additional Imports As far as I understand this setting, I am supposed to enter module search paths. This is correct. But I do get linker errors when I do not add either MyLib.lib to the linker settings or all the source files of MyLib to MyProject. You should add a dependency in the Project - Project Dependencies dialog. This will ensure proper rebuilds and add the library to the command line of dependent projects. The idea is to NOT create a lib, but just use the source code from MyLib in MyProject as additional includes. No project dependencies. I was hoping that some .obj files are still available from last builds, and do not need to recompile, as they are up to date ( reason for question about not cleaning files ). These object files are in the library ;-) That means manual selection, though, as incremental builds to multiple object files don't work with dmd, and single file compilation is painfully slow. The modules form MyProject do import the MyLib modules properly, I do not get compiler errors. However, the compiler should create Object files from MyLib modules, and the linker should link them. But he does not. On the other hand, when I add MyLib modules to MyProject ( Rightclick MyProject - add - existing item... MyLib source files ) then linking works. I do not understand why the later step is necessary. dmd does not compile imported modules, but rdmd does.
Re: [dmd 2.066] Is scope with nothrow regression?
On Sunday, 6 July 2014 at 12:31:42 UTC, NCrashed wrote:
```
void bar()
{
throw new Exception();
}
void foo() nothrow
{
scope(failure) {}
bar();
}
void main() {}
```
Doesn't compile with 2.066:
```
source/app.d(9): Error: 'app.bar' is not nothrow
source/app.d(6): Error: function 'app.foo' is nothrow yet may
throw
```
This is a bug which was already fixed.
Instead, you can use this:
scope(failure) assert(0);
See: https://issues.dlang.org/show_bug.cgi?id=11542
Re: [dmd 2.066] Is scope with nothrow regression?
On Sunday, 6 July 2014 at 13:04:35 UTC, Marc Schütz wrote:
On Sunday, 6 July 2014 at 12:31:42 UTC, NCrashed wrote:
```
void bar()
{
throw new Exception();
}
void foo() nothrow
{
scope(failure) {}
bar();
}
void main() {}
```
Doesn't compile with 2.066:
```
source/app.d(9): Error: 'app.bar' is not nothrow
source/app.d(6): Error: function 'app.foo' is nothrow yet may
throw
```
This is not an error. `scope(failure)` doesn't swallow the
exceptions it catches, it rethrows them when it's done.
Thank you, I was expecting different behavior for a long time and
now will use try-catch instead.
Re: [dmd 2.066] Is scope with nothrow regression?
On Sunday, 6 July 2014 at 22:03:21 UTC, hane wrote:
On Sunday, 6 July 2014 at 12:31:42 UTC, NCrashed wrote:
```
void bar()
{
throw new Exception();
}
void foo() nothrow
{
scope(failure) {}
bar();
}
void main() {}
```
Doesn't compile with 2.066:
```
source/app.d(9): Error: 'app.bar' is not nothrow
source/app.d(6): Error: function 'app.foo' is nothrow yet may
throw
```
This is a bug which was already fixed.
Instead, you can use this:
scope(failure) assert(0);
See: https://issues.dlang.org/show_bug.cgi?id=11542
To be exact: a bug I said is that scope(failure) { } breaks
nothrow checking.
Re: recursive definition error
On Friday, 4 July 2014 at 21:15:02 UTC, Frustrated wrote:
On Friday, 4 July 2014 at 20:25:28 UTC, Frustrated wrote:
On Friday, 4 July 2014 at 16:31:28 UTC, Stanislav Blinov wrote:
On Friday, 4 July 2014 at 16:28:48 UTC, Frustrated wrote:
On Friday, 4 July 2014 at 15:42:36 UTC, bearophile wrote:
Frustrated:
I'm not using 2.066 though...
I will revert back to the dmd version I was using when it
worked... Hopefully someone can make sure this is not a
regression in the mean time... (seems like it is and I don't
want to get bit again later on when I upgrade)
That template and its instantiation work fine for me on both
2.065 and 2.066b1.
Ok, I do not know where this error creeped in at. I do know at
one point the code was working fine without any changes I
believe. (it's possible though I messed something up)
The recursive error seems to be the wrong issue. Trying to
diagnose what the problem is now.
This must be some weird issue with Array or a change in what
imports does.
e.g.,
if I do
struct apple(T) { }
template Array(T) { alias apple!T Array; }
Then the code works(except I no longer can use array as an
array but I do not get any recursive issues.
The compiler I was using when it worked might have been pre
2.064... Or possibly something else is going on that breaks the
code.
Best I can tell is that the compiler is getting confused
between std.container.Array and my Array.
This seems to be a regression as it works fine in 2.064. The
error is not directly due to recursion as far as I can tell but
in a template that uses the Array template. Why it breaks the
array I have no idea. I will try to create a minimal project for
it.
Re: recursive definition error
So, I took all the code surrounding the error message(which was a lot of code) and stuck it into one .d file. No errors! Works as expected. So, WTF?!?! I guess now I have to attempt to split the code across modules to see WTF is going on? Maybe this is a modules issue. I know some of the code I'm using deals with module resolution and there was some talk in the main forum about changing something to do with modules. Could this be the issue? D really needs a better fing way to debug templates or improve the error messages. I'm dealing with about 20k lines of code spread across about 100 modules and the error messages are completely useless as when I put all the code surrounding what it says is causing the error, I do not get the error. Realize, this code works fine in 2.064 so it's not a coding issue as if something magical with my fingers when I copy the code from the modules into a single .d file. Either something was fixed or something was broke... after all the work I spend trying to figure out what was causing the problem, I'm just as clueless.
