Re: proposal: private module-level import for faster compilation

On Sunday, 24 July 2016 at 15:33:04 UTC, Chris Wright wrote: Look at std.algorithm. Tons of methods, and I imported it just for `canFind` and `sort`. Look at std.datetime. It imports eight or ten different modules, and it needs every one of those for something or other. Should we split it

Re: proposal: private module-level import for faster compilation

On 2016-07-25 01:12, Dicebot wrote: Benjamin proposed to stop considering `export` a protection attribute and mark all functions called from templates as `export` (allowing `export private` if necessary). Ah, forgot that detail. -- /Jacob Carlborg

Re: proposal: private module-level import for faster compilation

On Saturday, 23 July 2016 at 19:22:09 UTC, Jacob Carlborg wrote: How does this relate to templates? Or is the suggestion to now use templates on API boundaries? Benjamin proposed to stop considering `export` a protection attribute and mark all functions called from templates as `export`

Re: proposal: private module-level import for faster compilation

On Sun, 24 Jul 2016 12:53:50 +, Sebastien Alaiwan wrote: > Speeding up compilation should never be considered as an acceptable > solution here, as it's not scalable: it just pushes the problem away, > until your project size increases enough. In order to get an equivalent speedup by

Re: proposal: private module-level import for faster compilation

On Wednesday, 20 July 2016 at 19:59:42 UTC, Jack Stouffer wrote: I concur. If the root problem is slow compilation, then there are much simpler, non-breaking changes that can be made to fix that. I don't think compilation time is a problem, actually. It more has to do with dependency

Re: proposal: private module-level import for faster compilation

