Re: D Language Foundation April 2023 Quarterly Meeting Summary

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Friday, 28 April 2023 at 19:50:55 UTC, max haughton wrote:
1. The conversation about formatters is not quite on the money 
wrt internals, sdfmt doesn't work as written. I will write 
something explaining the two both architecturally (politically 
really for the purposes of this debate) and also which I think 
is better.


That would be good to see.  Is `sdfmt` actually documented 
anywhere?  I can't find anything obvious, including in the source 
code.

Re: A New Era for the D Community

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Wednesday, 3 May 2023 at 11:13:34 UTC, Mike Parker wrote:
I'm not exaggerating when I say that this is going to be the 
most significant change in the D community in the 20 years I've 
been a part of it. I expect we're going to encounter bumps 
along the way, but that's okay. We now have a clear vision and 
purpose, and that makes all the difference.


This sounds very exciting -- more than any details (which I'm 
sure we'll learn over time), I'm struck by the enthusiasm and 
confidence for the future of how D will be supported.


I really look forward to learning more as things progress.  Many 
thanks to Ucora for their investment of time, insight, and 
resources.

Re: Sociomantic Tsunami now under new community maintainership

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Wednesday, 30 September 2020 at 08:31:25 UTC, Iain Buclaw 
wrote:

I would like to thank dunnhumby for being supportive throughout
the entire process, and for handling the transition in a 
gracious

fashion since operations began winding down.


I would second those thanks, and would also like to offer a big 
hand to Iain for stewarding this whole process.

Re: Sociomantic Tsunami now under new community maintainership

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Thursday, 1 October 2020 at 07:43:38 UTC, Imperatorn wrote:
On Wednesday, 30 September 2020 at 08:31:25 UTC, Iain Buclaw 
wrote:

Hello Everybody,

Tsunami is a set of core libraries, applications, and tools 
that were used at
sociomantic labs/dunnhumby Germany, and have been available as 
open-source
software since 2017 under the direction and management of 
dunnhumby.


[...]


Cool. Are those projects on dub as well?


Ocean is up to date and on dub: 
https://code.dlang.org/packages/ocean


Adding dub config to the other projects is planned, and we'd 
welcome patches if anyone wants to speed up that process.

Re: Decimal string to floating point conversion with correct half-to-even rounding

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Saturday, 8 August 2020 at 18:16:30 UTC, Avrina wrote:
 there's no shame to it any more than it is
What's the purpose of that? If someone needs Mir, they can just 
add it as a dependency in dub. This will just be adding more 
bloat to drubtime. The development surrounding D seems to have 
a stigma of using external dependencies even when there is 
significant benefit. I find it odd that you bring up that 
there's no shame to copy and paste. It seems the only reason 
there simply wouldn't be a link to a dependency is because of 
stigma. There's no shame relying on another project and you 
don't have to copy and paste it. Optlink, DMC, DMC's club, etc. 
Its gotten better than it was, but there's no reason to even 
use any of those anymore, supporting them is just a waste of 
time. As would maintaining a copy pasta of Mir would be.


It's not about shame. It's about a guarantee of control, that the 
code and behaviour doesn't change unless you want it to, and 
about minimizing complexity for users trying to build the project 
from scratch. Phobos' zlib dependency is copy-pasted in the 
codebase for similar reasons.

Re: Decimal string to floating point conversion with correct half-to-even rounding

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Saturday, 11 July 2020 at 10:58:31 UTC, Dibyendu Majumdar 
wrote:
This argument seems a bit odd given ... when D code was 
contributed to gcc, did you follow the FSF rule of assigning 
copyright to FSF?


The issue is about maintenance of the codebase, not about who 
owns the copyright.

Re: Decimal string to floating point conversion with correct half-to-even rounding

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Tuesday, 7 July 2020 at 12:04:43 UTC, Steven Schveighoffer 
wrote:
Guys, this is all open source, all licensed identically. There 
are ways to solve this. Practically speaking, just because DMD 
depends on Mir, doesn't mean that Mir has control over how the 
dependency works. DMD can depend on a specific version of Mir, 
upgraded when reasonable (i.e. it should take a PR change to 
DMD for upgrading which code exactly is depended on) and if 
something changes in the future, you can fork it, or move back 
to using libc. This way, the code is only maintained in one 
place unless something catastrophic happens.


Well, for avoidance of doubt, I'm not personally opposed per se 
to the use of 3rd party libs in DMD or druntime/phobos.  It just 
struck me as important that everyone understands clearly each 
other's concerns.


What I think provoked concern was not the idea of using 
mir-algorithm as a 3rd party lib, but this alternative suggestion:



The second solution is to move `mir.bignum` and `mir.parse` to
DRuntime/Phobos. In this case, I would like to preserve the 
`mir.`

namespace and the same authority and veto right for this part of
the codebase as I have at Mir Org.


... where what's being asked is a rather stronger commitment, and 
not really workable: if the code's going to live in D foundation 
repos then any maintainer or veto rights are going to be 
provisional.  It's just not reasonable for the maintainer of 2 
stdlib modules to be able to unilaterally veto changes, or force 
breaking change.


There's no reason per se why 3rd party libs can't be used under 
the hood to provide implementations, but druntime and phobos 
maintainers need to be able to make their own API guarantees.

Re: Decimal string to floating point conversion with correct half-to-even rounding

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Sunday, 5 July 2020 at 11:07:55 UTC, 9il wrote:
There is no risk for DMD and DFL to depend on a Mir's Boost 
licensed library. If something happens with Mir or Mir change 
the license, DFL will be able to fork the required code at any 
point in the Boost licensed part of git history.


Can't speak for Walter or the D foundation here, but I'm not sure 
the concern is really about licensing.  It's about putting in 
place a required dependency on code where maintenance decisions 
are outside the hands of the D Foundation.

Re: Talk by Herb Sutter: Bridge to NewThingia

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Sunday, 28 June 2020 at 21:00:09 UTC, Dibyendu Majumdar wrote:
To be honest the analysis doesn't quite stack up. Because 
compatibility is not the reason for the success of Go, or Rust.


I think that's a misinterpretation of what was said.  
Compatibility is not a reason for success -- but the _absence_ of 
sufficient compatibility will always lead to failure.


I can't speak for Go, but Rust's compatibility is clearly 
adequate given how Mozilla is able to fit it inside the (mostly 
C++) Firefox codebase.

Re: iopipe v0.2.0 - safe update

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Sunday, 28 June 2020 at 18:57:22 UTC, Steven Schveighoffer 
wrote:
Just wanted to post that I finished my update of iopipe to be 
@safe. I still have some work to do with std.io so things are 
more usable (next on my list is to make standard handles 
accessible).


Cool, and congratulations :-)

Inside iopipe is a RefCounted type that is @safe. It uses the 
GC for memory management, so while destruction is synchronous, 
the memory itself is left to the GC to clean up.


One concern here -- this means that one cannot control when an 
app using this might block for GC, right?  Any thoughts on how a 
user could get more deterministic control on when the memory 
would be released?

Re: Origins of the D Programming Language now published by ACM!

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Saturday, 13 June 2020 at 03:16:05 UTC, Walter Bright wrote:

https://dl.acm.org/doi/abs/10.1145/3386323

Many, many thanks to Mike Parker and Andrei Alexandrescu for 
their endless hours spent fixing the mess I originally wrote.


Congratulations!  It's really nice to see this in final published 
form. :-)

Re: DIP1028 - Rationale for accepting as is

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Sunday, 24 May 2020 at 09:47:37 UTC, Walter Bright wrote:
It's a fair point, but without the source code the distinction 
is meaningless.


It's meaningless in terms of what the compiler can check, but 
it's not meaningless in terms of documenting the assumptions and 
promises the developer is making.

Re: DIP1028 - Rationale for accepting as is

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Friday, 22 May 2020 at 18:32:59 UTC, Steven Schveighoffer 
wrote:
So the solution is -- make the compiler be dumb for you? If you 
are going to incorrectly put @safe on it, I want you to have to 
do it because YOU made a conscious decision to be careless, not 
have it done for you because you forgot.


Yea, agreed.  If a library works around an extern(C) API by 
slapping `@safe:` on it, this is a visibly problematic thing to 
do, and people can file bug reports and patches about it.  And we 
can have well documented warnings about this being a bad way to 
do things.


If a library just gets extern(C) APIs as @safe by default, then 
it's not visibly obvious that this is problematic.


I would much rather have the problematic thing as something 
visibly done by the developer, than automatically done by the 
compiler.

Re: DIP1028 - Rationale for accepting as is

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Friday, 22 May 2020 at 01:22:19 UTC, Walter Bright wrote:

I have made these points before, but I'll summarize them here
for convenient referral.


Thanks Walter.  I really appreciate you taking the time to do 
this, as it's obviously no fun to be getting a big tide of 
negativity in this way.



This is Obviously A Good Idea. Why would I oppose it?

1. I've been hittin' the crack pipe again.
2. I was secretly convinced, but wanted to save face.
3. I make decisions based on consultation with my astrologer.
4. I am evil.


... wait, we don't ALL make decision like that? :-)

In seriousness: I really, really wish that everyone throwing 
around personal attacks would take a moment to stop and think 
about the consequences of pursuing this kind of discourse: it 
distracts from the technical, practical and organizational issues 
at hand, it creates a worse mood than exists already, and 
generally makes it harder to have a constructive conversation 
around the core disagreements here.


