Re: DConf hackathon track document

[Basile B via Digitalmars-d-announce]

On Friday, 4 May 2018 at 16:41:18 UTC, Seb wrote:
As the DConf hackathon is coming up soon, we created a quick 
document to list the tracks people will be working:


https://docs.google.com/document/d/1qrn7JZS62hzsylpGM1VhaT6YW2I1NVDDGQsANv5b1GQ/edit

If you already have an idea or want to start a new group, now 
is the time to add yourself to the track document.


Happy hacking tomorrow!


Maybe add 7804 to the list. 
(https://github.com/dlang/dmd/pull/8031). The feature can be 
split in two parts. The first was done. The feature branch is 
still there but i've abandoned it after a month without updating.

Re: DConf hackathon track document

[rikki cattermole via Digitalmars-d-announce]

On 05/05/2018 4:41 AM, Seb wrote:
As the DConf hackathon is coming up soon, we created a quick document to 
list the tracks people will be working:


https://docs.google.com/document/d/1qrn7JZS62hzsylpGM1VhaT6YW2I1NVDDGQsANv5b1GQ/edit 



If you already have an idea or want to start a new group, now is the 
time to add yourself to the track document.


Happy hacking tomorrow!


I've added some simple work to improve dmd as a library.
Two out of the three will require a decision from Walter (simple 
though!) and all three can be done by pretty much anyone!


I'll also add a note regarding shared redesign (since that was mentioned 
that was desired) along with my draft idea for it.

DConf hackathon track document

[Seb via Digitalmars-d-announce]

As the DConf hackathon is coming up soon, we created a quick 
document to list the tracks people will be working:


https://docs.google.com/document/d/1qrn7JZS62hzsylpGM1VhaT6YW2I1NVDDGQsANv5b1GQ/edit

If you already have an idea or want to start a new group, now is 
the time to add yourself to the track document.


Happy hacking tomorrow!

Re: DConf hackathon: idea list

[Seb via Digitalmars-d-announce]

On Saturday, 6 May 2017 at 10:13:28 UTC, Seb wrote:

On Thursday, 4 May 2017 at 13:32:21 UTC, Seb wrote:

Hi all,

the DConf hackathon isn’t a hackathon in the traditional 
sense. It is intended as a day for _collaboratively_ focusing 
on long-lasting problems and pain points in the D ecosystem, 
planning upcoming features or DIPs, and creation of a rough 
roadmap for the next months.
Of course, any D hackers who wish to simply progress their own 
personal projects are welcome too!


[...]


Please don't forget to put your names next to ideas that you 
would like to work on ;-)


For convenience a short link to the document: 
http://tinyurl.com/dconf17

Re: DConf hackathon: idea list

[Seb via Digitalmars-d-announce]

On Thursday, 4 May 2017 at 13:32:21 UTC, Seb wrote:

Hi all,

the DConf hackathon isn’t a hackathon in the traditional sense. 
It is intended as a day for _collaboratively_ focusing on 
long-lasting problems and pain points in the D ecosystem, 
planning upcoming features or DIPs, and creation of a rough 
roadmap for the next months.
Of course, any D hackers who wish to simply progress their own 
personal projects are welcome too!


[...]


Please don't forget to put your names next to ideas that you 
would like to work on ;-)

Re: DConf hackathon: idea list

[Adam Wilson via Digitalmars-d-announce]

On 5/4/17 16:33, rikki cattermole wrote:

On 04/05/2017 3:22 PM, Adam Wilson wrote:

On 5/4/17 15:32, Seb wrote:

Hi all,

the DConf hackathon isn’t a hackathon in the traditional sense. It is
intended as a day for _collaboratively_ focusing on long-lasting
problems and pain points in the D ecosystem, planning upcoming features
or DIPs, and creation of a rough roadmap for the next months.
Of course, any D hackers who wish to simply progress their own personal
projects are welcome too!

Experience has shown that in large groups too much time is wasted on
giving a voice to everyone, whereas for tiny groups chances are that it
takes too long to get the ball rolling.
Hence, a group size of four or five D hackers is recommended.

