Re: release of code-d 0.21.0 + serve-d 0.5.1

[uranuz via Digitalmars-d-announce]

Hello!
When code-d attempts self upgrade it prints the followinf output 
to console of VS Code:

"""
Installing DCD: DCD is outdated. Expected: 0.11.1, got none
Downloading from 
https://github.com/dlang-community/DCD/releases/download/v0.11.1/dcd-v0.11.1-linux-x86_64.tar.gz to /home/uranuz/.local/share/code-d/bin

Zip file already exists! Trying to install existing zip.
Extracting download...

tar xvfz dcd-v0.11.1-linux-x86_64.tar.gz


gzip: stdin: not in gzip format
/bin/tar: Child returned status 1
/bin/tar: Error is not recoverable: exiting now
Successfully downloaded DCD, but could not find the executables.
Please open your user settings and insert the paths for 
dcd-client and dcd-server manually.

Download base location: /home/uranuz/.local/share/code-d/bin

Tried "dcd-client", "dcd-server", "bin/dcd-client", 
"bin/dcd-server"

Successfully installed DCD
"""

Looks like something went wrong with extracting archive: 
dcd-v0.11.1-linux-x86_64.tar.gz. This archive is not opening with 
standart Kubuntu GUI archiver like "Ark", but still I was able to 
"unzip" in through "unar" programme. Maybe you just archived it 
with some exotical settings of compression so it doesn't open 
everywhere.

Re: dud: A dub replacement

[Laurent Tréguier via Digitalmars-d-announce]

On Monday, 18 November 2019 at 19:54:38 UTC, Russel Winder wrote:
It is so easy to make spelling errors in keys using 
hand-written JSON.


I don't understand why this would apply to JSON specifically. 
Whatever the language is, the config files will be hand-written; 
spelling errors are pretty universal, and anything we write is 
prone to mistakes to some extent

Re: dud: A dub replacement

[bachmeier via Digitalmars-d-announce]

On Monday, 18 November 2019 at 19:44:46 UTC, Russel Winder wrote:
On Mon, 2019-11-18 at 15:35 +, Joseph Rushton Wakeling via 
Digitalmars-d- announce wrote:



[…]
It is quite extraordinary how readily folks fall to arguing 
over what the config format should be, rather than what the 
app should actually be able to do. :-\


Perhaps because writing the configuration files is a critical 
part of the usability of the tool.


IMO this is one of the most important parts of the first five 
minutes with the language. Someone has installed the compiler, 
and now they want to test it out. If they have a bad experience 
with Dub, they will not continue with the language. A package 
manager, including the choice of format, is something you have to 
get right. Rust understands this.

Re: dud: A dub replacement

[Tobias Pankrath via Digitalmars-d-announce]

On Monday, 18 November 2019 at 19:54:38 UTC, Russel Winder wrote:

Probably yes. Though Cargo has taken many different decisions 
to Dub and mostly I think Cargo took better decisions.


Could you elaborate a bit, please? I am not familiar with Cargo 
though.

Re: dud: A dub replacement

[Paolo Invernizzi via Digitalmars-d-announce]

On Monday, 18 November 2019 at 15:35:12 UTC, Joseph Rushton 
Wakeling wrote:
On Monday, 18 November 2019 at 13:19:12 UTC, Paolo Invernizzi 
wrote:
Closing this kind of discussions and letting anyone to choose 
"tabs or spaces" is a constructive solution, I think.


It is quite extraordinary how readily folks fall to arguing 
over what the config format should be, rather than what the app 
should actually be able to do. :-\


Exactly, that's why I love pragmatism: let's dud emit the ones 
that are outdated, automatically.


Everyone can choose, work and update or the format he prefers, 
without impacting other people choices, and the discussion can 
move forward to something more interesting ...


my 2 cents, at least ...

Re: dud: A dub replacement

[Russel Winder via Digitalmars-d-announce]

