Re: From the D Blog: Crafting Self-Evident Code in D
On Monday, 2 October 2023 at 17:28:19 UTC, Mike Parker wrote: It's been a long, long while since I published anything on the blog. I do intend to get pick it up again down the road, but Walter recently surprised me with plans of his own. He's taken the topic of his DConf '23 talk and derived a blog post from it: https://dlang.org/blog/2023/10/02/crafting-self-evident-code-with-d/ I guess he got impatient with the pace at which I'm getting the talk videos uploaded :-) And for anyone who'd like to engage in any Reddit discussion that comes up: https://www.reddit.com/r/programming/comments/16y2h36/crafting_selfevident_code_in_dlang/ Good talk. Many very clever people would achieve more if they tried to understand why a v. experienced developer would care to spend so much time talking about what might appear to be such basic points. The key challenge: If this stuff was so obvious & everyone did it or it didn't matter so much that they didn't, why would Walter care about it so much?
Re: text based file formats
On Wednesday, 21 December 2022 at 04:19:46 UTC, 9il wrote: On Tuesday, 20 December 2022 at 19:46:36 UTC, John Colvin wrote: On Tuesday, 20 December 2022 at 00:40:07 UTC, H. S. Teoh wrote: [...] We use this at work with some light tweaks, it’s done a lot work 🙂 It has already been replaced with [mir.csv](https://github.com/libmir/mir-ion/blob/master/source/mir/csv.d). Mir is faster, SIMD accelerated, and supports numbers and timestamp recognition. Hah, so it has! Well anyway, it did do a lot of hard work for us for a long time, so thanks :)
Re: text based file formats
On Tuesday, 20 December 2022 at 00:40:07 UTC, H. S. Teoh wrote: On Mon, Dec 19, 2022 at 04:16:57PM -0800, Walter Bright via Digitalmars-d-announce wrote: On 12/19/2022 4:35 AM, Adam D Ruppe wrote: > On Monday, 19 December 2022 at 09:55:47 UTC, Walter Bright > wrote: > > Curious why CSV isn't in the list. > > Maybe std.csv is already good enough? LOL, learn something every day! I've even written my own, but it isn't very good. There's also my little experimental csv parser that was designed to be as fast as possible: https://github.com/quickfur/fastcsv However it can only handle input that fits in memory (using std.mmfile is one possible workaround), has a static limit on field sizes, and does not do validation. T We use this at work with some light tweaks, it’s done a lot work 🙂
Re: Beerconf October 2022
On Sunday, 30 October 2022 at 01:50:33 UTC, Steven Schveighoffer wrote: On 10/29/22 2:00 PM, FeepingCreature wrote: On Saturday, 29 October 2022 at 10:14:31 UTC, rikki cattermole wrote: And now for some good news! Its almost Halloween, so grab your candy and any spooky brews you may have, and join us for a ghostly chat! https://meet.jit.si/Dlang2022OctoberBeerConf I wish you'd announce the time a bit in advance. :) I don't want to announce a time, because I don't know what time it can be started. I'm in the US, so I'm usually asleep when it's started. But I do try to announce 2 weeks before and then 2 days before. -Steve Quiet here, I’m around for a couple of hours, come say hi! 👋
Re: Symmetry looking for D programmers in Singapore/Hong Kong/Australia/New Zealand
On Wednesday, 16 June 2021 at 17:13:35 UTC, russhy wrote: For what kind of project? need more info It might help to look at https://jobs.symmetryinvestments.dev/ and https://github.com/symmetryinvestments/
Re: From the D Blog -- Interfacing D with C: Strings Part One
On Monday, 24 May 2021 at 16:16:53 UTC, Steven Schveighoffer wrote: On 5/24/21 10:02 AM, Mike Parker wrote: The latest post in the D and C series dives into the weeds of D and C strings: how they're implemented, when you need to NUL-terminate your D strings and when you don't, and how the storage of literals in memory allows you to avoid NUL termination in one case you might not have considered and another case that you shouldn't rely on but can in practice with the current compilers. There are at least two more posts worth of information to go into on this topic, but everything in this post is enough to cover many use cases of D to C string interop. The blog: https://dlang.org/blog/2021/05/24/interfacing-d-with-c-strings-part-one/ Reddit: https://www.reddit.com/r/programming/comments/njyf76/interfacing_d_with_c_strings_part_one/ Nice article! Note that there is a huge pitfall awaiting you if you use `toStringz`: garbage collection. You may want to amend the article to identify this pitfall. And I'm not talking about requiring `@nogc`, I'm talking about the GC collecting the data while C is still using it. In your example: ```d puts(s1.toStringz()); ``` This leaves a GC-collectible allocation in C land. For `puts`, it's fine, as the data is not used past the call, but in something else that might keep it somewhere not accessible to the GC, you'll want to assign that to a variable that lasts as long as the resource is used. -Steve It’s worse than that, no? If the only reference to GC data isn’t on the stack of a tracked thread, in GC allocated memory or in a tracked root then it can be freed. Even in D: void foo(int* a) { int** b = cast(int**) malloc((int*).sizeof); *b = a; a = null; GC.collect(); **b = 4; // whoops!! } foo(new int); Right? Obviously that collection could be from calling another function (e.g. a callback from C to D code) or from another thread. Or am I missing something?
Re: Printing shortest decimal form of floating point number with Mir
On Monday, 4 January 2021 at 17:22:55 UTC, John Colvin wrote: On Monday, 4 January 2021 at 13:47:17 UTC, Ola Fosheim Grøstad wrote: [...] I have a longer reply I'm trying to write, but just to make sure I'm on the right track: template Foo(T) { alias Foo = T; } template Q(A : Foo!T, T) { pragma(msg, A.stringof, " ", T.stringof); } alias X = Q!(Foo!int); in your opinion, this should compile and msg `int int`, yes? I'm trying to make a really concise example without using IFTI. and presumably the same for alias X = Q!(int); yes?
Re: Printing shortest decimal form of floating point number with Mir
On Monday, 4 January 2021 at 13:47:17 UTC, Ola Fosheim Grøstad wrote: On Monday, 4 January 2021 at 12:35:12 UTC, John Colvin wrote: What's the simplest example that doesn't work and is that simple example just indirection through an alias or is it actually indirection through a template that *when instantiated* turns out to be just an alias? Indirection through a parametric alias. This is the simplest I have come up with so far: struct Foo(T) {} alias Bar(T) = Foo!T; void f(T)(Bar!T x) {} void main() { f(Bar!int()); } I created a thread for it: https://forum.dlang.org/post/nxrfrizqdmhzhivxp...@forum.dlang.org I have a suspicion that what you're asking for here is the type-inference to have x-ray vision in to uninstantiated templates that works for a few simple cases. Am I wrong? No, just substitute: "Bar!int" with "Foo!int". To be clear, a really useful special case can be really useful and worthwhile, but I'm not convinced this is the principled "type system bug" you are saying it is. Why are you not convinced? An alias is a short hand. If it is possible to discriminate by the alias and the actual object then that it a semantic problem. I have a longer reply I'm trying to write, but just to make sure I'm on the right track: template Foo(T) { alias Foo = T; } template Q(A : Foo!T, T) { pragma(msg, A.stringof, " ", T.stringof); } alias X = Q!(Foo!int); in your opinion, this should compile and msg `int int`, yes? I'm trying to make a really concise example without using IFTI.
Re: Printing shortest decimal form of floating point number with Mir
On Monday, 4 January 2021 at 09:21:02 UTC, Ola Fosheim Grøstad wrote: On Monday, 4 January 2021 at 09:18:50 UTC, Ola Fosheim Grøstad wrote: On Monday, 4 January 2021 at 05:55:37 UTC, Ola Fosheim Grostad wrote: On Monday, 4 January 2021 at 04:37:22 UTC, 9il wrote: I suppose the answer would be that D doesn't pretend to support all C++ template features and the bug is not a bug because we live with this somehow for years. But it is a bug even if there was no C++... An alias should work by simple substitution, if it does not, then it is no alias... Here is an even simpler example that does not work: struct Foo(T){} void foo(T)(T!int x) {} alias FooInt = Foo!int; void main() { foo(FooInt()); } Oh, now wait, it does: struct Foo(T){} void foo(alias T)(T!int x) {} alias FooInt = Foo!int; void main() { foo(FooInt()); } My mistake. What's the simplest example that doesn't work and is that simple example just indirection through an alias or is it actually indirection through a template that *when instantiated* turns out to be just an alias? I have a suspicion that what you're asking for here is the type-inference to have x-ray vision in to uninstantiated templates that works for a few simple cases. Am I wrong? To be clear, a really useful special case can be really useful and worthwhile, but I'm not convinced this is the principled "type system bug" you are saying it is.
Re: Printing shortest decimal form of floating point number with Mir
On Thursday, 24 December 2020 at 14:14:33 UTC, 9il wrote: On Thursday, 24 December 2020 at 14:08:32 UTC, welkam wrote: On Wednesday, 23 December 2020 at 18:05:40 UTC, 9il wrote: It was a mockery executed by Atila Read the all comments and didnt saw any mockery Yes, it wasn't explicit. He didn't write bad words, he did a bad decision. Bad for D. Big difference between bad decision and mockery. It's very possible he was wrong, but I don't think he wasn't taking it seriously.
Re: MIR vs. Numpy
On Wednesday, 18 November 2020 at 13:01:42 UTC, Bastiaan Veelo wrote: On Wednesday, 18 November 2020 at 10:05:06 UTC, Tobias Schmidt wrote: Dear all, to compare MIR and Numpy in the HPC context, we implemented a multigrid solver in Python using Numpy and in D using Mir and perforemd some benchmarks with them. You can find our code and results here: https://github.com/typohnebild/numpy-vs-mir Nice numbers. I’m not a Python guy but I was under the impression that Numpy actually is written in C, so that when you benchmark Numpy you’re mostly benchmarking C, not Python. Therefore I had expected the Numpy performance to be much closer to D’s. An important factor I think, which I’m not sure you have discussed (didn’t look too closely), is the compiler backend that was used to compile D and Numpy. Then again, as a user one is mostly interested in the out-of-the-box performance, which this seems to be a good measure of. — Bastiaan. A lot of numpy is in C, C++, fortran, asm etc But when you chain a bunch of things together, you are going via python. The language boundary (and python being slow) means that internal iteration in native code is a requirement for performance, which leads to eager allocation for composability via python, which then hurts performance. Numpy makes a very good effort, but is always constrained by this. Clever schemes with laziness where operations in python are actually just composing operations for execution later/on-demand can work as an alternative, but a) that's hard and b) even if you can completely avoid calling back in to python during iteration you would still need JIT to really unlock the performance. Julia fixes this by having all/most in one language which is JIT'd D can do the same with templates AOT, like C++/Eigen does but more flexible and less terrifying code. That's (one part of) what mir provides.
Highlight general point about software dev and design in general.
On Tuesday, 20 October 2020 at 21:58:16 UTC, Johan Engelen wrote: On Tuesday, 20 October 2020 at 20:21:56 UTC, aberba wrote: On Tuesday, 20 October 2020 at 17:36:11 UTC, kinke wrote: On Tuesday, 20 October 2020 at 16:08:47 UTC, aberba wrote: It's an option but doesn't fill the need for an installer. Not sure why its hasn't been done. See https://github.com/ldc-developers/ldc/issues/1754. From the discussions, it seems you still don't see the value of an installer...backing it with the idea that LDC is for "developers". I'm a developer myself and I use installers all the time when on Windows...there are very few people I personally know who would go for an archive file to set it up themselves. So not everyone is like you. The reason why I personally go for DMD over LDC is convenience (especially when introducing D to newbies)...even though LDC is more optimized for performance. Unless what you guys are doing is an artificial barrier to get others to not use it. Guys, all points have been made, there is no wrong and right here, let's stop arguing over this. What is needed is someone who thinks it is useful to have an exe installer and wants to do the work. It cannot be done by someone who thinks it is not useful, because there are decisions to be made (like which folder to install it in, whether to overwrite old or not), that can only be made by someone who actually cares about it. There is no point in trying to convince kinke or me. I'm sure noone will be against uploading the installer exe onto github release page once it's been made and checked. -Johan Johan hits an important nail right on the head here. While it is possible to design for others who are unlike you, it's much harder than designing for yourself or those who have similar values and priorities w.r.t. the thing in question. A lot of talk about "we (and by we I mean you) should do this thing I think is important" isn't pushing in the most productive direction, because _*_*_{ even if one becomes convinced that there is value in something, that does not mean one has the relevant understanding necessary for good design of that thing }_*_*_ Either the person with the problem works on understanding the tools to fix the problem, or the person with the tools works on understanding the problem. When values and "user experience" and "ease of use" are in play, I think the latter usually gets harder than normal, because understanding what will be easy or pleasing for others who are unlike us is not something everyone is good at.* This shifts the balance towards preferring the former approach where the person with the problem works towards doing at least a significant part of the design.** There will always be other considerations of course, this is just one force out of many. This is not to say that developers shouldn't be thoughtful about their users - they definitely should be - but that doing a good job of that when the users are unlike the developer is _hard_. * Perhaps in practice that ability is negatively associated with a strong sense of personal taste, e.g. great musicians writing the music _they_ want, not trying to specifically please people; the magic isn't that they understand other people, it's that their particular tastes resonate with others strongly. Maybe truly great mass-market businesses come from people who both have that magic _and_ a strong ability to experience their work from other's perspectives, the combination being rare and the ability to integrate the two effectively being even rarer (Steve Jobs comes to mind). ** Design and implementation often don't separate very cleanly in practice, so this probably means implementing it too, at least to proof-of-concept quality.
Re: Beta 2.094.0
On Friday, 18 September 2020 at 13:35:34 UTC, Jacob Carlborg wrote: On 2020-09-17 12:10, John Colvin wrote: I personally think it's not so bad as long as the commit gets written to the dub.selections.json It doesn't. I know. But it should be. But then again a lot of things “should be” with dub.
Re: Beta 2.094.0
On Wednesday, 16 September 2020 at 18:52:23 UTC, Jacob Carlborg wrote: On 2020-09-16 19:20, mw wrote: Why it's deprecated? can we revive it? It was deprecated because it's a bad idea to not lock versions. Using `~master` would fetch the latest code from the "master" branch when compiling. You never know which version you get. You don't get reproducible builds. I personally think it's not so bad as long as the commit gets written to the dub.selections.json
Re: Decimal string to floating point conversion with correct half-to-even rounding
On Tuesday, 7 July 2020 at 15:08:33 UTC, Adam D. Ruppe wrote: On Tuesday, 7 July 2020 at 13:00:04 UTC, Steven Schveighoffer wrote: Doing that these days would be silly. You can depend on a specific version of a repository without problems. I always have problems when trying to do that. git submodules bring pretty consistent pain in my experience. But it probably isn't so bad if the submodule rarely changes. Just for 100% control anyway nothing beats copy/paste. Then there's zero difference between you writing it yourself. I kinda wish the D upstream were more willing to do that. My view is it shouldn't be on independent developers to add stuff to Phobos, for example, instead the Phobos team should just be copying and testing modules they are interested in on their own. git subtree it's like submodules but also like copy-paste.
Re: Rationale for accepting DIP 1028 as is
On Wednesday, 27 May 2020 at 05:49:49 UTC, Walter Bright wrote: On 5/26/2020 9:31 AM, Bruce Carneal wrote: Currently a machine checked @safe function calling an unannotated extern C routine will error out during compilation. This is great as the C routine was not machine checked, and generally can not be checked. Post 1028, IIUC, the compilation will go through without complaint. This seems quite clear. What am I missing? Nothing at all. But I doubt there is much legacy non-compiling code around. The point isn't that incorrect legacy code that didn't compile now does (although that does matter a bit), it's that newly written code will compile when it shouldn't. Existing code will be full of extern(C) declarations that are implicitly and correctly @system now and will become @safe with dip1028, which means that when I write new @safe code calling those (could be through a deep dependency chain of inferred-@safety APIs, multiple dub packages...) I could easily find my new code compiling when it shouldn't. Effectively, by silently @safe-ing things you can't infer, you will be changing APIs from @system to @trusted without any checks. Just in case there's any confusion, here's a timeline: 1. library A is written containing a dangerous but useful extern(C) declaration assuming @system by default. 2. application B is written for and compiled with dip1028, @safe: at the top of every file. 3. B adds a dependency on A. It continues to compile as @safe, calling an unsafe C function. This seems like one of those things where it's either wrong or a showstopper.
Re: Luneta: terminal fuzzy finder
On Tuesday, 5 May 2020 at 07:31:18 UTC, Panke wrote: On Monday, 4 May 2020 at 22:49:49 UTC, Felipe wrote: Hi, I develop an interactive terminal fuzzy finder in D with ncurses. Feel free to check it out and contribute. Any feedback is welcome. Thanks, Felipe [1] https://github.com/fbeline/luneta [2] https://code.dlang.org/packages/luneta [3] https://code.dlang.org/packages/fuzzyd What's the difference to fzf? Seems like this is being discussed here: https://github.com/fbeline/luneta/issues/28
Re: dmdcache
On Saturday, 25 April 2020 at 10:17:50 UTC, Ali Çehreli wrote: A colleague of mine has written dmdcache which may be very useful for some projects: https://github.com/seeraven/dmdcache It drops our build time from 8 minutes to 45 seconds on a particular build environment for about half a dozen D programs, one of which ends up being a 2G executable! WAT! :) And the total cache size is 5.5G. Wow! This build is with dmd 2.084.1 and that one particular application uses tons of template instantiations most of which are in generated source code. If I remember correctly, 2.084.1 does not contain template symbol name improvements and that may be the reason for the large size. Enjoy! Ali Perhaps I'm being very dumb, but how does this differ from just using make?
Re: DConf 2019 Pictures
On Tuesday, 7 January 2020 at 13:37:24 UTC, Ethan wrote: On Tuesday, 7 January 2020 at 09:04:04 UTC, Ali Çehreli wrote: This one is Laeeth introducing Andrei at Symmetry Investments: http://acehreli.org/photo/dconf_2019/DSC04839.html Ali And if you start here you get to the important bits: BeerConf! http://acehreli.org/photo/dconf_2019/DSC04853.html Damn... I miss beerconf.
Re: code.dlang.org downtime
On Wednesday, 18 December 2019 at 10:18:03 UTC, Sebastiaan Koppe wrote: On Wednesday, 18 December 2019 at 09:29:50 UTC, John Colvin wrote: This is still down for me, regardless of using the IP or address. I don't think it's just me either: https://stats.uptimerobot.com/6mQX4Crw2L/783838659 Anytime you see the metadata working you can add `--registry=https://dub.bytecraft.nl` to dub. I am really tempted to cache the metadata as well. Although that brings up the question of how to purge it when new versions are released. (I could setup a job to import the dump every now and then, hmm). This stuff just begs to be fixed. can't get metadata, so no good right now.
Re: code.dlang.org downtime
On Monday, 16 December 2019 at 11:04:38 UTC, Sönke Ludwig wrote: As you may have already noticed, the main registry server, code.dlang.org got unreachable yesterday. This was caused by an old VPS of mine getting terminated. The registry had already moved to a different server years ago, but, without me realizing it, the DNS entry still pointed to the old one, with a "temporary" HTTP proxy forwarding to the new server being set up. By now the DNS entry has been corrected, an up-to-date TLS certificate is in place, and the registry is running stable. There are still reports of people not being able to access code.dlang.org, which is apparently caused by intermediate DNS servers still reporting the old IP address and should start working during the next few hours. A temporary workaround is to specify --registry=http://31.15.67.41/ on the dub command line. Unfortunately both fallback servers have been down for a while now, so that this resulted in a total blackout. I plan to move the main registry to a powerful dedicated server in January, which will fix all memory resource related issues that sometimes show up, and could then keep the current VPS as a relatively reliable fallback server. Both together should guarantee virtually 100% uptime, although more fallback servers are of course highly desirable. In addition to that, I plan to separate the repository polling process form the web and REST frontend, as the former appears to be the main cause for failures (a GC memory leak of some kind and a possibly codegen related crash when being compiled with DMD being the two known issues, which both need further investigation). This is still down for me, regardless of using the IP or address. I don't think it's just me either: https://stats.uptimerobot.com/6mQX4Crw2L/783838659
Re: bolts meta programming library version 1.0.0 - including the from idiom
On Tuesday, 16 July 2019 at 18:18:50 UTC, Atila Neves wrote: On Tuesday, 16 July 2019 at 00:10:19 UTC, Aliak wrote: On Monday, 15 July 2019 at 21:20:16 UTC, Atila Neves wrote: On Monday, 15 July 2019 at 11:13:10 UTC, aliak wrote: I've been using a set of meta tools for a while now, so decided to release it as 1.0.0 with a few enhancements chucked on. [...] Nice! I'm working on something similar but with a different goal. Thanks! How’s the thing similar and what’s the goal (if you don’t mind me asking)? Similar: One-stop shop for reflection unifying the disparate APIs. Goal: allow "regular" code for reflection purposes by (also) returning everything as strings. Is this related to the talk Andrei gave at a recent dconf?
Re: Dpp on run.dlang.io
On Saturday, 4 August 2018 at 01:27:49 UTC, Laeeth Isharc wrote: Thanks to Seb and Atila it is now very easy to show a D program just #includeing C headers. If just works. Modulo bugs. In time I am hopeful Atila will start to have more of C++ headers working too. https://run.dlang.io/is/JlH3Th Very cool. It seems like it's on by default with no option to turn it off. Is that a good idea? Also, it appears to have broken for me in the last couple of minutes. It worked initially, then I clicked the link again and ran it, got: Error: Could not execute `dmd onlineapp.d -ofonlineapp`: onlineapp.d(49): Error: no identifier for declarator `typedef` onlineapp.d(49): Error: semicolon expected, not `int` onlineapp.d(53): Error: semicolon expected, not `char` onlineapp.d(54): Error: semicolon expected, not `short` onlineapp.d(54): Error: no identifier for declarator `short` onlineapp.d(55): Error: semicolon expected, not `int` onlineapp.d(56): Error: semicolon expected, not `long` onlineapp.d(56): Error: no identifier for declarator `long` onlineapp.d(59): Error: semicolon expected, not `char` onlineapp.d(60): Error: semicolon expected, not `char` onlineapp.d(61): Error: semicolon expected, not `short` onlineapp.d(61): Error: no identifier for declarator `short` onlineapp.d(62): Error: semicolon expected, not `short` onlineapp.d(62): Error: no identifier for declarator `short` onlineapp.d(63): Error: semicolon expected, not `int` onlineapp.d(64): Error: semicolon expected, not `int` onlineapp.d(66): Error: semicolon expected, not `long` onlineapp.d(66): Error: no identifier for declarator `long` onlineapp.d(67): Error: semicolon expected, not `long` onlineapp.d(67): Error: no identifier for declarator `long` Program exited with code 1
Re: Bolts 0.4 meta programming library
On Thursday, 2 August 2018 at 08:40:55 UTC, John Colvin wrote: On Thursday, 2 August 2018 at 07:47:19 UTC, aliak wrote: Hi, just a release of a meta programming library (https://bolts.dub.pm) that has utilities that I use in personal projects, and that I find in phobos, and or in the forums. A notable difference is that functions here try to operate on any compile time entities if they can be resolved. I.e.: int i; void g0(int) {} struct S { void g1(int) {} } alias g2 = (int a) => a; static assert(isFunctionOver!(g0, int)); static assert(isFunctionOver!(S.g1, 3)); static assert(isFunctionOver!(g2, i)); And there's a "doth" super template that tries to contain most things under what I feel is a nicer api ("is" was taken, so i looked to Shakespearian gibberish :p) and also allows for easier use with meta functions: E.g.: int *pi = null; static assert( doth!3.of!int); static assert(!doth!pi.nullable); static assert( doth!((a, b, c, d) => a).functionOver!(int, int, int, int)); int i; import std.meta: allSatisfy; static assert(allSatisfy!(doth!int.of, 3, 4, int, i)); Here's an example of a gem adapted from inside the forms/phobos sources as well: alias a = AliasPack!(1, 2, 3); alias b = AliasPack!(4, 5, 6); alias c = AliasPack!(7, 8, 9); alias d = staticZip!(a, b, c); static assert(d.length == 3); static assert(d.Unpack[0].equals!(1, 4, 7)); static assert(d.Unpack[1].equals!(2, 5, 8)); static assert(d.Unpack[2].equals!(3, 6, 9)) static assert(AliasPack!(d.UnpackDeep).equals!(1, 4, 7, 2, 5, 8, 3, 6, 9)); Cheers, - Ali This looks cool. Lots of things that lots of people have reimplemented lots of times over the years, but all in one place and documented. 2 points: 1) Are you aware of this: https://github.com/dlang/phobos/blob/master/std/meta.d ? I think if a bunch of good motivating examples are given, making this public would be possible. Then everyone would be using the same one and your library would truly just be utilities. woops, pressed send too early: 2) I don't think "doth" is synonymous with "is" how you're using it. "doth" is for doing, e.g. "Methinks he doth protest too much" or "This code doth stink" is OK "Green doth a colour" or "strstr doth a function" is not OK.
Re: Bolts 0.4 meta programming library
On Thursday, 2 August 2018 at 07:47:19 UTC, aliak wrote: Hi, just a release of a meta programming library (https://bolts.dub.pm) that has utilities that I use in personal projects, and that I find in phobos, and or in the forums. A notable difference is that functions here try to operate on any compile time entities if they can be resolved. I.e.: int i; void g0(int) {} struct S { void g1(int) {} } alias g2 = (int a) => a; static assert(isFunctionOver!(g0, int)); static assert(isFunctionOver!(S.g1, 3)); static assert(isFunctionOver!(g2, i)); And there's a "doth" super template that tries to contain most things under what I feel is a nicer api ("is" was taken, so i looked to Shakespearian gibberish :p) and also allows for easier use with meta functions: E.g.: int *pi = null; static assert( doth!3.of!int); static assert(!doth!pi.nullable); static assert( doth!((a, b, c, d) => a).functionOver!(int, int, int, int)); int i; import std.meta: allSatisfy; static assert(allSatisfy!(doth!int.of, 3, 4, int, i)); Here's an example of a gem adapted from inside the forms/phobos sources as well: alias a = AliasPack!(1, 2, 3); alias b = AliasPack!(4, 5, 6); alias c = AliasPack!(7, 8, 9); alias d = staticZip!(a, b, c); static assert(d.length == 3); static assert(d.Unpack[0].equals!(1, 4, 7)); static assert(d.Unpack[1].equals!(2, 5, 8)); static assert(d.Unpack[2].equals!(3, 6, 9)) static assert(AliasPack!(d.UnpackDeep).equals!(1, 4, 7, 2, 5, 8, 3, 6, 9)); Cheers, - Ali This looks cool. Lots of things that lots of people have reimplemented lots of times over the years, but all in one place and documented. 2 points: 1) Are you aware of this: https://github.com/dlang/phobos/blob/master/std/meta.d ? I think if a bunch of good motivating examples are given, making this public would be possible. Then everyone would be using the same one and your library would truly just be utilities.
Re: #include C headers in D code
On Wednesday, 11 April 2018 at 18:36:56 UTC, Walter Bright wrote: On 4/11/2018 3:25 AM, Atila Neves wrote: I did the best I could having seen some macros. It's likely there are cases I've missed, or that maybe the translation in the link above doesn't work even for what it's supposed to be doing (I have no confidence about catching all the C casts for instance). If there are other cases, I'll fix them as they're encountered. It's possible some of them can't be fixed and the user will have to work around them. Right now I have a feeling it will probably be ok. Time will tell (assuming I have users!). That's right. There is no general solution. One can only look for common patterns and do those. For example, #define X 15 is a common pattern and can be reliably rewritten as: enum X = 15; If I understand it correctly, dpp doesn't do that. Instead, it runs the pre-processor on the source code, just like in C, so // test.dpp #define X 15 int foo() { return X; } becomes // test.d int foo() { return 15; } The upside of this approach: all macros just work, unless they use C (not C pre-processor, C proper) features that dpp can't handle. `sizeof(...)` is a special case that is handled in dpp.cursor.macro.translateToD and more could be added. The downside: macros can't be directly used outside .dpp files.
Homebrew dmd betas
On Saturday, 7 April 2018 at 18:39:12 UTC, Martin Nowak wrote: First beta for the 2.079.1 patch release. Comes with a handful of fixes. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.079.1.html Please report any bugs at https://issues.dlang.org - -Martin Available now on homebrew :) I try to keep homebrew up to date with the latest betas, but the stats show that almost no-one ever downloads them, despite reasonable numbers getting the stable version. See for example https://github.com/Homebrew/homebrew-core/pull/24348#issuecomment-367021918 . I will continue to keep adding the betas for my own use anyway, but please, PLEASE, install the betas and test them, it's so simple, just `brew upgrade dmd --devel`. You can then switch freely between the beta and the stable versions with `brew switch dmd 2.079.0`, `brew switch dmd 2.079.1-beta.1`. To inspect what versions you have installed, `brew info dmd`. To uninstall specific versions, `brew switch` to the relevant version then run `brew uninstall dmd`. The same steps apply for any other betas on homebrew. I try to keep dmd, dub, ldc, dfix, dfmt and dcd up to date. If I'm late updating something, you can try nagging me or you can DIY, take a look at https://github.com/Homebrew/homebrew-core/pulls?utf8=%E2%9C%93&q=is%3Apr+dmd for examples of how to submit the update yourself.
Re: LDC 1.7.0
On Saturday, 6 January 2018 at 16:25:46 UTC, German Diago wrote: - want no gc? Ok, at least there is BetterC, so if I invest myself quite a bit on D (I am the kind of programmer that likes to squeeze power out of machines, so this always means that I will not consider VM languages), I will always have. Also, it's perfectly possible to avoid most of the downsides of the GC (and keep some of the upsides) without worrying about BetterC. @nogc where you need it is great, BetterC is a much more extreme solution.
Re: Hong Kong dlang Meetup
On Monday, 4 September 2017 at 19:25:59 UTC, Jonathan M Davis wrote: Several of us from the D community will be in Hong Kong on a business trip next week (me, John Colvin, Atila Neves, and Ilya Yaroshenko), and our client, Symmetry Investments[1], has offered to sponsor a dlang meetup. We haven't decided when exactly to meet up yet, but we're looking to meet up sometime during the week of the 11th - 15th (probably on Thursday or Friday evening) and figured that we should see if anyone here was interested in showing up and would thus have some stake in when during the week it happened. The current plan is that the meetup will take place at Symmetry's main office in Chater House in Central Hong Kong. - Jonathan M Davis [1] http://symmetryinvestments.com/about-us/ Some open source dlang stuff whose developement was paid for by Symmetry: https://github.com/kaleidicassociates Of note is https://github.com/kaleidicassociates/excel-d which Atila talked about at dconf this year. We have a date and time: https://www.meetup.com//Dlang-Hong-Kong/events/243198527/?showDescription=true Sorry to those who can't make it, we really wanted to make it after the Codeaholics meetup
Re: Hong Kong dlang Meetup
On Wednesday, 6 September 2017 at 00:48:07 UTC, Lionello Lunesu wrote: Let's occupy codeaholics: https://www.meetup.com/Codeaholics/events/242640432/ Good idea. I'll be there :)
Re: D as a Better C
On Wednesday, 23 August 2017 at 13:12:04 UTC, Mike Parker wrote: To coincide with the improvements to -betterC in the upcoming DMD 2.076, Walter has published a new article on the D blog about what it is and why to use it. A fun read. And I'm personally happy to see the love this feature is getting. I have a project I'd like to use it with if I can ever make the time for it! The blog: https://dlang.org/blog/2017/08/23/d-as-a-better-c/ Reddit: https://www.reddit.com/r/programming/comments/6viswu/d_as_a_better_c/ "D polymorphic classes will not, as they rely on the garbage collector." They do? Don't have to allocate classes on the GC heap.
Re: Boston D Meetup: Strawman Structs
On Sunday, 2 July 2017 at 10:35:49 UTC, Steven Schveighoffer wrote: I'll have a short presentation on a weird trick I discovered while writing some MySQL serialization code. Hope you can attend! https://www.eventbrite.com/e/d-lang-presentation-strawman-structs-tickets-35120523431 -Steve Is there a written summary of the idea? Or is there a specific point in the video someone could point me to?
Re: DCompute: GPGPU with Native D for OpenCL and CUDA
On Tuesday, 18 July 2017 at 00:49:11 UTC, Nicholas Wilson wrote: On Monday, 17 July 2017 at 13:50:22 UTC, Mike Parker wrote: Nicholas Wilson has put together a blog post on his progress with DCompute, expanding on his DConf talk. I have to admit that this is one of the D projects I'm most excited about, even though I'll probably never have a need to use it. I'd love to find an excuse to do so, though! Blog: https://dlang.org/blog/2017/07/17/dcompute-gpgpu-with-native-d-for-opencl-and-cuda/ Reddit: https://www.reddit.com/r/programming/comments/6nt4ba/dcompute_gpgpu_with_native_d_for_opencl_and_cuda/ Thanks for that. Oh and @JohnColvin do you like the solution for the lambdas? I do, very nice :) You're essentially achieving what I set out to do and got stuck with, just much better.
Re: static foreach is now in github master
On Monday, 17 July 2017 at 18:14:35 UTC, Andrei Alexandrescu wrote: For those who want to play with our new static foreach feature and are willing to take the steps to building their own dmd, the feature is now merged in master: https://github.com/dlang/dmd/pull/6760 Happy hacking! Andrei or for those using homebrew: `brew install dmd --HEAD`
Re: Faster Command Line Tools in D
On Friday, 26 May 2017 at 14:41:39 UTC, John Colvin wrote: I spent some time fiddling with my own manual approaches to making this as fast, wasn't satisfied and so decided to try using Steven's iopipe (https://github.com/schveiguy/iopipe) instead. Results were excellent. https://gist.github.com/John-Colvin/980b11f2b7a7e23faf8dfb44bd9f1242 This version also has the advantage of being (discounting any bugs in iopipe) correct for arbitrary unicode in all common UTF encodings.
Re: Faster Command Line Tools in D
On Wednesday, 24 May 2017 at 13:39:57 UTC, Mike Parker wrote: Some of you may remember Jon Degenhardt's talk from one of the Silicon Valley D meetups, where he described the performance improvements he saw when he rewrote some of eBay's command line tools in D. He has now put the effort into crafting a blog post on the same topic, where he takes D version of a command-line tool written in Python and incrementally improves its performance. The blog: https://dlang.org/blog/2017/05/24/faster-command-line-tools-in-d/ Reddit: https://www.reddit.com/r/programming/comments/6d25mg/faster_command_line_tools_in_d/ I spent some time fiddling with my own manual approaches to making this as fast, wasn't satisfied and so decided to try using Steven's iopipe (https://github.com/schveiguy/iopipe) instead. Results were excellent. https://gist.github.com/John-Colvin/980b11f2b7a7e23faf8dfb44bd9f1242 On my machine: python takes a little over 20s, pypy wobbles around 3.5s, v1 from the blog takes about 3.9s, v4b took 1.45s, a version of my own that is hideous* manages 0.78s at best, the above version with iopipe hits below 0.67s most runs. Not bad for a process that most people would call "IO-bound" (code for "I don't want to have to write fast code & it's all the disk's fault"). Obviously this version is a bit more code than is ideal, iopipe is currently quite "barebones", but I don't see why with some clever abstractions and wrappers it couldn't be the default thing that one does even for small scripts. *using byChunk and manually managing linesplits over chunks, very nasty.
Re: LDC 1.3.0-beta1 has been released!
On Friday, 5 May 2017 at 10:16:41 UTC, Kai Nacke wrote: Hi everyone, LDC 1.3.0-beta1, the LLVM-based D compiler, is available for download! This release is based on the 2.073.2 frontend and standard library and supports LLVM 3.5-4.0. We provide binaries for Linux, OX X, FreeBSD, Win32 & Win64, now bundled with DUB. :-) It is the first release ever made at DConf. Feedback is highly welcome - just talk to me! As usual, you can find links to the changelog and the binary packages over at digitalmars.D.ldc: http://forum.dlang.org/post/hzdleysafdckzgarp...@forum.dlang.org Regards, Kai available on homebrew: `brew install ldc --devel`
Re: Call for arms: Arch Linux D package maintenance
On Thursday, 16 February 2017 at 19:58:47 UTC, Rory McGuire wrote: Hi, I am planning on asking to become TU for the dlang packages in community. I've been building and working with the current packages and making my own packages to make sure I know what I'm getting in to. LDC and GDC are matched with the system versions of llvm and gcc. If I can get TU approval I will put time in to these packages and hopefully make some Arch tools that use dlang to try and promote it more. To learn makepkg and nampac etc I built this [0], it is a set of PKGBUILD files that are loosely based on the way I use multiple official dmd compilers on my dev box. Some of my customers use older version of Vibe that do not build on current dmd. I actually normally use /usr/local/ and not /usr/lib for my dmd installation. It also has a little utility for switching between compilers versions, similar to archlinux-java. [0]: https://github.com/rjmcguire/archlinux-dmd Any news on this? The arch packages are listed as orphaned.
Re: vibe.d 0.8.0 and 0.7.31 beta releases
On Thursday, 9 February 2017 at 19:40:45 UTC, Sönke Ludwig wrote: Am 09.02.2017 um 18:00 schrieb Kagamin: On Wednesday, 8 February 2017 at 15:18:34 UTC, Sönke Ludwig wrote: The problem is that there are two affected call stacks - the @system API function that registers the @system callback, wrapping/casting it as @trusted, and the event handler that later on actually calls the callback. The latter place is where the hidden violation of the @safe guarantees happens. Hidden from whom? Since it's user, who supplies @system code to vibe, he knows that the resulting program doesn't provide @safe guarantees. It can be communicated at the API level: int f(@safe void delegate() dg) @safe { code } int f(@system void delegate() dg) @system { return f(cast(@safe void delegate())dg); } So that unsafe overload would be only callable from unsafe code. Hidden from the code that calls the callback. This may be an acceptable trade off in this particular case, because this is crossing a library border, but in general this is just misuse of the safety system, since the effects of the cast leave the scope of @system/@trusted. I don't know, I don't really like this, but maybe I should just postpone the `deprecated` attribute to be added for 0.8.1 to leave more room for a final decision. Just ran in to this trying to update a large project to 0.7.31-rc.2. The change to HTTPServerRequestDelegate breaks code where we have @system callbacks that it would not be sensible to make @trusted at the moment. What can we do?
Re: Update on Unums
On Monday, 13 March 2017 at 15:08:56 UTC, H. S. Teoh wrote: On Mon, Mar 13, 2017 at 08:32:04AM +, Nick B via Digitalmars-d-announce wrote: If I get the approval to post Johns latest presentation, I will do so. [...] Link? urmm...
Re: New (page-per-artifact) standard library doc examples are now editable and runnable
On Friday, 17 February 2017 at 05:06:20 UTC, Seb wrote: On Saturday, 7 January 2017 at 16:12:49 UTC, Andrei Alexandrescu wrote: Following https://github.com/dlang/dlang.org/pull/1532, the new-style docs now also allow editing and running examples. Start at http://dlang.org/library-prerelease/ and go anywhere to check it out. Thanks are due to Sönke Ludwig and Sebastian Wilzbach! Andrei Short follow-up: this is now live for the released documentation pages. Enjoy! Ddoc: https://dlang.org/phobos/std_algorithm_comparison.html#among Ddox: https://dlang.org/library/std/algorithm/comparison/among.html Your feedback is of course welcome. A couple of modules are still blacklisted, but it's WIP to remove the blacklist [1]. Also as mentioned DPaste [2] is used as Backend. If you want to hack with it directly, you may have a look at [3]. Cheers, Seb [1] https://github.com/dlang/phobos/pull/5142 [2] https://dlang.org/blog/2017/01/30/project-highlight-dpaste/ [3] https://github.com/dlang/dlang.org/blob/master/js/run_examples.js Might I suggest you change the output s to s with border: none; and max-height: 30em; This would make them auto-grow to the right height to fit the content (with max-height for sanity). It does mean you lose manual resizability (unless you mess around in js to sort out the clash with max-height)), but that doesn't seem so important if it auto-resizes.
Re: Questionnaire
On Thursday, 9 February 2017 at 18:34:44 UTC, bachmeier wrote: On Thursday, 9 February 2017 at 17:28:47 UTC, jmh530 wrote: Other stuff I would find useful: 1) R integration (I know someone's done work on this, but it's hard to find and I don't remember if it works on Windows. Really just needs a champion) Me. The latest version is here: https://bitbucket.org/bachmeil/embedr It's Linux-only because that's all I know or use. Others that I work with use it on Windows and OS X trivially with Docker, but for someone that understands development on those OSes, it shouldn't take much to get it working natively. Everything is handled internally by the R package manager, and the package itself has functions to take care of all steps for compilation. I don't promote it because I don't have time to run an open source project properly. However, I am happy to help in any way if someone else wants to use it. I am flexible on the license, so that's not an issue. There's a possibility of some commercial need for R <-> D where I'm working, so hopefully we'll be able to help here.
Re: unDE 0.1.0: original file manager, image and text viewer
On Thursday, 15 December 2016 at 20:16:10 UTC, unDEFER wrote: Hello, my dear friends! So many days you answers on many my questions. And today I glad to present my work: unDE 0.1.0. It is very original file manager, image and text viewer. More information: http://unde.sourceforge.net/en/ch24.html Video with English subtitles: https://youtu.be/29zuxU9eyXo This looks like a very interesting project. I have had similar ideas recently but haven't had time to do anything. I'm looking forward to seeing what you create.
Re: Milestone - DMD front end is now 100% D!
On Thursday, 15 December 2016 at 19:58:50 UTC, Iain Buclaw wrote: This will be the direction that I anticipate to head in until a time comes where the frontend exposes everything GDC depends upon in order to bootstrap to the latest stable branch. Is there a good list of what is necessary somewhere publicly visible?
Re: Boston D Language Meetup in Back Bay
On Thursday, 17 November 2016 at 16:28:08 UTC, Steven Schveighoffer wrote: On 11/17/16 10:38 AM, John Colvin wrote: On Thursday, 17 November 2016 at 13:59:25 UTC, Steven Schveighoffer wrote: [...] Can't you use a template lambda alias argument to pushTo instead, so then you can instantiate it inside pushTo? something like nullStream!char .bufferedInput .pushTo!(_ => _ .arrayCastPipe!ubyte .outputFile("output.txt") ); maybe? I could do that. But I don't like it ;) I don't think it's so bad, but fair enough I will note that Adrian Matoga's flod library has a different solution that I think is similar to this, but I don't understand it very well. I'm also concerned that using a lambda is going to confuse or prevent optimization. Why would you think that? If we can't trust the optimiser (dmd aside) to inline a template lambda argument then phobos is totally screwed! I think with some better naming, the push feature will look better. -Steve I look forward to it.
Re: Boston D Language Meetup in Back Bay
On Thursday, 17 November 2016 at 13:59:25 UTC, Steven Schveighoffer wrote: nullStream!char .bufferedInput .pushTo( arrayCastPipe!ubyte .outputFile("output.txt") ); But then the parameters to the "pushTo" hypothetical function don't know what the source type is before calling. By inserting valves, I get the equivalent thing, but the types all are passed down the chain properly. Can't you use a template lambda alias argument to pushTo instead, so then you can instantiate it inside pushTo? something like nullStream!char .bufferedInput .pushTo!(_ => _ .arrayCastPipe!ubyte .outputFile("output.txt") ); maybe?
Re: Formal review of DIP1002
On Thursday, 17 November 2016 at 11:37:09 UTC, Dicebot wrote: Disposition: REJECT. A proposal for a similar or identical feature would need to be include qualitatively new motivation/evidence of usefulness. Please follow the link for the full review text / rationale: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1002.md#review Regardless of the outcome, I just want to commend whoever wrote the rejection text* on doing such a clear and comprehensive job. I'm sure it must be disappointing for a DIP author to have it rejected, but detailed, constructive criticism like this would - for me at least - make the experience worthwhile and encourage further contributions of higher quality. * I see dicebot committed, but I'm presuming Walter &| Andrei had a lot of input and I think i detect recent exposure to the academic review process...
Re: Release D 2.072.0
On Saturday, 5 November 2016 at 04:04:12 UTC, Soulsbane wrote: On Monday, 31 October 2016 at 01:27:08 UTC, Martin Nowak wrote: [...] I've run into a problem with code using ctRegex that fails to compile only in release build. [...] please report at https://issues.dlang.org/
Re: Release vibe.d 0.7.30
On Tuesday, 1 November 2016 at 12:47:13 UTC, Jacob Carlborg wrote: On 2016-11-01 12:20, Saurabh Das wrote: How can I find out more information about the 'runApplication' change? What does "slowly fading out" mean? I think it should say something like: "slowly fading out the default main". Instead of having vibe.d define the main function and having a shared module constructor with all the setup, you can define your own main function with all the setup and then call runApplication, which basically contains the same logic as the main function defined by vibe.d. Is "phasing" the word that's being looked for here? I.e. "slowly phasing out the default main".
Re: Box2D Lite D Port (Yet Another)
On Monday, 31 October 2016 at 13:53:26 UTC, ketmar wrote: On Monday, 31 October 2016 at 13:40:38 UTC, John Colvin wrote: If you could put up with putting each file (or maybe group of files that might form one dub package) in to a separate folder, add a dub.sdl for each folder, put a single dub.sdl in the root folder with all the other folders listed in it as subPackages, then push the whole thing to bitbucket, register on code.dlang.org and you're done? If you really don't like having all those folders you could easily create a script to move everything in to place. Could even be in a git hook! that's not something i'd call "non-intrusive". ;-) I'm not saying it's non-intrusive, I'm suggesting that there might be a way to get what we all want - the code easily accessible for dub users - that might not be *too* intrusive/disruptive for you to put up with. Some sort of compromise in lieu of the perfect solution. If it's really just the bitbucket / github thing then I mean there's such a thing as pushing a principle below its point of zero-benefit, but that's your choice. Hopefully code.dlang.org support for other hosts will come soon.
Re: Box2D Lite D Port (Yet Another)
On Monday, 31 October 2016 at 09:56:09 UTC, ketmar wrote: i investigated the possibility of having IV as collection of DUB projects (again), and it is still too intrusive. alas. actually, i'd like to feature IV as a set of libraries with dependencies on code.dlang.org, so people can easily use 'em, but DUB isn't very tolerant to things that aren't done in "DUB way". i am really saddened by that, but i have no desire to work on DUB, neither to "dubify" my workflow. Are there any specific problems you came across? If you could put up with putting each file (or maybe group of files that might form one dub package) in to a separate folder, add a dub.sdl for each folder, put a single dub.sdl in the root folder with all the other folders listed in it as subPackages, then push the whole thing to bitbucket, register on code.dlang.org and you're done? If you really don't like having all those folders you could easily create a script to move everything in to place. Could even be in a git hook!
Re: Release D 2.072.0
On Monday, 31 October 2016 at 07:24:23 UTC, Sönke Ludwig wrote: Am 31.10.2016 um 02:27 schrieb Martin Nowak: Glad to announce D 2.072.0. http://dlang.org/download.html This is the release ships with the latest version of dub (v1.1.0), comes with lots of phobos additions and native TLS on OSX. See the changelog for more details. http://dlang.org/changelog/2.072.0.html -Martin Hm, looks like DUB 1.1.0 was tagged on master instead of stable, which means that some fixes are missing and some changes haven't gone through a testing phase. Can we still fix this for this release? Martin, have you considered posting each release* here on the newsgroup 24 hours before the actual release, marked "pre-release sanity check" so mistakes like this are more likely to be caught? * and I mean the actual bit-for-bit identical release packages here; this is test-firing the actual rocket that's going to space.
Re: Numerical age for D: Mir v0.18.0 is faster then OpenBLAS
On Friday, 23 September 2016 at 13:25:30 UTC, Ilya Yaroshenko wrote: Mir is LLVM-accelerated Generic Numerical Library for Science and Machine Learning. Benchmark: http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/glas-gemm-benchmark.html Mir v0.18.0 release notes: https://github.com/libmir/mir/releases/tag/v0.18.0 The release includes Mir's D Foundation GSoC project. Do not forget to star the project: https://github.com/libmir/mir Best regards, Ilya Looks excellent. I tested compared to Apple's Accelerate BLAS and got similar results. Environment variables to set single thread for cblas: for openBLAS: OPENBLAS_NUM_THREADS=1 for Accelerate (Apple): VECLIB_MAXIMUM_THREADS=1 for intel MKL: MKL_NUM_THREADS=1
Re: On the future of DIP1000
On Sunday, 21 August 2016 at 21:46:56 UTC, John Colvin wrote: On Sunday, 21 August 2016 at 20:01:27 UTC, Dicebot wrote: - scope is @safe only Why? I might have @system code that could still benefit from scope. I guess it would be too restrictive, but I'm just a bit frustrated at having to choose between lots of compiler checking and none at all. I wish there was a flag for the compiler that would give @safe violations as warnings in @system / @trusted code, it would be too noisy for routine use but it would be great to occasionally look through.
Re: On the future of DIP1000
On Sunday, 21 August 2016 at 20:01:27 UTC, Dicebot wrote: - scope is @safe only Why? I might have @system code that could still benefit from scope.
Re: DIP1000: Scoped Pointers
On Wednesday, 17 August 2016 at 07:53:49 UTC, Mike wrote: Got it! Thank you! But it still appears that what's illustrated on the deprecations page is not being deprecated. Mike I imagine that will change if/when DIP1000 is accepted.
Re: The D Language Foundation has filed for non-profit status
On Thursday, 21 July 2016 at 02:16:55 UTC, Andrei Alexandrescu wrote: By the Foundation bylaws we defined, the officers of the Foundation (Walter, Ali, and myself) are not allowed to receive payment for their work on the Foundation. You can still claim expenses though, no?
Re: pure D JPEG decoder, with progressive JPEG support, public domain
On Friday, 17 June 2016 at 13:05:47 UTC, ketmar wrote: finally, the thing you all waited for years is here! pure D no-frills JPEG decoder with progressive JPEG support! Public Domain! one file! no Phobos or other external dependecies! it even has some DDoc! grab it[1] now while it's hot! [1] http://repo.or.cz/iv.d.git/blob_plain/HEAD:/jpegd.d awesome. Without wanting to start a huge thing about this, see http://linuxmafia.com/faq/Licensing_and_Law/public-domain.html and http://www.rosenlaw.com/lj16.htm and please at least add an optional licencing under a traditional permissive open-source license (boost would be nice, who knows, maybe phobos should have jpeg support?).
Re: Button: A fast, correct, and elegantly simple build system.
On Thursday, 16 June 2016 at 12:32:02 UTC, Kagamin wrote: On Sunday, 12 June 2016 at 20:47:31 UTC, cym13 wrote: Yeah, I have often thought that writing a self-contained D program to build D would work well. The full power of the language would be available, there'd be nothing new to learn, and all you'd need is an existing D compiler (which we already require to build). What about Attila's work with reggae? Reggae still needs a prebuilt reggae to run the build script. But seeing as you need a d compiler to build and anyway...
Re: Button: A fast, correct, and elegantly simple build system.
On Thursday, 16 June 2016 at 12:53:35 UTC, John Colvin wrote: On Thursday, 16 June 2016 at 12:32:02 UTC, Kagamin wrote: On Sunday, 12 June 2016 at 20:47:31 UTC, cym13 wrote: Yeah, I have often thought that writing a self-contained D program to build D would work well. The full power of the language would be available, there'd be nothing new to learn, and all you'd need is an existing D compiler (which we already require to build). What about Attila's work with reggae? Reggae still needs a prebuilt reggae to run the build script. But seeing as you need a d compiler to build and anyway... Ugh, autocorrect. s/and/dmd
Re: Button: A fast, correct, and elegantly simple build system.
On Wednesday, 15 June 2016 at 11:47:00 UTC, Walter Bright wrote: On 6/15/2016 4:07 AM, Edwin van Leeuwen wrote: How about using reggae? https://github.com/atilaneves/phobos/blob/reggae/reggaefile.d I haven't studied either. If you do study that reggae file, remember that it's a deliberate transliteration of the makefile and therefore is a lot more verbose than it *could* be if done from a clean slate or as a proper translation. IIRC it was done to show that reggae could do literally everything the makefile does, in the same way.
Nested comments
On Wednesday, 8 June 2016 at 15:04:28 UTC, Kagamin wrote: BTW do people find nested comments particularly useful? Yes for: A) commenting out a block of code without having to care about syntactic correctness (otherwise version(none)) or whether it contains comments (otherwise /* */) B) code examples inside comments
Re: Reddit announcements
On Tuesday, 31 May 2016 at 18:57:29 UTC, o-genki-desu-ka wrote: Many nice announcements here last week. I put some on reddit. https://www.reddit.com/r/programming/comments/4lwufi/d_embedded_database_v01_released/ https://www.reddit.com/r/programming/comments/4lwubv/c_to_d_converter_based_on_clang/ https://www.reddit.com/r/programming/comments/4lwu5p/coedit_2_ide_update_6_released/ https://www.reddit.com/r/programming/comments/4lwtxw/compiletime_sqlite_for_d_beta_release/ https://www.reddit.com/r/programming/comments/4lwtr0/button_a_fast_correct_and_elegantly_simple_build/ https://www.reddit.com/r/programming/comments/4lwtn9/first_release_of_powernex_an_os_kernel_written_in/ I'm a bit concerned that people will react negatively to them all being dumped at once.
Re: amoeba, a chess engine written in D
On Friday, 20 May 2016 at 23:16:01 UTC, Richard Delorme wrote: I am pleased to announce the release of a chess engine written in D: https://github.com/abulmo/amoeba I am not aware of any other chess engine written with the D language. The source can be compiled with dmd, ldc or gdc, but the best performance are obtained with the latter (almost twice faster). This is my first program using the D language (I am a former C programmer), and I enjoyed it a lot. LDC might benefit from copying the _popcnt source from ldc's druntime in to your code as it has a problem inlining it from druntime. You might also see a benefit from the -single-obj flag (enabled by default in ldmd).
Re: Beta D 2.071.1-b1
On Sunday, 15 May 2016 at 04:40:21 UTC, Martin Nowak wrote: First beta for the 2.071.1 point release. A few issues remain to be fixed before the next beta. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.071.1.html Please report any bugs at https://issues.dlang.org -Martin Github tag / release ?
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 Doesn't affect me too much, so I guess it's ok as long as everyone knows. Might even be worth a big notice on the main conference page?
Re: XDG-APP and D
On Thursday, 21 April 2016 at 18:55:23 UTC, Gerald wrote: For those not familiar, xdg-app is a Linux virtualization system targeted at desktop apps, it's been under pretty heavy development and is available for use in Gnome 3.20. Mathias Clausen recently wrote a blog entry about creating his first xdg-app and the application he chose to play with was Terminix, a terminal emulator, which is written in D. He had some D specific challenges to deal with which may be interesting to others looking to support xdg-app. You can read his blog entry here: https://blogs.gnome.org/mclasen/2016/04/15/my-first-xdg-app. Can someone explain to me how xdg-app provides a significantly different experience to static linking (in a language like C or D)? I guess there's the old "what about libc?".
Re: Release D 2.071.0
On Tuesday, 5 April 2016 at 22:43:05 UTC, Martin Nowak wrote: Glad to announce D 2.071.0. http://dlang.org/download.html This release fixes many long-standing issues with imports and the module system. See the changelog for more details. http://dlang.org/changelog/2.071.0.html -Martin Apologies for the delay for homebrew users, all sorted now, 2.071.0 is now dmd stable.
Re: Beta D 2.071.0-b2
On Wednesday, 30 March 2016 at 16:00:34 UTC, Luís Marques wrote: On Wednesday, 30 March 2016 at 15:48:28 UTC, John Colvin wrote: That would be me. Waiting for merge: https://github.com/Homebrew/homebrew/pull/50539 Thanks! Would it be against the homebrew spirit for the DMD recipe to link to some URL like <...lastest-devel.tar.gz>? After all, that already happens with the --HEAD version, which doesn't link to any specific git commit. That way we wouldn't have to wait for the homebrew merges. There's the issue of the hash, but the --HEAD version doesn't have that either, and https://dlang.org should be trusted. I'm 99.9% certain the Homebrew core devs wouldn't allow something like that.
Re: Beta D 2.071.0-b2
On Wednesday, 30 March 2016 at 13:04:08 UTC, Luís Marques wrote: On Wednesday, 30 March 2016 at 11:03:51 UTC, Martin Nowak wrote: Second beta for the 2.071.0 release. 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 Who maintains the homebrew recipe? The --devel package is still at beta 1. That would be me. Waiting for merge: https://github.com/Homebrew/homebrew/pull/50539
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) As usual, `brew update && brew reinstall dmd --devel` :)
Re: IDE - Coedit 2 rc1
On Monday, 8 February 2016 at 07:25:49 UTC, Dominikus Dittes Scherkl wrote: On Monday, 8 February 2016 at 07:05:15 UTC, Suliman wrote: Cool! Thanks! But do you have any plans to reimplement it from Pascal to В to get it's more native... B? What is B? https://en.wikipedia.org/wiki/B_(programming_language) but obviously he meant D.
Re: Beta D 2.070.0-b2
On Sunday, 17 January 2016 at 20:52:20 UTC, Martin Nowak wrote: Second and last beta for the 2.070.0 release. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.070.0.html Please report any bugs at https://issues.dlang.org -Martin % dmd --version DMD64 D Compiler v2.069 Copyright (c) 1999-2015 by Digital Mars written by Walter Bright should be DMD64 D Compiler v2.070 Copyright (c) 1999-2016 by Digital Mars written by Walter Bright
Re: Official Announcement: 'Learning D' is Released
On Tuesday, 12 January 2016 at 22:00:32 UTC, jmh530 wrote: On Tuesday, 12 January 2016 at 21:10:28 UTC, John Colvin wrote: When you want to have control over the process of loading a library e.g. if you want it to be an optional dependency at runtime. I've seen the example in the book. I'm just not sure why you would want an optional runtime dependency. Anything in your application / library that relies on resources that may or may not be available on the user's system. E.g. plugins the user wants to load.
Re: Official Announcement: 'Learning D' is Released
On Tuesday, 12 January 2016 at 20:32:57 UTC, jmh530 wrote: I'm not sure when you would want to use dynamic bindings. When you want to have control over the process of loading a library e.g. if you want it to be an optional dependency at runtime.
Re: Beta D 2.070.0-b1
On Sunday, 3 January 2016 at 19:24:57 UTC, Martin Nowak wrote: First beta for the 2.070.0 release. Still a few things missing from the changelog, there is a new package std.experimental.ndslice, and native (DWARF based) exception handling on linux. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.070.0.html Please report any bugs at https://issues.dlang.org -Martin Very pleased to say that all of DlangScience worked with this beta, no regressions/breakage.
Re: Better docs for D (WIP)
On Tuesday, 5 January 2016 at 18:34:20 UTC, JohnCK wrote: On Tuesday, 5 January 2016 at 18:09:57 UTC, Andrei Alexandrescu wrote: Is the recent http://wiki.dlang.org/Contributing_to_dlang.org along the lines of what you need? What other sort of documentation would you find useful? I took a look at that link, and you know what would be (at least for me) more useful? A "Let's write a doc example", for example: Creating a sample function and documented it, step by step. I really think that would be many times more useful and you see that pattern a lot not only for docs, but explain things, currently we saw this in another topic about writing a scalable chat using vibe.d! JohnCK. +1 That wiki article is a great reference, but it's pretty daunting when someone just wants to make a small change.
Re: Testing Nightly Build Service
On Friday, 18 December 2015 at 15:42:32 UTC, steven kladitis wrote: On Monday, 14 December 2015 at 08:36:27 UTC, Andrea Fontana wrote: On Saturday, 12 December 2015 at 12:08:50 UTC, Martin Nowak wrote: As you might already know from the last sprint review (http://forum.dlang.org/post/56592679.3010604@dawg.), we've setup a server to build nightlies. The service is still in a test phase but seems to work steadily. You can try it using the install script curl -fsSL https://builds.dawg.eu/install.sh | bash -s dmd-nightly or by simply downloading the latest archive for your platform. https://builds.dawg.eu/dmd-nightly/ That's a good news! It looks lie it is building lots of C code, I thought D was written in 'D' now. Also looks like it is compiling 2.067? The backend is still in C++. 2.067 was fully C++ is probably built for bootstrapping.
Re: DlangUI
On Thursday, 17 December 2015 at 16:12:32 UTC, Vadim Lopatin wrote: On Wednesday, 16 December 2015 at 13:32:21 UTC, Suliman wrote: Is it's possible to use some native frontend with dlangui instead of drawing all controls with OpenGL? I really dislike how all OpenGL toolkit looks like. OpenGL is just hardware acceleration for drawing. Resulting picture is the same for both OpenGL and software rendering. DlangUI will never use native controls. It draws all widgets itself. But look and feel can be changed by providing custom theme. You can create theme (set of .xml and .png files) to get DlangUI app looking exactly like native one. In general I don't care about that sort of thing, but there is one exception: the main application menu. Unity and Aqua (OS X) both end up feeling odd if you don't use the system one.
Re: DConf 2016 news: 20% sold out, book signing
On Monday, 7 December 2015 at 17:39:14 UTC, Andrei Alexandrescu wrote: We're over 20% full and seats are going fast! We planned to send an announcement when we're 50% sold out. However, this time around registrations are coming quite a bit quicker than before so we thought we'd keep you posted earlier. At this time DConf is over 20% sold out. That's only three weeks after opening early bird registration and without having announced the program. (Which, of course, will be great.) The point here is, if you're considering going to DConf, you may want to secure your early bird registration now at http://dconf.org/2016/registration.html. On another vein, we're pleased to announce a book signing session by D book authors. Kai Nacke, Mike Parker, Ali Çehreli, and Andrei Alexandrescu will sign their respective books. Bring your copy (it better be dog-eared) or buy one on site (limited quantities available). Details forthcoming. Looking forward to seeing you at DConf! Andrei Booked now. Looking forward to it :)
Re: Beta D 2.069.2-b2
On Monday, 30 November 2015 at 03:30:02 UTC, Martin Nowak wrote: Second beta for the 2.069.2 point release. New fixes: Bugzilla 15281: std\experimental\allocator\package.d not included in build script http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.069.2.html Please report any bugs at https://issues.dlang.org -Martin Safe to ignore for non-windows, yes?
Re: PowerNex - My 64bit kernel written in D
On Wednesday, 25 November 2015 at 18:06:45 UTC, Wild wrote: On Wednesday, 25 November 2015 at 16:18:56 UTC, Piotrek wrote: Hi, No worries :) Feel free to use whatever license you want. It is your code. However my point was that the code released with license other than Boost (or similar) cannot be included in Phobos. That's one thing. The second is, non liberal licenses put burden on commercial adoption and put risk on legal actions. I know that from the employee POV who worked for many corporations and was obliged to follow the rules. The bottom line is that viral licenses (with varying aggressiveness) are in opposition to business. Yes, I know GPL is used by companies but the cost is high. To use analogy: you can live with viruses, but you need money for medicines. BTW. Sorry if I sounded to harsh and forgive me stealing your announcement for my propaganda ;) I'll try to figure out a way to present my ideas in proper way before I have to many enemies. Piotrek No offense taken. It's important for a project to have a fitting license. I chose MPLv2 because I like the code to be free like BSD, for it to be able to be located in all sorts of project, but I still want the code to remain open source. I will maybe change the license in the future, if needed. But currently I don't see a reason to do it. - Dan For phobos contributions it doesn't really matter what licence the code previously had as long as you can give permission for it to be used, which is easy if you're the only author. The difficulty comes when you have many authors over many years and you need to get all their permissions.
Re: [OT] bitcoin donation
On Wednesday, 25 November 2015 at 20:10:37 UTC, deadalnix wrote: On Wednesday, 25 November 2015 at 09:20:53 UTC, John Colvin wrote: On Wednesday, 25 November 2015 at 02:33:24 UTC, deadalnix wrote: Don't be confused. Krugman do not understand bitcoin, but Krugman think that terrorism and riots are good, that the internet will never work and that there was no bubble in 2008, so I think is it fairly secure to ignore him. I'm not 100% convinced by Krugman in many cases, but I'd say you'd have to be pretty confident in your own economics knowledge and intellect to dismiss him entirely, considering his standing among his - almost by definition also very knowledgable and intelligent - peers. That's a false dichotomy. I'm certainly not confident in my economics. But I'm confident that betting against Krugman is way safer than the reverse. Don't agree it's a false dichotomy, but as far as your opinion of Krugman goes, fair enough; it's not one I share, but in a discipline as difficult and loose as economics it can be reasonable to disagree.
Re: [OT] bitcoin donation
On Wednesday, 25 November 2015 at 02:33:24 UTC, deadalnix wrote: On Monday, 23 November 2015 at 12:11:36 UTC, Steven Schveighoffer wrote: One could ask the same thing about any currency that isn't the one accepted at a store. I looked with a tinge of fascination at what bitcoin was a while ago. I think there is a natural averse reaction to something that is valuable but that you cannot understand. Don't be confused. Krugman do not understand bitcoin, but Krugman think that terrorism and riots are good, that the internet will never work and that there was no bubble in 2008, so I think is it fairly secure to ignore him. I'm not 100% convinced by Krugman in many cases, but I'd say you'd have to be pretty confident in your own economics knowledge and intellect to dismiss him entirely, considering his standing among his - almost by definition also very knowledgable and intelligent - peers. Many other economist have model that explain bitcoin's value. I know bitcoin has real math and genius behind it, and this is a silly example, but for those who do not understand how it actually works (including myself), it seems very similar in nature. Dollars (or whatever local currency you use) are understandable, and generally accepted at places where I shop. It's easy to see how one cannot duplicate them without evidence of doing so (the fundamental characteristic of currency). Online bits don't seem so uncopyable. -Steve Most people to not understand fractional reserve, bond emission, or how credit card works. I think that's ok. I think a lot of the nonsense in the public discourse on economics and associated policy can be attributed to the speaker not understanding these basic systems, or the target audience not understanding. Most people don't even know what a bank really is, but they sure do hate them... Back to the point, one of the value of bitcoin is to be able to transfer money internationally easily and for cheap. People that do have USD to spend on digital mars do not care. People abroad do care. Now I don't expect that accepting bitcoin will create a giant wave of donation, but, if anything, it is always good PR and not complicated. There is also no reason to refuse a donation or to make it more complex to do a donation. Andrei, Walter, if you need help to navigate the bitcoin ecosystem, you can reach me, I can help. I agree, bitcoin would be a good donation mechanism to support.
Re: Next London D Meetup - 18th November
On Thursday, 19 November 2015 at 15:16:37 UTC, Jack Stouffer wrote: On Wednesday, 18 November 2015 at 13:59:36 UTC, John Colvin wrote: On Wednesday, 11 November 2015 at 22:43:22 UTC, Kingsley wrote: Hi Please come to the London D meetup on Wednesday 18th November. We have a great talk by John Colvin on semi functional programming. We have a fantastic venue at skills matter with great facilities and free video recording capabilities. http://www.meetup.com/London-D-Programmers/events/226237601/ Just a reminder that this is tonight. Were any of the talks recorded? No, but I'm hoping to follow up what I talked about with an article and/or video.
Re: Next London D Meetup - 18th November
On Wednesday, 11 November 2015 at 22:43:22 UTC, Kingsley wrote: Hi Please come to the London D meetup on Wednesday 18th November. We have a great talk by John Colvin on semi functional programming. We have a fantastic venue at skills matter with great facilities and free video recording capabilities. http://www.meetup.com/London-D-Programmers/events/226237601/ Just a reminder that this is tonight.
Re: D compiler daily downloads at an all-time high
On Tuesday, 17 November 2015 at 23:26:15 UTC, Vladimir Panteleev wrote: On Tuesday, 17 November 2015 at 13:08:37 UTC, Namal wrote: On Monday, 16 November 2015 at 15:20:51 UTC, Andrei Alexandrescu wrote: [...] Hello Andrei, what do you think how good the download numbers are representing the popularity of D? Because I myself have downloaded the new compiler several times. One for work, one for home and one for the virtual machine I guess. As long as we didn't change something in D that affects how often one person downloads the compiler, these are independent variables and do not affect the trend. One or three years ago (or if D were as it was one or three years ago), would you not have downloaded the compiler the same number of times? package manager presence has improved, so I would expect dlang.org downloads to represent a smaller fraction of total downloads than it used to.
Re: Please vote for the DConf logo
On Wednesday, 4 November 2015 at 09:30:30 UTC, Andrei Alexandrescu wrote: Reply to this with 1.1, 1.2, 2, or 3: 1) by ponce: Variant 1: https://github.com/p0nce/dconf.org/blob/master/2016/images/logo-sample.png Variant 2: https://raw.githubusercontent.com/p0nce/dconf.org/4f0f2b5be8ec2b06e3feb01d6472ec13a7be4e7c/2016/images/logo2-sample.png 2) by Jonas Drewsen: https://dl.dropboxusercontent.com/u/188292/g4421.png 3) by anonymous: PNG: http://imgur.com/GX0HUFI SVG: https://gist.github.com/anonymous/4ef7282dfec9ab327084 Thanks, Andrei 3
Re: Next London D Meetup - 18th November
On Wednesday, 11 November 2015 at 22:43:22 UTC, Kingsley wrote: Hi Please come to the London D meetup on Wednesday 18th November. We have a great talk by John Colvin on semi functional programming. We have a fantastic venue at skills matter with great facilities and free video recording capabilities. http://www.meetup.com/London-D-Programmers/events/226237601/ We had good fun last time, I'm looking forward to presenting and joining in with the coding afterwards :)
Re: dfmt 0.4.1
On Wednesday, 21 October 2015 at 23:21:21 UTC, Brian Schott wrote: dfmt is a formatter for D source code. Changes from 0.4.0: * #189: Better formatting for "in" expressions where the right side of the "in" operator is a function literal. * #190: Fix a bug where whitespace was removed from some ASM statements. * #191: Add "-i" as an alias for the "--inplace" option and document the existence of "-t" as an alias for the "indent_style" option. * #192: Fix a mistake in the README https://github.com/Hackerpilot/dfmt/releases/tag/v0.4.1 For those on OS X using homebrew: brew install dfmt should work now.
Re: dfmt 0.4.1
On Wednesday, 21 October 2015 at 23:21:21 UTC, Brian Schott wrote: dfmt is a formatter for D source code. Changes from 0.4.0: * #189: Better formatting for "in" expressions where the right side of the "in" operator is a function literal. * #190: Fix a bug where whitespace was removed from some ASM statements. * #191: Add "-i" as an alias for the "--inplace" option and document the existence of "-t" as an alias for the "indent_style" option. * #192: Fix a mistake in the README https://github.com/Hackerpilot/dfmt/releases/tag/v0.4.1 Ouch, that takes >30s to build, which feels long in D...
Re: DCD 0.7.1
On Monday, 19 October 2015 at 21:01:06 UTC, Brian Schott wrote: On Monday, 19 October 2015 at 20:29:41 UTC, Brian Schott wrote: From the README: "The D Completion Daemon is an auto-complete program for the D programming language." 0.7.1 is a (boring) bug-fix release. https://github.com/Hackerpilot/DCD/releases/tag/v0.7.1 Skip that. Grab 0.7.2 because it's 0.7.1 that builds with LDC. https://github.com/Hackerpilot/DCD/releases/tag/v0.7.2 brew upgrade dcd :)
Re: Beta D 2.069.0-b2
On Wednesday, 14 October 2015 at 13:53:17 UTC, Martin Nowak wrote: Second beta for the 2.069.0 release. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.069.0.html Please report any bugs at https://issues.dlang.org -Martin got through to homebrew a faster this time. brew reinstall dmd --devel
Re: Beta D 2.069.0-b1
On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak wrote: First beta for the 2.069.0 release. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.069.0.html Please report any bugs at https://issues.dlang.org -Martin brew reinstall dmd --devel :) thanks for all the hard work
Re: Beta D 2.069.0-b1
On Thursday, 8 October 2015 at 12:32:59 UTC, John Colvin wrote: On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak wrote: First beta for the 2.069.0 release. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.069.0.html Please report any bugs at https://issues.dlang.org -Martin Am I being dumb or does SYSCONFDIR do absolutely nothing... https://issues.dlang.org/show_bug.cgi?id=15181
Re: Beta D 2.069.0-b1
On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak wrote: First beta for the 2.069.0 release. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.069.0.html Please report any bugs at https://issues.dlang.org -Martin Am I being dumb or does SYSCONFDIR do absolutely nothing...
Re: This Week in D #37 - forum tutorials and tip on using UDAs
On Monday, 28 September 2015 at 13:03:50 UTC, Adam D. Ruppe wrote: The tip here is one I've been talking about on irc a little and decided to write up this time. Using a mixin template to hold the source code of a thing to be transformed is something I think is kinda cool though I haven't actually used it in a real project yet. (Actually, I've barely used UDAs in the real world at all yet. I was so excited for them when they were new, but it took so long to materialize that I found other ways to do my stuff and now haven't transitioned!) Somewhat related to this, see page 6 of what I was working on over the weekend: https://github.com/DlangScience/design/blob/master/design.pdf
Re: New blog about D
On Sunday, 27 September 2015 at 23:23:05 UTC, Márcio Martins wrote: Today I launched a very tiny and humble blog, with the first post being about D. It's likely all posts will be about D in the end... [...] this is what http://code.dlang.org/packages/gl3n does, right?
Re: DUB 0.9.24 release
On Thursday, 24 September 2015 at 09:21:06 UTC, John Colvin wrote: On Thursday, 24 September 2015 at 08:23:54 UTC, Suliman wrote: How I can add multiple dependencies? In json I was can wrote: dependencies": { "dini": ">=1.0.0", "colorize": ">=1.0.5", "ddbc": ">=0.2.11", } How it will be in SDL? http://code.dlang.org/package-format?lang=sdl woops, sorry, I see it's not actually mentioned there
Re: DUB 0.9.24 release
On Thursday, 24 September 2015 at 08:23:54 UTC, Suliman wrote: How I can add multiple dependencies? In json I was can wrote: dependencies": { "dini": ">=1.0.0", "colorize": ">=1.0.5", "ddbc": ">=0.2.11", } How it will be in SDL? http://code.dlang.org/package-format?lang=sdl