Re: Release D 2.070.0
Where is mention about std.experimental.ndslice?
Re: Vision for the first semester of 2016
On Thursday, 28 January 2016 at 00:28:26 UTC, Twenty Two wrote: Parkinson's Law: work expands so as to fill the time available for its completion. [...] I agree. Some of the core team uses trello for this: https://trello.com/b/XoFjxiqG/active However, that's not really meant for noobs and a lot of the core team, including Walter, doesn't really use it.
Re: Release D 2.070.0
On 01/27/2016 11:16 PM, Yazan D wrote: > Thanks for all the work. > > Looks like the changelog is missing some stuff. For example: https:// > issues.dlang.org/show_bug.cgi?id=15434 and https://issues.dlang.org/ > show_bug.cgi?id=15433. The commit messages are parsed by quite a few tools to find bug fixes. In order to automatically close bugzilla tickets, get a link from dlang-bot, and appear on the changelog you should mention `fix Issues 15433` in the relevant commit. The regex goes like this: ((close|fix|address)e?(s|d)? )?(ticket|bug|tracker item|issue)s?:? *([\d ,\+&#and]+) https://github.com/github/github-services/blob/2e886f407696261bd5adfc99b16d36d5e7b50241/lib/services/bugzilla.rb#L155 -Martin
Re: Release D 2.070.0
On 01/27/2016 10:37 PM, jmh530 wrote: > > I don't see a mention of the native exception handling on 64-bit linux > in the changelog. Yes, sorry for that nobody wrote the changelog entry. We now have changelog.dd files in each repo, and PRs should only be merged w/ the corresponding changelog entry. Unfortunately this isn't always followed.
Re: Release D 2.070.0
On 1/27/2016 1:08 PM, Martin Nowak wrote: Glad to announce D 2.070.0 http://dlang.org/download.html This release comes with the new std.experimental.ndslice, heavily expanded Windows bindings, and native exception handling on 64-bit linux. See the changelog for more details. http://dlang.org/changelog/2.070.0.html -Martin Thank you, Martin, for all your hard and diligent work taking charge of preparing and getting this release out the door!
Re: Sublime Text 3 Gets Better D Support
On Wednesday, 27 January 2016 at 19:27:47 UTC, Jack Stouffer
wrote:
On Wednesday, 27 January 2016 at 19:15:02 UTC, Damian wrote:
Thank you, this is very much welcome!
Wishlist:
Will we see some dub support integration for building? I find
when using rust the cargo build support is excellent, I wish
we had this for D in sublime :)
I actually didn't do this, I just complained on their issue
tracker :)
I use dub with sublime currently by using sublime's custom
build system. Just go to "Build System" under tools, click new
build system, and add in the following
{
"cmd": ["dmd", "-g", "-debug", "$file"],
"file_regex": "^(.*?)\\(([0-9]+),?([0-9]+)?\\): (.*)",
"selector": "source.d",
"path": "/usr/bin:/usr/local/bin",
"variants": [
{
"name": "Run",
"cmd": ["rdmd", "-g", "-debug", "$file"]
},
{
"name": "unittest",
"cmd": ["rdmd", "-g", "-debug", "-unittest",
"$file"]
},
{
"name": "dub",
"working_dir": "$project_path",
"cmd": ["dub"]
}
]
}
Now in your D project, select the build system you just
created, click shift command B, choose dub, and then command B,
and now your building with dub.
Is there any way to get that to build in a terminal window rather
than Sublime's inbuilt build window?
Re: Vision for the first semester of 2016
Parkinson's Law: work expands so as to fill the time available for its completion. Having a set of vague tasks to finish within 6 months is great, but having a weekly more specific priority list to go along with it would be better. If, in addition, there was some accountability (not with negative implications, just a designation of responsibility) that would further narrow focus and ramp up productivity. As a draft proposal, something like a weekly sticky TODO thread with clear goals could work. You'd list a few high priority items and ask for a volunteers for each and list them as they come in. You'd have bigger medium priority item list and ask for volunteers but only half of them need to be assigned to someone and completed. Then you'd have a much longer lower priority list that can be a bit more vague that people are encouraged to work on but that they don't need to volunteer for, just submit their pull requests (but they can flag an item and have it ticked off if they want). On top of that have a weekly pull request goal that updates daily (with a time stamp) and an overview of pull request numbers from previous weeks. If an item isn't completed it gets rolled over to the next week with an asterisk (if it's medium or high priority) for each time it's been rolled over and the previous volunteer listed as such (and they can volunteer for the same item the next week giving them the perfect opportunity to say where they're at, what needs to be done, if the task should be broken down further, etc). It'll make it clear if whoever volunteered for a task needs some help or encouragement, or if certain high priority tasks need a volunteer or to be broken down into more manageable chunks even if someone drops off the face of the earth. With a one item at a time rule you're going to cut down on stagnation. I'm sure there are lots of people who'd like to help out but they're not really sure what needs to be done or who else is doing it or if they'll step on toes, etc. Anyone wondering what's being worked on can take a look and help out themselves rather than getting upset in the forums about feature x never seeing the light of day. If they want feature x done they can take a look at the priority list and pick where it should go in the scheme of things, maybe even break it down - turn negative energy into productive energy :)
Re: Vision for the first semester of 2016
On Wednesday, 27 January 2016 at 22:36:37 UTC, Chris Wright wrote:
Longevity is an awkward one. If I create a project, do nothing
with it for four years, then make a release, will that count as
well as making a release once a month for four years? But the
other metrics should account for that.
Code I wrote below incorporates some of what you're talking about.
For simplicity, I represented the date of each release as a
dynamic array of doubles. I applied a weighting function to each
and then calculated the entropy. The score is 1 if you only have
one release. The score is higher, the more releases you have. If
you have one release five years ago and one release recently,
then your score is only marginally higher than 1. But if you have
lots of recent releases, then the score is much more favorable.
You could probably adjust this in a number of ways. For instance,
adjusting the denominator in
return weight.map!(a => a / weight.sum());
you could make it so that a release today is better than a
release five years ago.
auto weight(double[] x, double lambda)
{
import std.algorithm : sum, map;
import std.math : exp;
import std.array : array;
auto weight = x.map!(a => lambda * exp(-lambda * a)); // weights
given by
// exponential
// distribution
return weight.map!(a => a / weight.sum());
}
double entropy(T)(T x)
{
import std.algorithm : sum, map;
import std.math : exp, log;
auto e = x.map!(a => a * log(a));
return exp(-sum(e));
}
double calc_score(double[] x, double lambda)
{
return x.weight(lambda).entropy();
}
void main()
{
import std.stdio : writeln;
double lambda = 0.5; // controls decay in weighting function
double[] x; // represents years since last update
x = [0.1, 0.25, 1, 2, 5];
auto score = calc_score(x, lambda);
writeln(score);
}
Re: Sublime Text 3 Gets Better D Support
On Wednesday, 27 January 2016 at 19:15:02 UTC, Damian wrote: Thank you, this is very much welcome! Wishlist: Will we see some dub support integration for building? I find when using rust the cargo build support is excellent, I wish we had this for D in sublime :) I think the sublime D-Kit plugin has dub building support. Also thanks Jack, I have been using sublime for D for a while now, its great but the highlighting kind sucks. My hope is sometime in the future dcd will have support for semantic highlighting along with the great auto complete it already provides.
Re: Vision for the first semester of 2016
On Wed, 27 Jan 2016 21:01:47 +, Martin Nowak wrote: > On Monday, 25 January 2016 at 16:26:36 UTC, Russel Winder wrote: >> PyPI has is an highly opinionated metric that helps you decide what is >> good and what is dross. > > Could you help us on designing one for code.dlang.org as well? I'd want to use the number of releases, how recent the most recent release was, the longevity of the project, and the number of other projects that depend on it. If people are willing to let dub submit anonymous usage information, the number of builds depending on a project is also an indicator of its value. Longevity is an awkward one. If I create a project, do nothing with it for four years, then make a release, will that count as well as making a release once a month for four years? But the other metrics should account for that. If possible, I'd include when the project last compiled and whether it passes its unittests. This requires setting up a continuous integration service for untrusted code. I've seen other people's designs for that, and I think I could replicate it without too much trouble.
Re: Release D 2.070.0
On Wed, 27 Jan 2016 22:08:54 +0100, Martin Nowak wrote: > Glad to announce D 2.070.0 > > http://dlang.org/download.html > > This release comes with the new std.experimental.ndslice, heavily > expanded Windows bindings, and native exception handling on 64-bit > linux. > See the changelog for more details. > > http://dlang.org/changelog/2.070.0.html > > -Martin Thanks for all the work. Looks like the changelog is missing some stuff. For example: https:// issues.dlang.org/show_bug.cgi?id=15434 and https://issues.dlang.org/ show_bug.cgi?id=15433.
Re: Ever want to compile D on your Android phone? Well, now you can!
On Wednesday, 27 January 2016 at 07:48:53 UTC, Joakim wrote: On Wednesday, 27 January 2016 at 06:04:43 UTC, Laeeth Isharc wrote: https://www.reddit.com/r/programming/comments/42w404/dlang_llvmbacked_compiler_alpha_release_for/ Thanks, I wondered if it had been posted, as it's the kind of oddity they might enjoy. :) Currently 9th with 215 upvotes. Just submitted to hacker news too.
Re: Release D 2.070.0
On Wednesday, 27 January 2016 at 21:08:54 UTC, Martin Nowak wrote: Glad to announce D 2.070.0 http://dlang.org/download.html This release comes with the new std.experimental.ndslice, heavily expanded Windows bindings, and native exception handling on 64-bit linux. See the changelog for more details. http://dlang.org/changelog/2.070.0.html -Martin I don't see a mention of the native exception handling on 64-bit linux in the changelog.
Re: Release D 2.070.0
On Wed, 27 Jan 2016 22:08:54 +0100, Martin Nowak wrote: > Glad to announce D 2.070.0 Sweet. Thanks for all your work on this Martin, and to all the contributors. Justin
Release D 2.070.0
Glad to announce D 2.070.0 http://dlang.org/download.html This release comes with the new std.experimental.ndslice, heavily expanded Windows bindings, and native exception handling on 64-bit linux. See the changelog for more details. http://dlang.org/changelog/2.070.0.html -Martin
Re: Vision for the first semester of 2016
On Monday, 25 January 2016 at 16:26:36 UTC, Russel Winder wrote: PyPI has is an highly opinionated metric that helps you decide what is good and what is dross. Could you help us on designing one for code.dlang.org as well?
Re: Vision for the first semester of 2016
On Tuesday, 26 January 2016 at 12:38:09 UTC, Andrei Alexandrescu wrote: including things that some people argue shouldn't be part of a standard library: archives and compression, cryptography, databases, character encodings (including json and xml!), html templating, image processing, suffix arrays (sic), logging, networking, regexp, testing, tokenization. See my answer below, most of these are standard solutions that you need on a daily basis (except for the suffix array). I do agree with Dub's importance. What's unclear to me is what are reasonable criteria for including some given functionality within the stdlib vs. an external one. A good criteria is whether some area has an established and hard to debate solution, then it can go into the standard library. But if there are many different ways around the same topic you should leave the decision to the users. So for example there are 3 established ways to parse something, dom, stax and event based parsers. So you can add those parsers as sth. like std.xml or std.json. There are about 500 different configuration file formats, so anything that isn't as established as xml or json should be left for libraries. Likewise there are plenty of different GUI toolkits (taking imperative or declarative approaches). Leave it to people to pick one that suites their need. You could discuss endlessly about the syntax of html templating, but how such a library should work is clear. This is at the edge of standardizable, b/c by putting it into std, you're making a decision for all language users. It's albeit possible, just like declaring a particular code style as standard. Anything that is highly innovative or experimental should never go into standard libraries.
Re: Sublime Text 3 Gets Better D Support
On Wednesday, 27 January 2016 at 19:27:47 UTC, Jack Stouffer wrote: On Wednesday, 27 January 2016 at 19:15:02 UTC, Damian wrote: Thank you, this is very much welcome! Now in your D project, select the build system you just created, click shift command B, choose dub, and then command B, and now your building with dub. I've updated my blog post on ST3+D to reflect your build system tips. https://www.btbytes.com/posts/st3d.html#buildingprojects Thanks!
Re: Sublime Text 3 Gets Better D Support
On Wednesday, 27 January 2016 at 19:15:02 UTC, Damian wrote:
Thank you, this is very much welcome!
Wishlist:
Will we see some dub support integration for building? I find
when using rust the cargo build support is excellent, I wish we
had this for D in sublime :)
I actually didn't do this, I just complained on their issue
tracker :)
I use dub with sublime currently by using sublime's custom build
system. Just go to "Build System" under tools, click new build
system, and add in the following
{
"cmd": ["dmd", "-g", "-debug", "$file"],
"file_regex": "^(.*?)\\(([0-9]+),?([0-9]+)?\\): (.*)",
"selector": "source.d",
"path": "/usr/bin:/usr/local/bin",
"variants": [
{
"name": "Run",
"cmd": ["rdmd", "-g", "-debug", "$file"]
},
{
"name": "unittest",
"cmd": ["rdmd", "-g", "-debug", "-unittest", "$file"]
},
{
"name": "dub",
"working_dir": "$project_path",
"cmd": ["dub"]
}
]
}
Now in your D project, select the build system you just created,
click shift command B, choose dub, and then command B, and now
your building with dub.
Re: Sublime Text 3 Gets Better D Support
On Wednesday, 27 January 2016 at 17:34:35 UTC, Jack Stouffer wrote: Sublime Text is a very popular text editor, and for a while now it's had marginal D support. What has changed recently is updated syntax highlighting to support all the new keywords that have come in the last couple of years and UDAs https://github.com/sublimehq/Packages/commit/b9026cf6ab8ccd05e3704d21b2d5d5cc21450aca. Syntax highlighting was mostly based on D1 before, but now it supports every thing to pure and nothrow to correctly highlighting number literals with underscores. In order to use this, you can either wait until a version of sublime is released with these changes, or you can download the dev version here https://www.sublimetext.com/3dev, and then install the new packages as described here https://github.com/sublimehq/Packages#installation. Thank you, this is very much welcome! Wishlist: Will we see some dub support integration for building? I find when using rust the cargo build support is excellent, I wish we had this for D in sublime :)
Re: Vision for the first semester of 2016
On Wednesday, 27 January 2016 at 16:52:53 UTC, Laeeth Isharc wrote: your own argument. Of course there will be lots there that one doesn't need and can't use. But over time things that were once cutting edge become bog standard, and it makes sense to have coherence and convenience rather than to have to search out the best library for the purpose each time. I agree about coherence being desirable, but evolution tends to lead to the opposite. Just look at C++ streams vs iterators vs ranges vs ... Coherence is a good reason to have independent libraries that are replaced as a whole. The standard library should primarily cover stable types you need to describe APIs. Then you can have other recommended independent libraries with no mutual dependencies.
Sublime Text 3 Gets Better D Support
Sublime Text is a very popular text editor, and for a while now it's had marginal D support. What has changed recently is updated syntax highlighting to support all the new keywords that have come in the last couple of years and UDAs https://github.com/sublimehq/Packages/commit/b9026cf6ab8ccd05e3704d21b2d5d5cc21450aca. Syntax highlighting was mostly based on D1 before, but now it supports every thing to pure and nothrow to correctly highlighting number literals with underscores. In order to use this, you can either wait until a version of sublime is released with these changes, or you can download the dev version here https://www.sublimetext.com/3dev, and then install the new packages as described here https://github.com/sublimehq/Packages#installation.
Re: Vision for the first semester of 2016
On Wednesday, 27 January 2016 at 09:15:27 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 27 January 2016 at 06:17:44 UTC, Laeeth Isharc wrote: On Tuesday, 26 January 2016 at 22:48:23 UTC, Ola Fosheim Grøstad wrote: I am not sure if that is the right motivation. Sounds like recipe for bloat. Good libraries evolve from being used in real applications. Many applications. sayeth a low-level guy (if I understand correctly), which will certainly create a distinct perspective about what you would like to see in the standard library, and yet this may not be the right thing for the language as a whole. I am both low-level and high level, but D's primary advantage is that it allows low level programming. Surely, that is C's primary advantage! The whole point of D is that it doesn't just have one primary advantage, and that is why the front page no longer describes it is as a systems language, even though it's approaching suitable as such. fwiw, people that do use D on a serious scale have remarked that the richness of the standard library (even as it stands today) was a major advantage - in bioinformatics, at a London hedge fund, and I think AdRoll. Do you consider Angular to be low level? It was used in 100s if not 1000s of applications, but was considered inadequate and scrapped in favour of Angular2. This is the typical pattern for libraries and frameworks. I really don't see how this relates to the point at hand. You seemed to suggest that the standard library should be small, and I pointed out that many serious users in industries that are likely to be key markets for D do say that they find what's provided in the standard library to be quite appealing. Nothing lasts forever, and all is change - that's something I agree with. But it doesn't seem to have much bearing on the decision about what to put in the standard library. Your suggestions that because some cloud environments don't have a conventional file system, D perhaps shouldn't even have this in the standard library really seemed to me to be a reductio ad absurdum of your own argument. Of course there will be lots there that one doesn't need and can't use. But over time things that were once cutting edge become bog standard, and it makes sense to have coherence and convenience rather than to have to search out the best library for the purpose each time.
Re: GDC Explorer Site Update
On Monday, 25 January 2016 at 23:08:32 UTC, Iain Buclaw wrote: Hi, After a much needed rebuild of the server running various GDC-related hosted services [http://forum.dlang.org/post/zrnqcfhvyhlfjajtq...@forum.dlang.org] - I've gotten round to updating the compiler disassembler. http://explore.dgnu.org/ Now supports 12 different architectures from ARM to SystemZ! (not including -m32 or any -march options) I noticed that Intel ASM syntax no longer worked with supported compilers. This has been fixed.
Re: Vision for the first semester of 2016
On Wednesday, 27 January 2016 at 06:17:44 UTC, Laeeth Isharc wrote: On Tuesday, 26 January 2016 at 22:48:23 UTC, Ola Fosheim Grøstad wrote: I am not sure if that is the right motivation. Sounds like recipe for bloat. Good libraries evolve from being used in real applications. Many applications. sayeth a low-level guy (if I understand correctly), which will certainly create a distinct perspective about what you would like to see in the standard library, and yet this may not be the right thing for the language as a whole. I am both low-level and high level, but D's primary advantage is that it allows low level programming. fwiw, people that do use D on a serious scale have remarked that the richness of the standard library (even as it stands today) was a major advantage - in bioinformatics, at a London hedge fund, and I think AdRoll. Do you consider Angular to be low level? It was used in 100s if not 1000s of applications, but was considered inadequate and scrapped in favour of Angular2. This is the typical pattern for libraries and frameworks.
Re: Ever want to compile D on your Android phone? Well, now you can!
On Wednesday, 27 January 2016 at 09:07:18 UTC, Vadim Lopatin wrote: On Wednesday, 27 January 2016 at 07:48:53 UTC, Joakim wrote: On Wednesday, 27 January 2016 at 06:04:43 UTC, Laeeth Isharc wrote: https://www.reddit.com/r/programming/comments/42w404/dlang_llvmbacked_compiler_alpha_release_for/ I've updated the gist and wiki page to take that change into account; simply download the new gist, as shown on a reloaded wiki page. Thank you! I've sent pull request to fix GLES2 build errors, and to create dub.json Thanks, shows that I've only tested with OpenGL ES 1.0 so far. I was going to try porting one of the NDK sample apps that uses 2.0 next, shouldn't be an issue. Could you please register your project on code.dlang.org as DUB package? I'm going to use it as a dependency in DlangUI I had a dub.json written up locally, but simply never bothered to commit and register it. I'll do so now.
Re: Ever want to compile D on your Android phone? Well, now you can!
On Wednesday, 27 January 2016 at 07:48:53 UTC, Joakim wrote: On Wednesday, 27 January 2016 at 06:04:43 UTC, Laeeth Isharc wrote: https://www.reddit.com/r/programming/comments/42w404/dlang_llvmbacked_compiler_alpha_release_for/ I've updated the gist and wiki page to take that change into account; simply download the new gist, as shown on a reloaded wiki page. Thank you! I've sent pull request to fix GLES2 build errors, and to create dub.json Could you please register your project on code.dlang.org as DUB package? I'm going to use it as a dependency in DlangUI