On Mon, 2019-11-18 at 16:54 +, JN via Digitalmars-d-announce wrote:
> […]
> 
> I only use the JSON format. JSON is widespread together with XML. 
> SDL I heard first time of in the context of Dub and never seen it 
> used elsewhere. TOML also I know only from Cargo. YAML at least I 
> know from several different projects.

It is so easy to make spelling errors in keys using hand-written JSON.

SDL I have only ever used with Dub, but it works better for me than JSON.

TOML is really an INI evolution so known to many.

YAML is used by many but doesn't really allow for the ease of specifying lists
as TOML and SDL have.

> I guess the tool must be working very well though if the main 
> argument is what kind of data format to use :)

Probably yes. Though Cargo has taken many different decisions to Dub and
mostly I think Cargo took better decisions.

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



signature.asc
Description: This is a digitally signed message part

Re: dud: A dub replacement

[Russel Winder via Digitalmars-d-announce]

On Mon, 2019-11-18 at 15:35 +, Joseph Rushton Wakeling via Digitalmars-d-
announce wrote:
> 
[…]
> It is quite extraordinary how readily folks fall to arguing over 
> what the config format should be, rather than what the app should 
> actually be able to do. :-\

Perhaps because writing the configuration files is a critical part of the
usability of the tool.

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



signature.asc
Description: This is a digitally signed message part

Re: dud: A dub replacement

[JN via Digitalmars-d-announce]

On Monday, 18 November 2019 at 10:40:28 UTC, Russel Winder wrote:
On Mon, 2019-11-18 at 10:26 +, Sebastiaan Koppe via 
Digitalmars-d-announce wrote:
On Monday, 18 November 2019 at 09:53:56 UTC, Paolo Invernizzi 
wrote:
> A win-win move would be to have dud emit the other formats 
> automatically as part of the compilation procedure, so to 
> have always all of them present and synced on the content.


I already regret starting about this. Instead of rooting for 
the SDL format, I should have just recommended to deprecate 
the json one.


I do not think you should regret starting a discussion on this.

Personally I only ever use SDL with Dub. Even contemplating 
using JSON for human written configuration files is, for me, 
totally the wrong thing to do.


I only use the JSON format. JSON is widespread together with XML. 
SDL I heard first time of in the context of Dub and never seen it 
used elsewhere. TOML also I know only from Cargo. YAML at least I 
know from several different projects.


I guess the tool must be working very well though if the main 
argument is what kind of data format to use :)

Re: dud: A dub replacement

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 11/18/19 7:59 AM, Joseph Rushton Wakeling wrote:

   - I would imagine getting dependency resolution really right
     would be top of the list -- it would be good to aim to fix
     issues like https://github.com/dlang/dub/issues/1732


As has been discussed elsewhere a few months ago, dependency resolution 
should be outsourced to an established SAT 
 solving 
lib, to avoid re-inventing a notoriously difficult wheel. This is what 
all the serious package managers have been moving towards, after 
invariably hitting problems (much like dub) trying to roll-their-own.

Re: dud: A dub replacement

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 11/18/19 3:54 AM, Jacob Carlborg wrote:


Perhaps this ship has already sail. But YAML would have been a better 
choice. It's a superset of JSON. All the existing JSON description files 
would have worked as is.
YAML's grammar is a convoluted read-only mess. Every time I have to 
write it I feel like I'm just guessing and hoping I'm magically writing 
it correctly. I've even had silent problems on travis-ci that turned out 
to be .travis.yml not being parsed the way I thought. That sort of thing 
shouldn't even be *possible* on a config file format.