It is perfectly possible to critique the decision taken, or the 
way in which it was taken, or to voice personal frustrations, 
without casting aspersions on the decision-maker.


With the rationale laid out clearly as it is here, I do have some 
responses in mind.  But before sharing them, I'd like to know 
whether that would be useful right now: I've no wish to just 
press for a re-hashing of conversations that have already been 
had.

Re: DIP 1028--Make @safe the Default--Formal Assessment

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Thursday, 21 May 2020 at 21:41:53 UTC, Steven Schveighoffer 
wrote:
The unfortunate end result of this change is that safety will 
be gutted with all C functions being trusted by default


I'm really sorry, Walter, but I have to agree with Steve on this 
point.  This was the one aspect of the DIP that I really wanted 
to get modified, I also proposed a number of options for how to 
do so, and I'm really worried about the consequences of this 
decision.


I recognize and respect your right to make decisions as you see 
fit for the language, but I really wish I could persuade you to 
change your mind about this one :-)

Re: DIP 1028--Make @safe the Default--Formal Assessment

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Thursday, 21 May 2020 at 20:59:08 UTC, Walter Bright wrote:

Many replies to you, Steven:

https://digitalmars.com/d/archives/digitalmars/D/Discussion_Thread_DIP_1028--Make_safe_the_Default--Final_Review_336354.html

I did not ignore you. I just didn't agree.


One concern here is that these responses are scattered across 
different parts of a long discussion thread.  So it probably 
would be a good idea for the acceptance to be accompanied by an 
explanation of what the major objections were to the DIP, and why 
they were discounted.


It's not so different from the way that, at the end of a talk or 
presentation, it's a good idea to recap the key points that have 
already been covered.

Re: On the D Blog: Lomuto's Comeback

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Thursday, 14 May 2020 at 13:26:23 UTC, Mike Parker wrote:
After reading a paper that grabbed his curiosity and wouldn't 
let go, Andrei set out to determine if Lomuto partitioning 
should still be considered inferior to Hoare for quicksort on 
modern hardware. This blog post details his results.


Blog:
https://dlang.org/blog/2020/05/14/lomutos-comeback/


Nice stuff!

One curious question -- unless I've misread things horribly, it 
looks like the D benchmarks for Lomuto branch-free are 
consistently slower than for C++.  Any idea why that is?  I would 
expect gcc/gdc and clang/ldc to produce effectively identical 
results for code like this.

Re: DConf 2020 Canceled

[Joseph Rushton Wakeling via Digitalmars-d-announce]

Hi Mike,

I'm so sorry to hear this, but I completely understand and 
support the reasoning.  Given the circumstances I was honestly 
expecting this to happen.


As others have suggested, I hope we can organize something online 
via videoconferencing.  It will be good to "see" and chat with 
everyone even if only at a distance.


Yes, we all interact a lot online anyway, but there's a 
difference between our day to day interactions, versus having 
some dedicated presentation and Q time.  Besides, DConf isn't 
just for those of us who go, the presentation videos are part of 
our outreach.


Thanks and best wishes,

 -- Joe

Re: LDC 1.19.0

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Thursday, 26 December 2019 at 12:41:14 UTC, Joseph Rushton 
Wakeling wrote:

On Friday, 20 December 2019 at 18:30:37 UTC, H. S. Teoh wrote:

LLVM upgraded to v9.0.1, incl. experimental AVR backend.


Is that an upstream release?  I don't see a 9.0.1 in the LDC 
LLVM fork:

https://github.com/ldc-developers/llvm/releases


Oh, I see.  The details are covered in the LDC 1.19.0 release 
notes (there's a repo switch):

https://github.com/ldc-developers/ldc/releases/tag/v1.19.0

Re: LDC 1.19.0

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Friday, 20 December 2019 at 18:30:37 UTC, H. S. Teoh wrote:

LLVM upgraded to v9.0.1, incl. experimental AVR backend.


Is that an upstream release?  I don't see a 9.0.1 in the LDC LLVM 
fork:

https://github.com/ldc-developers/llvm/releases

Re: Hunt XML released 1.0.0 rc! Support for parsing, encoding, serialize, unserialize, object binding ..

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Thursday, 5 December 2019 at 16:28:48 UTC, Adam D. Ruppe wrote:
On Thursday, 5 December 2019 at 16:14:01 UTC, Joseph Rushton 
Wakeling wrote:
And -- mostly out of curiosity -- what are the major 
differences compared to other D XML libraries


or my beloved dom.d


Indeed!  Sorry for missing it out.  I've found it friendly and 
helpful for a number of use-cases, but as they were all related 
to HTML parsing, my mental map of dom.d is a bit focused on that, 
and its broader uses skipped my mind.

Re: Hunt XML released 1.0.0 rc! Support for parsing, encoding, serialize, unserialize, object binding ..

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Thursday, 5 December 2019 at 15:55:29 UTC, zoujiaqing wrote:

# Hunt-XML
A XML library for D Programming Language. Support for parsing, 
encoding, serialize, unserialize, object binding!


## Features
* DOM parser: parse XML Document
* DOM writer: to string and to file
* Object serialization/deserialization


Cool, congratulations :-)

Just based on a quick check, it looks like the `validate` method 
used in your example is just about strictly correct XML -- does 
the library provide any support for validating messages against a 
schema?


And -- mostly out of curiosity -- what are the major differences 
compared to other D XML libraries such as experimental.xml 
 and dxml 
 ... ?

Re: ldc2 1.18.0 snap package release

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Wednesday, 4 December 2019 at 10:52:58 UTC, zoujiaqing wrote:

Thanks!!

Could support flatpak? :)


I've commented on this before: 
https://forum.dlang.org/post/glpgelcitafzjayje...@forum.dlang.org


In short: unless anything has changed since the last time I 
looked, snap packages are better suited for compiler use-cases.


