date:20180214

[Issue 18442] New: documented unittests don't have anchors (so we can't link to them, eg in changelogs)

2018-02-14 Thread d-bugmail--- via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=18442

  Issue ID: 18442
   Summary: documented unittests don't have anchors (so we can't
link to them, eg in changelogs)
   Product: D
   Version: D2
  Hardware: x86
OS: Mac OS X
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: timothee.co...@gmail.com

eg:
https://dlang.org/phobos/std_complex.html
i see anchors for each function but not for documented unittests.

eg use case: linking to these in changelogs (and avoiding re-doing redundant
work in changelogs, more DRY; also changelog inline unittests are not as good
as they aren't runnable)

related already merged PR (which for similar past issue):
https://github.com/dlang/dlang.org/pull/2043

--

Re: Dub, Cargo, Go, Gradle, Maven

2018-02-14 Thread Pjotr Prins via Digitalmars-d

On Thursday, 15 February 2018 at 04:11:51 UTC, Graham St Jack 
wrote:
Maybe a compromise position would be for a package management 
system to define an interface through which it can do things 
like:


* Discover what the external dependencies are,

* Provide those external dependencies, and

* Invoke a full build.

Then, any number of build systems (and deployment systems?) 
could be adapted to work with the package management system.


That is exactly what GNU Guix offers. With support for isolated 
builds, continuous integration testing, and containers thrown in, 
if you want that. People misunderstand Guix somewhat because it 
presents itself as a 'package manager' and even distribution in 
its own right. But actually it is a dependency manager that can 
run on top of any system.


I am writing a BLOG on how to use Guix for Python development 
using its package managers and even dependency injection (say a 
choice of BLAS libraries or LLVM in the case of D). When that is 
done I could do a D writeup if there is enough interest.


I am sure some people roll their eyes when I mention GNU Guix. 
But, hey, if you are an Emacs or gcc user you may be able to 
afford to pay attention to long running GNU projects.


To anticipate real criticism: there are currently two main 
issues: (1) GNU Guix runs on Linux and (2) the default requires a 
running build daemon.


About (1) since this is a libre project the focus is on Linux and 
Hurd. It is actually fairly straightforward to port Guix to other 
OS's. Nix, which shares the build daemon with Guix, runs on OSX 
and Windows.


About (2) the daemon can run unprivileged. I have written 
documents about running Guix without root access (I need it on 
HPC). It is just a little more involved.


Anyway, I don't really care who uses Guix or who uses something 
else. I expect 99.9% of people to ignore these ideas. Just to say 
I simply use it to make my own life easier. The point here is 
that I understand what it took to create Guix and it is 
non-trivial. We can reuse this functionality very easily and take 
control over the dependency graph. You get reproducible builds, 
easy mixing of LLVM versions and many other features. Fixing (1) 
above is much easier than recreating something like Guix from 
scratch. And since Guix is distribution agnostic you can use it 
on any old CentOS, Debian, Ubuntu... you name it. The only thing 
Guix uses is the *running* kernel API. Even glibc and the linked 
library loader come with Guix (and you can easily run multiple 
versions of said libraries). That is a full and deep dependency 
graph.


With Guix I do not need dub or pip or gems. It is trivially easy 
to manage dependencies. Still I can use those package managers if 
I want to. In a controlled fashion.


PS The JVM world has the advantage of being a clear and isolated 
system. Good news is that Guix supports that too and it provides 
an awesome libre bootstrap from source. If you care about the 
free and open in FOSS that is a huge selling point in a world 
that appears to increasingly bootstrap from binary blobs.


It is easy to write-off such ideas. But if you don't try it, you 
don't understand it. Similar to the D vs other language 
discussions. I am not going to say Guix is easy. Similar to the 
fact that D is not easy. But you can gradually get in and learn 
to appreciate the great engineering under the hood. That goes for 
Nix too. Guix and Nix still share the build daemon, though they 
have become completely different systems with different 
characteristics.


If you want to try Guix - I am here to support you.

[Issue 18441] New: Add comments to GC page about tradeoffs in design and impl of GC (garbage collector)

2018-02-14 Thread d-bugmail--- via Digitalmars-d-bugs

https://issues.dlang.org/show_bug.cgi?id=18441

Issue ID: 18441
Summary: Add comments to GC page about tradeoffs in design and
impl of GC (garbage collector)
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: enhancement
Priority: P1
Component: dlang.org
Assignee: nob...@puremagic.com
Reporter: jgabri...@fastmail.fm

I regularly hear complaints online about D's GC being slow or not decent, but
those complaints rarely include details.

I've twice seen Walter explain some tradeoffs that were made in the design and
implementation of the D GC. [One was on the forum]. [Another on reddit], where
he wrote:

"You can make a moving GC with D, it's called a "mostly copying" collector. The
trick is to not move things that may have a pointer to them."

and

"Certain GCs instrument the generated code with write gates which notify the GC
when memory writes are being made. GC-focused languages rely on this to make
the GC better, at the cost of lower performance in the native code.

D has a GC, but is not a GC focused language. The performance cost of write
gates is an unacceptable compromise in the context of D."

***

The [D GC page](https://dlang.org/spec/garbage.html) may need a section
describing these tradeoffs that were made in the design and implementation of
the GC so people can easily see why it is the way it is. That may help avoid
regurgitated complaints of "it's too slow" and provide a link to point those
folks to.

1 2 >

1 - 100 of 142 matches

Mail list logo