Especially irritating to me is even just the basic nesting - the whole 
"sometimes you HAVE to use a hyphen and sometimes you have to OMIT the 
hyphen (or it'll silently be interpreted wrong)". And yea, yea, "Object 
vs array", whatever, but when you're using YAML for hand-written config 
files, the whole distinction between what should be objects vs arrays is 
just a big pile of arbitrary pointlessness (a flaw it inherits from JSON).


And the grammar being a superset of JSON doesn't really help much in 
practice, because real idiomatic YAML in the wild (including config file 
examples) doesn't use it.

Re: dud: A dub replacement

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Monday, 18 November 2019 at 13:19:12 UTC, Paolo Invernizzi 
wrote:
Closing this kind of discussions and letting anyone to choose 
"tabs or spaces" is a constructive solution, I think.


It is quite extraordinary how readily folks fall to arguing over 
what the config format should be, rather than what the app should 
actually be able to do. :-\

Re: setup-dlang v0.4.0 released

[Sebastiaan Koppe via Digitalmars-d-announce]

On Monday, 18 November 2019 at 10:32:29 UTC, Mihails wrote:

https://github.com/mihails-strasuns/setup-dlang/releases/tag/v0.4.0

Note: assuming no new issues will be found in a next few weeks, 
this will be eventually promoted to the 1.0.0 release. Fingers 
crossed.


Thanks for this. It works perfectly.

Re: dud: A dub replacement

[Paolo Invernizzi via Digitalmars-d-announce]

On Monday, 18 November 2019 at 10:44:18 UTC, Russel Winder wrote:
On Mon, 2019-11-18 at 09:53 +, Paolo Invernizzi via 
Digitalmars-d-announce

wrote:
[…]
A win-win move would be to have dud emit the other formats 
automatically as part of the compilation procedure, so to have 
always all of them present and synced on the content.


Why? In fact, why even think of doing this at all?

There should be one and only one human written configuration 
file for a build and it should be in a notation suitable for 
being written by humans.


It shouldn't be too much difficult, and maybe it's a cleaver 
way to move on from discussions about different formats.


Again why? It seems like a pointless overhead that achieves 
nothing constructive.


Closing this kind of discussions and letting anyone to choose 
"tabs or spaces" is a constructive solution, I think.


That's the whole point of a win-win solution, anyone has a gain, 
the JSON party and the SDL party.


But, hey, as someone has to implement that, feel free to simply 
ignore my opinion ...

Re: dud: A dub replacement

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Monday, 11 November 2019 at 13:44:28 UTC, Robert Schadek wrote:
So dub has some problems, and personally I find its code base 
very hard to get

into.
At Symmetry we are a very heavy user of dub, resulting in many 
wasted hours.


So I started to write dud [1]. I kept some boring/nice parts 
from dub, but most

code so far is a complete rewrite.

The goal of dud is mostly do what dub does, but more 
understandable.


Cool :-)  Since I have also been experiencing a fair bit of 
production-use DUB pain in the last year, I really appreciate 
your taking action on this.


A few things that would be good to understand up front:

  * what are the particular issues with DUB that you want to 
address?


  - making the codebase cleaner and more functional is 
obviously
nice but is at most a means to an end -- what's the real 
end

you have in mind?

  - I would imagine getting dependency resolution really right
would be top of the list -- it would be good to aim to fix
issues like https://github.com/dlang/dub/issues/1732

  - I would personally really appreciate it if you would make 
it

a design goal to better separate concerns in terms of what
DFLAGS are used and why (for example, the fact that right 
now
`dub test --build=release` will not actually run 
unittests,

as `--build=release` drops the `-unittest` flag)

  * are there any particular known issues with DUB that this 
definitely

will NOT address?

  * are there any key _breaking_ changes you have in mind?

  * where does this stand w.r.t. some of the proposals to break 
DUB apart
into more cleanly separated components, e.g. determining 
compatible
dependencies, downloading dependencies, building or running 
tests ... ?


Some concrete feedback on the project as it stands:

  * the tickboxes of compatible commands are nice, but it would 
be good to
have a more contextualized roadmap, in particular outlining 
the design

concerns for core data structures and functionality

  - this should probably be in issues rather than the README, 
but
it needs to be somewhere, otherwise it's hard for anyone 
outside

to identify things they can do

  - it might be nice to use a GitHub project to manage things 
so that
us outside folks can identify better what's being worked 
on and