There are apparently some compiler flatpaks out there (e.g. one 
for swift: 
http://swift-linux.refi64.com/en/latest/install.html#flatpak), 
but that appears to be tied to a desktop use-case.  And, frankly, 
look how much extra manual work you have to do to get that 
working, compared to just


 sudo snap install ...

... and run the newly installed compiler.

ldc2 1.18.0 snap package release

[Joseph Rushton Wakeling via Digitalmars-d-announce]

Hello folks,

Just to announce that there are now stable 1.18.0 releases for 
amd64 and i386 builds of the ldc2 snap package.  To install:


sudo snap install --classic --stable ldc2

or upgrade:

sudo snap refresh --classic --stable ldc2

There are also stable releases for all the recent 1.x releases 
(1.1 through 1.17).  To switch to these, use for example:


sudo snap install --classic --channel=1.17/stable ldc2

or to switch an installed version:

sudo snap refresh --classic --channel=1.16/stable ldc2

... or similarly for any other 1.x release you prefer.

These should work on any Ubuntu release more recent than 14.04, 
and any recent Debian, Arch, SuSE, Solus, and others.  For a full 
list of supported distros see:

https://snapcraft.io/docs/installing-snapd

Running the ldc2 snap requires gcc to be installed on the host 
system, as this is used for linking.


Hope this is useful, and please let me know if the snap package 
is useful for you.


Thanks & best wishes,

 -- Joe

Re: Proposal for porting D runtime to WebAssembly

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Monday, 25 November 2019 at 13:00:23 UTC, Sebastiaan Koppe 
wrote:
Yes, definitely. But what do you mean with improved support? 
Like better pattern matching over either types?


Yes, that sort of thing.  And maybe a move towards trying to use 
this kind of error handling in newer editions of the standard 
library (I'm reluctant to push too strongly on that, but I get 
the impression there is some inclination to move in this 
direction, as a reflection of wider design trends).

Re: dud: A dub replacement

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Monday, 25 November 2019 at 11:59:11 UTC, Andre Pany wrote:
Is there any chance you can be convinced to join our force to 
improve Dub?
A lot of developers invested their time to either improve Dub 
in general

or to get their needed scenarios running.

My gut feeling is, it would take years to rebuild the same set 
of functionality

starting from the green field.


The distinction seems academic at this stage, because nothing 
stops anyone blessing dud as dub 2.0 when it's in a good enough 
state to be used in production, and nothing stops dub devs and 
contributors from offering feedback and code to help out with 
dud.  And even if Robert were to work inside the dub repo, the 
basic tasks -- going bottom-up to rewrite core data structures 
and algorithms, etc. -- would still be mostly the same.


That's why I strongly recommend that at this stage, the focus 
should be on the behaviours we want from our build system, and 
how they should interact and overlap.


What's currently broken or impossible in DUB?  What parts of that 
can be fixed without changing the config or CLI?  And what 
improvements are most efficiently made via breaking changes?


Please, let's bring our focus on that.

Re: Proposal for porting D runtime to WebAssembly

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Saturday, 23 November 2019 at 09:51:13 UTC, Sebastiaan Koppe 
wrote:
This is my proposal for porting D runtime to WebAssembly. I 
would like to ask you to review it. You can find it here: 
https://gist.github.com/skoppe/7617ceba6afd67b2e20c6be4f922725d


Thanks for putting this together, it looks very carefully thought 
out.


On this particular part:

Exceptions can be thrown but not catched. A thrown exception 
will
terminate the program. Exceptions are still in the proposal 
phase.

When the proposal is accepted exceptions can be fully supported.


This would suggest that there may be some benefit in D providing 
improved support for return-type-based error propagation (as with 
`Result` from Rust), no ... ?

Re: dud: A dub replacement

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Thursday, 21 November 2019 at 14:50:59 UTC, Steven 
Schveighoffer wrote:

Assuming the code you wrote does what you wanted it to do...

Often times, comments convey what you're thinking, and it's 
much easier to understand a description than mentally compiling 
and running the code to figure out what you were thinking.


Exactly.  And of course this isn't just for the benefit of others 
-- future you often needs the exact same help to understand what 
past you was thinking ...

Re: dud: A dub replacement

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Wednesday, 20 November 2019 at 11:40:19 UTC, Robert Schadek 
wrote:

Here is disagree, to a degree I consider comments a code smell.
If I have to write them, I failed to convey the information
needed to understand the code in the code.


That depends on what you're using documentation and comments for.

It's obviously great to try to write code that is as clean and 
clear and comprehensible as possible.  But in general even the 
cleanest and clearest code rarely communicates the WHY behind 
design decisions.  "This design was chosen because ..."  "These 
are the assumptions made ..." etc.


That WHY is what you want to clearly document, because that's 
what saves the most time for anyone looking to understand and 
modify the codebase.

Re: dud: A dub replacement

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Monday, 18 November 2019 at 16:31:09 UTC, Nick Sabalausky 
(Abscissa) wrote:
As has been discussed elsewhere a few months ago, dependency 
resolution should be outsourced to an established SAT


I have no objections to that in principle, but I am not sure that 
will resolve the issue I posted: IIRC DUB's key problem is not so 
much how it resolves dependencies _per se_ but the fact that it 
includes dependency constraints that actually don't apply to a 
given build (e.g. constraints that derive from the testing 
requirements of dependencies).

Re: dud: A dub replacement

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Monday, 18 November 2019 at 20:48:53 UTC, bachmeier wrote:
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.


Fair point.  But that isn't something that has to be decided at 
the _start_ of a rewrite: better to focus on wanted behaviour, 
and then derive the ideal config format from that.

Re: dud: A dub replacement

[Joseph Rushton Wakeling 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.


Fair.  My remark was maybe a little too intemperate :-)

I'm simply concerned that if we don't put enough scrutiny on the 
app features and behaviour, we run the risk of simply reproducing 
some of the problematic design decisions of the existing tool.


As an example -- try running `dub test --build=release`.  
Intuition suggests that this is testing a release build.  But 
actually it strips out your unittests, because `--build=release` 
determines not only the optimization flags, but the complete set 
of DFLAGS used -- and `-unittest` isn't among them.


I ran `dub test && dub test --build=release` as a matter of habit 
for some time before discovering the latter wasn't actually 
testing anything.  And while I now know that I _can_ define a 
custom build to get what I want, that's clumsy and hard(er) to 
discover, and annoying to have to repeat for every project I 
create.


That's the kind of usability and design concern we really ought 
to be revisiting in any rewrite.

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: 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: Blog Post: Beating std::visit Without Really Trying

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Monday, 7 October 2019 at 01:38:04 UTC, Paul Backus wrote:
Just to clarify: SumType isn't, and was never intended to be, a 
drop-in replacement for Algebraic. Their interfaces are similar 
enough that porting code from Algebraic to SumType shouldn't be 
too difficult, but even within the common subset, there are 
incompatibilities. For example, here's a post from an old 
sumtype announcement thread where I discuss the differences 
between SumType's `match` and Algebraic's `visit`:


https://forum.dlang.org/post/xipgrrfljdnyhrhnm...@forum.dlang.org


I don't follow. The visit and match template signatures are 
identical, and from what you describe the SumType match 
implementation should support the same handler choices as visit, 
while allowing extra/more flexible choices.


Where's the breaking change? Are there selections of handlers 
that work for visit and don't work with match?

Re: Blog Post: Beating std::visit Without Really Trying

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Sunday, 6 October 2019 at 14:08:07 UTC, Adam D. Ruppe wrote:
D can eliminate error paths at compile time too, e.g. static 
assert - which can be used to create all kinds of new useful 
errors. So I am guessing this is just a case of the code 
needing a lil tweak or the compiler being conservative and 
putting the code in even though it is never supposed to happen 
(like final switch keeps an error path because you can do like 
cast(some_enum) value_not_in_enum and then better to have 
the assertion failure than UB.)


Good to hear. I confess I was a bit mystified about why it should 
be an issue for D or why compiler vs. library implementation 
should make a difference to the ability to eliminate the error 
path (I infer from your remarks that it shouldn't, in principle).


I'm not fluent in assembly so, leaving the error path aside, I 
wasn't sure how to interpret the "main path" assembly from the D 
and Rust code, and whether they were practically equivalent 
(clearly the assembly posted looked different). Can anyone offer 
any interpretation there?

Re: Blog Post: Beating std::visit Without Really Trying

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Sunday, 6 October 2019 at 08:27:35 UTC, Seb wrote:

Well, my guess it will be similar [...]


If you're not the one making those decisions it may be better not 
to prejudge them. A significant performance improvement is a 
different beast to moderate API/usability improvements.


A standard library is _not_ supposed to be a place where actual 
battle-testing happens. It's where things move when they have 
been tested and no longer change.


You misunderstand what I mean by "battle-testing". Clearly 
designs should go through a high level of testing and usage 
before they go anywhere near the standard library. But the very 
fact of being placed in the standard library exposes them to 
orders of magnitude more usage, and hence gives a much stronger 
guarantee of establishing their correctness (or identifying their 
flaws).


It's much better to get newer and apparently better designs 
exposed to this level of scrutiny _before_ making them the only 
option in a new major release. That way you are much less likely 
to get hit by a showstopper edge case that no one anticipated.

Re: Blog Post: Beating std::visit Without Really Trying

[Joseph Rushton Wakeling via Digitalmars-d-announce]

Speaking of performance, I was intrigued by the Reddit response 
noting that Rust can go one better by eliminating the error path 
at compile time:

https://www.reddit.com/r/programming/comments/ddi5wb/comment/f2iow4u

The commenter suggests that's because Rust bakes the 
functionality into the compiler instead of making it a library 
type. @Walter, @Andrei, that might be an interesting data point 
for the question of what should have compiler vs. library support?

Re: Blog Post: Beating std::visit Without Really Trying

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Sunday, 6 October 2019 at 03:47:25 UTC, Seb wrote:
My earlier post tried to point out that SumType is an excellent 
candidate for v2.


Sorry, Seb, but I don't get this. There's no reason to wait for a 
v2 to introduce a new SumType symbol that outperforms the old 
Variant (assuming it's not possible to just rewrite the latter 
implementation under the hood without changing behaviour).


On the contrary, the best way to do a v2 is likely to be that all 
or most of the stuff we want in it is already there and has been 
battle tested in the wild.

Re: D at 20: Hits and Misses, and what I learned along the way Oct 19

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Tuesday, 24 September 2019 at 23:27:44 UTC, Walter Bright 
wrote:

On 9/23/2019 3:01 PM, H. S. Teoh wrote:
On Mon, Sep 23, 2019 at 02:55:00PM -0700, Walter Bright via 
There should be redundant, decoupled camera/operator crew to 
solve this

problem. ;-)


I know. The same thing happened at DConf 2018, where the first 
morning's sessions were all lost.


Going by the lessons of DConf 2015, I reckon we should always 
have at least one person using their laptop to stream to YouTube 
;-)

Re: Five Projects Selected for SAOC 2019

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Monday, 26 August 2019 at 03:55:43 UTC, Andrej Mitrovic wrote:

On Sunday, 25 August 2019 at 13:38:24 UTC, Mike Parker wrote:

...
Solve Dependency Hell:
This is considered as a crucial first step in making Phobos 
available via the DUB registry


I'm guessing this means we might even be able to use multiple 
versions of Phobos one day. However before we do that, we will 
really need to fix the use of globals in Phobos.


Honestly, I'm a bit leery about this use-multiple-versions 
approach. It feels like it carries some serious risks of code 
bloat, which may be accentuated by the fact that DUB has some 
serious dependency resolution bugs even with single version 
dependencies... :-\

Important fix for DUB snap package

[Joseph Rushton Wakeling via Digitalmars-d-announce]

Hello all,

I've just released an important fix for the DUB snap package: it 
now bundles its own libcurl.


This should prevent issues observed on Ubuntu 18.04 where the dub 
snap was unable to find a suitable libcurl to load, and therefore 
could not download package data.


To upgrade to this new version, use:

sudo snap refresh --classic --channel=stable dub

This release also updates DUB itself to v1.13.0.

Thanks to Phil Burr who submitted a PR with the fix, and 
apologies to anyone who was impacted by the problem.


Best wishes,

-- Joe

Re: Release D 2.075.0

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Wednesday, 19 July 2017 at 15:36:22 UTC, Martin Nowak wrote:

Glad to announce D 2.075.0.

This release comes with various phobos additions, a repackaged
std.datetime, configurable Fiber stack guard pages (now also on
Posix), and optional precise GC scanning for the DATA/TLS 
segment (static

data) on Windows.

http://dlang.org/download.html 
http://dlang.org/changelog/2.075.0.html


- -Martin


Congratulations Martin and everyone!

A snap package for DMD 2.075.0 is now available in the `edge` 
channel of the snap store:


sudo snap install --classic --edge dmd

for a fresh install, or

sudo snap refresh --classic --edge dmd

... for anyone who already has an earlier version installed.

