Re: Vision document for H1 2017
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 for D so feel free to introduce me to the student. I can probably save her/him a lot of time. After *many* attempts it seems the only way to get this right is to look at how clang does it and replicate the logic (starting point https://github.com/llvm-mirror/clang/blob/google/stable/include/clang/AST/Mangle.h) The state of my research on mangling so far are summed up here https://github.com/gchatelet/gcc_cpp_mangling_documentation I also have a bunch of failed experiments branches: - https://github.com/gchatelet/dmd/tree/new_cpp_mangle - https://github.com/gchatelet/dmd/tree/new_cpp_mangle2 - https://github.com/gchatelet/dmd/tree/new_cpp_mangling2 - https://github.com/gchatelet/dmd/tree/more_mangling_tests Unfortunately I couldn't spend more time on this :(
Deimos bindings for MPFR
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
Re: DIP1000: Scoped Pointers
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 copied by value, and (iii)
allows them to work effectively with (input) range semantics.
Isn't it what a scoped class is supposed to provide?
class Rnd {}
void foo() {
scope rnd = new Rnd; // reference semantic and stack allocated
}
Re: new cpuid is ready for comments
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 https://issues.dlang.org/show_bug.cgi?id=16028 Please report your CPU (GitHub/Gist): ``` dub fetch cpuid dub test cpuid ``` ... AMD was not tested at all and I hope to see your reports. ARM contributors are wanted! Destroy! Best regards, Ilya Docs: http://docs.cpuid.dlang.io GitHub: https://github.com/libmir/cpuid Dub: cpuid Also: Intel(R) Atom(TM) CPU 230 @ 1.60GHz https://gist.github.com/gchatelet/d3d347e4630ec2567eae7fe0391a9316
Re: new cpuid is ready for comments
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 implementation. Hey Ilya, Quick question: where do the data come from/how reliable do you think they are? Hello Guillaume, The data come from CPUID x86/x86_64 instruction. I have fixed bugs for AMD yesterday. Information for Intel and AMD processors should be reliable. But I am not sure about Cache and TLB information for virtual machines and other vendors. You can use cpuid.x86_any._cpuid [1] to get any information that is not presented. [1] http://docs.cpuid.dlang.io/latest/cpuid_x86_any.html#._cpuid Thx Ilya, I was discussing this a few colleagues. I'm quoting one of them here with his permission: "It doesn't seems that a userland library like this has any possibility to solve the root problem on Android/ARM. It's a twofold problem: 1. On ARM, the registers containing CPU identification and cache structure information, are privileged. See: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344f/Chdebced.html etc... (more such registers listed in the left pane on that page) Thus it is up to the operating system to expose this information to userspace. That takes us to the second part of the problem: 2. As far as I know, Android does not expose either CPU identification or cache structure information to userspace. Please do correct me if I'm wrong and this library found a way around that --- but from a cursory look at the cpuid library code, it does not have an ARM implementation at the moment?"
Re: new cpuid is ready for comments
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?
Re: new cpuid is ready for comments
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 https://issues.dlang.org/show_bug.cgi?id=16028 Please report your CPU (GitHub/Gist): ``` dub fetch cpuid dub test cpuid ``` ... AMD was not tested at all and I hope to see your reports. ARM contributors are wanted! Destroy! Best regards, Ilya Docs: http://docs.cpuid.dlang.io GitHub: https://github.com/libmir/cpuid Dub: cpuid Looks good! Here are my results (I added a `cat /proc/cpuinfo` for the record) https://gist.github.com/gchatelet/31a8cf41ba1d888c1efaef314d6a0c97
Re: First dmd nightly shipping with dub
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. Pretty cool!
Re: Sociomantic's short DConf2016 video
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!
Re: LDC 1.0.0-beta1 has been released! Please help testing!
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 help testing to make it the best release ever! We provide binaries for Linux, OX X, Win32 & Win64, Linux/ARM (armv7hf). :-) As usual, you can find links to the changelog and the binary packages over at digitalmars.D.ldc: http://forum.dlang.org/post/bwrnvztwkzhhwhzsk...@forum.dlang.org Regards, Kai Why does it requires libconfig.so.8? Could you static link it?
Re: Proposed: start DConf days one hour later
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 early on Friday. -- Andrei I'll take off early on Friday and will miss the last talk, with this one hour shift I'll probably miss the last two talks ... But hey they'll be recorded right?
Re: Beta D 2.071.0-b1
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 -transition=checkimports [¹] switches to ease updating existing code. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.071.0.html Please report any bugs at https://issues.dlang.org -Martin [¹]: -transition=checkimports currently has a bug that creates false positive warnings about the $ symbols, this will be fixed in the next beta (Bugzilla 15825) Shouldn't this be part of the release ? https://issues.dlang.org/show_bug.cgi?id=15581
Re: MurmurHash3
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 (which needs it) is explicitly making sure it's always a multiple of 8 bits.
Re: MurmurHash3
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 of the file make sure they do. alias MurmurHash3_x86_32 = Digester!SMurmurHash3_x86_32; alias MurmurHash3_x86_128 = Digester!SMurmurHash3_x86_128; alias MurmurHash3_x64_128 = Digester!SMurmurHash3_x64_128; More importantly, I believe your `put()` implementation only works if it is fed the entire data at once. I haven't tested it, but I believe that the following two calls will have a different result, while they should result in the same hash: hash.put([1,2,3,4,5,6]); vs hash.put([1,2,3]); hash.put([4,5,6]); I suspect this as well although I haven't tested. I'll add more tests and add the missing logic if needed.
Re: MurmurHash3
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; alias MurmurHash3_x86_128 = Digester!SMurmurHash3_x86_128; alias MurmurHash3_x64_128 = Digester!SMurmurHash3_x64_128; [...] I suspect this as well although I haven't tested. I'll add more tests and add the missing logic if needed. Fixed in last commit. Thx for the heads up Marc.
Re: MurmurHash3
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 http://dpaste.dzfl.pl/a24050042758 Ilya I created https://github.com/gchatelet/murmurhash3_d and updated the code a bit. It conforms to the digest template interface, allows pushing ulong[2] and accept ranges. PR welcome :)
Re: MurmurHash3
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 very happy, if step 1 will be represented as an output range. Then it can be used directly like reduce aggregator for ranges and multidimensional slices. Done Not thoroughly tested but updated for range and taking an ulong seed for MurmurHash3_x64_128: http://dpaste.dzfl.pl/1b94ed0aa96e Not sure I got what you meant about the optimized version. For the return value ? I haven't done any benchmarking yet.
MurmurHash3
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
Re: Interfacing D to existing C++ code
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
Re: Interfacing D to existing C++ code
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.
Re: Interfacing D to existing C++ code
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, std::allocatorchar ::basic_string() So constructors and destructors are mangled 'a la D' instead of the C++ way.
