On Friday, 28 April 2017 at 13:31:33 UTC, Petar Kirov [ZombineDev] wrote:
> [...]
>
> 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.
> * ...

Thanks for the summary :)

On Friday, 28 April 2017 at 13:31:33 UTC, Petar Kirov [ZombineDev] wrote:
> Other applications include:
> * compiling/transpiling D functions to targets
> like JS, SPIR-V,

I got you covered ;)
(LDC not CTFE though. It would be fiendishly complicated to do at CTFE as a fair amount of compiler magic is necessary.)

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?

Not so much major issue but I would like to:
    * figure out a solution for https://github.com/ldc-developers/ldc/issues/2011
    * consider the merits of standardising allocSize (https://github.com/ldc-developers/druntime/blob/ldc/src/ldc/attributes.d#L16) or equivalent among dmd/ldc/gdc
    * get half precision floating point into the language /or/ ability to create __vector's of user types (need for intrinsics for GPU et al targets of dcompute).

I would also like to hold a mini hackathon/gauge interest in dcompute as we could benefit significantly from the ML craze.

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?

Wishlist
1) Make alias parameters work with buildin types, I bet anyone using D has fallen into trip trap.

alias X(alias T) = T;
X!int x;

On Saturday, 29 April 2017 at 00:54:59 UTC, Nicholas Wilson wrote:
> On Friday, 28 April 2017 at 13:31:33 UTC, Petar Kirov [ZombineDev] wrote:
>> Other applications include:
>> * compiling/transpiling D functions to targets
>> like JS, SPIR-V,
>
> I got you covered ;)

I know, and I'm looking forward to using your GPU support in LDC :P

> (LDC not CTFE though. It would be fiendishly complicated to do at CTFE as a fair amount of compiler magic is necessary.)

The way I see it, metaprogramming is a whole spectrum. Yes, you
need a full compiler if you want to compile a whole program to
e.g. JS or WebAsm, but there are many areas where even the smallest
improvement would be highly beneficial.

Take for example C#. It has zero CTFE capabilities (you can
safely ignore constant folding, which works only with string and number literals),
yet it has pretty powerful reflection and code-generation capabilities
at run-time. Even though the performance difference between CT and RT
reflection is orders of magnitude, those reflection capabilities are used
pervasively throughout the whole ecosystem. The prime example being LINQ -
probably the most widely used feature of .NET. Given a chain of operations
(similar to D's ranges) like:

dbContext.Persons
  .Where(p => p.Birthdate < DateTime.Now.Date.AddYears(-18))
  .Where(p => p.Birthdate > DateTime.Now.Date.AddYears(-28))
  .Select(p => new { Name = p.FirstName + " " + p.LastName, Birthdate = p.Birthdate })

It gets compiled to the following SQL:
-- Region Parameters
DECLARE @p0 DateTime = '1989-05-01 00:00:00.000'
DECLARE @p1 DateTime = '1999-05-01 00:00:00.000'
DECLARE @p2 NVarChar(1000) = ' '
-- EndRegion
SELECT ([t0].[FirstName] + @p2) + [t0].[LastName] AS [Name], [t0].[Birthdate]
FROM [Person] AS [t0]
WHERE ([t0].[Birthdate] > @p0) AND ([t0].[Birthdate] < @p1)

As you can see the mapping and filtering is done entirely on the
database server side. The only magic need is to make the compiler to
dump the AST. In C# that's accomplished by wrapping the function
type F in to an Expression<F> [0]. For example C#'s analog of:

InputRange!T filter(T)(InputRange!T source, bool delegate(T) predicate)

is expressed as:

IEnumerable<T> Where<T>(IEnumerable<T> source, Func<T, bool> predicate)

In order to request the AST of the predicate function, it needs to
be wrapped in Expression<T>:

IQueryable<T> Where<T>(
    IQueryable<T> source, Expression<Func<T, bool>> predicate)

(IQueryable<T> [1] is an extension of IEnumerable<T> [2] interface (which is
similar to D's Input/ForwardRange-s) which adds the Expression property
which represents the AST of the query against the IQueryable data source.)

----

In addition to compiling range operations to database queries, this would
also be useful specializing on lambda's in range libraries (see [3]) and
much more.


[0]: https://msdn.microsoft.com/en-us/library/bb335710(v=vs.110).aspx
[1]: https://msdn.microsoft.com/en-us/library/bb351562(v=vs.110).aspx
[2]: https://msdn.microsoft.com/en-us/library/9eekhta0(v=vs.110).aspx
[3]: https://github.com/dlang/phobos/pull/4265

On 4/29/17 5:42 AM, Daniel N wrote:
> 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?
>
> Wishlist
> 1) Make alias parameters work with buildin types, I bet anyone using D
> has fallen into trip trap.
>
> alias X(alias T) = T;
> X!int x;
>

+1, I would love to see this fixed. I recall Walter said it should be fixed 2 years ago in Utah.

-Steve

On Monday, 1 May 2017 at 12:35:11 UTC, Petar Kirov [ZombineDev] wrote:
> On Saturday, 29 April 2017 at 00:54:59 UTC, Nicholas Wilson wrote:
>> On Friday, 28 April 2017 at 13:31:33 UTC, Petar Kirov [ZombineDev] wrote:
>>> Other applications include:
>>> * compiling/transpiling D functions to targets
>>> like JS, SPIR-V,
>>
>> I got you covered ;)
>
> I know, and I'm looking forward to using your GPU support in LDC :P
>
>> (LDC not CTFE though. It would be fiendishly complicated to do at CTFE as a fair amount of compiler magic is necessary.)
>
> The way I see it, metaprogramming is a whole spectrum. Yes, you
> need a full compiler if you want to compile a whole program to
> e.g. JS or WebAsm, but there are many areas where even the smallest
> improvement would be highly beneficial.
>