Note that there's a known issue with `rdmd` in this package 
(which is an issue with `snapd` rather than the package itself).  
However, please do let me know about any other issues (or 
successes!).

Re: LDC 1.3.0

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Sunday, 9 July 2017 at 21:33:17 UTC, kinke wrote:

LDC 1.3.0, the LLVM-based D compiler, is available for download!
This release is based on the 2.073.2 frontend and standard 
library and supports LLVM 3.5-4.0.


Congratulations all! :-)

The ldc2 snap package has been updated to 1.3.0 as well.

Re: Developer positions at Sociomantic Labs

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Tuesday, 13 June 2017 at 12:16:48 UTC, Vadim Lopatin wrote:

Is German needed?


No.  The office is English-speaking (and very international).

Re: Developer positions at Sociomantic Labs

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Tuesday, 13 June 2017 at 02:53:14 UTC, Dsby wrote:

唉、、My poor English、、、


English is important to us, but if you're keen, I would encourage 
you to apply anyway and let us make the decision on whether 
you're at the level we need.

Re: LDC 1.3.0-beta2

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Monday, 12 June 2017 at 17:49:46 UTC, kinke wrote:
LDC 1.3.0-beta2, the LLVM-based D compiler, is available for 
download!
This release is based on the 2.073.2 frontend and standard 
library and supports LLVM 3.5-4.0.


A snap package for this, using the LLVM 4.0.0 backend, is 
available in the 1.3/beta release channel.  New users can install 
this with:


sudo snap install --classic --channel=1.3/beta ldc2

while existing users can switch to it with

sudo snap refresh --classic --channel=1.3/beta ldc2

Developer positions at Sociomantic Labs

[Joseph Rushton Wakeling via Digitalmars-d-announce]

Hello all,

I'm happy to announce that we have some new D developer positions 
on offer at Sociomantic:

https://www.sociomantic.com/jobs/d-software-developer-adserving/
https://www.sociomantic.com/jobs/software-developer-d-language-bidding/

The first of these would particularly suit someone with 
experience with statistics, data science, and/or machine 
learning.  For the second, we're looking for someone with a good 
solid UNIX background (fully capable of going down all the twisty 
dark rabbit holes and finding those pesky hard-to-catch rabbits), 
preferably also with a good understanding of internet protocols.


D experience is nice, but by no means necessary: a capable C/C++ 
background is just fine.


Hope to hear from some of you soon :-)

All the best,

-- Joe

Re: Snap packages for DMD and DUB

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Tuesday, 6 June 2017 at 14:27:40 UTC, Johan Engelen wrote:
Have you thought about creating a `dtools` package with rdmd, 
dustmite, and ddemangle in it?
They are useful for LDC and GDC too, perhaps people would like 
to be able to install them without needing to install DMD.  
(Perhaps the DMD/LDC/GDC package can automatically install such 
a "dtools" package?)


Yes, I did consider this, and I may do it if there is an ongoing 
issue with `rdmd`.  It might for example be possible to entirely 
disable confinement for such a dtools package, as a short term 
measure to avoid the current problems.


I did have some discussion over the advisability of splitting up 
the `dmd` snap package in this discussion thread:

https://lists.ubuntu.com/archives/snapcraft/2017-March/003645.html

... albeit I was coming at things from a slightly different angle 
there.  The short version is, keeping everything in one snap 
might reduce the amount of duplication; but I'm not sure that 
it's a very big deal in any case.


AFAIK snap packages don't have an equivalent of deb packages' 
"Recommends", but I can raise the issue.


On a different note: does anyone have an interest in there being 
dmd versions available other than the most recent?

Re: Snap packages for DMD and DUB

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Tuesday, 6 June 2017 at 08:20:54 UTC, Piotr Mitana wrote:

Hi, I got yet another error - this time Ubuntu 16.04 and rdmd.

Failed to flush stdout: Permission denied
Failed: ["dmd", "-v", "-o-", "main.d", "-I."]

It seems like (despite classic confinement) apps ran by rdmd 
cannot print things on the screen...


Yes, this is a known issue :-(  It's related to how AppArmor is 
used by snapd, rather than anything in the package.  See 
discussion here:

https://forum.snapcraft.io/t/failed-to-flush-stdout-permission-denied/485

You can use a workaround, which is to explicitly point `rdmd` to 
the actual compiler binary rather than relying on $PATH:


 rdmd --compiler=/snap/dmd/current/bin/dmd

or, instead of `rdmd --compiler=ldmd2`, try:

 rdmd --compiler=/snap/ldc2/current/bin/ldmd2

etc.

Re: Release D 2.074.1

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Monday, 5 June 2017 at 18:25:19 UTC, Martin Nowak wrote:
IMO the problem here is the usage of a VERSION file in the 
first place, which exists only b/c it's somewhat tricky to 
invoke git on Windows.


Yup, my instinct is that if a VERSION file needs to exist at all 
it should be created during the build process out of `git 
describe` output.


Apart from Windows, are there any other cases where it's still 
more convenient to have it up front?  And what makes invoking git 
tricky on the Windows side?


If your building a version, you know which one it is and 
can/should provide that version.


Who's "you" in this scenario? :-)

I think it's reasonable that e.g. an official source tarball 
should contain sufficient information that building it, without 
modification or the need for user input, will result in a 
compiler that reports correct version information.  (Official 
here means the stuff available on the Downloads page, not the 
autogenerated tarballs that GitHub offers which are just a copy 
of a checkout of the git tree.)


OTOH if one is building from within a git checkout, then git 
should be queried to provide the version info (with an option to 
disable/override this if the user wants to).


I'd have thought those two options would cover almost all 
requirements out there, no ... ?

Re: Release D 2.074.1

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Friday, 2 June 2017 at 09:52:45 UTC, Joseph Rushton Wakeling 
wrote:
Great news, thanks Martin.  I'll update the snap packages over 
the weekend. :-)


Done.

sudo snap refresh --classic --edge dmd

should upgrade things for anyone who already has the package 
install; otherwise,


sudo snap install --classic --edge dmd

will install the dmd snap package for you.

Re: Release D 2.074.1

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Saturday, 3 June 2017 at 21:17:18 UTC, Seb wrote:
I understand the problem, but there's only so much Martin can 
do in his free time.


I'm not asking anyone to do the work.  I'm asking for a clear 
recognition that this is a problem that should be fixed.  I'm 
also asking for a clear recognition that the impact of this 
problem is greater now that there is likely to be a greater 
volume of downstream packaging of dmd.



Yep, but it's just a one-liner, right?
https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/dmd#n32


Not the point.  Workaround != fix.

Well, as said before _until_ there's no one volunteering to do 
this, it won't happen.
FWIW in the past sometimes even bumping the major version has 
been forgotten:

https://github.com/dlang/dmd/commits/master/VERSION


I'm aware of that.  All the more reason to address the 
fundamental problem.


I pointed you to the release scripts, because these are the 
spots where an addition to automatically update the VERSION 
file could be inserted ;-)


Thanks for the heads-up, then.  But I'm not sure that the best 
way to deal with this problem is to automate the process of 
patching the VERSION file.  It would be better to find a way to 
avoid the need for the VERSION file altogether.


Obvious example: if you want to promote a release candidate to 
the final release, it's much nicer to be able to tag the same 
commit, than to need to add an extra patch just to update VERSION.

Re: Release D 2.074.1

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Saturday, 3 June 2017 at 19:31:51 UTC, Seb wrote:

Tags are only made from the stable branch.


The point is that the VERSION file is wrong in the officially 
tagged release source.


Well, as mentioned minor point releases have never been changed 
in the git repo before:


https://github.com/dlang/dmd/commits/stable/VERSION


Yes, and this is wrong.  It means that one cannot reliably build 
from unmodified source and wind up with a DMD that accurately 
describes its own version.


It's a mistake that remains tolerated, despite the problem being 
known and having an associated issue, because the dlang/installer 
scripts work around it, meaning the fundamental problem never 
gets fixed.



So I'm not sure how necessary it is.


The problem here is that anyone downstream wanting to build or 
package from source has to work around this issue, that without 
manual intervention, the version information of the compiler will 
be incorrect.


If that's not fixed in how dmd itself is managed (NOT the 
dlang/installer scripts), this will continue to be an unnecessary 
burden on downstream packagers.



Anyhow, the interesting bits are here:


I very much appreciate your pointing me to material that can help 
me create a workaround.  But I'd feel a lot better about 
implementing such a workaround if I felt sure that there was a 
clear understanding of why it matters to fix this properly in dmd 
itself.


Note, I don't say anything about what such a fix should be, so 
please don't assume that I'm asking for any particular thing to 
be done.  (There are a variety of ideas in the open issue.)  What 
I'm asking is that it should be possible to build from unmodified 
source and have correct version info in the compiler.

Re: Release D 2.074.1

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Saturday, 3 June 2017 at 19:02:36 UTC, Joseph Rushton Wakeling 
wrote:

The point is here that this keeps happening.


The relevant issue (filed over a year ago): 
https://issues.dlang.org/show_bug.cgi?id=15910

Re: Release D 2.074.1

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Saturday, 3 June 2017 at 18:42:57 UTC, Seb wrote:
So, I guess your problem is the VERSION file on the dmd stable 
branch?


No, it's the VERSION file present if one checks out the v2.074.1 
tag.


I suspect this doesn't show up in the official packages because 
IIRC the VERSION file is edited as part of the standard 
official-package build process.


