Re: SAoC Updates
On Tuesday, 31 July 2018 at 20:05:28 UTC, 12345swordy wrote: Would it be easier to submit a approved conflict of interest paper with the application? All I'm saying is that each applicant is responsible for making sure they are free and clear to participate. If you have an employment contract that makes participation problematic, then yes, obtaining permission from your employer and including a document to that effect with your application would be fulfilling that responsibility.
Re: Fastest JSON parser in the world is a D project
Am Fri, 13 Jul 2018 18:14:35 + schrieb iris : > Any idea about the performance of this json parser? > https://jsonformatter.org/json-parser ? That one is implemented in client side JavaScript. I didn't measure it, but the closest match in Kostya's benchmark could be the Node JS entry that is an order of magnitude slower. -- Marco
Re: SAoC Updates
On Tuesday, 31 July 2018 at 13:50:52 UTC, Mike Parker wrote: On Tuesday, 31 July 2018 at 13:36:13 UTC, bachmeier wrote: On Tuesday, 31 July 2018 at 03:23:41 UTC, Mike Parker wrote: Second, it is incumbent upon non-student applicants who are currently employed by a software development firm to ensure there are no contractual barriers to participating. That seems risky - an employer may claim ownership of those contributions. That's precisely why I mention it. We expect that applicants to take the necessary steps to verify there are no issues *before* applying. If, during the application process, it is discovered that there are potential issues, that's grounds for an automatic rejection. We do have access to a legal team, so there will be a certain level of due diligence where required. Would it be easier to submit a approved conflict of interest paper with the application? -Alexander
Re: SAoC Updates
On Tuesday, 31 July 2018 at 13:36:13 UTC, bachmeier wrote: On Tuesday, 31 July 2018 at 03:23:41 UTC, Mike Parker wrote: Second, it is incumbent upon non-student applicants who are currently employed by a software development firm to ensure there are no contractual barriers to participating. That seems risky - an employer may claim ownership of those contributions. That's precisely why I mention it. We expect that applicants to take the necessary steps to verify there are no issues *before* applying. If, during the application process, it is discovered that there are potential issues, that's grounds for an automatic rejection. We do have access to a legal team, so there will be a certain level of due diligence where required.
Re: SAoC Updates
On Tuesday, 31 July 2018 at 03:23:41 UTC, Mike Parker wrote: Second, it is incumbent upon non-student applicants who are currently employed by a software development firm to ensure there are no contractual barriers to participating. That seems risky - an employer may claim ownership of those contributions.
Re: Blogpost about parallelizing Datacat with std.parallelism
On Thursday, 26 July 2018 at 20:29:56 UTC, ikod wrote: On Thursday, 26 July 2018 at 12:13:01 UTC, Joakim Brännström wrote: Hello, I've written up a blog post[0] of my explorations when parallelizing Datacat[1]. Thanks for nice article. Just in case if you never tried this: https://bitbucket.org/andrewtrotman/d-profile-viewer https://bytebucket.org/andrewtrotman/d-profile-viewer/raw/277a7eff16a2b1ffab656d0c6d76a718e8076745/images/OneMethod.png those function names look interesting :)
Re: autowrap v0.0.1 - Automatically wrap existing D code for use in Python and Excel
On Tuesday, 31 July 2018 at 09:09:11 UTC, Nicholas Wilson wrote: [snip] Also I'm working on a D kernel for Jupyter notebook which should be done soon. Excellent.
Re: On D in competitive programming
On Tuesday, 31 July 2018 at 00:52:22 UTC, 9il wrote: Are competitors allowed to use mir-algorithm and mir-random? The libraries can be used for graphs (Tarjan algorithm), matrices/tensors, nd-iteration, RNGs, interpolation, and distributions? Sadly, no: most of the time, language compilers on the server side are provided as they are out-of-the-box. I'll try to explain why. When a language is added to a competition, one of the goals for the organizers is to keep the whole thing fair. Different languages have different pros and cons already as they are, and what is an implementation-heavy problem for one language is solved in a couple lines with another. So, the availability of several programming languages already puts some burden on the problemsetters: at least for important competitions, they have to come up with problems which don't play too much into the strengths of any particular language, and that means knowing what to generally expect of all the languages. For example, most problems don't rely on number crunching with integers above 64 bits, since C++ is notoriously lacking in this regard. This all gets a new dimension if a platform decides to supply additional libraries. Once it's done for one language, there are no clear boundaries: if we get mir-algorithm for D, we will have to at least install Boost for C++, and numpy for Python, and the users of other languages also ask for their favourite libraries, which are in turn more powerful than Boost, and so on. And it would take significant expertise to balance such requests so that no language has too much of an unfair advantage or disadvantage. It takes a bit of expertise too to keep the libraries in all languages working and up-to-date. All the way, the problemsetters now have to avoid a different set of topics, changing with new libraries being added. Yet another factor is that there are central competitions perceived as the most important, which are currently ACM ICPC World Finals for university teams, and their regional contests. Many platforms strive to act as training grounds for the important competitions. So when the World Finals, which are understandably conservative, don't do X, it's a disincentive to do X for the training grounds too. So, the default approach is to keep each language at a bare minimum. It would be nice to have this feature, as mir-algorithm can be a good default library for competitive programming. Plus competitors can add additional graph algorithms. It may still be reasonable to ask for additional libraries on the platforms where the focus is not some big competition: e.g., perhaps no for ACM ICPC archives, perhaps yes for interview training sites. For a particular platform and a particular cause (e.g., a training course for a learning platform), it's entirely possible to have D with mir-algorithm installed on the platform. Ivan Kazmenko.
Re: autowrap v0.0.1 - Automatically wrap existing D code for use in Python and Excel
On Sunday, 29 July 2018 at 18:14:31 UTC, Nikos wrote:
But when I try to export the whole dmdEngine
export:
auto engine(char[] txt) {
return interpreter(dmdEngine());
}
Can you export an instance of `interpreter(dmdEngine())`?
e.g.
__gshared auto dmdi = interpreter(dmdEngine());
export ref dmd()
{
return dmdi;
}
or if that doesn't work, proxy it
__gshared auto dmdi = interpreter(dmdEngine());
struct Dmd
{
mixin Proxy!dmdi;
}
export auto dmd()
{
Dmd d;
return d;
}
That is pretty much required if you want to maintain state across.
Also I'm working on a D kernel for Jupyter notebook which should
be done soon.
