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
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
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
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
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
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.
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
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
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
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 :-)
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
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
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
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.
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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).
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.
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
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
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
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 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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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 :-)
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
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
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
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.
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
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
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 :-)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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]
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
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
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
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,
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.
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
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
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
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
1 - 100 of 176 matches
Mail list logo