Can't you simply overwrite the VERSION file in your build 
process?

Otherwise it's just one simple PR away ;-)


The point is here that this keeps happening.  Assuming a VERSION 
file is considered necessary at all (I believe the intent is to 
support people using a tarball of the source rather than a git 
checkout), it shouldn't be possible for a release to be made 
without it containing the correct version number.


Workarounds like this just perpetuate the problem and throw a 
burden on downstream packagers.  Now that dmd is open-sourced and 
widespread packaging is feasible, it really would be preferable 
to fix the problem where it arises.

Re: Release D 2.074.1

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Thursday, 1 June 2017 at 21:04:00 UTC, Martin Nowak wrote:
This point release fixes a few issues over 2.074.0, see the 
changelog for more details.


I'm afraid that the release has another fault: the VERSION file 
still gives 2.074.0.  This means that unless it is edited during 
the build process, the compiler will report the wrong version 
number when `dmd --version` is invoked.

Re: Release D 2.074.1

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Thursday, 1 June 2017 at 21:04:00 UTC, Martin Nowak wrote:

Glad to announce D 2.074.1.

http://dlang.org/download.html

This point release fixes a few issues over 2.074.0, see the 
changelog for more details.


http://dlang.org/changelog/2.074.1.html


Great news, thanks Martin.  I'll update the snap packages over 
the weekend. :-)

Re: Snap packages for DMD and DUB

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Tuesday, 16 May 2017 at 19:56:56 UTC, Joseph Rushton Wakeling 
wrote:
With your patch in the repo, the packages should be 
automatically rebuilt and uploaded some time in the next hours.
 I'll follow up with an announcement here once that has 
happened.


Patches with Petar's PIC fix in them have now been uploaded to 
the store.  I've tested on Ubuntu 16.10 and 17.04 and they seem 
to work well.

Re: Snap packages for DMD and DUB

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Monday, 15 May 2017 at 21:07:05 UTC, Petar Kirov [ZombineDev] 
wrote:
This should fix it: 
https://github.com/dlang-snaps/dmd.snap/pull/7


Thanks ever so much for that.  It's really nice to have the first 
not-by-me patch in that repo, especially when it comes with such 
a nicely-written commit message :-)


It seems that you added PIC on the tools repo, instead of 
druntime.
I missed that too when debugging the snapcraft build myself. 
Looking
at the diff without expanding it on github 
(https://github.com/dlang-snaps/dmd.snap/commit/b82fb60cb33e6ed42534e36f8703f75702f2c9fb) can

be quite confusing. I came back to that file only after reading
the druntime, phobos and tools makefiles several times and
scratching my head for about an hour :D


D'oh!  Thanks again for taking that time.  I think I'm going to 
hold some of the shorter-term effects of DConf responsible for 
the misplaced PICs ... :-P


With your patch in the repo, the packages should be automatically 
rebuilt and uploaded some time in the next hours.  I'll follow up 
with an announcement here once that has happened.

Re: Snap packages for DMD and DUB

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Thursday, 11 May 2017 at 22:30:52 UTC, Joseph Rushton Wakeling 
wrote:
OK, looks like `-fPIC` was missing from some of the druntime 
and phobos build commands.  I've pushed a patch to the `dmd` 
package definition that should fix this.


Hmm, no dice.  I'll look into this further in the next days.

Re: Snap packages for DMD and DUB

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Thursday, 11 May 2017 at 14:46:10 UTC, Joseph Rushton Wakeling 
wrote:

On Thursday, 11 May 2017 at 11:47:10 UTC, Piotr Mitana wrote:
Hello, I have tried those snaps recently on Ubuntu 16.10. 
There were -fPIC related errors (if you need the output, I can 
install the snap again and post it tomarrow).


OK, looks like `-fPIC` was missing from some of the druntime and 
phobos build commands.  I've pushed a patch to the `dmd` package 
definition that should fix this.


Can I confirm whether you had these problems with `dmd` only or 
also with the `dub` package?

Re: Snap packages for DMD and DUB

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Thursday, 11 May 2017 at 11:47:10 UTC, Piotr Mitana wrote:
Hello, I have tried those snaps recently on Ubuntu 16.10. There 
were -fPIC related errors (if you need the output, I can 
install the snap again and post it tomarrow).


Ouch!  Thanks for reporting this: it sounds like something 
similar to what Attila was reporting for his attempts at building 
on Arch.


I'll look into it and see if I can fix packaging side (it's 
probably possible by tweaking CFLAGS), before submitting fixes 
upstream if it's something that can reasonably be addressed there.

Re: Snap packages for DMD and DUB

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Monday, 8 May 2017 at 20:23:36 UTC, bachmeier wrote:
Thanks for making these available. I needed to install ldc 
today, so I used the snap package. Installation was trivial 
(Ubuntu 16.04).


That's great to hear.  Note that it's also trivial to swap 
between the current stable release and the latest beta, if you 
want to try things out:


sudo snap refresh --channel=1.3/beta   [to switch to the 
1.3.0-beta1 release]
sudo snap refresh --channel=stable [to switch back to the 
latest stable release]

Re: LDC 1.3.0-beta1 has been released!

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Friday, 5 May 2017 at 10:16:41 UTC, Kai Nacke wrote:
As usual, you can find links to the changelog and the binary 
packages over at digitalmars.D.ldc:

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


In addition, the snap package can be installed on Linux distros 
that support it  using:


sudo snap install --classic --channel=1.3/beta ldc2

or, if you already have a version installed:

sudo snap refresh --channel=1.3/beta ldc2

:-)

Snap packages for LDC 1.2.0

[Joseph Rushton Wakeling via Digitalmars-d-announce]

Hello all :-)

Stable snap packages for LDC 1.2.0 have been available since 
before the official 1.2.0 release announcement 1 week ago.  
However, since there's more than just the availability of the 
packages to announce, I thought I'd write up some notes for the 
forums.


The full writeup (including installation instructions) is 
available here:

https://forum.dlang.org/post/tqxfcvdzcqendwyyd...@forum.dlang.org

but in short, the latest news can be summarized as:

  * the packaged LDC version has been updated to 1.2.0, comprising
DMD/druntime/phobos 2.072.2 and LLVM 4.0

  * packages are now available for both i386 and amd64 
architectures,

with ongoing work to extend the list

  * specific release tracks are now available, allowing users to
install and update from either the latest LDC releases or from
specific minor release series

  * these packages are expected to work with (at least) Ubuntu 
14.04,
16.04, 16.10, 17.04 and development releases; Debian Testing 
and

Unstable; and OpenSUSE Leap.

Please report any issues encountered with the packages here:
https://github.com/ldc-developers/ldc2.snap.

Enjoy, and please do let me know how you get on with using these 
packages!


Thanks & best wishes,

-- Joe

Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Tuesday, 11 April 2017 at 14:36:18 UTC, Ali Çehreli wrote:

On 04/11/2017 02:35 AM, Joseph Rushton Wakeling wrote:

will we see you at DConf? :-)


Yes. I'm looking forward to it. :)


Great!  And, likewise :-)

Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Tuesday, 11 April 2017 at 06:08:16 UTC, Ali Çehreli wrote:
Do you agree or disagree that D brings competitive advantage? 
Please let me know.


Agree.  There are different tradeoffs, obviously, and it won't 
suit all use-cases, but the ability to iterate fast through 
highly performant and provably correct code is very striking.


If you manage your compile-time generics well -- i.e. using them 
to generalize for use cases that you definitely have, rather than 
premature generalization -- you can get a lot of power out of 
this that really helps with _effective_ code re-use.


Compile time checks, contracts, and easy built-in unittests all 
make a big help in being able to make changes to code while 
maintaining confidence in its correctness -- again, making it 
faster to get things done.


And the simple clarity of the syntax really helps compared to, 
say, C++.  It's much easier to write and much easier to read and 
understand.  So, once again, it's easier to move fast.




Are you attending the conference?


Not C++Now, I'm afraid.  But will we see you at DConf? :-)

Re: Release Candidate 2.074.0-rc1

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Monday, 10 April 2017 at 20:16:29 UTC, Martin Nowak wrote:

Unfortunately too late.
As usual, just make sure that changes end up in stable before 
the
release. We do check all PRs that target stable or are in a 
milestone.


You didn't get my messages on slack about the backend license, 
then :-(


I'd assumed that was the fastest way to reach you -- I should 
have filed an issue sooner.

Re: Release Candidate 2.074.0-rc1

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Saturday, 8 April 2017 at 13:16:44 UTC, Martin Nowak wrote:

First release candidate for 2.074.0.

http://dlang.org/download.html#dmd_beta 
http://dlang.org/changelog/2.074.0.html


Please report any bugs at https://issues.dlang.org


Reported at https://issues.dlang.org/show_bug.cgi?id=17317 but 
I'm also highlighting it here since I think it's important:


The backend license change has not yet been applied to the 
2.074.0 branch.  It would seem like a very, very good idea to 
make sure this happens.

Re: dmd Backend converted to Boost License

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Friday, 7 April 2017 at 22:02:31 UTC, Walter Bright wrote:

I'll defer to Martin Nowak on what to do about that.

It would help for those who need this for specific versions to 
let Martin know which ones.


Great, thanks -- I'll follow up with Martin on slack.

Re: dmd Backend converted to Boost License

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Friday, 7 April 2017 at 15:35:00 UTC, Walter Bright wrote:

It applies to all of it!


Cool :-)