On 2016-07-22 10:28, Dicebot wrote: .. which naturally leads to watching about Benjamin DConf talk about fixing "export" and that is where everything clicks together. Organizing large projects as bunch of small static libraries per package and defining public API of those via `export` (and not

Re: proposal: private module-level import for faster compilation

On Friday, 22 July 2016 at 10:47:33 UTC, Bauss wrote: On Wednesday, 20 July 2016 at 07:50:13 UTC, Timothee Cour wrote: typo: s/dmd -c -o- -deps A.d/dmd -c -o- -deps B.d On Wed, Jul 20, 2016 at 12:45 AM, Timothee Cour wrote: [...] I believe private import is

Re: proposal: private module-level import for faster compilation

On Wednesday, 20 July 2016 at 07:50:13 UTC, Timothee Cour wrote: typo: s/dmd -c -o- -deps A.d/dmd -c -o- -deps B.d On Wed, Jul 20, 2016 at 12:45 AM, Timothee Cour wrote: [...] I believe private import is already reserved. It's being used 618 places inside of

Re: proposal: private module-level import for faster compilation

On 07/22/2016 10:23 AM, Kagamin wrote: > On Friday, 22 July 2016 at 06:38:25 UTC, Jacob Carlborg wrote: >> The .di/header for module "a" don't need to include "import b" because >> "Bar" is not part of the interface of module "a". > > It works for your example, but doesn't work for idiomatic D

Re: proposal: private module-level import for faster compilation

On Friday, 22 July 2016 at 06:38:25 UTC, Jacob Carlborg wrote: The .di/header for module "a" don't need to include "import b" because "Bar" is not part of the interface of module "a". It works for your example, but doesn't work for idiomatic D code, which is always heavily templated.

Re: proposal: private module-level import for faster compilation

On 2016-07-21 10:52, Kagamin wrote: As I see dependency resolution has function granularity, but headers have only file granularity. How do you expect headers to work on finer granularity level? If a module depends on another module, the header must assume it depends on all members of that

Re: proposal: private module-level import for faster compilation

On Thursday, 21 July 2016 at 08:52:42 UTC, Kagamin wrote: Not sure if tup can solve this problem. It can if it builds full dependency graph for each file instead of having one graph for the whole project. So a solution for make would be -deps reporting full dependency graph per file. Would

Re: proposal: private module-level import for faster compilation

On Wednesday, 20 July 2016 at 09:35:03 UTC, Dicebot wrote: I think this is a wrong approach patching a problem instead of fixing it. Real solution would be to improve and mature .di header generation and usage by compilers so that it can become the default way to import packages/libraries.

Re: proposal: private module-level import for faster compilation

On Wednesday, 20 July 2016 at 19:59:42 UTC, Jack Stouffer wrote: On Wednesday, 20 July 2016 at 19:11:56 UTC, deadalnix wrote: Implementation problem should not be "fixed" by changing the language. I concur. If the root problem is slow compilation, then there are much simpler, non-breaking

Re: proposal: private module-level import for faster compilation

On Wednesday, 20 July 2016 at 19:11:56 UTC, deadalnix wrote: Implementation problem should not be "fixed" by changing the language. I concur. If the root problem is slow compilation, then there are much simpler, non-breaking changes that can be made to fix that.

Re: proposal: private module-level import for faster compilation

On Wednesday, 20 July 2016 at 19:11:56 UTC, deadalnix wrote: Implementation problem should not be "fixed" by changing the language. this, i believe, closes the topic altogether.

Re: proposal: private module-level import for faster compilation

On Wednesday, 20 July 2016 at 18:51:49 UTC, Timothee Cour wrote: That means that a change in any single dependency would trigger recompilations in many files. so what? can you even imagine how many things you'll have to recompile if you'll change something in /usr/include? it's just your tools

Re: proposal: private module-level import for faster compilation

On Wednesday, 20 July 2016 at 07:45:12 UTC, Timothee Cour wrote: currently, top-level imports in a module A are visible by other modules B importing A, and are visited (recursively) during compilation of A, slowing down compilation and increasing dependencies (eg with separate compilation

Re: proposal: private module-level import for faster compilation

Same answer : http://forum.dlang.org/post/nmngk8$inm$1...@digitalmars.com

Re: proposal: private module-level import for faster compilation

On Wednesday, 20 July 2016 at 18:21:46 UTC, ketmar wrote: p.s. the sole improvement in symbol lookup mechanics can speed up the things by several factors, and without breaking the language. current dmdfe symbol/template lookup mechanics is not really fast. If this example weren't enough,

Re: proposal: private module-level import for faster compilation

p.s. the sole improvement in symbol lookup mechanics can speed up the things by several factors, and without breaking the language. current dmdfe symbol/template lookup mechanics is not really fast.

Re: proposal: private module-level import for faster compilation

On Wednesday, 20 July 2016 at 18:09:06 UTC, Timothee Cour wrote: this simple example shows this feature would provide a 16X speedup. 100 ms speedup in exchange of creating another special case in language? no, thank you, won't buy. that was exactly what i meant: if we'll look at *real*

Re: proposal: private module-level import for faster compilation

this simple example shows this feature would provide a 16X speedup. time dmd -c -o- -version=A -I$code main.d 0.16s time dmd -c -o- -version=B -I$code main.d 0.01s ---main.d: module tests.private_import.main; import tests.private_import.fun; void test(){} --- ---fun.d: module

Re: proposal: private module-level import for faster compilation

On Wednesday, 20 July 2016 at 17:05:11 UTC, Jack Stouffer wrote: IIRC compiler also spends extra work on templates because it doesn't cache the result, so things like isInputRange!(string) could be evaluated hundreds of times for your program. it does cache that (see template merging), it

Re: proposal: private module-level import for faster compilation

On Wednesday, 20 July 2016 at 07:45:12 UTC, Timothee Cour wrote: ... This, and function local imports, are hacks around the actual problem: the compilers spending time on codegen on things your program will never use. IIRC compiler also spends extra work on templates because it doesn't

Re: proposal: private module-level import for faster compilation

i can't see what problem this thing is trying to solve. did you ever measured time taken by building AST of imported module? use separate compilation and/or templates to avoid codegen. problem solved.

Re: proposal: private module-level import for faster compilation

I think this is a wrong approach patching a problem instead of fixing it. Real solution would be to improve and mature .di header generation and usage by compilers so that it can become the default way to import packages/libraries.

Re: proposal: private module-level import for faster compilation

typo: s/dmd -c -o- -deps A.d/dmd -c -o- -deps B.d On Wed, Jul 20, 2016 at 12:45 AM, Timothee Cour wrote: > currently, top-level imports in a module A are visible by other modules B > importing A, and are visited (recursively) during compilation of A, slowing > down

proposal: private module-level import for faster compilation

currently, top-level imports in a module A are visible by other modules B importing A, and are visited (recursively) during compilation of A, slowing down compilation and increasing dependencies (eg with separate compilation model, a single file change will trigger a lot of recompilations). I