On 27 April 2017 at 17:15, Jack Stouffer via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> * Docs which allow people to go back and see docs for previous versions. Huge headache when using GDC or LDC
>

Maybe you could submit a patch to add build hook to generate the documentation for GDC.  It would be a welcome contribution to add to the current bulk of documentation I'm starting to build up. ;-)

On Thursday, 27 April 2017 at 17:47:19 UTC, Moritz Maxeiner wrote:
> On Thursday, 27 April 2017 at 17:06:39 UTC, Andre Pany wrote:
>>
>> Another big issue for me is using dub in a company. Big companies do not want to use the official dub repository due to security issues. They want to run their own dub repository with dub packages they have done code checks. That means also the git projects are mirrored in git repositories within the company. First step into this direction is to have the possibility to specify the dub repository address within the dub.json.
>
> Is there a problem with just using the dub command line arguments for this?
> # cat > /usr/local/bin/company-dub
> #! /bin/sh
> /usr/bin/env dub --skip-registry=standard --registry=YOUR_COMPANYS_REGISTRY

As workaround this is possible. Every developer and in every continious integration build step, dub is used, you have to remember to use these arguments. Defining it one time in dub.json would be great.

Kind regards
Andre

On Thursday, 27 April 2017 at 19:55:44 UTC, Andre Pany wrote:
> On Thursday, 27 April 2017 at 17:47:19 UTC, Moritz Maxeiner wrote:
>> On Thursday, 27 April 2017 at 17:06:39 UTC, Andre Pany wrote:
>>>
>>> Another big issue for me is using dub in a company. Big companies do not want to use the official dub repository due to security issues. They want to run their own dub repository with dub packages they have done code checks. That means also the git projects are mirrored in git repositories within the company. First step into this direction is to have the possibility to specify the dub repository address within the dub.json.
>>
>> Is there a problem with just using the dub command line arguments for this?
>> # cat > /usr/local/bin/company-dub
>> #! /bin/sh
>> /usr/bin/env dub --skip-registry=standard --registry=YOUR_COMPANYS_REGISTRY
>
> As workaround this is possible. Every developer and in every continious integration build step, dub is used, you have to remember to use these arguments. Defining it one time in dub.json would be great.

Alright, I take your point. Since the internal functionality itself is already there, this seems like an easy fix (just add a new field to the json/sdlang parsing of dub and bind it to what the CLI arguments already do). Have you opened a dub issue about this (first step to getting an issue fixed and so on), I wasn't able to find one on first glance?

On Thursday, 27 April 2017 at 14:53:02 UTC, Mike Parker wrote:
> To help in compiling the list, what are some major issues from the ecosystem that you'd like to see fixed?

Backtraces with line information on macOS?

On Thursday, 27 April 2017 at 14:53:02 UTC, Mike Parker wrote:
> This year, DConf has an extra day tacked on for problem solving in the form of a hackathon. The intent is to work on issues people find frustrating in the D ecosystem. While there will be time given at the event for proposals, and those involving third-party projects are welcome, it will help speed things along for the organizers to come in with a list of big issues to get the ball rolling.
>
> To help in compiling the list, what are some major issues from the ecosystem that you'd like to see fixed?

It's probably not a "major issue", but I'd be interested in joining any efforts towards making dub more cross-compilation-friendly. "--compiler=" and "--arch=" aren't quite useful in any serious scenario with multiple target platforms that use different compiler settings and sysroots.

On 2017-04-28 04:12, Luís Marques wrote:

> Backtraces with line information on macOS?

That would be nice. Should be fairly trivial to look at the Linux implementation and to the same but read the data from different sections.

-- 
/Jacob Carlborg

On Thursday, 27 April 2017 at 14:53:02 UTC, Mike Parker wrote:
> This year, DConf has an extra day tacked on for problem solving in the form of a hackathon. The intent is to work on issues people find frustrating in the D ecosystem. While there will be time given at the event for proposals, and those involving third-party projects are welcome, it will help speed things along for the organizers to come in with a list of big issues to get the ball rolling.
>
> To help in compiling the list, what are some major issues from the ecosystem that you'd like to see fixed?

Here's my wishlist:

D's @safe-ty story