My question should have been more specific: will we see the patch 
changing the license in the source code applied to existing 
stable release branches?


I'd really appreciate it if we could get such a patch applied at 
least to the current stable release.  Obviously the code's real 
license is now officially Boost by your decision, but it's nice 
to have the source clearly match up to this.

Re: dmd Backend converted to Boost License

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Friday, 7 April 2017 at 15:14:40 UTC, Walter Bright wrote:

https://github.com/dlang/dmd/pull/6680

Yes, this is for real! Symantec has given their permission to 
relicense it. Thank you, Symantec!


Question: will this 'fix' be backported to existing stable 
releases?  Or will it just apply going forward?


I ask because it could make a difference to what is legally 
possible to package for e.g. Linux distros, etc.

Re: dmd Backend converted to Boost License

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Friday, 7 April 2017 at 15:14:40 UTC, Walter Bright wrote:

https://github.com/dlang/dmd/pull/6680

Yes, this is for real! Symantec has given their permission to 
relicense it. Thank you, Symantec!


Congratulations Walter!  This is marvellous news :-)

Re: Updates to LDC snap package

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Wednesday, 5 April 2017 at 20:27:02 UTC, Joseph Rushton 
Wakeling wrote:
The package provides LDC 1.1.1 (based on the DMD 2.071.2 
frontend) and uses LLVM 3.9.1 as the backend.  It is expected 
to work on any distribution with a sufficiently up-to-date 
snapd package.  In practice this means at least:


  * Ubuntu 14.04, 16.04, 16.10 and 17.04

  * Debian Testing and Unstable

  * OpenSUSE Leap 42.2


More detailed installation instructions for different distros are 
available here:

https://snapcraft.io/docs/core/install

Updates to LDC snap package

[Joseph Rushton Wakeling via Digitalmars-d-announce]

Hello all,

In the absence of any reports of problems with the current LDC 
snap package, I've released it to the stable release channel.  
This means that it should now be possible to install it with the 
command:


sudo snap install --classic ldc2

where the --classic flag is necessary in order to grant the 
access permissions the snap package needs to do its work.


Existing users wishing to ensure they will use this stable 
package release should refresh their installation:


sudo snap refresh --classic --stable ldc2

The package provides LDC 1.1.1 (based on the DMD 2.071.2 
frontend) and uses LLVM 3.9.1 as the backend.  It is expected to 
work on any distribution with a sufficiently up-to-date snapd 
package.  In practice this means at least:


  * Ubuntu 14.04, 16.04, 16.10 and 17.04

  * Debian Testing and Unstable

  * OpenSUSE Leap 42.2


-- Known issues ---

The package is not expected to work on Arch Linux for the time 
being due to some issues with the snapd package currently 
available.


Link-time optimization (i.e. the -flto flag) is expected to work 
only on Ubuntu 16.04, 16.10 and 17.04.  Since this is in any case 
an experimental feature, this partial support has been tolerated 
for the current release.



-- Upcoming development releases ---

With a stable package now available, the `edge` and `beta` 
release channels will soon be used to make releases related to 
the upcoming 1.2.0 release.  Some planned updates include:


  * supporting architectures other than amd64

  * upgrading LLVM to 4.0

The `edge` channel will publish every individual update to the 
development branch of the package.  Development packages will be 
upgraded to the `beta` channel once they have been shown to work 
on multiple distributions.  Once LDC 1.2.0 is officially 
released, the package will move towards the `candidate` and 
`stable` channels once more.


You can check which release channel your current install is 
tracking using the command


snap info ldc2

... and looking at the `tracking:` field.  You can switch which 
channel you are tracking by using the `snap refresh` command (see 
the beginning of this post) and choosing the channel using the 
corresponding flag: --stable, --candidate, --beta or --edge (in 
increasing order of instability:-)


For more information on snap package release channels, see: 
https://snapcraft.io/docs/reference/channels


Hope this package proves useful to people!

Best wishes,

-- Joe

Re: Updated LDC snap package with improved Ubuntu 14.04 support

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Sunday, 19 February 2017 at 16:18:48 UTC, visitor wrote:

Works for me on ubuntu 16.04 (llvm-3.8), Thanks :-)
Not heavily tested, just to let you know for some feedback on 
your work, again Thanks


Great to know that it works for you, thanks for trying it out :-)

Note the snap package doesn't use the distro-packaged LLVM; it's 
based on a fresh build of LLVM 3.9.1.  You can verify this by 
using


which ldc2  # just to verify you are using the snap 
packaged version
ldc2 --version  # should tell you all about the LDC, LLVM and 
D frontend versions


The latter should read:

  LDC - the LLVM D compiler (1.1.0):
based on DMD v2.071.2 and LLVM 3.9.1
built with LDC - the LLVM D compiler (0.17.3)

Out of curiosity, have you tried using the link-time optimization 
feature?  (-flto=full)

Updated LDC snap package with improved Ubuntu 14.04 support

[Joseph Rushton Wakeling via Digitalmars-d-announce]

Revision 4 of the ldc2 snap package is now available in the 
'edge' channel of the snap store.  This still provides LDC 1.1.0 
with an LLVM 3.9.1 backend, but has been rebuilt in a clean build 
using the latest `snapcraft` release, which has improved support 
for classic snaps across different distributions.


This package should therefore now work on Ubuntu 14.04 LTS as 
well as on 16.04 or later.


Link-time optimization (the `-flto={full,thin}` flag) is however 
still limited to Ubuntu 16.04 or later: on 14.04 it will fail 
with a linker error.


As always, I'd be very happy if people could try this out and let 
me know how it works for you.



-- to install --

This package should be possible to install on Ubuntu 16.04 or 
later, or Ubuntu 14.04, as well as any other distro making 
available a recent version of snapd (2.21 or later):

https://snapcraft.io/docs/core/install

Once snapd is installed (on Ubuntu or Debian, `sudo apt install 
snapd`), the ldc2 snap can be installed with:


sudo snap install --classic --edge ldc2

If you already have a version installed, you can upgrade it with:

sudo snap refresh --classic --edge ldc2

Note, if this version breaks something for you, you can downgrade 
to revision 3 with:


sudo snap refresh --classic --edge --revision=3 ldc2

Re: two points

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Thursday, 9 February 2017 at 23:44:31 UTC, Walter Bright wrote:
I appreciate how frustrating it must be to have people saying, 
'Hey, do this! Do that!' without necessarily volunteering their

own efforts in support, but organizational improvements so very
often fail unless they are eagerly pursued at a leadership
level.


Before I respond, just wanted to say: I hope the above didn't 
come over as a personal attack, it wasn't meant as one.  I was 
speaking in general about my experience of what can best 
influence change.



There are 29 people with commit privileges on Phobos:

  https://github.com/orgs/dlang/teams/team-phobos

What do you suggest? What are you willing to step up and do?


I'm painfully aware that I have limited ability to commit time 
and energy right now.  I think that's one reason have been 
pushing this discussion: because my time is limited, when I _do_ 
find time to craft some code and send it to Phobos or elsewhere, 
it's quite precious to me, and I try to take a lot of care over 
it.  It's not very nice to feel that this time is wasted because 
no one is paying attention to the results, and it's not very nice 
to feel that this is a situation that is just accepted.


So, that said, what would I suggest?  Well, 29 people with commit 
privileges is less than 4 currently-open PRs per person.  Let's 
be conservative and suppose 10 of them are regularly active.


What I would suggest is it takes one or two people with authority 
(important caveat, more on this in a moment) to periodically 
nudge those 10+ people about any PRs that (i) do not have an 
assigned reviewer with commit rights or (ii) do have an assigned 
reviewer but haven't had any activity in more than, say, 2 weeks. 
 This doesn't need to be orders (impossible in a volunteer 
project) -- just encouraging requests for help and 
awareness-raising to make sure that no PR falls behind.


Then in turn, the 10+ people with commit rights need to be 
actively encouraging appropriate people to review the PRs they 
are responsible for, with the sense that it strongly matters that 
no PR author feels they're being abandoned (a feeling which needs 
to be encouraged by the top people: if the people with commit 
rights aren't nudging the reviewers on a particular PR, they need 
to be nudged themselves).


The authority bit matters because the one or two people at the 
top need to be able to field the questions that the 10+ with 
commit rights can't decide for themselves -- in a way that helps 
them understand the principles behind those decisions so that 
they can apply them themselves, confident that they're not going 
to be knocked back if the apply the same principles in future.


Basically, the role of the senior authority figure here is to 
support the people with commit rights in learning how to make 
decisions which won't need to be countermanded.  No one person 
scales, but 10 people who understand 95% of that one person's 
thought _can_ -- and they can pass on that understanding to 
others.


Of course, I understand that I might be suggesting things that 
have been tried and have not worked out.  But you asked for my 
suggestions, so ... that's what seems important to me.

Re: GSoC 2017 Application Rejected

[Joseph Rushton Wakeling via Digitalmars-d-announce]

Hi Craig,

So sorry to hear that this happened.  I know very well from 
working with you last year how much care and attention you put 
into GSoC, so I can imagine how you must feel right now.


In the circumstances it seems best to focus on: how could we try 
to stop something like this happening again?  One thing that 
occurs to me is that it might be a good idea for the email 
address through which the application is submitted to forward to 
a couple of other people, who could step in should there be an 
emergency like this (with the principle being, whoever gets such 
an emergency alert deals with it ASAP, unless they hear that it's 
dealt with from the other people involved).


