December 11, 2017
On Friday, 8 December 2017 at 06:43:22 UTC, Dmitry Olshansky wrote:
> On Thursday, 7 December 2017 at 22:26:08 UTC, Bastiaan Veelo wrote:
>> On Tuesday, 5 December 2017 at 18:20:40 UTC, Seb wrote:
>>> I am looking forward to hearing (1) what you think can be done in three months by a student and (2) will have a huge impact on the D ecosystem.
>>>
>>> [2] https://wiki.dlang.org/GSOC_2018_Ideas
>>
>> I see there is a dub section in [2]. Maybe another issue that has been brought up repeatedly fits in that category, namely extending code.dlang.org in various ways?
>
> +1111
>
> Indeed enhancing user experience of code.dlang.org such as showing github stars and e.g. downloads per month would be way more important then build tool itself.

+10^^4

I recommend to add a "donate for button", and to evaluate and visualize how many people are donating, for a certain package. This might give strong evidence where to invest more time - man power.
In the first step the D Foundation should get all money and should try to use it to support the most often selected packages, to avoid loosing focus.



December 11, 2017
On Mon, 11 Dec 2017 09:14:29 +0000, Martin Tschierschke wrote:

> I recommend to add a "donate for button", and to evaluate and visualize
> how many people are donating, for a certain package. This might give
> strong evidence where to invest more time - man power.
> In the first step the D Foundation should get all money and should try
> to use it to support the most often selected packages,
> to avoid loosing focus.

If something looks like donating money is going to support the development of a project, then any many received needs to actually support that project. A home page with a "support the D Foundation" link is fine; the foundation receiving the money from a donate button on vibe-d's project page is not, unless the vibe-d maintainer(s) make that decision.
December 11, 2017
On Monday, 11 December 2017 at 09:14:29 UTC, Martin Tschierschke wrote:
> On Friday, 8 December 2017 at 06:43:22 UTC, Dmitry Olshansky wrote:
>> On Thursday, 7 December 2017 at 22:26:08 UTC, Bastiaan Veelo wrote:
>>> On Tuesday, 5 December 2017 at 18:20:40 UTC, Seb wrote:
>>>> I am looking forward to hearing (1) what you think can be done in three months by a student and (2) will have a huge impact on the D ecosystem.
>>>>
>>>> [2] https://wiki.dlang.org/GSOC_2018_Ideas
>>>
>>> I see there is a dub section in [2]. Maybe another issue that has been brought up repeatedly fits in that category, namely extending code.dlang.org in various ways?
>>
>> +1111
>>
>> Indeed enhancing user experience of code.dlang.org such as showing github stars and e.g. downloads per month would be way more important then build tool itself.
>
> +10^^4
>
> I recommend to add a "donate for button", and to evaluate and visualize how many people are donating, for a certain package. This might give strong evidence where to invest more time - man power.
> In the first step the D Foundation should get all money and should try to use it to support the most often selected packages, to avoid loosing focus.

Martin, I am replying to your post specifically, but this reply is targeted at the 'code.dlang.org' discussion in general.

Improvements to code.dlang.org are going to be borderline ineligible for a GSoC project.  Any such project would have to be carefully crafted so that it is a development project and not a website maintenance/upgrading project. In any case this work can likely be made into something valid, but the project would need involve a cohesive development effort and not a series of minor improvements (even if they mostly involved coding).
December 11, 2017
On Tuesday, 5 December 2017 at 18:20:40 UTC, Seb wrote:
> Hi all,
>
> Google Summer of Code (GSoC) 2018 is about to start soon [1] [...]
> I am looking forward to hearing (1) what you think can be done in three months by a student and (2) will have a huge impact on the D ecosystem.
>
> Cheers,
>
> Seb
>
> [1] https://developers.google.com/open-source/gsoc/timeline
> [2] https://wiki.dlang.org/GSOC_2018_Ideas

My two cents:

## Lowerer

1. I think that this project is too abstract, there's no concrete application.
2. Issue 5051 is mentioned but i think that many features listed in this project are actually **already** done when the switch "-vcg-ast" is used (scope lowering(), foreach() lowering, ...)

## Phobos: D Standard Library

- std.units: no there are user libs for that, particularly one by klickverbot and one of its fork that is more maintained IIRC.
- std.serialization: yes, this is the idea i like the more, although we can regret that std.xml2 would have been good to be there as supported file format.
- std.container: skeptical, changes are announced for the allocators, Big(O) notation was planned in another container project that should have been made by Alexandrescu (although this was announced something like 2 years ago already).
- std.decimal: I've seen that J.Stouffler has just started an stdx project for this.