DMD as a library (both frontend and backend):
* the backend usable as a JIT library.
* unittests (!= integration tests like those in https://github.com/dlang/dmd/tree/master/test)
* fixing the GC interoperability (AFAIK, dmd currently can't use the GC)
* less coupling (e.g. https://github.com/dlang/dmd/pull/6625)
* no use of global state, except in the compiler driver
* task-based parallelism
* better docs
etc.

D REPL based on dmd library. There were a couple of attempts (e.g. https://github.com/callumenator/dabble, https://github.com/MartinNowak/drepl), but as far I know, none of them is using dmd as a library and I'm not sure how close they are actually being useful.

AST introspection - given a function definition (!= declaration, i.e. the body is available) f, the expression __traits(ast, f) should return an instance of FuncDeclaration (https://github.com/dlang/dmd/blob/197ff0fd84b7b101f47458ab06e5b6f95959941e/src/ddmd/astnull.d#L151) with all of its members filled. The class-es used to represent the AST should be plain old data types (i.e. should contain no functionality). The AST as produced by the parser should be returned, without any semantic analysis (which can modify it). No backwards compatibility guarantees should be made about __traits(ast, f) at least for a couple of years.

DMD usable as a library can help the various IDE projects improve the user experience, which is major complaint of new comers (e.g. better auto-completion, refactoring, etc).
AST introspection (in addition with the previous point) is needed for D to remain competitive on the metaprogramming front with other rising languages such as Jai or Nim.

I would love to meet and work with other people interested in those areas at DConf.

On Friday, 28 April 2017 at 09:52:29 UTC, Petar Kirov [ZombineDev] wrote:
>
> AST introspection - given a function definition (!= declaration, i.e. the body is available) f, the expression __traits(ast, f) should return an instance of FuncDeclaration (https://github.com/dlang/dmd/blob/197ff0fd84b7b101f47458ab06e5b6f95959941e/src/ddmd/astnull.d#L151) with all of its members filled. The class-es used to represent the AST should be plain old data types (i.e. should contain no functionality). The AST as produced by the parser should be returned, without any semantic analysis (which can modify it). No backwards compatibility guarantees should be made about __traits(ast, f) at least for a couple of years.
>

This sounds interesting, but could you expand on what this enables/improves compared to CTFE+mixins?

On 2017-04-27 19:06, Andre Pany wrote:

> Another big issue for me is using dub in a company. Big companies do not
> want to use the official dub repository due to security issues.

That would be nice.

-- 
/Jacob Carlborg

On Friday, 28 April 2017 at 10:09:32 UTC, Moritz Maxeiner wrote:
> On Friday, 28 April 2017 at 09:52:29 UTC, Petar Kirov [ZombineDev] wrote:
>>
>> AST introspection - given a function definition (!= declaration, i.e. the body is available) f, the expression __traits(ast, f) should return an instance of FuncDeclaration (https://github.com/dlang/dmd/blob/197ff0fd84b7b101f47458ab06e5b6f95959941e/src/ddmd/astnull.d#L151) with all of its members filled. The class-es used to represent the AST should be plain old data types (i.e. should contain no functionality). The AST as produced by the parser should be returned, without any semantic analysis (which can modify it). No backwards compatibility guarantees should be made about __traits(ast, f) at least for a couple of years.
>>
>
> This sounds interesting, but could you expand on what this enables/improves compared to CTFE+mixins?

CTFE and mixins are building blocks, needed to for my idea to actually useful.
Currently if you want to introspect a piece of code (function body) at compile time,
you need to duplicate the code in a string and then pass this string to a
CTFE-able D parser. As you can imagine, even with Stefan's new CTFE engine,
this would be orders of magnitude slower than just reusing the work that parser
inside the compiler *has already done* anyway. This makes such code introspection
infeasible for large projects. Strings (at least until mixined)
can contain uncompilable source (though lexically valid, in the case of q{}),
further complicating the matter. Additionally, the fact that you need to
keep the source code and the strings in sync is just stupid, violating DRY
at a whole new level.

In addition to AST introspection, AST transformation should be as easy as:

mixin template profileFunctionStatements(alias func, string newFunctionName)
{
    enum funcAst = __traits(ast, func);
    enum newAst = insertProfiling(funcAst, newFunctionName);
    mixin(newAst.toString());

    // a further optimization would be AST mixins, which
    // could directly be used by the compiler, instead of
    // first converting the AST to string and then
    // parsing it after mixing:
    mixin(newAst);
}

void main()
{
    int local = 42;

    void fun(int[] arr)
    {
        import std.conv : text;
        import std.file : remove, write;
        arr[] += local;
        string s = text(arr);
        "delete-me.txt".write(s);
    }

    mixin profileFunctionStatements!(print, `funInstrumented`);

    import std.array : array;
    import std.range : iota;
    funInstrumented(10000.iota.array);
}

Output:
{  arr[] += local;  } took 0.002 miliseconds to execute.
{  string s = text(arr);  } took 1.8052 miliseconds to execute.
{ "delete-me.txt".write(s); } took 7.746 miliseconds to execute.

Where funInstrumented could be generated to something like this:

void funInstrumented(int[] arr)
{
    import std.datetime : __Sw = StopWatch, __to = to; // generated
    import std.stdio : __wfln = writefln; // generated
    import std.conv : text;
    import std.file : remove, write;

    __Sw __sw; // generated

    __sw.start(); // generated
    arr[] += local;
    __sw.stop(); // generated
    __wfln("{ %s } took %s miliseconds to execute.",
        q{ arr[] += local; },
        __sw.peek().__to!("msecs", double)); // generated

    __sw.start(); // generated
    string s = text(arr);
    __sw.stop(); // generated
    __wfln("{ %s } took %s miliseconds to execute.",
        q{ string s = text(arr); },
        __sw.peek().__to!("msecs", double)); // generated

    __sw.start(); // generated
    "delete-me.txt".write(s);
     __sw.stop(); // generated
    __wfln("{%s} took %s miliseconds to execute.",
        q{ "delete-me.txt".write(s); },
        __sw.peek().__to!("msecs", double)); // generated
}

Other applications include:
* compiling/transpiling D functions to targets
like JS, SPIR-V, WebAssembly, etc. using CTFE.
* CTFE-driven code diagnostics (linting)
* Adding semantic to user defined attributes:
  E.g. @asyncSafe attribute for use in libraries like vibe.d that allows calling only
  functions marked as @asyncSafe from @asyncSafe code. That way libraries can
  introduce *and enforce* correct use of UDAs without any need for language changes.
* ...