Oh I agree. For text to text (or lambda to text) this is comprehensible and not too difficult (perhaps even simple with Dmitry Olshansky's Pry) but SPIRV is rather complicated, as evidenced by a 203 page spec *(that doesn't even include the OpenCL or Vulkan specific stuff). Having said that it shouldn't be too difficult to port the tablegen tables I've been working on for LLVM to D (or write a D backend for tablegen) and get most of the really boring work out of the way.
I won't stop you, but just letting you know the rabbit hole is quite deep :)

The good news is the the runtime stuff will be all transferable.
This approach for SPIRV won't automatically translate for NVPTX like it will for ldc though, which is one of the main draws for dcompute

*Other languages probably have longer specs, but this is just for the format.

> Take for example C#. It has zero CTFE capabilities (you can
> safely ignore constant folding, which works only with string and number literals),
> yet it has pretty powerful reflection and code-generation capabilities
> at run-time. Even though the performance difference between CT and RT
> reflection is orders of magnitude, those reflection capabilities are used
> pervasively throughout the whole ecosystem. The prime example being LINQ -
> probably the most widely used feature of .NET. Given a chain of operations
> (similar to D's ranges) like:
>
> dbContext.Persons
>   .Where(p => p.Birthdate < DateTime.Now.Date.AddYears(-18))
>   .Where(p => p.Birthdate > DateTime.Now.Date.AddYears(-28))
>   .Select(p => new { Name = p.FirstName + " " + p.LastName, Birthdate = p.Birthdate })
>
> It gets compiled to the following SQL:
> -- Region Parameters
> DECLARE @p0 DateTime = '1989-05-01 00:00:00.000'
> DECLARE @p1 DateTime = '1999-05-01 00:00:00.000'
> DECLARE @p2 NVarChar(1000) = ' '
> -- EndRegion
> SELECT ([t0].[FirstName] + @p2) + [t0].[LastName] AS [Name], [t0].[Birthdate]
> FROM [Person] AS [t0]
> WHERE ([t0].[Birthdate] > @p0) AND ([t0].[Birthdate] < @p1)
>
> As you can see the mapping and filtering is done entirely on the
> database server side. The only magic need is to make the compiler to
> dump the AST. In C# that's accomplished by wrapping the function
> type F in to an Expression<F> [0]. For example C#'s analog of:
>
> InputRange!T filter(T)(InputRange!T source, bool delegate(T) predicate)
>
> is expressed as:
>
> IEnumerable<T> Where<T>(IEnumerable<T> source, Func<T, bool> predicate)
>
> In order to request the AST of the predicate function, it needs to
> be wrapped in Expression<T>:
>
> IQueryable<T> Where<T>(
>     IQueryable<T> source, Expression<Func<T, bool>> predicate)
>
> (IQueryable<T> [1] is an extension of IEnumerable<T> [2] interface (which is
> similar to D's Input/ForwardRange-s) which adds the Expression property
> which represents the AST of the query against the IQueryable data source.)
>
> ----
>
> In addition to compiling range operations to database queries, this would
> also be useful specializing on lambda's in range libraries (see [3]) and
> much more.
>
>
> [0]: https://msdn.microsoft.com/en-us/library/bb335710(v=vs.110).aspx
> [1]: https://msdn.microsoft.com/en-us/library/bb351562(v=vs.110).aspx
> [2]: https://msdn.microsoft.com/en-us/library/9eekhta0(v=vs.110).aspx
> [3]: https://github.com/dlang/phobos/pull/4265

On Thursday, 27 April 2017 at 16:33:02 UTC, singingbush wrote:
> SDL should be dropped.

Deprecated, sure.  But dropping it seems a bad idea given that various projects do still use it for their DUB package config.

> NOBODY USES IT!

Probably not true.  Perhaps a hackathon project could be to create a little app to find which projects on GitHub (or at least code.dlang.org) still use a `dub.sdl`, and auto-submit a PR to fix that? :-)

On Monday, 1 May 2017 at 14:38:11 UTC, Joseph Rushton Wakeling wrote:
> On Thursday, 27 April 2017 at 16:33:02 UTC, singingbush wrote:
>> SDL should be dropped.
>
> Deprecated, sure.  But dropping it seems a bad idea given that various projects do still use it for their DUB package config.
>
>> NOBODY USES IT!
>
> Probably not true.  Perhaps a hackathon project could be to create a little app to find which projects on GitHub (or at least code.dlang.org) still use a `dub.sdl`, and auto-submit a PR to fix that? :-)

I love SDL and much prefer it over JSON for DUB configs. Use it for all of my D projects. It looks cleaner and supports comments. I really would hate to see support dropped.

On Thursday, 27 April 2017 at 22:57:48 UTC, Moritz Maxeiner wrote:
> 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:
>>> [...]
>>
>> 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?

I created an issue in the dub github repository
https://github.com/dlang/dub/issues/1119

Kind regards
André