Below you can find a list of themes with a short abstract and a couple
of ideas. The abstracts and ideas are intended to get you started and
guide you. Please feel free to _add your own ideas_ and _add your names_
next to them so that people can ping you (IRC, email, and other IM
handles might be handy as well). Of course, you can add your name to
multiple projects.
On Sunday the first half an hour will be used to finalize the group
forming. All existing groups and persons with an idea, but without a
group can pitch their idea shortly (one minute max, no slides) and thus
find other motivated D hackers.


https://docs.google.com/document/d/1L5edu6LLj3Afa3tPgqk-aX-fErwr7sPj37Dt5avoc5w/edit#





From the Phobos wishlist:
I am working an a generic SQL database interface. If anybody is
interested in helping out I have a small amount of code that shows the
general design direction I've taken so far. We can discuss the design
and collaboratively hack out a prototype.

The current code is here:
https://github.com/LightBender/std.experimental.database.sql


Looking at that I think focusing on describing of tables ext. would be a
good first step. I worry that it won't be very flexible memory
management or serialization wise.



It's definitely the hardest problem to solve. Obviously we could start 
with a brute force approach (box everything like ADO.NET does) for the 
sake of getting started and then work on improving it later. For now I 
compromised and used Variant, which should be sufficient for most cases 
right now. (See latest commit) I am using Classes and Dynamic Arrays so 
it's not @nogc yet, but this is something that can be improved over 
time. There is no reason that this could not use the new Allocators API 
at a later date.


I'm not looking for inclusion into Phobos during the DConf Hackathon, 
but I would like to block out something that we can start using.


--
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;

Re: DConf hackathon: idea list

[OoopsAgain via Digitalmars-d-announce]

On Thursday, 4 May 2017 at 15:40:57 UTC, rikki cattermole wrote:

On 04/05/2017 4:29 PM, OoopsAgain wrote:

On Thursday, 4 May 2017 at 14:53:34 UTC, Adam D. Ruppe wrote:

[...]


I just had a vision:

pragma(pushAttributes);
@safe: void foo();
pragma(popAttributes);
void notsafeanymore();

No need for reverse for each attribute (and new attributes in 
the future).


So:

@safe {
void foo();
}

void notsafeanymore();


I suppose this would be fundamentally implemented in this way:  
new scope with scope attridfgjlkdg,;

Re: DConf hackathon: idea list

[rikki cattermole via Digitalmars-d-announce]

On 04/05/2017 4:29 PM, OoopsAgain wrote:

On Thursday, 4 May 2017 at 14:53:34 UTC, Adam D. Ruppe wrote:

I just added two things:

1) error messages, which are code intensive but a HUGE payoff in
productivity (and thus marketing)

and 2) Opposite attributes, which are trivial to implement but painful
to get merged.


I think dconf is a good opportunity for you guys to get things like #2
actually merged. No more waiting for months for a review, discuss it
right there and have an in-person decision to go or not go. Merge
immediately without additional delay.


I just had a vision:

pragma(pushAttributes);
@safe: void foo();
pragma(popAttributes);
void notsafeanymore();

No need for reverse for each attribute (and new attributes in the future).


So:

@safe {
void foo();
}

void notsafeanymore();

Re: DConf hackathon: idea list

[OoopsAgain via Digitalmars-d-announce]

On Thursday, 4 May 2017 at 14:53:34 UTC, Adam D. Ruppe wrote:

I just added two things:

1) error messages, which are code intensive but a HUGE payoff 
in productivity (and thus marketing)


and 2) Opposite attributes, which are trivial to implement but 
painful to get merged.



I think dconf is a good opportunity for you guys to get things 
like #2 actually merged. No more waiting for months for a 
review, discuss it right there and have an in-person decision 
to go or not go. Merge immediately without additional delay.


I just had a vision:

pragma(pushAttributes);
@safe: void foo();
pragma(popAttributes);
void notsafeanymore();

No need for reverse for each attribute (and new attributes in the 
future).

Re: DConf hackathon: idea list

