Re: Blog post: What D got wrong
On Saturday, 15 December 2018 at 19:53:06 UTC, Atila Neves wrote: Not the case in Rust, not the case in how I write D. TBH it's not such a big deal because something has to be typed, I just default to const now anyway instead of auto. @safe and pure though... I'd be interested in seeing some of that Rust code. My impression from Clojure is that an all-immutable style requires leaning heavily on the garbage collector and as far as I know Rust has none.
Re: Blog post: What D got wrong
On Thursday, 13 December 2018 at 10:14:45 UTC, Atila Neves wrote: My impression is that it's a consensus that it _should_, but it's not going to happen due to breaking existing code. I think it would be a bad idea for `immutable` because more often than not it would need to be turned off. I've heard Java called a "BSDM language" because it forces the programmer to type reams of unnecessary characters to accomplish ordinary tasks. This reminds me of that.
Re: usable @nogc Exceptions with Mir Runtime
On Wednesday, 24 October 2018 at 10:57:27 UTC, 9il wrote: Release v0.0.5 comes with - mir.exception - @nogc MirException - mir.format - @nogc formatting Fantastic!
Re: Article: Why Const Sucks
On Monday, 5 March 2018 Jonathan M Davis wrote at http://jmdavisprog.com/articles/why-const-sucks.html: What Java has instead is `final`, which IMHO is borderline useless In Java `final` is extremely useful for efficient threadsafe code.
Re: Release D 2.078.0
On Wednesday, 10 January 2018 at 21:32:55 UTC, Nathan S. wrote: On my mac laptop running DMD 2.078.0, building and running the mir-algorithm unittests takes 8 seconds normally but takes ~3 minutes 49 seconds with dub options "releaseMode", "optimize", "inline", "noBoundsCheck". When I remove the "inline" option the build + test time becomes <10 seconds. So the weirdly slow part is related to inlining.
Re: Release D 2.078.0
DMD64 2.078.0 on Linux and macOS is taking wildly longer to build and run unittests for mir-algorithm. The extra time appears to be related to release mode optimizations. Build logs: https://travis-ci.org/libmir/mir-algorithm/builds/324052159 DMD 2.077.1 for linux32: 3 min 20 sec DMD 2.077.1 for linux64: 3 min 16 sec DMD 2.077.1 for mac64: 5 min 4 sec DMD 2.078.0-rc.1 for linux32: 13 min 30 sec DMD 2.078.0-rc.1 for linux64: 9 min 39 sec DMD 2.078.0-rc.1 for mac64: 10 min 56 sec, then the job was aborted The above tests all include a non-release build and a release build. On my mac laptop running DMD 2.078.0, building and running the mir-algorithm unittests takes 8 seconds normally but takes ~3 minutes 49 seconds with dub options "releaseMode", "optimize", "inline", "noBoundsCheck". I don't see any new compiler optimizations in the changelog. Any idea of what could be causing this?
Re: Proposal for a standard Decimal type in alpha
On Thursday, 21 December 2017 at 13:59:28 UTC, 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. The dub page: https://code.dlang.org/packages/stdxdecimal The docs: https://jackstouffer.github.io/stdxdecimal/ What you can do so far: * Control behavior with a Hook type a-la std.experimental.checkedint * Addition, subtraction, multiplication, division * Construction from a strings and built-in number types I think it would be clearer if the precision, the rounding mode, and the error behavior were three separate parameters instead of a single Hook. Predefined settings named "Abort", "Throw", and "NoOp" would then be self-explanatory, and it wouldn't be necessary to entirely rewrite them if you wanted precision of 10 or 20 decimal digits instead of 9 or wanted to use a different rounding mode.
Mir Random v0.3.0 release
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 -- You may find the release notes with hyperlinks more useful: https://github.com/libmir/mir-random/releases/tag/v0.3.0 Performance Increases -- We now use Daniel Lemire's fast alternative to modulo reduction. Compiling with LDC 1.6.0 for x86-64, Mt19937_64 randIndex throughput increased 40% for uint and 136% for ulong. Xoroshiro128Plus randIndex throughput increased 73% for uint and 325% for ulong. The required mir-algorithm version has increased to v0.7.0 because extMul is necessary for the ulong version. New since v0.2.8 -- - New engine: SplitMix64 / Splittable64 - Convenience functions related to thread-local randoms: rne (like std.random rndGen); threadLocal!Engine for arbitrary engine; & ways of mucking about with the bookkeeping state that most people won't need but a few have requested in the past. - Made some engines compatible with APIs that expect std.random-style UniformRNG. Compatible as-is: Xoroshiro128Plus; all predefined PCG engines; and the new SplitMix64/Splittable64 engines. For any others there is an adaptor. Copy-constructors are disabled so they will only work with functions that "do the right thing" and take PRNGs by reference and don't make implicit copies of them. Fixed since v0.2.8 -- - Changed many parts of the library to be @safe. - Linux GETRANDOM in unpredictableSeed now works on non-x86/x86-64 architectures. - Removed endian-dependency when producing 64-bit values from a native-32-bit PRNG. Changed APIs -- - The versions of genRandomBlocking/genRandomNonBlocking that take a pointer and a length are no longer @trusted. Instead there are trusted overloads for both that take a ubyte[]. - mir.random.algorithm has been changed in the interest of memory safety. You can still write unsafe code but now if you try to write @safe code the library will let you. Instead of taking engines by reference and storing their addresses (which could result in the stored address outliving the engine), now the various functions require arguments to be either objects or pointers to structs. For local-scoped engines there are templates with alias parameters. This is a major API change so feedback/criticism is welcome. Links -- [1] https://github.com/libmir/mir-random [2] http://en.cppreference.com/w/cpp/numeric/random
mir-algorithm v0.7.0: new interpolation, optmath, bugfixes
About Mir Algorithm Mir Algorithm[1] is Dlang core library for math, finance and a home for Dlang multidimensional array package - ndslice. New Modules since v0.6.21 - Reworked interpolation API, now found in mir.interpolate, mir.interpolate.linear, mir.interpolate.pchip. - New module mir.interpolate.spline for cubic interpolation. Warning: multivariate cubic spline with derivatives is still experimental. - New module mir.interpolate.constant for constant interpolation. Warning: multivariate constant interpolant is still experimental. API Changes since v0.6.21 - Added in mir.math.common function attributes @optmath and @fmamath. They only have effect when compiling with LDC but can be used with all compilers. (This now also applies to @fastmath.) @optmath is similar to @fastmath but does not allow unsafe-fp-math. Does not force LDC to replace division with multiplication by reciprocal. - New mir.utility.extMul extended unsigned multiplication that makes available the high bits of the result - New mir.functional.aliasCall - New mir.ndslice.algorithm.maxLength returns max length across all dimensions. - New mir.ndslice.slice.IteratorOf!(T : Slice) extracts iterator type from a Slice - New mir.ndslice.slice.ndassign assignment utility template that works both with scalars and with ndslices. - In mir.ndslice.slice.Slice: iterator is now inout; opUnary now works with - and +; opIndexAssign now returns ref this instead of void. - mir.ndslice.field.MagicField supports length and shape. Removed Modules - mir.interpolation, mir.interpolation.linear, mir.interpolation. Migrate to replacements (mir.interpolate.*). Other Changes since v0.6.21 - Uses of @fastmath in the Mir codebase have been replaced by @optmath, excepting mir.math.sum Summation.fast. - In mir.ndslice.topology under-the-hood improvements in slide, diff, pairwise - In mir.ndslice.slice.Slice opBinary and opBinaryRight now internally use mir.ndslice.topology.vmap instead of mir.ndslice.topology.indexed. Fixed since v0.6.21 - Fix in mir.ndslice.topology.map for compilation failing in cases where chained map calls couldn't be coalesced due to capturing multiple contexts (seemingly a compiler bug in some cases) - Made mir.ndslice.topology.flattened backwards compatible with LDC 1.2.0 for those who haven't upgraded - Added workaround in mir.ndslice.algorithm.reduce for DMD inlining bug for non-Windows x86-64 (LDC unaffected) - mir.primitives.shape now takes its argument by reference [1] https://github.com/libmir/mir-algorithm Release notes with hyperlinks: https://github.com/libmir/mir-algorithm/releases/tag/v0.7.0
Re: Release D v2.077.1
On Friday, 1 December 2017 at 12:17:38 UTC, Christian Köstlin wrote: also this link is broken for me i get a 404 Omit the "v" from "v2.077.1.html". https://dlang.org/changelog/2.077.1.html
mir-linux-kernel 1.0.0: Linux system call numbers for different architectures
About package
--
Linux system call numbers for different architectures. That's all.
https://code.dlang.org/packages/mir-linux-kernel
Motivating Example
--
Linux 3.17 added the getrandom syscall. Using it instead of
/dev/[u]?random was a win. But we didn't think about all of the
architectures that people might try building our library on, and
soon we got a report from a user that our latest and greatest
release was failing to compile on Raspberry Pi.
Example
--
import mir.linux._asm.unistd: NR_getrandom;
/*
* If the GRND_NONBLOCK flag is set, then
* getrandom() does not block in these cases, but instead
* immediately returns -1 with errno set to EAGAIN.
*/
private ptrdiff_t genRandomImplSysNonBlocking(scope void* ptr,
size_t len) @nogc nothrow @system
{
return syscall(NR_getrandom, cast(size_t) ptr, len,
GRND_NONBLOCK);
}
Re: Mir Random v0.2.8 release
On Tuesday, 24 October 2017 at 03:30:19 UTC, Nathan S. wrote: - On macOS, OpenBSD, and NetBSD, use arc4random_buf [4] in unpredictableSeed and genRandomNonBlocking. Since I am not sure whether this is common knowledge, arc4random isn't based on RC4 on these platforms. macOS uses AES, and OpenBSD and NetBSD use ChaCha20.
Mir Random v0.2.8 release
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 v0.2.8 -- Additions: - Added xorshift1024*φ and xoroshiro128+ generators [3] (mir.random.engine.xorshift : Xorshift1024StarPhi, Xoroshiro128Plus) - Mt19937 and Mt19937_64 can be seeded from array or ndslice - mir.random.engine.preferHighBits!T to query new optional enum bool preferHighBits Improvements: - When the high bits of a PRNG's output are known to have better statistical properties than the low bits, use high bits when not all bits of output are required. - On macOS, OpenBSD, and NetBSD, use arc4random_buf [4] in unpredictableSeed and genRandomNonBlocking. Bugfixes: - Fix isSaturatedRandomEngine!T not working when T.opCall is a function template. - Fix address-based increment for PCGs in unique_stream mode. - Incorporated upstream fix for seeding a MCG with a seed that's a multiple of the modulus. Links -- [1] https://github.com/libmir/mir-random [2] http://en.cppreference.com/w/cpp/numeric/random [3] http://xoroshiro.di.unimi.it/ [4] https://man.openbsd.org/arc4random.3