what's blocked by what

  * I don't mind breaking changes in either the config format or 
the command
line API if it gets us to a nicer tool, so please embrace the 
opportunity

where appropriate

  - I can imagine this might be the reason why the aim is to 
support
a "tasteful subset" of DUB's features: it means that 
others can

be re-implemented in an incompatible but better way

  - auto-conversion mechanisms may be preferable to outright 
support

for old formats and commands

  * I really recommend trying to start writing clean, clear 
commit messages
from the very start -- think of this as another form of code 
documentation
that communicates to all interested readers the intent and 
considerations
behind any particular change to the codebase.  This makes it 
much easier
for outsiders to get a clear understanding of the project and 
get into the

habit of contribution

  - right now, pretty much all the commit messages read like 
spontaneous
notes where even YOU won't remember the whys or 
wherefores in a few

months' time

  - long term it saves a LOT of time when trying to look back 
and understand
"Why did we do things that way?" -- particularly useful 
when trying to

fix some subtle design bug

  * for the same reasons, really try to provide good 
documentation and comments
for all code from the start -- this really makes it much 
easier for anyone
interested to grasp the major design concerns and get 
contributing


  * these concerns are going to be strongest for the key data 
structures and
algorithms -- please make sure these are REALLY documented 
well, from the

very start

Hope all of that's helpful, and best wishes for taking this 
forward -- I will try to help as I can, but time right now is 
very constrained ... ;-)


Thanks & best wishes,

 -- Joe

Re: dud: A dub replacement

[Russel Winder via Digitalmars-d-announce]

On Mon, 2019-11-18 at 09:53 +, Paolo Invernizzi via Digitalmars-d-announce 
wrote:
[…]
> A win-win move would be to have dud emit the other formats 
> automatically as part of the compilation procedure, so to have 
> always all of them present and synced on the content.

Why? In fact, why even think of doing this at all?

There should be one and only one human written configuration file for a build
and it should be in a notation suitable for being written by humans.

> It shouldn't be too much difficult, and maybe it's a cleaver way 
> to move on from discussions about different formats.

Again why? It seems like a pointless overhead that achieves nothing
constructive.

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



signature.asc
Description: This is a digitally signed message part

Re: dud: A dub replacement

[Russel Winder via Digitalmars-d-announce]

On Mon, 2019-11-18 at 10:26 +, Sebastiaan Koppe via Digitalmars-d-announce 
wrote:
> On Monday, 18 November 2019 at 09:53:56 UTC, Paolo Invernizzi 
> wrote:
> > A win-win move would be to have dud emit the other formats 
> > automatically as part of the compilation procedure, so to have 
> > always all of them present and synced on the content.
> 
> I already regret starting about this. Instead of rooting for the 
> SDL format, I should have just recommended to deprecate the json 
> one.

I do not think you should regret starting a discussion on this.

Personally I only ever use SDL with Dub. Even contemplating using JSON for
human written configuration files is, for me, totally the wrong thing to do.

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



signature.asc
Description: This is a digitally signed message part

setup-dlang v0.4.0 released

[Mihails via Digitalmars-d-announce]

https://github.com/mihails-strasuns/setup-dlang/releases/tag/v0.4.0

Note: assuming no new issues will be found in a next few weeks, 
this will be eventually promoted to the 1.0.0 release. Fingers 
crossed.


Fixes
-

* ldc-master will use latest uploaded asset for the current 
platform


Fixes rare issue when actions runs during new nightly asset 
upload and not all

platforms are available for the latest commit.

New features