[Adam D. Ruppe via Digitalmars-d-announce]

I just added two things:

1) error messages, which are code intensive but a HUGE payoff in 
productivity (and thus marketing)


and 2) Opposite attributes, which are trivial to implement but 
painful to get merged.



I think dconf is a good opportunity for you guys to get things 
like #2 actually merged. No more waiting for months for a review, 
discuss it right there and have an in-person decision to go or 
not go. Merge immediately without additional delay.

Re: DConf hackathon: idea list

[rikki cattermole via Digitalmars-d-announce]

On 04/05/2017 3:22 PM, Adam Wilson wrote:

On 5/4/17 15:32, Seb wrote:

Hi all,

the DConf hackathon isn’t a hackathon in the traditional sense. It is
intended as a day for _collaboratively_ focusing on long-lasting
problems and pain points in the D ecosystem, planning upcoming features
or DIPs, and creation of a rough roadmap for the next months.
Of course, any D hackers who wish to simply progress their own personal
projects are welcome too!

Experience has shown that in large groups too much time is wasted on
giving a voice to everyone, whereas for tiny groups chances are that it
takes too long to get the ball rolling.
Hence, a group size of four or five D hackers is recommended.

Below you can find a list of themes with a short abstract and a couple
of ideas. The abstracts and ideas are intended to get you started and
guide you. Please feel free to _add your own ideas_ and _add your names_
next to them so that people can ping you (IRC, email, and other IM
handles might be handy as well). Of course, you can add your name to
multiple projects.
On Sunday the first half an hour will be used to finalize the group
forming. All existing groups and persons with an idea, but without a
group can pitch their idea shortly (one minute max, no slides) and thus
find other motivated D hackers.


https://docs.google.com/document/d/1L5edu6LLj3Afa3tPgqk-aX-fErwr7sPj37Dt5avoc5w/edit#




From the Phobos wishlist:
I am working an a generic SQL database interface. If anybody is
interested in helping out I have a small amount of code that shows the
general design direction I've taken so far. We can discuss the design
and collaboratively hack out a prototype.

The current code is here:
https://github.com/LightBender/std.experimental.database.sql


Looking at that I think focusing on describing of tables ext. would be a 
good first step. I worry that it won't be very flexible memory 
management or serialization wise.

Re: DConf hackathon: idea list

[Adam Wilson via Digitalmars-d-announce]

On 5/4/17 15:32, Seb wrote:

Hi all,

the DConf hackathon isn’t a hackathon in the traditional sense. It is
intended as a day for _collaboratively_ focusing on long-lasting
problems and pain points in the D ecosystem, planning upcoming features
or DIPs, and creation of a rough roadmap for the next months.
Of course, any D hackers who wish to simply progress their own personal
projects are welcome too!

Experience has shown that in large groups too much time is wasted on
giving a voice to everyone, whereas for tiny groups chances are that it
takes too long to get the ball rolling.
Hence, a group size of four or five D hackers is recommended.

Below you can find a list of themes with a short abstract and a couple
of ideas. The abstracts and ideas are intended to get you started and
guide you. Please feel free to _add your own ideas_ and _add your names_
next to them so that people can ping you (IRC, email, and other IM
handles might be handy as well). Of course, you can add your name to
multiple projects.
On Sunday the first half an hour will be used to finalize the group
forming. All existing groups and persons with an idea, but without a
group can pitch their idea shortly (one minute max, no slides) and thus
find other motivated D hackers.


https://docs.google.com/document/d/1L5edu6LLj3Afa3tPgqk-aX-fErwr7sPj37Dt5avoc5w/edit#



From the Phobos wishlist:
I am working an a generic SQL database interface. If anybody is 
interested in helping out I have a small amount of code that shows the 
general design direction I've taken so far. We can discuss the design 
and collaboratively hack out a prototype.


The current code is here: 
https://github.com/LightBender/std.experimental.database.sql


--
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;

Re: DConf hackathon: idea list

[rikki cattermole via Digitalmars-d-announce]

