Re: DCD 0.3.0-beta1 and DScanner 0.1.0-beta1

2014-03-02 Thread Suliman

On Wednesday, 5 February 2014 at 12:45:28 UTC, yazd wrote:

On Wednesday, 5 February 2014 at 11:55:59 UTC, Suliman wrote:

On Tuesday, 4 February 2014 at 20:09:18 UTC, yazd wrote:

On Tuesday, 4 February 2014 at 10:19:46 UTC, Suliman wrote:
It's look like Sublime do not understand from which folder 
module should be imported.


It's do not colorized
import readconfig;
if readconfig.d are putted in folder with main file.


Try running 'DKit: Update Import Paths' command in Sublime. 
If that doesn't resolve it, please submit a bug 
https://github.com/yazd/DKit.



Should I past it's here? http://snag.gy/h6b0f.jpg


Use Sublime's Command Palette. Press Ctrl+Shift+P, and start 
writing 'update import paths', you'll get it in a drop-down 
list.



I still can't get it's work. 
http://dynamic.dlang.ru/Files/2014/20e81184-9e39-427e-b06e-dd4de73bcce2.png
Before I would report a bug, could anybody try it? Maybe it's 
just my issue.

My steps:
1. open SL
2. open 2 tabs
3. write code
4. try to compile the code.

result on the screenshot. I also tried to run this command, but 
without result.


Re: Facebook open sources flint, a C++ linter written in D

2014-03-02 Thread Denis Shelomovskij

25.02.2014 16:48, Dicebot пишет:

On Tuesday, 25 February 2014 at 11:20:37 UTC, bearophile wrote:

Currently the D compiler catches several bugs that are caught only by
C lints. Clang shows that you can add lot of lint-like tests to the
compiler. I'd like some more tests in the D compiler.


Full stop. It should be other way around - remove all such arguable
warnings from compiler to dedicated lint tool and never add any single
one to compiler.


I'd say a good static code analysis require a full compiler frontend and 
I see no reasons why there can't be such thing in dmd as it is just as 
required as profiler, unittesting or documentation generation which are 
already in. Of course it has nothing to do with compiler warnings and is 
a separate thing. But looks like people aren't interested in it as 
enhancement request 9811 [1] still has no votes or discussion.


[1] https://d.puremagic.com/issues/show_bug.cgi?id=9811

--
Денис В. Шеломовский
Denis V. Shelomovskij


Re: Facebook open sources flint, a C++ linter written in D

2014-03-02 Thread Dicebot

On Sunday, 2 March 2014 at 12:29:15 UTC, Denis Shelomovskij wrote:
I'd say a good static code analysis require a full compiler 
frontend and I see no reasons why there can't be such thing in 
dmd as it is just as required as profiler, unittesting or 
documentation generation which are already in. Of course it has 
nothing to do with compiler warnings and is a separate thing. 
But looks like people aren't interested in it as enhancement 
request 9811 [1] still has no votes or discussion.


I think built-in profile and documentation is also inferior to 
having those as separate binaries but distributing together with 
compiler and being callable from it. Unit test are different 
because those are much more integrated with language itself.



Compiler as a (dynamic) library is the way to go.


Re: Facebook open sources flint, a C++ linter written in D

2014-03-02 Thread Nick Sabalausky

On 3/2/2014 7:35 AM, Dicebot wrote:

On Sunday, 2 March 2014 at 12:29:15 UTC, Denis Shelomovskij wrote:

I'd say a good static code analysis require a full compiler frontend
and I see no reasons why there can't be such thing in dmd as it is
just as required as profiler, unittesting or documentation generation
which are already in. Of course it has nothing to do with compiler
warnings and is a separate thing. But looks like people aren't
interested in it as enhancement request 9811 [1] still has no votes or
discussion.


I think built-in profile and documentation is also inferior to having
those as separate binaries but distributing together with compiler and
being callable from it. Unit test are different because those are much
more integrated with language itself.



Personally, I've never really understood the benefit one way or another 
of related tools being in one binary vs multiple binaries. As I see it, 
the important thing is that all relevant *source* is well-encapsulated. 
Unless you're on a system where kilobytes matter (ie, if you're in a 
time warp), anything else just comes down to a matter of:


git clone url
dmd -profile src.d

vs

git-clone url
dmd-profile src.d



Compiler as a (dynamic) library is the way to go.


Definitely!



Re: Facebook open sources flint, a C++ linter written in D

2014-03-02 Thread Dicebot

On Sunday, 2 March 2014 at 21:41:26 UTC, Nick Sabalausky wrote:
Personally, I've never really understood the benefit one way or 
another of related tools being in one binary vs multiple 
binaries. As I see it, the important thing is that all relevant 
*source* is well-encapsulated. Unless you're on a system where 
kilobytes matter (ie, if you're in a time warp), anything else 
just comes down to a matter of:


...


Main difference that matters is separation of the code base that 
makes maintenance of each tool independent from compiler core and 
thus easier. This also propagates to separation of CLI flags and 
configuration files and so on, allowing for more combined 
interface complexity.


git CLI is designed hierarchically so passing all those 
parameters is obvious. This can't be done for dmd without 
changing it CLI completely or introducing some weird hacks.