Re: DLS (D Language Server) v0.20
On Friday, 28 December 2018 at 11:14:01 UTC, Laurent Tréguier wrote: Hello, and merry Christmas! (a bit late, but whatever) At the end of March of this year, I had made a post [1] about this project, aimed at helping with D development on various editors (VSCode, Atom, Sublime text, vim...) [2]. In a nutshell, it's a bit like serve-d [3], albeit with fewer features, and focused more on being 'plug and play': a single binary with no dependencies, can be installed without being compiled on most OS's, automatically updates itself and tries to adapt to different dmd/ldc installations. [...] Can dfmt be disabled completely? I think I tried this before way back and it couldn't. I don't really want auto formatting of my code.
SecureD 2.0 Released
SecureD is a library that provides strong cryptography with a simple-to-use interface that ensures that your data will be correctly and securely stored with a minimum amount of effort. What's New in 2.0? Complete rewrite of symmetric encryption and decryption. Prior to V2 the standard encryption and decryption functions only provided one set of algorithms and no path to use safe alternatives or work with encrypted data from other sources. Both of these shortcomings have now been rectified. If you need to perform custom encryption or interoperate with other systems, please see the encrypt_ex and decrypt_ex functions. New algorithms. - Digests: - SHA2 512/224, 512/256 - SHA3 224, 256, 384, 512 - Symmetric Algorithms: AES (128/192/256), ChaCha20 - Stream Modes: GCM, CTR, Poly1305 (ChaCha20 only) - Block Modes: OFB, CFB, CBC (PKCS7 Padding Only) - KDFs: - HKDF - SCrypt - ECC: - P256 Curve - P521 Curve To support these new algorithms, SecureD now requires OpenSSL 1.1.1. It is my opinion that, as 1.1.1 is the new LTS release, it would be prudent to upgrade now as 1.1.1 will be support for many years to come. Please note that the API's have changed significantly. Additionally, due to the major overhaul of the symmetric encryption code and the new algorithms, I was unable to upgrade the Botan code-path and was forced to remove it to ship. If anybody is interested in doing the work to bring Botan back into the project I would be grateful. -- Adam Wilson IRC: EllipticBit import quiet.dlang.dev;
Re: DLS (D Language Server) v0.20
On Friday, 28 December 2018 at 11:14:01 UTC, Laurent Tréguier wrote: [...] Wow, just awesome! I really love this language server. It just works!
Re: now it's possible! printing floating point numbers at compile-time
On Thursday, 27 December 2018 at 12:46:06 UTC, Nick Treleaven wrote: Is the MIT license compatible with Boost? Simply put, no. The MIT license comes with the additional requirement of including the copyright notice and license in all copies (incl. binary form), whereas BSL-1.0 requires this only for source form. PS: I am not a lawyer.
Re: now it's possible! printing floating point numbers at compile-time
H. S. Teoh wrote: actually, there is a 3rd issue, which is often overlooked: conversion from string to float. to get a perfect roundtrip, this one should be done right too. Doesn't hex output format (e.g. std.format's %a and %A) already solve this? It basically outputs the exact bits in hex. No room for error there. it does. but then you can simply go with writing binaries as-is -- they are not really less readable than hex floats. ;-) but we want decimals! ;-)
Re: ldexp and frexp benchmark between Mir, C and Phobos
On Friday, 28 December 2018 at 19:48:28 UTC, 9il wrote: ldexp and frexp are base building blocks for a lot of math functions. Here is a small benchmark that compares Mir, C and Phobos implementations: Wow, thanks! Been waiting for an exp() rewrite. And Boost-licensed! I'm using expf() from whatever libc is shipped and the variability of results and lack of control is annoying.
Re: now it's possible! printing floating point numbers at compile-time
On Sun, Dec 30, 2018 at 03:26:33PM +0200, ketmar via Digitalmars-d-announce wrote: > Basile B. wrote: > > > On Sunday, 30 December 2018 at 12:19:19 UTC, ketmar wrote: > > > too bad that i didn't knew about Ryu back than. > > > > It's very recent, announce on proggit is < 1 year. > > > > It would be nice to have one to format in phobos. RYU or Grisu3 > > doesn't matter much as long as the two issues that are > > > > - CTFE formatting of floats > > - formatting is identical on all platforms > actually, there is a 3rd issue, which is often overlooked: conversion > from string to float. to get a perfect roundtrip, this one should be > done right too. [...] Doesn't hex output format (e.g. std.format's %a and %A) already solve this? It basically outputs the exact bits in hex. No room for error there. T -- It said to install Windows 2000 or better, so I installed Linux instead.
Re: now it's possible! printing floating point numbers at compile-time
Basile B. wrote: On Sunday, 30 December 2018 at 12:19:19 UTC, ketmar wrote: too bad that i didn't knew about Ryu back than. It's very recent, announce on proggit is < 1 year. It would be nice to have one to format in phobos. RYU or Grisu3 doesn't matter much as long as the two issues that are - CTFE formatting of floats - formatting is identical on all platforms actually, there is a 3rd issue, which is often overlooked: conversion from string to float. to get a perfect roundtrip, this one should be done right too. is solved. There's also the "real" problem. I'm pretty sure that 32 and 64 bits floats are always handled. Someteimes 128 bits ones but not sure for 80 bits... 80 bits can (usually) be extended to 128. you'll get some extra meaningless digits, of course, but it is better than nothing, i think. actually, Ryu has all the math to derive 80-bit implementation. it will require 128-bit integers, though. (less than 128, but there is no sense in using smaller ints anyway).
Re: now it's possible! printing floating point numbers at compile-time
On Sunday, 30 December 2018 at 12:19:19 UTC, ketmar wrote: too bad that i didn't knew about Ryu back than. It's very recent, announce on proggit is < 1 year. It would be nice to have one to format in phobos. RYU or Grisu3 doesn't matter much as long as the two issues that are - CTFE formatting of floats - formatting is identical on all platforms is solved. There's also the "real" problem. I'm pretty sure that 32 and 64 bits floats are always handled. Someteimes 128 bits ones but not sure for 80 bits...
Re: now it's possible! printing floating point numbers at compile-time
i think that porting Ryu will get us the fastest one (and with smaller/easier code). and without pathological cases of grisu too. too bad that i didn't knew about Ryu back than. as for roundtrips -- you're probably right. stb implementation was made to be "mostly correct", afair, but not fully correct. or i broke something (which is very possible). it worked for my cases, tho, so i just sticked with it. anyway, two is better than one! ;-)
Re: now it's possible! printing floating point numbers at compile-time
Hi Ketmar, thanks for sharing your work! On Friday, 28 December 2018 at 19:03:02 UTC, ketmar wrote: Stefan Koch wrote: [ ... ] [1] https://github.com/UplinkCoder/fpconv/blob/master/src/fpconv_ctfe.d of course, it is not all that fancy, but i ported STB converter quite a long time ago, and it is ctfe-able too. ;-) [0] https://repo.or.cz/iv.d.git/blob_plain/HEAD:/ctfefloat.d I've benchmarked it[0] against fpconv_ctfe[1] and yours is almost as fast! However it has a a little more error when converting floats than grisu2 has. Meaning generally the output cannot round-trip. Warm greetings, Stefan
Re: Release Candidate [was: Re: Beta 2.084.0]
On Saturday, 29 December 2018 at 19:14:29 UTC, Andre Pany wrote: On Saturday, 29 December 2018 at 15:21:32 UTC, Martin Nowak wrote: On 12/17/18 10:38 PM, Martin Nowak wrote: Release Candidate for 2.084.0 is live now. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.084.0.html As usual please report any bugs at https://issues.dlang.org -Martin The Runtime.loadLibrary issue is a heavy regression (https://issues.dlang.org/show_bug.cgi?id=19498). Is there a workaround for the issue? Should the workaround info be added to the release note? Kind regards Andre Thanks a lot Rainer for solving this issue (https://github.com/dlang/druntime/pull/2425) Kind regards Andre