In short I want Phobos to have an image library and long with it a 
windowing lib (but lets ignore that last part for now).
I welcome people stealing and creating a competing ideas for anything in 
[0] and [1] that I have.


Alternatively you can also create PR's for anything there as well.
There is also [2] which is the start of my fixed-sized linear algebra 
library for game development.


Of note is my managed memory concept, it needs a full rewrite. I have 
yet to be able to use it to its full power with its managers (e.g. data 
structure knowing when memory is ready to die).


There is a serializer in[1] that could do with a couple of iterations in 
becoming faster and more feature full.


I will try my best to be available via IRC and on the N.G. but well New 
Zealand time zones and all that. If you have any questions or want some 
assistance, hit me up!


Now let's destruct these ideas.

[0] 
https://github.com/rikkimax/alphaPhobos/tree/master/source/std/experimental
[1] 
https://github.com/Devisualization/spew/tree/master/src/base/cf/spew/serialization

[2] https://gist.github.com/rikkimax/f5c0accd3463d52fda524f1f929b29ab

DConf hackathon: idea list

[Seb via Digitalmars-d-announce]

Hi all,

the DConf hackathon isn’t a hackathon in the traditional sense. 
It is intended as a day for _collaboratively_ focusing on 
long-lasting problems and pain points in the D ecosystem, 
planning upcoming features or DIPs, and creation of a rough 
roadmap for the next months.
Of course, any D hackers who wish to simply progress their own 
personal projects are welcome too!


Experience has shown that in large groups too much time is wasted 
on giving a voice to everyone, whereas for tiny groups chances 
are that it takes too long to get the ball rolling.

Hence, a group size of four or five D hackers is recommended.

Below you can find a list of themes with a short abstract and a 
couple of ideas. The abstracts and ideas are intended to get you 
started and guide you. Please feel free to _add your own ideas_ 
and _add your names_ next to them so that people can ping you 
(IRC, email, and other IM handles might be handy as well). Of 
course, you can add your name to multiple projects.
On Sunday the first half an hour will be used to finalize the 
group forming. All existing groups and persons with an idea, but 
without a group can pitch their idea shortly (one minute max, no 
slides) and thus find other motivated D hackers.



https://docs.google.com/document/d/1L5edu6LLj3Afa3tPgqk-aX-fErwr7sPj37Dt5avoc5w/edit#

Re: DConf Hackathon Ideas

[Jacob Carlborg via Digitalmars-d]

On 2017-05-01 16:51, Mike Parker wrote:


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.


+1

I would be fine with YAML as well.

--
/Jacob Carlborg

Re: DConf Hackathon Ideas

[Stefan Koch via Digitalmars-d]

On Monday, 1 May 2017 at 17:04:42 UTC, Iain Buclaw wrote:
On 1 May 2017 at 16:51, Mike Parker via Digitalmars-d 
 wrote:
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.


We should make XML the default config format for DUB.



http://code.dlang.org/;
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;>
  description="The vibe.d server application running 
gdcproject.org."

copyright="Copyright © 2014, Iain Buclaw">

  


  
  


  

  



/Runaway!


You forgot a few / there

Re: DConf Hackathon Ideas

[H. S. Teoh via Digitalmars-d]

On Mon, May 01, 2017 at 06:02:53PM +, Moritz Maxeiner via Digitalmars-d 
wrote:
> On Monday, 1 May 2017 at 17:04:42 UTC, Iain Buclaw wrote:
> > [...]
> > 
> > We should make XML the default config format for DUB.
> > 
> > [...]
> > 
> > /Runaway!
> 
> Well, at least nearly everyone hates XML equally, which may be an
> indicator of a good compromise.

Whoa.  XML for DUB?  That may just be the final nail in the coffin for
me ever picking up DUB in this lifetime. ;-)


T

-- 
Dogs have owners ... cats have staff. -- Krista Casada

Re: DConf Hackathon Ideas

[Moritz Maxeiner via Digitalmars-d]

On Monday, 1 May 2017 at 17:04:42 UTC, Iain Buclaw wrote:

[...]

We should make XML the default config format for DUB.

[...]

/Runaway!


