Re: Dlang club meeting Thu May 30 7pm at the Red Robin
On Monday, 20 May 2024 at 22:36:30 UTC, Walter Bright wrote: Given last month's successful conversion of a sand pile to an atomic pile, this #dlang meeting will be about resurrecting the lost technology of the Atomic Earth Blaster. Thu May 30 7pm at the Red Robin 2390 148th Ave NE, Redmond, WA 98052 https://twitter.com/WalterBright/status/1792685408620605709 I am planning on being there, and I've got a list...
Re: SecureD 3.0 has been released!
On Thursday, 7 March 2024 at 17:06:00 UTC, Andrea Fontana wrote: On Wednesday, 6 March 2024 at 07:47:04 UTC, Adam Wilson wrote: SecureD 3.0 has been released. This version was set in motion by a Cedric Picard, a D community member with Cryptography experience, reaching out and suggesting a number of improvements to the Symmetric and KDF API's. This resulted in an API for symmetric encryption that improves correctness and security without significantly increasing developer workload. Also improved is the encryption envelope that contains symmetrically encrypted data. Algorithm Changes: - Removed: SHA2-224, AES-OFB - Added: SHA3-224/256/384/512 And I even remembered to update the examples in the README. Future work will focus on using the Operating System provided cryptography where available. Check it out here: https://code.dlang.org/packages/secured Well done Adam! I only miss the docs :) Andrea Yea, I totally whiffed and forgot to add examples for the new methods. And I can never seem to find the time for the DDoc comments that it really needs. It'll happen ... someday.
Re: SecureD 3.0 has been released!
On Thursday, 7 March 2024 at 11:04:08 UTC, Dukc wrote: On Wednesday, 6 March 2024 at 07:47:04 UTC, Adam Wilson wrote: This version was set in motion by a Cedric Picard, a D community member with Cryptography experience, reaching out and suggesting a number of improvements to the Symmetric and KDF API's. Wow, a Cym13 verified crypto library - excellent news! Indeed. I was actually excited to get the feedback. I am quite proud of what this release accomplished.
Re: SecureD 3.0 has been released!
On Thursday, 7 March 2024 at 08:17:47 UTC, aberba wrote: On Wednesday, 6 March 2024 at 07:47:04 UTC, Adam Wilson wrote: SecureD 3.0 has been released. This version was set in motion by a Cedric Picard, a D community member with Cryptography ... And I even remembered to update the examples in the README. +1 I wish more packages did this And even then I still forgot to add examples for the new Password methods...
SecureD 3.0 has been released!
SecureD 3.0 has been released. This version was set in motion by a Cedric Picard, a D community member with Cryptography experience, reaching out and suggesting a number of improvements to the Symmetric and KDF API's. This resulted in an API for symmetric encryption that improves correctness and security without significantly increasing developer workload. Also improved is the encryption envelope that contains symmetrically encrypted data. Algorithm Changes: - Removed: SHA2-224, AES-OFB - Added: SHA3-224/256/384/512 And I even remembered to update the examples in the README. Future work will focus on using the Operating System provided cryptography where available. Check it out here: https://code.dlang.org/packages/secured
Re: Phobos 3 Development is Open!
On Thursday, 29 February 2024 at 00:34:59 UTC, zjh wrote: On Wednesday, 28 February 2024 at 20:41:46 UTC, Adam Wilson wrote: or start a discussion if there is disagreement on how to handle this. Although Github has discussions, why not just discuss them in the `D forum`? This is `the forum`. Github doesn't have the convenience of the `D forum` at all. Why bother with them? A couple of reasons. First it's easier to cross-tab discussions with work on the design docs. Second, we started this during the whole fork and didn't need that bleeding into the discussion. Third, we didn't know how this will this GH experiment would work but we wanted to try it out. So far it's been a smashing success.
Re: Phobos 3 Development is Open!
On Thursday, 29 February 2024 at 13:44:37 UTC, Andrew wrote: On Wednesday, 28 February 2024 at 20:41:46 UTC, Adam Wilson wrote: I am totally on board with this if the community thinks there are improvements to be had here. Head on over to the Design repo and you can either submit a PR to the design document, or start a discussion if there is disagreement on how to handle this. I'll see if I can check it out next weekend, if that's not too late. Studying for my private pilot exam takes priority sadly. As a fellow pilot, I agree with this prioritization.
Re: Phobos 3 Development is Open!
On Wednesday, 28 February 2024 at 19:45:53 UTC, Greggor wrote: On Wednesday, 28 February 2024 at 15:55:52 UTC, Andrew wrote: On Wednesday, 28 February 2024 at 15:45:06 UTC, ryuukk_ wrote: https://github.com/dlang/phobos/pull/8925/files#diff-647aa2ce9ebedd6759a2f1c55752f0279de8ae7ba55e3c270bd59e1f8c1a5162R131 Why can't D have its own types? I have to agree with ryuukk_ on this one; it's one thing to maintain binary compatibility with C, and another to import and use C symbols all over the place in the standard library. I think that interfaces with C (or any other language) should be reduced to the minimum required to make something work, and nothing more. So, keep the usage of malloc/realloc/free to allocators and whatnot, and use fread/fwrite only in stdio. Absolutely agreed, I’d love to use Phobos in code targeting smaller platforms that is not just desktop Linux, macOS, windows or Bsd. Also being able to use smaller libc(s) where a full glibc is not available would be really nice. I am totally on board with this if the community thinks there are improvements to be had here. Head on over to the Design repo and you can either submit a PR to the design document, or start a discussion if there is disagreement on how to handle this.
Phobos 3 Development is Open!
The first PR for Phobos 3 has been merged into the Phobos repo! Now, to be clear, this is mostly a housekeeping PR that paves the way for further work and there isn't actually anything useful in it yet. We've setup the basic structure, DUB build/test config, and copied over the modules that don't have any `std` imports. The next project will be to (slowly) audit each file for any trace of auto-decoding. No module can be added to V3 without first being cleared of auto-decoding. With this comes a few changes in the development process for Phobos. The first of which is that all changes to Phobos will now need to be cross-applied to both libraries. We have kept V3 in the same repo as V2 to make this process easier, but you will need to check the V3 directory (tentatively labeled `lib`) to see if the V2 file you're modifying is included in V3 yet, and if it is, please include your change in corresponding V3 file as well. This will be enforced during the review process. If you are unsure, you can ping me on GitHub as `@LightBender` in your PR and I'll take a look. As we progress, I am sure that the other reviewers will become familiar with the state of the V3 code-base. Note that this process will continue for the indefinite future as we intended to maintain V2 alongside V3+. While the exact level of support that V2 will receive once V3 is launched hasn't been fulled resolved, at a minimum, it must remain in a buildable state indefinitely. Another note is that I do have a day job, so I will only be working on V3 in my spare time, as such, any help with the auto-decoding audit would be immensely appreciated as that will significantly speed up the time to completion and let us start focusing on the projects we all want to see happen in Phobos. If you have any V3 specific questions or comments you can join the discussion that's happening in this GitHub repo: https://github.com/LightBender/PhobosV3-Design Or, you can ask on the Forums and in the Discord and I'll do my best to keep up with the updates in those places. Finally, I would like to thank everybody who has contributed to the design of V3 already (there are too many to list, you know who you are), you've been a wonderful help as we start this journey. Thanks to your efforts the future of Phobos is looking very bright!
Re: Dlang mtg at Red Robin in Overlake 7pm tonight
On Wednesday, 24 January 2024 at 20:49:51 UTC, Walter Bright wrote: be there or be square! PhobosV3 is on the menu!
Re: Seattle D Meetup Mailing List - Ferrari Night
On Saturday, 16 December 2023 at 22:24:46 UTC, Walter Bright wrote: If you want to be on it, email me your address! We hope to have some fun activities for D aficionados. For example, I am planning "Ferrari Night" towards the end of the month where we all meet at the theater to watch "Ferrari". https://www.imdb.com/title/tt3758542 You have my email already!
Re: Seattle Area D-Meetup
On Tuesday, 12 December 2023 at 17:52:12 UTC, Gregor Mückl wrote: Hi! I'm interested in joining this time. Looking forward to meeting you all! I look forward to meeting you!
Seattle Area D-Meetup
Hello Everyone, If you're going to be in the Seattle area over the holidays, Walter, Bruce C, and I will be hanging out at the Red Robin in Redmond on December 14th from 7PM until whenever they kick us out. Normally we would meet after NWCPP, but they are on a holiday break this month so we have the opportunity to rant and rage... I mean have collegial dialog with Walter for an extended period of time this month. Address: 2390 148th Ave NE, Redmond, WA 98052
Re: Release D 2.106.0
On Saturday, 2 December 2023 at 18:09:11 UTC, Iain Buclaw wrote: Glad to announce D 2.106.0, ♥ to the 33 contributors. This release comes with... - In the D language, it is now possible to statically initialize AAs. - In dmd, there's a new `-nothrow` CLI flag. - In dub, `dub init` now has a select menu for package format and license. As always, you can find the release binaries and full changelog on the dlang.org site. http://dlang.org/download.html http://dlang.org/changelog/2.106.0.html -Iain on behalf of the Dlang Core Team I'm excited about this release! The ImportC fixes alone are with the wait. And it's good to see the ODBC bindings restored. Up next: ODBC 4.0 in Phobos.
Re: DLF September 2023 Planning Update
On Wednesday, 15 November 2023 at 05:27:40 UTC, Mike Parker wrote: If someone misses all of that and tries to use tuples without specifying edition N, the compiler should be able to tell them what the problem is, how to solve it (annotate your module declaration with `@edition(N)`), and provide the URL to the relevant documentation. This is exactly backwards from how most languages today. By default you are working with the current edition and you have to down-select to earlier editions. But if we're really enamored of using the crippled version of the language by default then it is absolutely imperative that edition selection be a command-line option. Here is how it should work IMO. The build system needs to able to specify editions at the package level, but when no package level edition is specified, then you assume current. If you need to down-select to an older edition then the dependency specifier in the project file that I control must set the correct edition. This neatly works around the lack of edition specifier in abandonware without enforcing crippled-by-default behavior that is going to confuse the entire world.
Re: First Beta 2.106.0
On Tuesday, 14 November 2023 at 17:44:11 UTC, Steven Schveighoffer wrote: This might be one of the greatest releases of D ever. -Steve I second this.
Re: SerpentOS departs from Dlang
On Saturday, 16 September 2023 at 12:34:24 UTC, Richard (Rikki) Andrew Cattermole wrote: Although I do want a write barrier on each struct/class, to allow for cyclic handling especially for classes. How dare you bring the High Heresy of write barriers into D! I thought that it was well understand that even mentioning Write Barriers is a mortal sin against the Church of @nogc. Kidding aside. If you do this, you might as well turn them on everywhere. After that it's a easy stroll to a non-blocking moving GC, which would end most complaints about the GC (nobody complains about the .NET GC anymore).
Re: SerpentOS departs from Dlang
On Friday, 15 September 2023 at 21:49:17 UTC, ryuukk_ wrote: Ikey seems to still want to use D, so the main driving factor is the contributors, i wonder what are the exact reasons, pseudo memory safety can't be the only reason I would guess that the following is the bigger problem: "we don't quite have the resources to also be an upstream for the numerous D packages we'd need to create and maintain to get our works over the finish line." This has long been a chicken-egg problem for D. We need more packages to attract more users, but we need more users building packages before we can attract more users. DIP1000 is also a bit of marketing problem. We kinda-sorta promise that someday you'll be able to build memory safe programs without a GC. We need to either push through and get it done, or admit we're not actually going to get there and cut it. I know there are ref-counted languages so theoretically it should be workable, but the in a language as complex as D there may be dragons on the edges. In any case, we should not be marketing something we can't actually do.
Re: New beginnings - looking for part-time D programming help
On Friday, 24 March 2023 at 09:01:21 UTC, Sergey wrote: On Friday, 24 March 2023 at 07:54:06 UTC, Monkyyy wrote: On Thursday, 23 March 2023 at 16:02:46 UTC, Laeeth Isharc wrote: Hi. For those that didn't hear, I resigned from Symmetry in September and my last day was a couple of weeks back. [...] "Not hedge fund" and "scripting" doesn't seem like enough of a job description to me My guess it is something related to context reconstruction :) When someone said something with quite limited words and sentences - he has a lot more context in his mind. Not always this context is the same for other people. Based on description this script could help to align the same context of conversation. Just guessing :) Btw is any LLM embedding available in open source? That makes sense to me as well. When I last spoke with Laeeth his brain was 10 steps ahead of, and accelerating away from, wherever he was in the conversation. Keeping up with people like that means that either the other person has the IQ to fill in the context on the fly, or we use tools to fill it in for us lesser minds. I'm guessing that this is about the later since IQ isn't something that we have a lot of control over. Could be useful, but I can see quality being an issue, how useful such a tool would be would depend on how accurately it deduces the correct context. Not an easy problem to solve.
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: DConf 2019: Shepherd's Pie Edition
On 12/22/18 10:47 AM, Robert M. Münch wrote: On 2018-12-22 12:18:25 +, Mike Parker said: Thanks to Symmetry Investments, DConf is heading to London! We're still ironing out the details, but I've been sitting on this for weeks and, now that we have a venue, I just can't keep quiet about it any longer. Hi, you should consider the upcoming Brexit chaos, which is expect to have a high impact on all airlines. Currently I wouldn't bet that all parties involved get things sorted out until May... I very much doubt that Brexit will cause anything approaching choas insofar as airlines are concerned. Currently all international flights are governed by the Montreal Convention which was signed by the individual states of the EU and not the EU itself, and the ICAO which is a UN function. They will remain in force regardless of the UK's status vis-a-vis Brexit. There may be the additional annoyance of EU folks having to pass through passport control depending on the final disposition of Brexit, but that's probably it. Chaos is a persuasion word that has zero measurable technical meaning, it's purpose is to allow your mind to fill it's space with your worst nightmares. Whenever I see it in the news I assume that the writer is ideologically opposed to whatever event the writer is describing and lacks any evidence to back up their claims. Airlines have had years to prepare for Brexit, and humans are generally pretty good at avoiding disasters that they've know about for years. My guess is that on Brexit day you won't even notice, save having to pass through an automated passport kiosk. -- Adam Wilson IRC: EllipticBit import quiet.dlang.dev;
Re: Autowrap for .NET is Now Available
On 12/14/18 2:33 PM, Sjoerd Nijboer wrote: Is there any overhead on the generated interface? Or overhead the compiler can't trivially optimise away. Yes, any overheads that would normally be associated with a P/Invoke call will be present here. Do you have any recocmendations about mixing coe like, don't use strings for now or try to minimize switching from D to C# and vice-versa. Strings are fine. But definitely try to minimize switching as there is some pretty significant overheads on the D side with module constructors. And "switching" can happen in some pretty well hidden places, for example, appending to a range is switch. Do you have plans to incorportae this as a VisualD project .csproj project since it's already intended to be microsoft oriented? (It would seem like a good fit to me.) That way you could even take away the mixin code and the "running the main method" code. I do not since I wouldn't know where to start, but it's possible. Does it work with LDC or only with DMD? How about GCC on linux? It works with anything that can output a shared library and C interfaces. :) -- Adam Wilson IRC: EllipticBit import quiet.dlang.dev;
Re: Aurora DirectX Bindings 12.1
On 10/3/18 10:15 PM, rikki cattermole wrote: On 04/10/2018 5:33 PM, Nicholas Wilson wrote: On Thursday, 4 October 2018 at 04:03:27 UTC, rikki cattermole wrote: On 04/10/2018 2:06 PM, Adam Wilson wrote: The Aurora DirectX bindings have been updated to support Windows 10 1809. Also the D2D Effect Authoring SDK has been added. GitHub: https://github.com/auroragraphics/directx DUB: http://code.dlang.org/packages/aurora-directx Please send PR's if you find any bugs! It would be nice to get DirectX bindings into druntime. Just need 9/10 (some are floating about) after these mature a bit. I don't think thats wise, nor is it ever like to happen. Druntime is D's runtime, the only reason there are bindings to the C and and C++ standard library is because of their ubiquity. This is much better suited to a dub package. Side note, its possible that I might end up adding a DX12 backend to LDC/DCompute (which I'm going to have to rename if I do) based on https://github.com/Microsoft/DirectXShaderCompiler/ even more likely if MS (Hi Adam) upstream it to LLVM. Direct3D is part of the system API on Window's today, it is equivalent to using WinAPI for graphics. Which is well within the scope of druntime bindings. A couple of thoughts on this. First IIRC, the Win32 bindings in DRT is nowhere near a complete implementation of the Win32, I think it's primarily from user32.lib. Second, the DirectX bindings themselves are absolutely massive and the move pretty quickly (they change with every release of Windows, so every 6 months right now). Putting them in DRT would significantly slow down updates. For example, I had these updates released within two days of the release of 1809. Third, my implementation is not complete. There are a bunch of missing macros and helper functions that have not yet been ported. So for now I definitely think the package route is a better option. But if you do end up using these bindings on DCompute please let me know! I've made sure that all the Shader interfaces exist, but if you find anything missing I will gladly except PR's. -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Re: Aurora DirectX Bindings 12.1
The Aurora DirectX bindings have been updated to support Windows 10 1809. Also the D2D Effect Authoring SDK has been added. GitHub: https://github.com/auroragraphics/directx DUB: http://code.dlang.org/packages/aurora-directx Please send PR's if you find any bugs! -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Re: SecureD moving to GitLab
On 06/05/2018 12:28 AM, Brian wrote: On Tuesday, 5 June 2018 at 06:55:42 UTC, Joakim wrote: On Tuesday, 5 June 2018 at 06:45:48 UTC, Adam Wilson wrote: Hello Fellow D'ers, As some of you know I work for Microsoft. And as a result of the recent acquisition of GitHub by Microsoft, I have decided, out of an abundance of caution, to move all of my projects that currently reside on GitHub to GitLab. [...] This reads like a joke, why would it matter if you contributed to open source projects on an open platform that your employer runs? Yes! We support Github. Note that I am not saying that this is bad move for Microsoft of GitHub. Elsewhere on these forums I have defended the move as the best possible outcome for GitHub. -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Re: SecureD moving to GitLab
On 06/04/2018 11:55 PM, Joakim wrote: On Tuesday, 5 June 2018 at 06:45:48 UTC, Adam Wilson wrote: Hello Fellow D'ers, As some of you know I work for Microsoft. And as a result of the recent acquisition of GitHub by Microsoft, I have decided, out of an abundance of caution, to move all of my projects that currently reside on GitHub to GitLab. [...] This reads like a joke, why would it matter if you contributed to open source projects on an open platform that your employer runs? And this reads like someone who has never talked to a lawyer. :) I am intentionally keeping this ambiguous as possible so that others don't try to take this as legal advice. I'm guessing you live somewhere outside the US? For reference, I do live in the US. -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Re: GitHub could be acquired by Microsoft
On 06/04/2018 08:53 PM, Adam Wilson wrote: On 6/3/18 20:51, Anton Fediushin wrote: This is still just a rumour, we'll know the truth on Monday (which is today). Some articles about the topic: https://fossbytes.com/microsoft-github-aquisition-report/ https://www.theverge.com/2018/6/3/17422752/microsoft-github-acquisition-rumors What's your opinion about that? Will you continue using GitHub? Both GitLab and Bitbucket can be used instead to host your D projects - dub registry supported them for a while now. IMHO Microsoft isn't the type of company I want to see behind the GitHub. Maybe I am wrong since Microsoft has both money and programmers to improve it further, I just don't trust them too much which is the right thing to do when dealing with companies. This means that I will move my repositories elsewhere and use GitHub just to contribute to other projects. I've been thinking how to best respond to this and here is where I am. First, let me state up-front that I work for Microsoft (Office 365 Workplace Analytics). Second, my employer (Volometrix) prior to working for Microsoft was acquired by Microsoft almost three years ago. What that means is that while my division had no fore-warning of this acquisition I have first-hand experience with what will be happening at GitHub over the next months and years. As an employee of Microsoft I am required to follow Microsoft's policy on Social Media, which can be reduced to "If you have nothing nice to say, then say nothing at all." Or stated plainly, what follows may or may not represent the entirety of my thoughts on the matter as I am effectively barred from revealing any negative thoughts. So what I can say about this acquisition is that it is the best possible outcome of GitHub's possible futures for both the company and the employees. GitHub has not been profitable for years and is thought to have had cash reserves for only one or two more months of operations. Losing GitHub entirely overnight would have been an unmitigated disaster for the entire Open-Source community. And there are fates worse than death. Imagine for a second GitHub at Google or ... *shudder* Oracle. Whatever your opinions about Microsoft, you cannot possible imagine that either of those outcomes would have been qualitatively better. In that sense Microsoft was the best of the bad options GitHub. As to any other concerns/opinions, all I will say is ... think laterally. As a reminder I have no inside information on what goes on over in the Azure world and that is where GitHub will land as has been announced. -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Re: GitHub could be acquired by Microsoft
On 06/04/2018 11:46 PM, RalphBa wrote: Sorry to hear that. Since I do not belive Microsoft changed perspective and am convinced they still see open source as cancer I need to assume they try to inflitrate the OSS community the last years. So for sure I won't rely on their stuff. So is there a chance Digital Mars and D main development is getting bought by Microsoft? BR Ralph They have C++ and C#. What do they need D for? -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
SecureD moving to GitLab
Hello Fellow D'ers, As some of you know I work for Microsoft. And as a result of the recent acquisition of GitHub by Microsoft, I have decided, out of an abundance of caution, to move all of my projects that currently reside on GitHub to GitLab. Additionally, until I cease working for Microsoft, I will no longer be contributing code to projects hosted on GitHub, including DLang and it's related projects. I will continue to contribute bug reports and post to the forums. I will post a link to the new SecureD repo on this thread and update the DUB links once I have everything setup correctly post-move. DISCLAIMER: The actions described herein are the result of my specific situation and not intended as a larger commentary on recent events. This message should not be considered legal advice in any way. Any Microsoft employees reading this thread should refer to their lawyers about their specific situation or concerns. -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Re: GitHub could be acquired by Microsoft
On 6/3/18 20:51, Anton Fediushin wrote: This is still just a rumour, we'll know the truth on Monday (which is today). Some articles about the topic: https://fossbytes.com/microsoft-github-aquisition-report/ https://www.theverge.com/2018/6/3/17422752/microsoft-github-acquisition-rumors What's your opinion about that? Will you continue using GitHub? Both GitLab and Bitbucket can be used instead to host your D projects - dub registry supported them for a while now. IMHO Microsoft isn't the type of company I want to see behind the GitHub. Maybe I am wrong since Microsoft has both money and programmers to improve it further, I just don't trust them too much which is the right thing to do when dealing with companies. This means that I will move my repositories elsewhere and use GitHub just to contribute to other projects. I've been thinking how to best respond to this and here is where I am. First, let me state up-front that I work for Microsoft (Office 365 Workplace Analytics). Second, my employer (Volometrix) prior to working for Microsoft was acquired by Microsoft almost three years ago. What that means is that while my division had no fore-warning of this acquisition I have first-hand experience with what will be happening at GitHub over the next months and years. As an employee of Microsoft I am required to follow Microsoft's policy on Social Media, which can be reduced to "If you have nothing nice to say, then say nothing at all." Or stated plainly, what follows may or may not represent the entirety of my thoughts on the matter as I am effectively barred from revealing any negative thoughts. So what I can say about this acquisition is that it is the best possible outcome of GitHub's possible futures for both the company and the employees. GitHub has not been profitable for years and is thought to have had cash reserves for only one or two more months of operations. Losing GitHub entirely overnight would have been an unmitigated disaster for the entire Open-Source community. And there are fates worse than death. Imagine for a second GitHub at Google or ... *shudder* Oracle. Whatever your opinions about Microsoft, you cannot possible imagine that either of those outcomes would have been qualitatively better. In that sense Microsoft was the best of the bad options GitHub. As to any other concerns/opinions, all I will say is ... think laterally. -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
SecureD 1.0.0 Released!
Hello! I am pleased to announce that after a year of development and stabilization SecureD has been released in stable form. The most recent release consists of an upgrade to OpenSSL 1.1 in order to be compliant with more recent and supported versions of OpenSSL. If you need to use OpenSSL 1.0.x add version 'OpenSSL10' to your command line. As always, PR's are welcome. Thank you! -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Aurora DirectX Bindings 12.1
I am happy to announce that after a prolonged hiatus the Aurora DirectX bindings have been updated to support DirectX 12.1 and DirectX 11.4. The project has been refactored to more closely align with the DirectX SDK headers and the scope is significantly increased to include the D3D Video, D2D Effects, SVG, and Debugging libraries. And finally, the package has now been added to DUB. The following components of DirectX are supported: DirectX 12.1 - Shaders - Shader Tracing - Video - SDK Layers (Debugging) DirectX 11.4 - Shaders - Shader Tracing - Video - SDK Layers (Debugging) Direct2D 1.3 - Effects 1.2 - SVG DirectWrite 1.3 DXGI 1.6 WIC The work is a combination of mechanical and hand conversion and there may be some inconsistent or incorrect types in the interface. If you encounter any inconsistencies I would love you pull requests. Please note that most Macros are NOT ported yet. PR's welcome! These bindings are based on the Windows SDK version 10.0.16299.0 (Windows Build 1709 - Redstone 3) GitHub: https://github.com/auroragraphics/directx DUB: http://code.dlang.org/packages/aurora-directx -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Re: Release D 2.079.0
On 3/5/18 15:40, Atila Neves wrote: On Monday, 5 March 2018 at 17:47:13 UTC, Seb wrote: On Monday, 5 March 2018 at 15:16:14 UTC, Atila Neves wrote: On Saturday, 3 March 2018 at 01:50:25 UTC, Martin Nowak wrote: Glad to announce D 2.079.0. This release comes with experimental `@nogc` exception throwing (-dip1008), a lazily initialized GC, better support for minimal runtimes, and an experimental Windows toolchain based on the lld linker and MinGW import libraries. See the changelog for more details. Thanks to everyone involved in this https://dlang.org/changelog/2.079.0.html#contributors. http://dlang.org/download.html http://dlang.org/changelog/2.079.0.html - -Martin Is is just me or did this release just break the latest non-beta vibe.d? Is the Jenkins build testing the dub packages on master instead of the latest tag? Atila https://github.com/vibe-d/vibe.d/issues/2058 It's great that there's an issue for vibe. This doesn't change the fact that right now, somebody trying D for the 1st time with the latest official compiler will get an error if they try out the most popular dub package that I know of if they follow the instructions on code.dlang.org. It also doesn't change that I can't upgrade dmd on our CI at work because it can't compile vibe unless I change dozens of dub.sdl files to use a beta version. This breaks semver! I found out about this after removing a dependency on stdx.data.json since dmd >= 2.078.0 broke it (by breaking taggedalgebraic. Yes, I filed a bug.). I can upgrade from 2.077.1 to 2.078.3,but not 2.079.0. I'd have a snowball's chance in hell convincing anyone at a "regular" company of adopting D if anyone there even imagined any of the above could happen. We have to do better than this. Atila May I make a recommendation? Only upgrade to the 2.0xx.2[.3] releases. You'll have to wait a month or so for the latest features, but by then the important packages will have been upgraded and the regressions (mostly) worked out. It's kind of like the old saying about Microsoft software. "Never use the first version of anything". If we treat the .0 releases as "v1" then it fits. :) -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Re: GSoC 2018 - Your project ideas
On 12/5/17 10:20, Seb wrote: Hi all, Google Summer of Code (GSoC) 2018 is about to start soon [1] (the application period for organizations is in January 2018). Hence, I would very happy about any project ideas you have or projects which are important to you. And, of course, if you would be willing to mentor a student, please don't forget to tell me. You can always reach me via mail (seb [at] wilzba [dot] ch) or on Slack (dlang.slack.com). There's also a special #gsoc channel. I have also started to work over the ideas from last year [2], but this page is currently WIP. @Students: if you have any questions or maybe have an idea for a project yourself, please feel free to contact me. I'm more than happy to help! I am looking forward to hearing (1) what you think can be done in three months by a student and (2) will have a huge impact on the D ecosystem. Cheers, Seb [1] https://developers.google.com/open-source/gsoc/timeline [2] https://wiki.dlang.org/GSOC_2018_Ideas I am absolutely up for mentoring this year and there are some fantastic projects on this list. The ones I'd be willing to mentor are: std.database - I've done a significant amount of work on this (not on github yet). And I have almost two decades of experience with various SQL interface libraries. I've seen the good, the bad, and the ugly, and would be able to work very closely with the student. :) std.eventloop - This will be needed if I am ever going to get Async/Await off the ground. std.decimal - I need this for some personal projects. Garbage Collector - It's not on the list but somebody mentioned it. There are actually two PR's outstanding for a precise GC from the 2016 GSoC I mentored; here: https://github.com/dlang/druntime/pull/1603 and here: https://github.com/dlang/druntime/pull/1977. But there is still a ton of room for improvement. There are more areas that precision could be expanded too. The 2016 student started playing around with a type-based pooling collector. There are a number of ideas we could explore. Note that I'm not a big fan of the fork()-based GC idea since it's limited to *nix based systems -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Re: Release D v2.076.1
On 10/12/17 19:50, Jonathan M Davis wrote: On Thursday, October 12, 2017 14:39:27 b4s1L3 via Digitalmars-d-announce wrote: Also i'd like to say that the policy that is that regression fixes are commited on stable and that the fact that they only come to master in a "sync operation" is a problem. In the travis yaml we have to test dmd, dmd beta (stable, not yet released) and finally dmd master (current working tree). The policy should be changed so that regression fixes are commited to both master and stable, allowing to decrease the CI complexity. The problem is mainly that testing a project with dmd beta is pointless. It's only useful 1 or 2 weeks before a release, which happens , let's say, 4 times per years, leading to a waste of computing resources at the CI service. With reg fixes put in master at the same time that in stable, testing 3 versions of the DMD compiler would not be necessary anymore, i think. I don't know what the best way to handle committing regression fixes is, but I did find it annoying recently when I ran into a bug on master that I'd fixed on stable, but the fix hadn't been merged over yet. The fact that the fixes are delayed on master makes master buggier than it would be otherwise, and a number of us use master as our primary compiler. - Jonathan M Davis At work we branch out of stable (not yet released) and fix the bug. Merge branch to stable and then merge branch to master. Works pretty well. As long as you don't merge things into stable that you never intend for master. -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Re: Dynamic binding to the Mono runtime API
On 6/4/17 04:15, Jakub Szewczyk wrote: On Sunday, 4 June 2017 at 09:43:23 UTC, Adam Wilson wrote: On 6/4/17 01:18, Jakub Szewczyk wrote: This is an interface to the Mono libraries, D/CLI would [...] My interest is less in code ports than bindings to the actual code. My experience with code ports or translations is that often subtle bugs creep in during translation due to the fact that each language has different idioms. What I am thinking about is a tool that loads an assembly, examines it's types and methods via this API and emits D code that directly interfaces into the .NET types via this API. The tricky part here is mapping the .NET dependencies into D. The moment the library exposes a type from a dependency, that dependency ALSO needs to be included somehow. All libraries reference "mscorlib", AKA the BCL, so we'd have to provide a "mono-bcl" package on DUB. That's what I actually meant, "porting" was a misused term on my part, "binding" would be a better word, sorry for that. As for the dependency problem - I think that a linking layer generator would accept a list of input assemblies (and optionally, specific classes) to which it should generate bindings, the core Mono types could be automatically translated to D equivalents, and the rest could be left as an opaque reference, like MonoObject* in C, also providing support for very basic reflection through the Mono methods if it turned out to be useful for anyone. Mono actually supports some kind of GC bridging as far as I understand, [...] On the GC side I was mostly thinking about GC Handles so that the objects don't get collected out from underneath us. That is something is trivial to code-gen. As for exceptions, I like the catch->translate->rethrow mechanism. And if the exception is unknown we could simply throw a generic exception. The important thing is to get close to the D experience, not try to map it perfectly. Yes, GCHandles to keep Mono objects in D and a wrapper based on that GC bridge to keep D references from being collected by Mono. I have previously implemented a very similar mechanism for Lua in a small wrapper layer, and it worked perfectly. I can make a static library version, [...] Thank you for this! I find static libraries easier to deal with. I'm sure other people have differing opinions, so having both would make everyone happy. It's now public as v1.1.0, I've tested that it works with the tiny sample, the only important part is that the library to link must be specified by the project using this binding, because those paths may vary across systems, and they cannot be specified in code like the dynamic link ones. However, a simple "libs":["mono-2.0"] entry in dub.json should be enough for most use cases. Thank you for this, I've tried it and it works! I did some in depth research and prototyping in D, and it looks like the only way to enumerate the types in an assembly is to use the Metadata Table API's map everything that way. That's a little beyond the scope of my free time so I'll have to shelve the idea from now. :( -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Re: Dynamic binding to the Mono runtime API
On 6/4/17 01:18, Jakub Szewczyk wrote: This is an interface to the Mono libraries, D/CLI would require quite a lot of compiler changes, both on the front-end and back-end side, but thanks to metaprogramming a wrapper library can get very close to such an interface. I plan on making an automated D to Mono bridge, akin to LuaD, so that it can be used as a scripting platform for e.g. games. I haven't thought about doing it the other way around, but now it seems like a very interesting idea! Unfortunately no XAML (http://www.mono-project.com/docs/gui/wpf/), but many other libraries, such as XWT (https://github.com/mono/xwt) could be ported this way, I'll certainly look into it. My interest is less in code ports than bindings to the actual code. My experience with code ports or translations is that often subtle bugs creep in during translation due to the fact that each language has different idioms. What I am thinking about is a tool that loads an assembly, examines it's types and methods via this API and emits D code that directly interfaces into the .NET types via this API. The tricky part here is mapping the .NET dependencies into D. The moment the library exposes a type from a dependency, that dependency ALSO needs to be included somehow. All libraries reference "mscorlib", AKA the BCL, so we'd have to provide a "mono-bcl" package on DUB. One solution is to simply include the exposed dependency in the generated code. This would work because while the D code would have distinct types for the same class, the underlying .NET types is the same. The drawback with this approach is that you can't share the instances across D interfaces as the types are different. For example, Library1.B and Library2.C both rely on Dependency.A. In D you would have Library1.B.A and Library2.C.A and these two types, while the same in practice, are different types to the compiler. Maybe a clever use of alias can solve this at code-gen time... more research is required there. The other solution is too have the code-gen throw an error when it encounters a type from a dependency. This ensures that the types are the same across libraries in D, but at the cost of increased complexity for the developer when running the tool (specifying extra deps) and when building their code (ensuring all relevant packages are built/referenced). I'm not sold on either one. And it'd be best if it's possible to support both somehow. As for the WPF remark, my brain immediately jump to trying to interface to .NET/Core using a similar mechanism, but alas some research time indicates that this is not possible outside of COM. *le sigh* My apologize for the random side-track. Mono actually supports some kind of GC bridging as far as I understand, as there is a sgen-bridge.h header just for that, and it has apparently been used in the C#-Java Xamarin interace on Android. As for exceptions - D functions have to be wrapped in a nothrow wrapper, but that can be completely automated with templates. The other way around is also quite simple - when invoking a Mono function a pointer can be given that will set an exception reference if one is thrown from the .NET side, and a wrapper can easily rethrow it back to D. On the GC side I was mostly thinking about GC Handles so that the objects don't get collected out from underneath us. That is something is trivial to code-gen. As for exceptions, I like the catch->translate->rethrow mechanism. And if the exception is unknown we could simply throw a generic exception. The important thing is to get close to the D experience, not try to map it perfectly. I can make a static library version, it's just some regex substitutions done on the functions file actually, most probably I'll publish it today. It will be a dub subconfiguration like it is the case for GLFW3. Btw, I've manually ported the basic and configuration headers, so that no mistakes are made, and then used DStep and a modified DStep to generate the rest of the headers - my modification was only to change the way function declarations are generated, to make them in derelict form of alias da_function = void function(...);, and the rest was done with quite a lot of editor(VSCode) shortcuts. Thank you for this! I find static libraries easier to deal with. I'm sure other people have differing opinions, so having both would make everyone happy. I am very excited about this! -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Re: Dynamic binding to the Mono runtime API
On 6/3/17 10:30, Jakub Szewczyk wrote: Mono runtime is a cross-platform, open-source alternative to Microsoft's .NET framework [1], and it can be embedded in other applications as a "scripting" VM, but with JIT-compilation enhanced performance and support of many languages such as C#, F# or IronPython [2]. It provides a C API, so I've bound it to D as a Derelict-based project, available at https://github.com/kubasz/derelict-mono, and as a DUB package (http://code.dlang.org/packages/derelict-mono). It currently wraps the Mono 5.0 API. There's also a simple example of calling a C# main from D code, and C# code calling a native function implemented in D. PS: Because I don't own a Mac I have no idea what the correct paths to the Mono shared library are, so it'd be great if someone could post/create a PR of them. [1] http://www.mono-project.com/ [2] http://www.mono-project.com/docs/advanced/embedding/scripting/ I work with C# professionally and this is some SERIOUSLY cool work. Thank you for this! I've looked over the code a bit and I have a couple of questions. This appears to be an interface to the runtime itself, not a BCL interface correct? It looks like this could be used to could this be used to read into a Mono Class Libraries, and if so would so some sort of automated code generation tool be required? It looks to me like the binding will be non-trivial, with GC, exceptions, etc. that all need to be handled at the call-site. Can we get a static library version of this, or is there a dependency on dynamic libraries? I have to admit I am very impressed. I have spent a lot of time building code generators before and I have to admit that the idea of binding to arbitrary .NET libraries via code generation is extremely appealing to me. I am seriously tempted to take this and start building a binding generator... I seriously need more free time! Way too many cool and useful things happening in D for my limited free time. A D binding for XAML ... THAT would sight to behold! -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Re: DConf hackathon: idea list
On 5/4/17 16:33, rikki cattermole wrote: On 04/05/2017 3:22 PM, Adam Wilson wrote: On 5/4/17 15:32, Seb wrote: Hi all, the DConf hackathon isn’t a hackathon in the traditional sense. It is intended as a day for _collaboratively_ focusing on long-lasting problems and pain points in the D ecosystem, planning upcoming features or DIPs, and creation of a rough roadmap for the next months. Of course, any D hackers who wish to simply progress their own personal projects are welcome too! Experience has shown that in large groups too much time is wasted on giving a voice to everyone, whereas for tiny groups chances are that it takes too long to get the ball rolling. Hence, a group size of four or five D hackers is recommended. Below you can find a list of themes with a short abstract and a couple of ideas. The abstracts and ideas are intended to get you started and guide you. Please feel free to _add your own ideas_ and _add your names_ next to them so that people can ping you (IRC, email, and other IM handles might be handy as well). Of course, you can add your name to multiple projects. On Sunday the first half an hour will be used to finalize the group forming. All existing groups and persons with an idea, but without a group can pitch their idea shortly (one minute max, no slides) and thus find other motivated D hackers. https://docs.google.com/document/d/1L5edu6LLj3Afa3tPgqk-aX-fErwr7sPj37Dt5avoc5w/edit# From the Phobos wishlist: I am working an a generic SQL database interface. If anybody is interested in helping out I have a small amount of code that shows the general design direction I've taken so far. We can discuss the design and collaboratively hack out a prototype. The current code is here: https://github.com/LightBender/std.experimental.database.sql Looking at that I think focusing on describing of tables ext. would be a good first step. I worry that it won't be very flexible memory management or serialization wise. It's definitely the hardest problem to solve. Obviously we could start with a brute force approach (box everything like ADO.NET does) for the sake of getting started and then work on improving it later. For now I compromised and used Variant, which should be sufficient for most cases right now. (See latest commit) I am using Classes and Dynamic Arrays so it's not @nogc yet, but this is something that can be improved over time. There is no reason that this could not use the new Allocators API at a later date. I'm not looking for inclusion into Phobos during the DConf Hackathon, but I would like to block out something that we can start using. -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Re: DConf hackathon: idea list
On 5/4/17 15:32, Seb wrote: Hi all, the DConf hackathon isn’t a hackathon in the traditional sense. It is intended as a day for _collaboratively_ focusing on long-lasting problems and pain points in the D ecosystem, planning upcoming features or DIPs, and creation of a rough roadmap for the next months. Of course, any D hackers who wish to simply progress their own personal projects are welcome too! Experience has shown that in large groups too much time is wasted on giving a voice to everyone, whereas for tiny groups chances are that it takes too long to get the ball rolling. Hence, a group size of four or five D hackers is recommended. Below you can find a list of themes with a short abstract and a couple of ideas. The abstracts and ideas are intended to get you started and guide you. Please feel free to _add your own ideas_ and _add your names_ next to them so that people can ping you (IRC, email, and other IM handles might be handy as well). Of course, you can add your name to multiple projects. On Sunday the first half an hour will be used to finalize the group forming. All existing groups and persons with an idea, but without a group can pitch their idea shortly (one minute max, no slides) and thus find other motivated D hackers. https://docs.google.com/document/d/1L5edu6LLj3Afa3tPgqk-aX-fErwr7sPj37Dt5avoc5w/edit# From the Phobos wishlist: I am working an a generic SQL database interface. If anybody is interested in helping out I have a small amount of code that shows the general design direction I've taken so far. We can discuss the design and collaboratively hack out a prototype. The current code is here: https://github.com/LightBender/std.experimental.database.sql -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Re: DConf 2017 Schedule
On 3/23/17 4:21 PM, Joakim wrote: On Thursday, 23 March 2017 at 16:14:03 UTC, xtreak wrote: On Thursday, 23 March 2017 at 12:34:13 UTC, Nicholas Wilson wrote: On Wednesday, 15 March 2017 at 15:20:03 UTC, Joakim wrote: On Tuesday, 14 March 2017 at 16:12:56 UTC, Mike Parker wrote: Fresh from the D Foundation HQ, the DConf 2017 schedule [1] is now available for your perusal. If you haven't registered yet, you have just over five weeks to get it done. The registration deadline has been set for April 23, so don't procrastinate. Even better, head over to the registration page [2] and do it now! [1] http://dconf.org/2017/schedule/ [2] http://dconf.org/2017/registration.html Killer lineup, makes me wish I was going, is it on reddit? I haven't seen it there yet. someone should definitely put it there. Submitted to Reddit : https://www.reddit.com/r/programming/comments/612sy4/dconf_2017_schedule_announced_scott_meyers_is_one/ Thanks, it's too bad that someone had to link to the ustream of Scott's last talk in the comments, because both the official links here don't work: http://dconf.org/2014/talks/meyers.html Damn, I just watched it on YouTube a few days ago and now the whole account is gone. What happened? -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Re: DConf 2017 Early Bird Registration expires Monday!
On 2/24/17 11:02 PM, Walter Bright wrote: http://dconf.org/2017/registration.html Don't forget, it goes up to $400 after Monday. What do we do if we purchased three pass via EventBrite? I didn't see anywhere to set name/company info... -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Re: Reminder - DConf 2017 is May 4-6 !!
On 1/6/17 4:46 PM, Walter Bright wrote: It's 2017 already - sharpen your pencils and start on a proposal for a presentation! Time is moving fast! Just sent mine in! -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Re: Silicon Valley D Meetup - December 22, 2016 - "The Curse of Knowledge: Et tu, D?" by Adam Wilson
Ali Çehreli wrote: On 12/15/2016 12:20 AM, Ali Çehreli wrote: https://www.meetup.com/D-Lang-Silicon-Valley/events/236253882/ The slides: http://files.meetup.com/18234529/The%20Curse%20of%20Knowledge.pptx The video: http://youtu.be/XjnBMfVTI0k (There is no audio on the recording until 45:45.) Ali This one is on me. And I do apologize profusely. We were talking beforehand about how we needed to remember to unmute, we had tested everything to make sure it worked, and then in a fit of eagerness to get started, I forgot to switch windows and unmute. I would like to give this talk again as it generated some very good discussion on the topic. Hopefully, with someone else in charge of A/V, we will have more luck. -- Adam Wilson IRC: LightBender //quiet.dlang.dev
Re: SecureD - A simple cryptography library for D
Jacob Carlborg wrote: On 2016-12-12 08:07, Adam Wilson wrote: On OSX you need to use LDC or the linker will fail. What linker errors do you get using DMD? ld: in ../../.dub/packages/botan-1.12.8/botan/.dub/build/full-unittest-posix.osx-x86_64-dmd_2072-0D593375D53C36354213ADF6E4F6A036/libbotan_base.a(unique_40d1_3b6.o), in section __TEXT,__textcoal_nt reloc 2: symbol index out of range for architecture x86_64 -- Adam Wilson IRC: LightBender //quiet.dlang.dev
Re: SecureD - A simple cryptography library for D
Adam Wilson wrote: Adam Wilson wrote: rikki cattermole wrote: On 14/11/2016 9:31 AM, Adam Wilson wrote: Jacob Carlborg wrote: On 2016-11-12 21:50, Adam Wilson wrote: I choose OpenSSL because it's a well respected, highly trusted, and it is available everywhere. I despise the license and the API. Sadly, those are not primary concerns when dealing with Cryptograpy libraries. Well, Apple abandoned it years ago because it was difficult to upgrade without breaking applications that are using it. There are also very few core developers working on it, as I understand it. Other companies/organizations have abandoned it as well in favor of other implementations like libressl due to various reasons. Perhaps, if possible, a common API on top of whatever is the "native" cryptographic library on each supported platform. What if we did something with DUB build configurations. You can build the default OpenSSL configuration or build a Botan configuration based on the Botan D port depending on your needs. They would use the same cryptographic primitives and produces the same results, just using different libraries. Would that work? Yup, simple set of versions should do it. I'll take a look at it. Botan should be easier to work with than OpenSSL. This is going to have to wait. The Botan port currently does not build with 2.072.0 due to the removal of std.stream. I've filed a bug here: https://github.com/etcimon/botan/issues/24 The std.stream deprecation has been fixed and I've pushed the code to implement Botan, but the tests fail on a SegFault inside Botan in the PEM export functions. AES/Hash/HMAC/PBKDF2/RNG work. On OSX you need to use LDC or the linker will fail. Tracking issue for the segfault: https://github.com/etcimon/botan/issues/25 -- Adam Wilson IRC: LightBender //quiet.dlang.dev
Re: SecureD - A simple cryptography library for D
Adam Wilson wrote: rikki cattermole wrote: On 14/11/2016 9:31 AM, Adam Wilson wrote: Jacob Carlborg wrote: On 2016-11-12 21:50, Adam Wilson wrote: I choose OpenSSL because it's a well respected, highly trusted, and it is available everywhere. I despise the license and the API. Sadly, those are not primary concerns when dealing with Cryptograpy libraries. Well, Apple abandoned it years ago because it was difficult to upgrade without breaking applications that are using it. There are also very few core developers working on it, as I understand it. Other companies/organizations have abandoned it as well in favor of other implementations like libressl due to various reasons. Perhaps, if possible, a common API on top of whatever is the "native" cryptographic library on each supported platform. What if we did something with DUB build configurations. You can build the default OpenSSL configuration or build a Botan configuration based on the Botan D port depending on your needs. They would use the same cryptographic primitives and produces the same results, just using different libraries. Would that work? Yup, simple set of versions should do it. I'll take a look at it. Botan should be easier to work with than OpenSSL. This is going to have to wait. The Botan port currently does not build with 2.072.0 due to the removal of std.stream. I've filed a bug here: https://github.com/etcimon/botan/issues/24 -- Adam Wilson IRC: LightBender //quiet.dlang.dev
Re: SecureD - A simple cryptography library for D
rikki cattermole wrote: On 14/11/2016 9:31 AM, Adam Wilson wrote: Jacob Carlborg wrote: On 2016-11-12 21:50, Adam Wilson wrote: I choose OpenSSL because it's a well respected, highly trusted, and it is available everywhere. I despise the license and the API. Sadly, those are not primary concerns when dealing with Cryptograpy libraries. Well, Apple abandoned it years ago because it was difficult to upgrade without breaking applications that are using it. There are also very few core developers working on it, as I understand it. Other companies/organizations have abandoned it as well in favor of other implementations like libressl due to various reasons. Perhaps, if possible, a common API on top of whatever is the "native" cryptographic library on each supported platform. What if we did something with DUB build configurations. You can build the default OpenSSL configuration or build a Botan configuration based on the Botan D port depending on your needs. They would use the same cryptographic primitives and produces the same results, just using different libraries. Would that work? Yup, simple set of versions should do it. I'll take a look at it. Botan should be easier to work with than OpenSSL. -- Adam Wilson IRC: LightBender //quiet.dlang.dev
Re: SecureD - A simple cryptography library for D
Steven Schveighoffer wrote: On 11/12/16 8:15 PM, Adam Wilson wrote: Hello DLang, I wanted to announce that I have completed the bulk of the work on my Cryptography library for D, SecureD. I was inspired to do this project by Stan Drapkin and his Inferno.NET project, however, the two projects NOT compatible. [snip] Let me know what you think! I'm not a crypto guru or even a casual user. But I think it's very important that we have something like this for D, thanks for your work! You're welcome. There are more goodies in the pipe. :) I know vibe.d uses crypto for https usage. Any ideas/comparison with that? Would the code look better with your lib instead? Would it be more secure? Having vibe.d as a consumer would be a huge boost to testing/usage. vibe.d uses OpenSSL for HTTPS streaming, I use OpenSSL for the cryptographic primitives it supports. A benefit is that you only have to link one library. And vibe.d's code absolutely would look cleaner. Unfortunately, my library targeted for long-term storage scenarios, and SSL is a streaming scenario. To my mind, you would use OpenSSL for HTTPS as part of an HTTP or web library like vibe.d. Anything I implement would be lower level and not very useful outside of that scenario. It's not a bad idea, but I think it's outside the scope of what my library is trying to accomplish. My apologies for not more clearly noting that I was targeting long-term storage scenarios, I meant to in the write-up and it must've slipped through the edits. -Steve -- Adam Wilson IRC: LightBender //quiet.dlang.dev
Re: SecureD - A simple cryptography library for D
Jacob Carlborg wrote: On 2016-11-12 21:50, Adam Wilson wrote: I choose OpenSSL because it's a well respected, highly trusted, and it is available everywhere. I despise the license and the API. Sadly, those are not primary concerns when dealing with Cryptograpy libraries. Well, Apple abandoned it years ago because it was difficult to upgrade without breaking applications that are using it. There are also very few core developers working on it, as I understand it. Other companies/organizations have abandoned it as well in favor of other implementations like libressl due to various reasons. Perhaps, if possible, a common API on top of whatever is the "native" cryptographic library on each supported platform. What if we did something with DUB build configurations. You can build the default OpenSSL configuration or build a Botan configuration based on the Botan D port depending on your needs. They would use the same cryptographic primitives and produces the same results, just using different libraries. Would that work? -- Adam Wilson IRC: LightBender //quiet.dlang.dev
Re: SecureD - A simple cryptography library for D
Suliman wrote: It would take some research, but the native Botan library makes heavy use of C++ templates There is native lib https://github.com/etcimon/botan Some people with whom I talked said that botan is too low level for them and it's hard for them to use it. So your lib maybe very good wrap on top of it. I know of that work. I even looked at it. But it is a port and not an interface, that makes me very skeptical. Even though it's the same codebase, you basically have to restart the trust building and code verification process all over again. It's Botan the code, but not Botan the library. I also agree that Botan is too low level. If you want too, I'd be happy to review a PR that integrates Botan instead of OpenSSL. My goal is the simple interface, not the underlying implementation. -- Adam Wilson IRC: LightBender //quiet.dlang.dev
Re: SecureD - A simple cryptography library for D
Suliman wrote: Is its possible to make its wrap on botan instead of openssl? Some of developers have problems with openssl because it's require openssl lib. But botan is more native but much more lowlevel. So its hard to use. It might be possible. But it would not be without difficulties. It would take some research, but the native Botan library makes heavy use of C++ templates. Additionally, I have a strong aversion to ports of Cryptography libraries, it is far to easy for a port to miss or break a subtle implementation detail and the compiler itself could cause a leak of information. I choose OpenSSL because it's a well respected, highly trusted, and it is available everywhere. I despise the license and the API. Sadly, those are not primary concerns when dealing with Cryptograpy libraries. Personally, I actually prefer Botan. Two years ago I started a project to attempt to wrap Botan in a similar manner as this but I ran headlong into the template meat-grinder and found it almost impossible to make it work. It might be possible now with DLang's C++ template support. That said, if we want to talk about developing a common Cryptography interface for D that would allow us to use the same interface for supporting multiple underlying cryptography libraries I would *LOVE* to have that conversation. -- Adam Wilson IRC: LightBender //quiet.dlang.dev
SecureD - A simple cryptography library for D
Hello DLang, I wanted to announce that I have completed the bulk of the work on my Cryptography library for D, SecureD. I was inspired to do this project by Stan Drapkin and his Inferno.NET project, however, the two projects NOT compatible. GitHub: https://github.com/LightBender/SecureD DUB: https://code.dlang.org/packages/secured Design Philosophy Developer-Friendly Misuse-Resistant API: One of the largest problems with most cryptography libraries available today is that their API's practically encourage broken implementations. Safe by design: Use only safe algorithms with safe modes. Make conservative choices in the implementation Do no re-implement cryptography algorithms: Use industry standard libraries instead. SecureD is based on OpenSSL. Minimal Code: Keep the code to a minimum. This ensures high-maintainability and eases understanding of the code. Unittesting: All API's are unittested using D's built in unittests. Any developer can verify the implementation with a simple 'dub test' command. This ensures that the library will perform as advertised. Algorithms HASH: SHA2-384 HMAC: SHA2-384 KDF:PBKDF2 (HMAC/SHA2-384) AEAD Symmetric: AES-256-CTR-HMAC384 Asymmetric: ECC-P384 (Key Derivation + Sign/Verify with SHA2-384) RNG:System RNG on POSIX and Windows OTHER: Constant Time Equality Why these Algorithms? SHA2-384 is as fast as SHA2-512 but it's truncated design serves as an effective defense against length extensions attacks. AES-256-CTR is an alternative for GCM that offers greater security for cold-stored data when paired with a strong HMAC. GCM use a 96-bit authentication tag where the HMAC tag is a full 384 bits. Let me know what you think! Adam Wilson IRC: LightBender //quiet.dlang.dev
Re: DConf 2014 Day 2 Talk 3: Designing an Aurora: A Glimpse at the Graphical Future of D by Adam Wilson
On Tue, 15 Jul 2014 09:12:01 -0700, Kapps opantm2+s...@gmail.com wrote: On Tuesday, 15 July 2014 at 05:40:29 UTC, Adam Wilson wrote: Yes, performance is not a goal, because we are intentionally not targeting scenarios where that is the first concern. I understand that a lot of people want Aurora to be a high-performance graphics API with a focus on games, but that isn't our goal. Simplicity is the goal and we will sacrifice performance where it directly conflicts with that goal. If you need a high-performance game engine, I would strongly recommend either creating a custom solution or using an off-the-self system. To clarify, while Aurora may not be a performant enough solution for a full graphics engine, it should theoretically be sufficiently fast for a GUI within a game, correct? That shouldn't be a problem. -- Adam Wilson GitHub/IRC: LightBender Aurora Project Coordinator
Re: DConf 2014 Day 2 Talk 3: Designing an Aurora: A Glimpse at the Graphical Future of D by Adam Wilson
On Tue, 08 Jul 2014 09:03:37 -0700, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: https://news.ycombinator.com/newest (please find and vote quickly) https://twitter.com/D_Programming/status/486540487080554496 https://www.facebook.com/dlang.org/posts/881134858566863 http://www.reddit.com/r/programming/comments/2a5ia9/dconf_2014_day_2_talk_3_designing_an_aurora_a/ Andrei So instead of replying to each messages and accumulating a LOT of quoted text I will attempt to answer some of your questions here. The first is that I would like to challenge the assumption that Scene Graphs are somehow Less Performant. In fact the they are a very highly performant solution to many problems, yes there are a few drawbacks but they are far outweighed by the performance gains. Remember that when you are designing a system you must consider the system as a whole, it's WAY to easy to get caught up in individual concerns. Most AAA game engines use some form of scene graph. The one I am familiar with is CryENGINE 3. Now those scene graphs are more specialized, but there is absolutely no reason that a scene graph has to be slow. In fact D's immutability may give the compiler (and us) the ability to build the most performant scene graph in the world. Scene graphs make relative transforms easy for example, and since that is really all you're doing in 3D, making that easy for the computer is a massive win. As for similarity in graphics subsystem API's they are, at best, superficial. When you actually try to implement something on top of them, you end up forcing the abstraction far higher than you'd think. Plus the high-level API design was something that Walter, Andrei, and I all agreed on at the start. I want to reiterate that Aurora is NOT a high-performance game engine and we won't even pretend to try. The focus on 2D is not about how difficult 2D versus 3D is, but about project scope. We want to build Aurora in components that are useful on their own. Based on previous message traffic in the forum I think that more people will find use for the 2D components than the 3D components. Writing a DSL for shaders is one of those things that sounds good until you actually try it. There is a LOT of complexity, both at the language level and the number of output variations, within shaders that would have to addressed. While D is appealing to game designers, Aurora is very explicitly NOT targeting them. They will either create their own engines or using a COTS system that's already available. Walter made this point extremely clear to me when he asked me to take this project on. Yes, performance is not a goal, because we are intentionally not targeting scenarios where that is the first concern. I understand that a lot of people want Aurora to be a high-performance graphics API with a focus on games, but that isn't our goal. Simplicity is the goal and we will sacrifice performance where it directly conflicts with that goal. If you need a high-performance game engine, I would strongly recommend either creating a custom solution or using an off-the-self system. -- Adam Wilson GitHub/IRC: LightBender Aurora Project Coordinator
Re: DirectX bindings
On Tue, 27 May 2014 02:24:01 -0700, evilrat evilrat...@gmail.com wrote: On Sunday, 3 November 2013 at 05:27:24 UTC, evilrat wrote: https://github.com/evilrat666/directx-d this is it. i think i can't continue on this one anymore, nor do i have time, nor passion. i've made a lot of work and meet (almost) no interest. i will be stay in contact, so any pull request will not be lost, but i think this is my last commit to it. i have encountered lot of obstacles such as UFCS on classes, which makes impossible seamless migration of user code from C++ to D(no, that wasnt real purpose but for me it is important point). i may return later, let say in a year or two when D will be more complete and usable, but for now i take my leave. please take my apologies if one really used this bindings or have high hopes on it. I think it would appropriate at this point to note that Aurora is currently hosting bindings for DirectX and will continue to maintain DirectX bindings for a the foreseeable future. DirectX 12 bindings will be provided once they become available. So if you need current and maintained bindings for DirectX you can find them on GitHub here: https://github.com/auroragraphics/directx -- Adam Wilson GitHub/IRC: LightBender Project Coordinator The Aurora Project
Re: Announcing TitaniumD - A D Binding for the Botan Cryptography Library
On Thu, 01 May 2014 14:55:05 -0700, brad clawsie b...@b7j0c.org wrote:
Adam, this is very cool!
do you have any examples showing its use? In particular, examples
highlighting D code using AES and SHA libs
thanks!
brad
You're welcome. There are no example yet. And the build script only
supports Windows. Pull requests using *make tools most welcome.
A little walkthrough:
Build TitaniumCore, TitaniumD and TDI as static libraries. TitaniumCore
and TitaniumD can be compiled with any C++ compiler and the availability
of Boost Filesystem and ASIO. Although you'll have to specify the paths to
Boost.
Once those libraries are built you'll need to pass all three of them to
DMD along with your project.
Then the following code should work:
module test;
import std.stdio;
import Titanium.TDI; //Make sure to specify the correct search path with
-I on the DMD commandline.
void main(string[] args)
{
auto t = new TitaniumLibrary();
//Hash Test Vectors
string vec1 = The quick brown fox jumps over the lazy dog;
string vec2 = The quick brown fox jumps over the lazy dog.;
//Hash Testing
writeln(HashSHA2(HashSize.Size256, vec1));
SHA2 h = new SHA2(HashSize.Size256);
writeln(h.Process(vec2));
AES c = new AES(CipherKeySize.Key128, CipherMode.GCM, 16);
ubyte[] enc1 = c.Encrypt(cast(ubyte[])vec1.dup);
string dec1 = cast(string)c.Decrypt(enc1);
ubyte[] enc2 = c.Encrypt(cast(ubyte[])vec2.dup);
string dec2 = cast(string)c.Decrypt(enc2);
writeln(enc1);
writeln(dec1);
writeln(enc2);
writeln(dec2);
}
The above sample shows SHA2 and AES-128/GCM.
Please submit bug reports and pull requests on GitHub if you run into any
problems!
--
Adam Wilson
IRC: LightBender
Project Coordinator
The Aurora Project
Announcing TitaniumD - A D Binding for the Botan Cryptography Library
Hello Fellow D'ers, I'd like to announce TitaniumD, a binding for D to the Botan Cryptography Library. Botan is an open-source cryptography library written in C++11 and makes extensive use of the C++ Standard Library in it's API. Titanium is a PIMPL around the Botan API designed to make interfacing Botan with other languages easier by translating the STL API into something more friendly. TitaniumD is the D specific binding for Botan. Botan is distributed as source only and utilizes a script to configure individual modules into a single header and source file called an amalgamation build. Because of this Botan and Titanium are not a typical library distributions, such as OpenSSL, and therefore I am unsure how this might fit into Deimos. A TitaniumD consists of three components: - TitaniumCore, contains the Botan amalgamation build and the PIMPL wrapper. - TitaniumD, the C++ half of the D binding that maps the PIMPL wrapper to a D compatible ABI. - TDI, the D half of the binding. Each of these components is built as a static library. Currently Titanium supports the following algorithms: AES - Sizes: 128/192/256- Modes: CBC, CTS, CFB, OFB, CTR, EAX, GCM, SIV Camellia- Sizes: 128/192/256 - Modes: CBC, CTS, CFB, OFB, CTR, EAX, GCM, SIV Serpent - Sizes: 128- Modes: CBC, CTS, CFB, OFB, CTR, EAX, GCM, SIV Threefish - Sizes: 512 - Modes: CBC, CTS, CFB, OFB, CTR, EAX, SIV Twofish - Sizes: 128- Modes: CBC, CTS, CFB, OFB, CTR, EAX, GCM, SIV SHA-2 - Sizes: 224/256/384/512 SHA-3 - Sizes: 224/256/384/512 Skein - Sizes: 512 Whirlpool - Sizes: 512 RSA Elliptic Curve Diffie-Hellman HMAC RNG ANSI X.923 RNG SSL/TLS support is coming soon. Botan has supported SSL/TLS for a long time, however, there were a few bugs in code that prevented Visual C++ from compiling the TLS modules. These are in the process of being fixed and I'll be building a wrapper for TLS in Titanium shortly. Botan currently supports x86, x64, and ARM, on Linux, OSX, Windows, iOS, and Android. The only dependency that Botan has is on Boost, and any recent version will do, I've tested it 1.54 and 1.55. At this point in time, I only have the time and energy to maintain the Windows portion of the code. Currently you can build it on Windows by entering the directory and running Build.sh in the Git Console. However, I could really use help in porting the build processes to other platforms. Beyond Botan the code itself is pretty vanilla C++, so any recent compiler should be able to compile the interface libraries without much fuss. So if anybody has any interest in a Crypto library for D that is easy to use and isn't OpenSSL, I could really use some help getting this library ported to more platforms. Pull requests will be accepted! Repositories: Botan: https://github.com/randombit/botan/tree/net.randombit.botan Titanium: https://github.com/ellipticbit/titanium -- Adam Wilson GitHub/IRC: LightBender Aurora Project Coordinator
D Breaks on to the TIOBE Top 20 List.
I know we don't place much value in TIOBE and it's brethren. However, I thought that this was a milestone worthy of a note anyways. http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html -- Adam Wilson GitHub/IRC: LightBender Aurora Project Coordinator
Re: Mono-D 1.9 - opIndex/opSlice overload recognition + completion
On Thu, 17 Apr 2014 09:56:32 -0700, Adam Wilson flybo...@gmail.com wrote: On Wed, 16 Apr 2014 20:15:21 -0700, Kapps opantm2+s...@gmail.com wrote: On Wednesday, 16 April 2014 at 22:45:45 UTC, Adam Wilson wrote: On Fri, 04 Apr 2014 07:35:18 -0700, Alexander Bothe i...@alexanderbothe.com wrote: On Monday, 31 March 2014 at 21:41:26 UTC, Théo Bueno wrote: Mono-D seems pretty complete to me now, I was wondering if you are thinking about new major features ? http://mono-d.alexanderbothe.com/mono-d-v1-9-opindexopslice-overload-recognition-completion/ :-) I am getting a Completion Timeout and Xamarin Studio is lagging hard when the completion window pops up... I didn't think my files were that big or complex... I had a similar issue until I disabled mixin and template analysis. It seems to have been getting into an infinite loop somewhere in my code (though I'm not sure where). Interesting, I'll have to try that, the project has a LOT of the same mixin template, and it worked for a while, but as the project has gotten bigger it's timed out... I just checked my settings and it was already off. -- Adam Wilson GitHub/IRC: LightBender Aurora Project Coordinator