## DUB

There are good ideas. A proper plan is needed.

## Linux debugger

I think it's a bad idea.

1. because of the 3 months. Would it be usable despite of being an interesting for the student ?
2. what will it do better than GDB ?
3. I.Buclaw is the official maintainer for the D support in GDB, so why not doing something in GDB instead (yeah but what... )


So in short, i see only two good projects:
- std.serializer
- DUB

The others, excepted those i find useless or unrealistic or existing, are just "meh", but it's a personal point of view. It's a problem of balance: it must be interesting and motivating for the student but also useful for the community.
December 11, 2017
On 11 December 2017 at 21:15, Basile B. via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
> ## Linux debugger
>
> I think it's a bad idea.
>
> 1. because of the 3 months. Would it be usable despite of being an
> interesting for the student ?
> 2. what will it do better than GDB ?
> 3. I.Buclaw is the official maintainer for the D support in GDB, so why not
> doing something in GDB instead (yeah but what... )
>

There are still things that GDB supports, but DMD doesn't generate proper debug info in order to leverage it.
December 13, 2017
On Tuesday, 5 December 2017 at 18:20:40 UTC, Seb wrote:
> I am looking forward to hearing (1) what you think can be done in three months by a student and (2) will have a huge impact on the D ecosystem.

Of the projects in [2], I like the general purpose betterC libraries most, and I think it's something where students could make a real impact in that time period.

> [1] https://developers.google.com/open-source/gsoc/timeline
> [2] https://wiki.dlang.org/GSOC_2018_Ideas


December 13, 2017
On Wed, Dec 13, 2017 at 07:50:44PM +0000, bpr via Digitalmars-d-announce wrote:
> On Tuesday, 5 December 2017 at 18:20:40 UTC, Seb wrote:
[...]
> Of the projects in [2], I like the general purpose betterC libraries most, and I think it's something where students could make a real impact in that time period.
[...]
> > [2] https://wiki.dlang.org/GSOC_2018_Ideas

The "Who's (using) who?" project can use my symbol dependency tool as a
starting point:

	https://github.com/quickfur/symdep

Basically, as it stands, it can extract the list of symbols from the program, and which symbol references which other symbols, where "A references B" means the disassembled code between A and the next symbol in the executable contains a reference to an address somewhere between B and the next symbol after B.  This is done by inspecting the output of the `objdump` tool.  A list of dependencies can be produced in either text format or in GraphViz .dot format, which can be passed to graphviz or neato to produce a graphical chart of symbol dependencies.

As of now, the following are possible points of improvement:

- Make it work on Windows and other OSes that don't have the `objdump`
  utility;

- Add better capability to limit the output to a subgraph of the full
  graph. Because of the huge number of symbols in a typical D program,
  outputting the entire dependency graph will produce a graph far too
  large to be easily understood.

  Currently, symdep has the capability of restricting the output to the
  subgraph of symbols reachable from a certain given symbol (useful for
  answering "what does function foo call?"), or the subgraph of symbols
  NOT reachable from a certain given symbol (e.g., "what are the symbols
  that aren't reachable from _Dmain?").  However, in medium-to-large D
  programs, the resulting subgraph is still far too large to be useful,
  so a better way of selecting a subgraph would be nice.  Perhaps
  implementing a maximum recursion level to the existing subgraph
  functions might be a good start, i.e., "what are the symbols
  referenced by _Dmain up to 3 levels down the call chain / reference
  graph?".

- Better accuracy for dependency detection. Currently, it may not
  produce the most accurate results because if there are private /
  static symbols in a module that don't export a public symbol in the
  executable, symdep won't know if a reference is actually to that
  private symbol, and will blindly assume that it's actually referencing
  the closest public symbol that comes before the private symbol in the
  executable.  This makes the output graph inaccurate.

  Also, some references that go through indirection may not be detected
  correctly, e.g., if function F calls function G via a function pointer
  table or thunk. (I think the function table case should still work, as
  long as the function table itself has a public symbol; it will just
  show up in the output as F -> tableSym -> G. But this has not been
  rigorously tested.)

- Currently, symdep does not distinguish between code symbols and data
  symbols.  For its stated purpose (i.e., find unexpected dependencies
  to Phobos modules that seemingly aren't used), this is not necessarily
  a bad thing. But being able to tell the difference helps to make the
  output more readable, e.g., use different node shapes for code vs.
  data symbols; it also allows subgraph queries to be restricted to a
  particular node type (show me the call graph vs. show me the data
  dependency graph), etc..


T

-- 
Dogs have owners ... cats have staff. -- Krista Casada
1 2
Next ›   Last »