Well, at least nearly everyone hates XML equally, which may be an 
indicator of a good compromise.

Re: DConf Hackathon Ideas

[Joakim via Digitalmars-d]

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?


Probably the plan anyway, but my suggestion would be for the core 
team to not hack on anything, but spend the time discussing 
issues that have been discussed to death online but not resolved, 
such as some devs not agreeing with Walter and the DIP 1000 path 
he's taking.


Use the in-person time to get some heavy bandwidth on those 
issues and try to make sure the differences are hashed out.  
There may not be a final agreement on the solution, but there 
certainly shouldn't be any more misunderstanding of the proposed 
options.


For people not on the core team, they can hack on a lot of the 
stuff mentioned in this thread, perhaps after coordinating with 
the core team about what's really needed and how to go about 
doing it.


Great idea, btw, to set aside a day just for this.

Re: DConf Hackathon Ideas

[Iain Buclaw via Digitalmars-d]

On 1 May 2017 at 16:51, Mike Parker via Digitalmars-d
 wrote:
> 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.

We should make XML the default config format for DUB.



http://code.dlang.org/;
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;>
  

  


  
  


  

  



/Runaway!

Re: DConf Hackathon Ideas

[Mike Parker via Digitalmars-d]

On Monday, 1 May 2017 at 15:36:16 UTC, bachmeier wrote:

On Monday, 1 May 2017 at 14:51:19 UTC, Mike Parker wrote:

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.


I'm not even sure what it would mean to "drop" support for SDL. 
As long as someone decides to support it, it will be supported. 
SDL to my knowledge is not an "official" D project.


Well, sure, but we were specifically talking about support in DUB.

http://forum.dlang.org/post/eejeorhqgwxbduunm...@forum.dlang.org

Re: DConf Hackathon Ideas

[bachmeier via Digitalmars-d]

On Monday, 1 May 2017 at 14:51:19 UTC, Mike Parker wrote:

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.


I'm not even sure what it would mean to "drop" support for SDL. 
As long as someone decides to support it, it will be supported. 
SDL to my knowledge is not an "official" D project.

Re: DConf Hackathon Ideas

[Andre Pany via Digitalmars-d]

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é

Re: DConf Hackathon Ideas

[Mike Parker via Digitalmars-d]

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.

Re: DConf Hackathon Ideas

[Joseph Rushton Wakeling via Digitalmars-d]

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? :-)

Re: OT: Re: DConf Hackathon Ideas

[Nicholas Wilson via Digitalmars-d]

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 [0]. For example C#'s analog of:

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


is expressed as:

IEnumerable Where(IEnumerable source, Func 
predicate)


In order to request the AST of the predicate function, it needs 
to

be wrapped in Expression:

IQueryable Where(
IQueryable source, Expression> predicate)