What do you think?

Best wishes,

-- Joe

Re: Updated LDC snap package with link-time optimization (LTO) support

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Friday, 10 February 2017 at 16:37:13 UTC, Daniel Kozak wrote:

http://www.phoronix.com/scan.php?page=news_item=Snaps-v-Flatpaks-Linux-Distros


Please don't ask me to read that dreadful, dreadful website :-\

I have read the blogpost that article summarizes.  My own 
feelings are:


  * short term up-to-dateness of snapd is probably something that 
will

sort itself out in good time

  * the 'centralization' of the Ubuntu snap store (which serves 
all
snap users on all distros) isn't really true, but inasmuch as 
it

is a thing, it's an asset: one place of delivery for all snap
users, a bunch of automated security checking guaranteed on 
every
upload, no burden to host one's own repository or for the 
user to

need to know about multiple repos ... compare with the flatpak
website where every highlighted download is coming from a 
different

site

Basically: snaps provide an easy way to define a package that can 
reach a lot of developers, now, with minimal infrastructural 
effort required.  That seems a worthwhile investment to me.

Re: Updated LDC snap package with link-time optimization (LTO) support

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Friday, 10 February 2017 at 16:30:57 UTC, David Nadlinger 
wrote:
Hmm, for whatever reason, Arch still ships 2.16 by default… 
Seems to work fine on Ubuntu 16.10, though.


Yes, I'll ping the maintainer about it some time soon.  It's 
possible they were holding off until after the Ubuntu 14.04 
rollout of snapd was complete: there are some changes needed for 
that which might also prove useful for other distros.


Glad to hear it works on 16.10, though.  Including the LTO ... ?

Re: Updated LDC snap package with link-time optimization (LTO) support

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Thursday, 9 February 2017 at 17:16:35 UTC, Joseph Rushton 
Wakeling wrote:
This package should be possible to install on Ubuntu 16.04 or 
later, or Ubuntu 14.04, as well as any other distro making 
available a recent version of snapd (2.21 or later):

https://snapcraft.io/docs/core/install


Looks like there is a linking problem on Ubuntu 14.04 presumably 
related to ABI incompatibility between the precompiled libphobos 
and libdruntime and the system toolchain.  I'll investigate 
further and follow up on this with an appropriate fix.

Re: two points

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Thursday, 9 February 2017 at 20:43:00 UTC, Walter Bright wrote:

*Anyone* in this community can step up and do that.


Anyone can make observations and proposals, but not everyone has 
the authority to effect change.


I appreciate how frustrating it must be to have people saying, 
'Hey, do this!  Do that!' without necessarily volunteering their 
own efforts in support, but organizational improvements so very 
often fail unless they are eagerly pursued at a leadership level.

Re: two points

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Thursday, 9 February 2017 at 19:53:37 UTC, Walter Bright wrote:
There's a lot going on needing attention, and sometimes a bit 
of championing is needed by their proponents.


Yes, but it could be good to examine what can be done to more 
pro-actively look at open PRs that have had no recent follow-up.  
It's not really going to work that well if attention gets given 
substantially on the basis of who's most eagerly seeking it.


People like that metaphor "It's the squeaky wheel that gets the 
grease", but as a first aid trainer once pointed out to me, the 
quieter patient may be the one more in need of immediate 
attention.


Also, please keep in mind that the smaller and more focussed a 
PR is, the more likely it'll have a quick resolution.


Unfortunately my current one is large with good reason.  But I 
think you'll find I also provided very detailed commit messages 
to explain and justify all my changes ;-)

Re: two points

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Thursday, 9 February 2017 at 19:58:57 UTC, Seb wrote:
We gave this a try a couple of months ago with Facebook's 
mention-bot:


Example: 
https://github.com/dlang/phobos/pull/4318#issuecomment-241817191

Repo: https://github.com/dlang-bots/mention-bot

Eventually I disabled it because people complained about the 
added noise.


It's great that you gave this a go.  Seriously, people considered 
one small informative post in the PR to be "added noise"? :-(


Out of curiosity: is it typical that it would not post until some 
way into the discussion (as in that example)?  I could see why it 
would be irritating if it popped up once discussion and review 
had already started happening.


Assuming that the bot can be relied on to be 'first responder' to 
any PR, I'm happy to try to draft an alternative text for it to 
post (and maybe also look at what texts it can link to).

Updated LDC snap package with link-time optimization (LTO) support

[Joseph Rushton Wakeling via Digitalmars-d-announce]

Revision 3 of the ldc2 snap package is now available in the 
'edge' channel of the snap store.  This still provides LDC 1.1.0, 
but with the following important changes:


  * the backend is provided by LLVM 3.9.1

  * support for LDC's experimental link-time optimization
(the -flto={full,thin} flag) has been included

I would be very grateful if people could try out these new 
features and report back on whether or not they work (and if any 
problems are encountered, on which distro and version).



-- to install --

This package should be possible to install on Ubuntu 16.04 or 
later, or Ubuntu 14.04, as well as any other distro making 
available a recent version of snapd (2.21 or later):

https://snapcraft.io/docs/core/install

Once snapd is installed (on Ubuntu or Debian, `sudo apt install 
snapd`), the ldc2 snap can be installed with:


sudo snap install --classic --edge ldc2

If you already have a version installed, you can upgrade it with:

sudo snap refresh --classic --edge ldc2

Note, if this version breaks something for you, you can downgrade 
to revision 2 with:


sudo snap refresh --classic --edge --revision=2 ldc2

Re: two points

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Thursday, 9 February 2017 at 09:49:53 UTC, Walter Bright wrote:
In any case, shouldn't it be an uphill battle to merge things? 
There are a lot of things that need to be satisfied to merge 
something. Being too hasty leads to legacy code that we come to 
regret, angry people whose code was broken, and technical debt.


There's a difference between it being an uphill battle because 
review and feedback are careful, cautious, in-depth and strict 
(as they should be!), versus it being an uphill battle because no 
feedback or interest is being offered and PRs are left to bitrot. 
:-(


I accept that there are a lot of things that need to be satisfied 
to merge something.  Personally speaking, I'm willing to endure 
any number of rebases and conflict-fixes, so long as I'm getting 
feedback and engagement that allows my PR to become better code.  
It's when I'm _not_ getting any indicators as to what needs to be 
satisfied that things become problematic.

Re: two points

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Thursday, 9 February 2017 at 08:02:23 UTC, Walter Bright wrote:

The PR in question:

  https://github.com/dlang/dmd/pull/4745

It took me a while to find it, because you were using a 
pseudonym that I did not recognize. There are a number of 
frequent contributors to D using pseudonyms, and all have this 
issue with varying degrees.


This is a fair point in its own right, but it's completely 
orthogonal to the issue Nick is complaining about -- which is 
that after some initial interest and feedback, the PR just got 
left alone with no decision to accept or reject it, and no 
indication of why.


That's really a very unpleasant situation to face, regardless of 
whether the contributor in question is a well-known name or some 
complete anonymous stranger.  I have a PR of my own that's been 
in this situation for (only!) a month now, and it's distinctly 
frustrating, particularly because it was a contribution that 
Andrei specifically called for on these forums:

https://github.com/dlang/phobos/pull/5011

(... Andrei's request: 
https://forum.dlang.org/post/o1cqdb$245o$1...@digitalmars.com)


Contrast this with the experience I had the one time I submitted 
a (tiny, trivial) patch to rust: immediately after submitting the 
PR I got a message from their 'highfive' robot that included:


  * a friendly thank you for the PR;

  * the GitHub ID of a contact who I could expect to be taking 
responsibility

for the PR, who was also assigned as a reviewer;

  * some helpful notes on how to add changes to the PR if 
requested;


  * a link to the contributor guidelines.

By contrast with a Phobos PR it's not clear who to contact if 
review or decision-making is not forthcoming.


There's clearly in part a scaling problem here (in terms of how 
many people are available in general, and in terms of how many 
people have expertise on particular parts of the library) but it 
also feels like a few simple things (like making sure every PR 
author is given a reliable contact or two who they can feel 
entitled to chase up) could make a big difference.

Re: Call for arms: Arch Linux D package maintenance

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Thursday, 2 February 2017 at 10:08:19 UTC, Daniel Kozak wrote:

I belive arch would prefer flatpak ;)


Didn't notice this before, but: the good thing about both snap 
and flatpak is one doesn't have to choose between them; these 
packages can coexist on the same system.


So as long as Arch is prepared to have an up to date snapd in its 
repos, snap packages should Just Work for those who want to use 
them.

Re: Call for arms: Arch Linux D package maintenance

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Thursday, 2 February 2017 at 11:34:42 UTC, Dicebot wrote:

On Thursday, 2 February 2017 at 10:01:04 UTC, qznc wrote:
In another thread [0] Snap packages are discussed. What is the 
view of Arch? If Snap wins, there would be only one package to 
maintain for all distros.


[0] 
https://forum.dlang.org/post/mzklrdgeyymuwmtqz...@forum.dlang.org


There is snapd daemon available in Arch repositories but with 
zero support and guarantees for any actual snap packages. I am 
not aware of any discussions about in TU mail list either.


The main problem right now is that the snapd version is a few 
releases behind and does not support the 'classic' snap 
confinement needed for tools like compilers, dub, etc.  I'll 
probably ping the snapd uploader about this if the situation 
doesn't change soon.  With that dealt with, we can confirm if the 
current ldc2 snap package really does its intended job ;-)


