On 20.12.2017 19:42, Johan Engelen wrote:
On Wednesday, 20 December 2017 at 13:57:20 UTC, Mike Parker wrote:
Many thanks to Rainer for his insightful new article for the D Blog
outlining the new name mangling algorithm.
Nice!
Thanks.
"D and C++ avoid this problem by adding more
On Wednesday, 20 December 2017 at 13:57:20 UTC, Mike Parker wrote:
The blog
https://dlang.org/blog/2017/12/20/ds-newfangled-name-mangling/
it won’t catch every error; for example, structs, classes and
other user defined types are mangled > by name only, so that a
change to their definition
Andrej Mitrovic wrote:
ah, 'cmon, we can hash the whole source file! let's move build system's
work to linker! ;-)
sorry, but this is really overkill. tracking changed files and rebuilding
'em on demand is something your build system should do.
On 2017-12-20 11:31, Benjamin Thaut wrote:
Would this work in all cases? Do tls variables work across Linux shared
libraries?
As far as I know it works on Linux and FreeBSD, but it doesn't work on
macOS. I don't know about windows.
Do we expect all dub libraries to have correct export
On 12/21/2017 5:59 AM, Jack Stouffer wrote:
I just finished getting the type into an alpha version, and I wanted to solicit
people's opinions on the API and if I'm heading in the right direction with this.
Thanks for doing this.
Your proposal would be enhanced a lot if it included a
On Tuesday, 19 December 2017 at 21:38:40 UTC, Mike Wey wrote:
And for GtkD, that is why it would make sense to relay on the
packages supplied by your distribution. And just list "gtkd-3"
in the "libs" section. Avoiding the need for the workaround to
build a shared version.
That would be
excel-d lets you write plain D code that can be run from Excel
unmodified via the magic of compile-time reflection.
Other than bug fixes, the main new feature since 0.2.15 is
@Async. Slap it on a function like so:
@Async
double myfunc(double d) {
// ...
return ret;
}
And it will be
About package
--
Mir-Random [1] is a random number generator library that covers
C++ STL [2]. It is compatible with mir.ndslice, std.algorithm,
and std.range. In the same time mir.random has its own API,
which is more secure and safe compared with std.random.
Release 0.3.0
http://code.dlang.org/packages/unit-threaded
Another release of unit-threaded, an advanced testing library for
D. Changes since the last post to announce:
* Bug fixes.
* @Flaky UDA to rerun flaky tests. But really, fix the test
instead!
* Property-based tests for user-defined types.
*
On Thursday, 21 December 2017 at 21:24:57 UTC, user1234 wrote:
"" to each url, e.g
click page 10:
http://code.dlang.org/?sort=updated==180=20
then gotta to change it by hand to:
http://code.dlang.org/?sort=updated==180=20
The query parameter is a hidden dev preview, meant to wait a
little
On Thursday, 21 December 2017 at 23:08:22 UTC, Andre Pany wrote:
That are fantastic news. Thanks for working on this topic.
Is it possible to define a decimal type with a defined scale
and precision?
From the examples and the documentation I am not sure whether
it is possible.
Yes, the Hook
On Thursday, 21 December 2017 at 13:59:28 UTC, Jack Stouffer
wrote:
A couple of months ago, Andrei noted that a donor asked for a
precise decimal type for D specifically:
https://forum.dlang.org/post/osnema$d5s$1...@digitalmars.com. I've
also heard this asked for many times, so I decided to
On Thursday, 21 December 2017 at 12:43:51 UTC, Jacob Carlborg
wrote:
On 2017-12-20 11:31, Benjamin Thaut wrote:
Would this work in all cases? Do tls variables work across
Linux shared libraries?
As far as I know it works on Linux and FreeBSD, but it doesn't
work on macOS. I don't know about
On Thursday, 21 December 2017 at 13:30:32 UTC, David Nadlinger
wrote:
There would probably have to be some sort of compatibility flag
to avoid breaking all libraries on systems where symbols are
visible externally by default (Linux, ...).
— David
Agree, although this currently really is a
A couple of months ago, Andrei noted that a donor asked for a
precise decimal type for D specifically:
https://forum.dlang.org/post/osnema$d5s$1...@digitalmars.com. I've
also heard this asked for many times, so I decided to start work
on a library for eventual proposal to Phobos.
I just
On Thursday, 21 December 2017 at 13:44:18 UTC, Benjamin Thaut
wrote:
Ideally we should end up with visibility hidden being the
default and only making symbols visible which use "export",
because that is what it was designed for in the first place.
If this is an option, that would be really
On Thursday, 21 December 2017 at 20:22:05 UTC, Martin Nowak wrote:
On Monday, 6 November 2017 at 16:12:14 UTC, Martin Tschierschke
wrote:
Even being the wrong Martin :-) I think the DUB registry
really needs more and better filters, so that the gems inside
can be found easily. (like: Number of
On Monday, 6 November 2017 at 16:12:14 UTC, Martin Tschierschke
wrote:
Even being the wrong Martin :-) I think the DUB registry really
needs more and better filters, so that the gems inside can be
found easily. (like: Number of Github stars, number of
downloads, number of developers and in the
18 matches
Mail list logo