(IQueryable [1] is an extension of IEnumerable [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

Re: DConf Hackathon Ideas

[Steven Schveighoffer via Digitalmars-d]

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

Re: OT: Re: DConf Hackathon Ideas

[via Digitalmars-d]

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 [0]. For example C#'s analog of:

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


is expressed as:

IEnumerable Where(IEnumerable source, Func 
predicate)


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

IQueryable Where(
IQueryable source, Expression> predicate)

(IQueryable [1] is an extension of IEnumerable [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

Re: DConf Hackathon Ideas

[Daniel N via Digitalmars-d]

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;

Re: DConf Hackathon Ideas

[Nicholas Wilson via Digitalmars-d]

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.

Re: OT: Re: DConf Hackathon Ideas

[Nicholas Wilson via Digitalmars-d]

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.)

Re: OT: Re: DConf Hackathon Ideas

[Moritz Maxeiner via Digitalmars-d]

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 :)

Re: OT: Re: DConf Hackathon Ideas

[via Digitalmars-d]

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(1.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.

* ...

Re: DConf Hackathon Ideas

[Jacob Carlborg via Digitalmars-d]

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

OT: Re: DConf Hackathon Ideas

[Moritz Maxeiner via Digitalmars-d]

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?

Re: DConf Hackathon Ideas

[via Digitalmars-d]

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.

Re: DConf Hackathon Ideas

[Jacob Carlborg via Digitalmars-d]

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

Re: DConf Hackathon Ideas

[Adrian Matoga via Digitalmars-d]

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.

Re: DConf Hackathon Ideas

[Luís Marques via Digitalmars-d]

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?

Re: DConf Hackathon Ideas

[Moritz Maxeiner via Digitalmars-d]

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?

Re: DConf Hackathon Ideas

[Andre Pany via Digitalmars-d]

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

Re: DConf Hackathon Ideas

[Iain Buclaw via Digitalmars-d]

On 27 April 2017 at 17:15, Jack Stouffer via Digitalmars-d
 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. ;-)

Re: DConf Hackathon Ideas

[H. S. Teoh via Digitalmars-d]

On Thu, Apr 27, 2017 at 11:22:06AM -0700, Brad Roberts via Digitalmars-d wrote:
> The pending pull requests.  In person is a great high-bandwidth way to
> work through the massive backlog.

+1. Phobos at one time was down to about 30-40 PRs, but now it has
clogged back up to around 100. We need to get it back under control so
that valuable contributions aren't just sitting there bitrotting.


T

-- 
Не дорог подарок, дорога любовь.

Re: DConf Hackathon Ideas

[ag0aep6g via Digitalmars-d]

On 04/27/2017 04:53 PM, 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?


I'm most frustrated by regressions and wrong-code bugs in 
dmd/druntime/phobos (with a focus on dmd). Regressions are annoying, 
because that stuff used to work, dammit! And wrong-code bugs are 
annoying, because they can be hard to track down and work around.


I don't really have a list of them sorted by importance or impact, but I 
guess the one's I have reported are, on average, more dear to me than 
others [1][2].


I haven't reported this one, but it has a special place in my heart, 
because the miscompiled code is so simple:

https://issues.dlang.org/show_bug.cgi?id=15538

Generally, just sorting the issue list by severity and going from the 
top would probably have a good impact:


https://issues.dlang.org/buglist.cgi?bug_status=__open__=component%2Cassigned_to%2Cbug_status%2Cbug_severity%2Cshort_desc=_redirect=1=bug_severity%2Cbug_status%2Cpriority%2Cassigned_to%2Cbug_id=_based_on=_format=specific

Instead of trying to fix those bugs during DConf, maybe experienced devs 
could help interested folks get into it. Look at an issue together, lay 
out what needs to be done about it. I'm thinking about dmd in 
particular, because it seems to be understaffed. Only works if there are 
people who want to get into fixing compiler bugs, of course.




[1] My regressions: 
https://issues.dlang.org/buglist.cgi?bug_severity=regression=ag0aep6g=1=substring_id=214636_format=advanced=---
[2] My wrong-code bugs: 
https://issues.dlang.org/buglist.cgi?email1=ag0aep6g=1=substring=wrong-code_type=allwords_id=214637_format=advanced=---

Re: DConf Hackathon Ideas

[Brad Roberts via Digitalmars-d]

The pending pull requests.  In person is a great high-bandwidth way to 
work through the massive backlog.



On 4/27/2017 7:53 AM, Mike Parker via Digitalmars-d 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?

Re: DConf Hackathon Ideas

[Moritz Maxeiner via Digitalmars-d]

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

Re: DConf Hackathon Ideas

[Andre Pany via Digitalmars-d]

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?


I would vote for getting the std.decimal proposal from the review 
queue into a good shape for std.experimental.



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.


Kind regards
Andre

Re: DConf Hackathon Ideas

[Moritz Maxeiner via Digitalmars-d]

On Thursday, 27 April 2017 at 16:33:02 UTC, singingbush wrote:

As far as I can tell the only reason dub defaults to sdl now


It did in the past, but hasn't done so for several minor versions 
(it defaults to json).

Re: DConf Hackathon Ideas

[singingbush via Digitalmars-d]

- More than one official package description language (json and 
sdlang). I honestly don't care which it ends up being, but 
please pick *one* (I am aware of the previous discussions on 
the topic, but the current state of supporting both is just one 
more point of friction for newcomers)


SDL should be dropped. for starters it's poorly supported. just 
go to https://sdlang.org/ and scroll to the links at the bottom. 
official homepage and reference are both broken urls (as 
http://sdl.ikayzo.org/ is offline) and needs mirrors. Then 
there's the fact that there's not very good support for SDL in 
other languages, sure the website says there are implementations 
in other languages but has anyone tried using them? I did 
recently, the Java version (actually written by ikayzo - 
https://github.com/ikayzo/SDL) will not even parse all the 
examples on the homepage! not to mention it being a dead project 
with no response to issues 
(https://github.com/ikayzo/SDL/issues). As far as I can tell the 
only reason dub defaults to sdl now is because s-ludwig maintains 
the sdlang.org website. at least json is universally known and 
can already be handled by just about any tool. If we really want 
to have an alternative it would at least make sense to use 
something like YAML that is also heavily used and supported by 
all IDE's. It would save me the hassle of writing a lexer for SDL 
- which of course has no support in my tool of choice because...


NOBODY USES IT!

Re: DConf Hackathon Ideas

[Moritz Maxeiner via Digitalmars-d]

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?


For starters:
- https://github.com/dlang/dub/issues/104
- https://github.com/dlang/dub-registry/issues/117
I don't think the following ones are feasible to deal with in 
that context, but they are ones that irk me in the ecosystem:
- ABI compatibility between D compilers with the same frontend 
version.
- More than one official package description language (json and 
sdlang). I honestly don't care which it ends up being, but please 
pick *one* (I am aware of the previous discussions on the topic, 
but the current state of supporting both is just one more point 
of friction for newcomers)

Re: DConf Hackathon Ideas

[Jack Stouffer via Digitalmars-d]

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?


* multi-threaded parsing in DMD
* https://github.com/dlang/dub/issues/838
* finishing std.experimental.xml 
https://github.com/dlang/phobos/pull/4741
* Docs which allow people to go back and see docs for previous 
versions. Huge headache when using GDC or LDC

DConf Hackathon Ideas

[Mike Parker via Digitalmars-d]

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?

Re: DConf Hackathon

[Nicholas Wilson via Digitalmars-d]

On Thursday, 30 March 2017 at 07:28:12 UTC, Adam Wilson wrote:

Hello fellow DConfers!

In the spirit of "the DConf 2017 hackathon isn't a hackathon in 
the traditional sense as most of the time and focus will 
hopefully be spent discussing, planning and developing future D 
projects"; I was thinking that it might be beneficial to pull 
together a list of areas in the D ecosystem that DConf 
attendees would be interested in hacking on. These areas could 
then be used to create a number of "hacking groups" where 
like-minded colleagues could sit together, discuss, and even 
hack on that topic if they wish.


Please reply with your vote and whether or not you are willing 
to organize those groups.


I would be interested in participating in the following areas:
Security Libraries   (Morning)- Willing to Organize
Database Interfaces  (Afternoon)  - Willing to Organize

I am looking forward to seeing everyone there!


I was thinking of doing something to coordinate the development 
of DCompute. So I'd be up for Organising a high performance / 
numeric group.

DConf Hackathon

[Adam Wilson via Digitalmars-d]

Hello fellow DConfers!

In the spirit of "the DConf 2017 hackathon isn't a hackathon in the 
traditional sense as most of the time and focus will hopefully be spent 
discussing, planning and developing future D projects"; I was thinking 
that it might be beneficial to pull together a list of areas in the D 
ecosystem that DConf attendees would be interested in hacking on. These 
areas could then be used to create a number of "hacking groups" where 
like-minded colleagues could sit together, discuss, and even hack on 
that topic if they wish.


Please reply with your vote and whether or not you are willing to 
organize those groups.


I would be interested in participating in the following areas:
Security Libraries   (Morning)- Willing to Organize
Database Interfaces  (Afternoon)  - Willing to Organize

I am looking forward to seeing everyone there!

--
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;