It's my intention to ensure that there are snap packages 
available for all the core D compilers and tools (i.e. dmd, ldc2, 
gdc, rdmd and dub; I'm happy to add to that list if need be).  
This ought to ensure in the long run that there are packages 
available to Arch users (and other distros) even if no one steps 
up to maintain the distro packages.


However, I think it would be a good idea for someone to step up 
to maintain the dedicated Arch packages in any case -- it's 
healthy for D to have a representative inside the Arch community.

Re: Snap package for LDC 1.1.0 available to test

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Monday, 6 February 2017 at 12:50:15 UTC, qznc wrote:

Worked in my quick try. :)


Great, thanks for trying it out :-)


Why does it not show up with `snap find`? Because it is "edge"?


Yes, I think so.  Off the top of my head I can't remember what 
the command is to find snaps in non-stable channels, but `snap 
find --help` ought to give you the info you need.

Re: Snap package for LDC 1.1.0 available to test

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Saturday, 4 February 2017 at 14:56:21 UTC, aberba wrote:

There is now support for 14.04 too.


Right now that may not work for people unless they enable the 
`proposed` repository.  There's a bug that currently prevents 
installation of `snapd` via the stable repos, but a fix for that 
has been prepared and I would guess it will probably be released 
next week.  I will post here when that's the case.


Although snaps are marketed by Canonical, I see flatpack to be 
more technically safe a superior. And that's what most free 
software devs commit.


My impression is quite the opposite -- that snap packages right 
now offer more features (security included) and make fewer 
assumptions about the host system.  But, obviously, your call 
what you wish to work with.


However, since the snap package is available now ... if you are 
able to, could you possibly do me the favour of trying it out and 
confirming whether or not it works for you?


Thanks & best wishes,

-- Joe

Snap package for LDC 1.1.0 available to test

[Joseph Rushton Wakeling via Digitalmars-d-announce]

As of earlier today, a snap package for LDC 1.1.0 has been 
published in the 'edge' channel of the Ubuntu store.


Snap packages are a new format developed by Ubuntu to facilitate 
upstreams being able to provide the latest versions of their apps 
directly to users.  The format is also designed to provide 
effective confinement for apps, so that they can only access the 
parts of the host system that they need to.  While developed by 
Ubuntu, the format is gaining quite a bit of of cross-distro 
traction: see http://snapcraft.io/ for more information.


On Ubuntu 16.04 or later, or Debian Sid, it should be possible to 
install this package using the following commands:


sudo apt install snapd   # in order to be able to install 
snap packages at all


sudo snap install --classic --edge ldc2

The `--classic` flag is needed in order to accept the confinement 
choice of the ldc2 package, while the `--edge` flag is needed to 
search in the similarly-named package channel.  As the name 
suggests this is for 'bleeding edge' packages.


The package includes the ldc2 compiler plus its 'dmd-like' 
version ldmd2, as well as ldc-profdata and ldc-prune-cache.  
You'll find the commands in /snap/bin/ : note that the latter 
three will (for now) be called ldc2.ldmd2, ldc2.ldc-profdata and 
ldc2.ldc-prune-cache (these names will hopefully be simplified in 
a future release).


It should be possible to use ldc2 and ldc2.ldmd2 in the same way 
that you would use their equivalents installed by any other 
package manager.  Please let me know of any issues you encounter 
in trying to use this!


In principle it should also be possible to install this snap on 
other distros that have support for snap packages (e.g. Arch, 
Gentoo, Fedora, OpenSUSE); however, it will require an up-to-date 
version of snapd (2.21 or later) which some distros may not yet 
have made available.  For instructions on how to install snapd on 
other distros, see:

http://snapcraft.io/docs/core/install

For information on 'classic' confinement, see:
https://insights.ubuntu.com/2017/01/09/how-to-snap-introducing-classic-confinement/

Finally, for the snap package definition, see:
https://github.com/ldc-developers/ldc2.snap

I would be happy to explain any aspects of the snap packaging 
process or syntax that anyone is interested in.


Finally, thanks to the LDC developers who eagerly embraced this 
project to create and distribute an LDC snap package, and for all 
the helpful advice and support they have offered throughout the 
process.


Please do let me know what your experience is trying the package!

Thanks & best wishes,

-- Joe

Re: [GSoC] Mir.random.flex - Generic non-uniform random sampling

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Tuesday, 23 August 2016 at 05:40:24 UTC, Ilya Yaroshenko wrote:
This is an API problem, and will not be fixed. Making D 
scripting like language is bad for Science. For example, 
druntime (Fibers and Mutexes) is useless because it is too high 
level and poor featured in the same time.


Yes, this is not an issue that is immediately fixable without 
introducing other issues (e.g. defining everything as a class 
brings immediate issues related to heap allocation).


In the long run it would obviously be nice to address that issue, 
but it would have been a major blocker to throw that onto Seb's 
shoulders (as we all recognized quite quickly when we started 
discussing it).  It was (rightly) not the focus of this project.


For this reason, the random distributions introduced in mir are 
implemented as functors (as is the case with random distributions 
in C++11 ) rather than as ranges.


The main problem with std.random is that std.random.uniform is 
broken in context of non-uniform sampling. The same situation 
is for 99% uniform algorithms. They just ignore the fact that 
for example, for [0, 1) exponent and mantissa should be 
generated separately with appropriate probabilities for for 
exponent


Just as a point of terminology: we should make clear here that 
this is about sampling from a non-uniform distribution.  It 
shouldn't be confused with "sampling" in the sense of what is 
done by (say) `RandomSample`.

Re: DIP1000: Scoped Pointers

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Sunday, 14 August 2016 at 10:11:25 UTC, Guillaume Chatelet 
wrote:

Isn't it what a scoped class is supposed to provide?

class Rnd {}

void foo() {
  scope rnd  = new Rnd; // reference semantic and stack 
allocated

}


Does that actually work in D2? I thought it was a D1-only thing.

Re: DIP1000: Scoped Pointers

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Saturday, 13 August 2016 at 19:51:07 UTC, Walter Bright wrote:

On 8/13/2016 5:02 AM, Joseph Rushton Wakeling wrote:
On Saturday, 13 August 2016 at 11:09:05 UTC, Walter Bright 
wrote:
Taking the address of a ref variable has not been allowed in 
@safe code for a

long time.


Which is understandable given things as they are, but which 
could probably be

relaxed given good scope/lifetime analysis by the compiler...?


It's relaxed in @system code.


Sure, but doesn't the envisioned DIP create the circumstances in 
which it could also be permitted in @safe code where the compiler 
can guarantee that the pointer's lifetime will not outlive the 
data referred to?


The above code is unsafe only if the lifetime of `data` 
outlives the lifetime of
`input`.  Surely the new scope rules should be able to 
distinguish the cases?

If that's already envisioned, how would that work?


That depends on how the instance of MyWrapperStruct is 
allocated. How did you

intend to allocate it?


As a normal stack variable. Is that problematic?


Shouldn't be.


And if not, what would be problematic cases?


Allocating it on the heap.


OK.  I wonder if it might be a good idea for us to discuss my 
use-case directly some time.  It's quite subtle, and I'm far from 
sure that I've ironed out all the details or corner-cases in my 
head, but I think the details of the scope proposal could be very 
important in determining whether it's workable or not.


The TL;DR here is that I'm concerned about having a solution for 
random number generators and random algorithms that (i) allows 
them to be stack-allocated, (ii) ensures that their internal 
state is not accidentally copied by value, and (iii) allows them 
to work effectively with (input) range semantics.

Re: DIP1000: Scoped Pointers

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Saturday, 13 August 2016 at 11:09:05 UTC, Walter Bright wrote:
Taking the address of a ref variable has not been allowed in 
@safe code for a long time.


Which is understandable given things as they are, but which could 
probably be relaxed given good scope/lifetime analysis by the 
compiler...?


The above code is unsafe only if the lifetime of `data` 
outlives the lifetime of
`input`.  Surely the new scope rules should be able to 
distinguish the cases?

If that's already envisioned, how would that work?


That depends on how the instance of MyWrapperStruct is 
allocated. How did you intend to allocate it?


As a normal stack variable. Is that problematic? And if not, what 
would be problematic cases?

Re: DIP1000: Scoped Pointers

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Friday, 12 August 2016 at 19:37:47 UTC, Walter Bright wrote:

That's just what this DIP addresses.

struct MyWrapperStruct (T)
{
private T* data;

public this (ref T input)
{
this.data =  // error: not allowed to take 
address of ref variable

}
}

The DIP does not add ownership annotations or semantics.


Unless I've misunderstood you, that doesn't address my use-case 
-- it outright bans it!


The above code is unsafe only if the lifetime of `data` outlives 
the lifetime of `input`.  Surely the new scope rules should be 
able to distinguish the cases?  If that's already envisioned, how 
would that work?


BTW, the application here is a design that Dicebot and I have 
been discussing since DConf 2015 to address the concerns related 
to range implementations of random number generation and random 
algorithms.

Re: DIP1000: Scoped Pointers

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Friday, 12 August 2016 at 12:51:26 UTC, Joseph Rushton 
Wakeling wrote:
I'm not sure I follow.  I'm looking for the ability to 
guarantee that a pointer to a stack-allocated entity will not 
go out of scope


... more precisely, that the pointer will not become invalid 
because the data it points to goes out of scope.