On Friday, 25 October 2019 at 07:59:36 UTC, bioinfornatics wrote:
> On Thursday, 17 October 2019 at 07:18:15 UTC, Russel Winder wrote:
>> [...]
>
>  I would agree with Russel. Indeed we have some resource that maintains GtkD, it works well to create a D heavy application.
>
> [...]

About D and data scientist framework
a) I missed pandas python library
b) maybe Andrei could use its relationship with Yann LeCun (work at Facebook) and other key leaders on the deeplearning field to promote D through a killer DeepLearning framework

On Friday, 25 October 2019 at 10:01:06 UTC, bioinfornatics wrote:
> [snip]
>
> About D and data scientist framework
> a) I missed pandas python library

This is a step in the right direction:
https://forum.dlang.org/thread/jgsdvnjpttejswscxcjk@forum.dlang.org?page=1

On 25/10/2019 8:13 PM, Walter Bright wrote:
> On 10/24/2019 11:44 PM, Sebastiaan Koppe wrote:
>> Having said that, I am of the same opinion as Mike Franklin, and I would rather see work being done on a pay-as-you-go druntime than on a better betterC.
> 
> The two mostly go together.

As of late I've been helping one or two people out with -betterC.

So many modules under the hood are relying on things that can't be CTFE'd with -betterC enabled.

Fix this, and pay-as-you-go druntime will be able to take advantage of that. Its not a wasted effort.

On 10/25/2019 4:05 AM, rikki cattermole wrote:
> So many modules under the hood are relying on things that can't be CTFE'd with -betterC enabled.

It'd be nice if you could file a specific bugzilla issue on this.

On Friday, 18 October 2019 at 20:40:46 UTC, Nicholas Wilson wrote:
> On Thursday, 17 October 2019 at 19:00:47 UTC, Ola Fosheim Grøstad wrote:
>> Low level.  With some high level runtime features.  There is very little room for high level optimization in D.
>
> I hope for that not to be the case if/when the MLIR SAOC project comes through.
>
> Even without that being able to do array of struct <-> struct of array in the language is very nice and as an example of high level optimisation parameterisation that is far more effective in allow optimisation from the top down and still be able to change design decisions.

Right, you can establish that a program follows a high level strategy by statically proving that the program at hand is written without depending on memory layout, but that doesn't make the language high level (in which case all programs written in that language have that property).

Though, I guess it is fair to say that if a language provides 100% encapsulation for library constructs then libraries can do high level optimizations (if the language provide the right meta programming features, e.g. term rewriting).

On Mon, 2019-10-21 at 09:45 +0000, Jacob Carlborg via Digitalmars-d wrote: […]
> Dub needs a Git tag and it needs to follow semantic versioning, otherwise Dub will ignore it. The tags for the compiler do not follow semantic versioning. There's no technical reason. It's just that the compiler releases doesn't follow the semantic versioning model. Any release can break anything, basically.

Should Dub really be mandating use of Git? Mercurial and Breezy still exist even if GitHub, GitLab, and BitBucket make it seem like Git is the only VCS option. Subversion is still also a player.

> I suggested a workaround until the compiler properly follows the semantic versioning model. Which is to add two tags for each new release. One that we already add today. The other one would be explicitly intended only for the library and would be `0.x.0` and we increment `x` by one for each release. Since the `0.x.y` versions have special meaning, it's for the initial development. Semantic versioning says:
> 
> "Anything MAY change at any time. The public API SHOULD NOT be considered stable."

The numbering should at least be 2.x.y for the current DMD.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On 30/10/2019 9:33 PM, Russel Winder wrote:
> Should Dub really be mandating use of Git? Mercurial and Breezy still exist
> even if GitHub, GitLab, and BitBucket make it seem like Git is the only VCS
> option. Subversion is still also a player.

In the context of dmd which is on Github and uses Git.

Dub is not tied to a single VCS system nor hosting site. Even if dub repository is limited to what it can interact with.

On Monday, 21 October 2019 at 09:45:08 UTC, Jacob Carlborg wrote:
> On Friday, 18 October 2019 at 16:07:43 UTC, Atila Neves wrote:
>
>> I agree and support all of this. I know that dmd as a library right now can only be used from dub with `~master`. What is the technical reason stopping a version number again?
>
> Dub needs a Git tag and it needs to follow semantic versioning, otherwise Dub will ignore it. The tags for the compiler do not follow semantic versioning. There's no technical reason. It's just that the compiler releases doesn't follow the semantic versioning model. Any release can break anything, basically.
>
> I suggested a workaround until the compiler properly follows the semantic versioning model. Which is to add two tags for each new release. One that we already add today. The other one would be explicitly intended only for the library and would be `0.x.0` and we increment `x` by one for each release. Since the `0.x.y` versions have special meaning, it's for the initial development. Semantic versioning says:
>
> "Anything MAY change at any time. The public API SHOULD NOT be considered stable."
>
> Nothing happened with that with that suggestion.
>
> --
> /Jacob Carlborg

Officially, yes, dub relies on git tags. Unofficially you can set the version attribute in dub.json / dub.sdl.

This works quite well in my scenario, where the build system needs to know the version of the package and in a later step will create itself the git tag.

Kind regards
Andre

On Wednesday, 30 October 2019 at 12:11:12 UTC, Andre Pany wrote:
> On Monday, 21 October 2019 at 09:45:08 UTC, Jacob Carlborg wrote:
>> On Friday, 18 October 2019 at 16:07:43 UTC, Atila Neves wrote:
>>
>>> [...]
>>
>> Dub needs a Git tag and it needs to follow semantic versioning, otherwise Dub will ignore it. The tags for the compiler do not follow semantic versioning. There's no technical reason. It's just that the compiler releases doesn't follow the semantic versioning model. Any release can break anything, basically.
>>
>> I suggested a workaround until the compiler properly follows the semantic versioning model. Which is to add two tags for each new release. One that we already add today. The other one would be explicitly intended only for the library and would be `0.x.0` and we increment `x` by one for each release. Since the `0.x.y` versions have special meaning, it's for the initial development. Semantic versioning says:
>>
>> "Anything MAY change at any time. The public API SHOULD NOT be considered stable."
>>
>> Nothing happened with that with that suggestion.
>>
>> --
>> /Jacob Carlborg
>
> Officially, yes, dub relies on git tags. Unofficially you can set the version attribute in dub.json / dub.sdl.
>
> This works quite well in my scenario, where the build system needs to know the version of the package and in a later step will create itself the git tag.
>
> Kind regards
> Andre

Weirdly enough dub writes out a dub.json (even if the original was dub.sdl) in the ~/.dub folder it downloads the package into, adding to it a version tag even if not present in the original. It never occurred to me that one could add it to get the version, but I wonder how the repository deals with that.