* Use github access token for the api (#15)

Oauth access token is supposed to come from a yml configuration 
file if
ldc-master is used. Github actions provide one that can be used 
out of

the box with secrets.GITHUB_TOKEN variable.

* Verify DMD downloads with GPG (#5)

DMD does not use HTTPS for download links, thus using GPG 
signature is
necessary to avoid MitM. LDC currently does not need/provide 
those.

Re: dud: A dub replacement

[Sebastiaan Koppe via Digitalmars-d-announce]

On Monday, 18 November 2019 at 09:53:56 UTC, Paolo Invernizzi 
wrote:
A win-win move would be to have dud emit the other formats 
automatically as part of the compilation procedure, so to have 
always all of them present and synced on the content.


I already regret starting about this. Instead of rooting for the 
SDL format, I should have just recommended to deprecate the json 
one.

Re: dud: A dub replacement

[Paolo Invernizzi via Digitalmars-d-announce]

On Monday, 18 November 2019 at 09:42:16 UTC, Russel Winder wrote:
On Mon, 2019-11-18 at 09:31 +, Sebastiaan Koppe via 
Digitalmars-d-announce wrote:
On Monday, 18 November 2019 at 08:57:58 UTC, Russel Winder 
wrote:

> Is SDL the right format? Cargo uses TOML to great effect.
> 
> And TOML has, I suspect greater traction more widely than 
> SDL.


I personally prefer SDL when it comes to nested data, but 
yeah, that would work as well.


The point I was making is to just have 1 format. With dud that 
should be possible.


For me the argument is that SDL and TOML are intended for 
human's to write configuration scripts, whilst XML and JSON are 
intended for computers to send data to other computers.


A win-win move would be to have dud emit the other formats 
automatically as part of the compilation procedure, so to have 
always all of them present and synced on the content.


It shouldn't be too much difficult, and maybe it's a cleaver way 
to move on from discussions about different formats.

Re: dud: A dub replacement

[Russel Winder via Digitalmars-d-announce]

On Mon, 2019-11-18 at 09:31 +, Sebastiaan Koppe via Digitalmars-d-announce 
wrote:
> On Monday, 18 November 2019 at 08:57:58 UTC, Russel Winder wrote:
> > Is SDL the right format? Cargo uses TOML to great effect.
> > 
> > And TOML has, I suspect greater traction more widely than SDL.
> 
> I personally prefer SDL when it comes to nested data, but yeah, 
> that would work as well.
> 
> The point I was making is to just have 1 format. With dud that 
> should be possible.

For me the argument is that SDL and TOML are intended for human's to write
configuration scripts, whilst XML and JSON are intended for computers to send
data to other computers.

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



signature.asc
Description: This is a digitally signed message part

Re: dud: A dub replacement

[Sebastiaan Koppe via Digitalmars-d-announce]

On Monday, 18 November 2019 at 08:57:58 UTC, Russel Winder wrote:

Is SDL the right format? Cargo uses TOML to great effect.

And TOML has, I suspect greater traction more widely than SDL.


I personally prefer SDL when it comes to nested data, but yeah, 
that would work as well.


The point I was making is to just have 1 format. With dud that 
should be possible.

Re: dud: A dub replacement

[Russel Winder via Digitalmars-d-announce]

On Sun, 2019-11-17 at 19:10 +, Sebastiaan Koppe via Digitalmars-d-announce 
wrote:
> On Sunday, 17 November 2019 at 16:26:45 UTC, Denis Feklushkin 
> wrote:
> > On Thursday, 14 November 2019 at 23:33:06 UTC, Nick Sabalausky 
> > (Abscissa) wrote:
> > Also, this, apparently, should lead to the fact that dud will 
> > have their own package description format. Almost inevitable. 
> > (This has already been discussed, perhaps.)
> 
> SDL all the way please.

Is SDL the right format? Cargo uses TOML to great effect.

And TOML has, I suspect greater traction more widely than SDL.

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



signature.asc
Description: This is a digitally signed message part

Re: dud: A dub replacement

[Jacob Carlborg via Digitalmars-d-announce]

On Sunday, 17 November 2019 at 19:10:05 UTC, Sebastiaan Koppe 
wrote:



SDL all the way please.


Perhaps this ship has already sail. But YAML would have been a 
better choice. It's a superset of JSON. All the existing JSON 
description files would have worked as is.


--
/Jacob Carlborg