On Saturday, 7 January 2017 at 15:58:43 UTC, Andrei Alexandrescu
wrote:
On 01/04/2017 08:06 PM, Dibyendu Majumdar wrote:
C++ integration has disappeared? Is this now "done"?
We have a student on that. I've added a line for that to the
doc. -- Andrei
I did a lot of work on C++ name mangling
I just created D bindings[1] for the MPFR library[2].
It also contains a D type[3] that wraps call to the library.
---
1. http://code.dlang.org/packages/deimos-mpfr
2. http://www.mpfr.org/
3.
https://github.com/gchatelet/deimos-mpfr/blob/master/source/mpfrd.d
On Saturday, 13 August 2016 at 20:50:53 UTC, Joseph Rushton
Wakeling wrote:
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
On Monday, 11 July 2016 at 16:30:44 UTC, Ilya Yaroshenko wrote:
Hello :-)
`cpuid` package is core.cpuid analog.
It would be used by future D BLAS implementation.
Why it is better?
See
https://github.com/libmir/cpuid#api-features
https://github.com/libmir/cpuid#implementation-features
On Tuesday, 12 July 2016 at 13:23:46 UTC, Ilya Yaroshenko wrote:
On Tuesday, 12 July 2016 at 12:46:26 UTC, Guillaume Chatelet
wrote:
On Monday, 11 July 2016 at 16:30:44 UTC, Ilya Yaroshenko wrote:
Hello :-)
`cpuid` package is core.cpuid analog.
It would be used by future D BLAS
On Monday, 11 July 2016 at 16:30:44 UTC, Ilya Yaroshenko wrote:
Hello :-)
`cpuid` package is core.cpuid analog.
It would be used by future D BLAS implementation.
Hey Ilya,
Quick question: where do the data come from/how reliable do you
think they are?
On Monday, 11 July 2016 at 16:30:44 UTC, Ilya Yaroshenko wrote:
Hello :-)
`cpuid` package is core.cpuid analog.
It would be used by future D BLAS implementation.
Why it is better?
See
https://github.com/libmir/cpuid#api-features
https://github.com/libmir/cpuid#implementation-features
On Wednesday, 6 July 2016 at 09:28:44 UTC, Martin Nowak wrote:
This is the first nightly dmd build that includes dub binaries.
http://nightlies.dlang.org/dmd-2016-07-06/
They will also be part of the upcoming 2.072.y releases.
We will sync the dub and dmd release cycles, but not the
versioning.
On Tuesday, 24 May 2016 at 11:06:45 UTC, Leandro Lucarella wrote:
For the ones that missed it (and the ones that didn't too),
here is a short video about the conference.
https://vimeo.com/167235872
Neat!
On Monday, 25 April 2016 at 06:42:02 UTC, Kai Nacke wrote:
Hi everyone,
LDC 1.0.0-beta1, the LLVM-based D compiler, is available for
download!
This BETA release is based on the 2.070.2 frontend and standard
library and supports LLVM 3.5-3.8.
The 1.0 release will be a major milestone. Please
On Wednesday, 27 April 2016 at 18:36:54 UTC, Andrei Alexandrescu
wrote:
The folks at Sociomantic suggested to start at 10:00 AM instead
of 9:00 AM, therefore shifting the end time by one as well.
Please reply with thoughts on this! We're particularly
concerned about folks who need to take off
On Thursday, 24 March 2016 at 01:49:25 UTC, Martin Nowak wrote:
First beta for the 2.071.0 release.
This release comes with many import and lookup related changes
and fixes. You might see a lot of deprecation warnings b/c of
these changes. We've added the -transition=import switch and
The last version of the code is available here and is feature
complete AFAICT
https://github.com/gchatelet/murmurhash3_d/blob/master/murmurhash3.d
Last concern, I declared blockSize in bytes where
std.digest.digest says it should be in bits. Why does it need to
be bits ? It looks like HMAC
On Sunday, 13 December 2015 at 12:44:06 UTC, Marc Schütz wrote:
AFAICS this doesn't conform to the digest interface. For
example, there should be a `finish` method that returns the
hash as a static array (see the ExampleDigest [1]).
The structs themselves do not but the alias at the beginning
On Sunday, 13 December 2015 at 16:24:35 UTC, Guillaume Chatelet
wrote:
On Sunday, 13 December 2015 at 12:44:06 UTC, Marc Schütz wrote:
[...]
The structs themselves do not but the alias at the beginning of
the file make sure they do.
alias MurmurHash3_x86_32 = Digester!SMurmurHash3_x86_32;
On Saturday, 12 December 2015 at 02:59:21 UTC, Ilya wrote:
Current version is suitable for arrays but not ranges or types.
Few examples:
1. Compute hash of ulong.
2. Compute hash of all elements in matrix column (element are
in different arrays).
I have created output range API draft
On Friday, 11 December 2015 at 01:51:09 UTC, Ilya wrote:
http://dpaste.dzfl.pl/1b94ed0aa96e#line-222 - seed is uint, can
it be ulong?
Done
Mutmur hash has three stages:
1. Computation of hash for blocks (32bit or 128bit)
2. Compitation of hash for tail (remainder)
3. Finalization.
I will be
Here is an implementation of MurmurHash [1] for D.
http://dpaste.dzfl.pl/1b94ed0aa96e
I'll do a proper pull request later on for addition to std.digest
if the community feels like it's a valuable addition.
Guillaume
--
1 - https://en.wikipedia.org/wiki/MurmurHash
Thx for the feedback !
bug : https://issues.dlang.org/show_bug.cgi?id=14086
I worked around the name mangling issue with pragmas for now, a
new version is available here :
https://github.com/gchatelet/dlang_cpp_std/blob/5d52957372f7055b95d4f62ee6d9633bd620a61d/cpp_std.d
Walter how far did you get to integrate with the STL ?
I started writing std::vector and std::string (linux gcc
libstdc++) but maybe someone already made progress on this. It's
harder than I thought and will probably require a lot of work to
maintain all implementations.
I pushed some code for string here (nothing fancy yet)
https://github.com/gchatelet/dlang_cpp_std/blob/master/cpp_std.d
The linker complains about missing
std::basic_stringchar, std::char_traitschar,
std::allocatorchar ::__ctor()
where it should be
std::basic_stringchar, std::char_traitschar,
21 matches
Mail list logo
