Re: matrix library
On Monday, 23 May 2016 at 07:28:20 UTC, Vlad Levenfeld wrote: https://github.com/evenex/linalg I've some heard people (including me) asking about matrix libraries for D, and while there is gl3n it only goes to 4x4 matrices and was written before all the multidimensional indexing stuff. So I was using gl3n for awhile until I needed some 6x6s and threw together a syntax-sugary sort of wrapper over std.experimental.ndslice and cblas for matrix math. Generic matrix-matrix multiplication is available in Mir version 0.16.0-beta2 http://docs.mir.dlang.io/latest/mir_glas_gemm.html It should be compiled with recent LDC beta, and -mcpu=native flag.
Re: matrix library
On Monday, 23 May 2016 at 07:28:20 UTC, Vlad Levenfeld wrote: https://github.com/evenex/linalg I've some heard people (including me) asking about matrix libraries for D, and while there is gl3n it only goes to 4x4 matrices and was written before all the multidimensional indexing stuff. [...] Generic matrix-matrix multiplication is available in Mir version 0.16.0-beta2 http://docs.mir.dlang.io/latest/mir_glas_gemm.html It should be compiled with recent LDC beta, and -mcpu=native flag.
Re: [GSoC] Mir.random.flex - Generic non-uniform random sampling
On Monday, 22 August 2016 at 18:09:28 UTC, Meta wrote: On Monday, 22 August 2016 at 15:34:47 UTC, Seb wrote: Hey all, I am proud to publish a report of my GSoC work as two extensive blog posts, which explain non-uniform random sampling and the mir.random.flex package (part of Mir > 0.16-beta2): http://blog.mir.dlang.io/random/2016/08/19/intro-to-random-sampling.html http://blog.mir.dlang.io/random/2016/08/22/transformed-density-rejection-sampling.html It's really nice to see that GSoC has been such a huge success so far. Everyone has done some really great work. Over the next weeks and months I will continue my work on mir.random, which is supposed to supersede std.random, so in case you aren’t following the Mir project [1, 2], stay tuned! Best regards, Seb [1] https://github.com/libmir/mir [2] https://twitter.com/libmir I'm curious, have you come up with a solution to what is probably the biggest problem with std.random, i.e., it uses value types and copying? I remember a lot of discussion about this and it seemed at the time that the only really solid solution was to make all random generators classes, though I think DIP1000 *may* help here. This is an API problem, and will not be fixed. Making D scripting like language is bad for Science. For example, druntime (Fibers and Mutexes) is useless because it is too high level and poor featured in the same time. The main problem with std.random is that std.random.uniform is broken in context of non-uniform sampling. The same situation is for 99% uniform algorithms. They just ignore the fact that for example, for [0, 1) exponent and mantissa should be generated separately with appropriate probabilities for for exponent
Re: [GSoC] Mir.random.flex - Generic non-uniform random sampling
On Monday, 22 August 2016 at 15:34:47 UTC, Seb wrote: Hey all, I am proud to publish a report of my GSoC work as two extensive blog posts, which explain non-uniform random sampling and the mir.random.flex package (part of Mir > 0.16-beta2): http://blog.mir.dlang.io/random/2016/08/19/intro-to-random-sampling.html http://blog.mir.dlang.io/random/2016/08/22/transformed-density-rejection-sampling.html Reddit: https://www.reddit.com/r/programming/comments/4z4sp7/an_introduction_to_nonuniform_random_sampling/
Re: Autotesting dub packages with dmd nightly
On Wednesday, 10 August 2016 at 18:35:03 UTC, Sebastiaan Koppe wrote: So true. Then I will do PR's first. I finally got around implementing running dmd/druntime/phobos pull requests against all dub packages. Thank you digger, for making it so easy. I did a run of master + druntime#1602. Then I ran a comparison with a batch from 2.071.2-b2. 108 packages had a different build result. I have no nice stats or pictures, but a quick glance over the raw data: 50 of them went from green unittests to a dmd exit code 1. 16 went from unknown build results to dmd exit code 1. 10 went from dmd exit code 255 to 1 9 of them are now green. 8 of them went from linker errors to a dmd exit code 1. 6 of then went from non-zero exit code during unittest run to a dmd exit code 1. 3 previous ran out of memory but now resulted in dmd exit code 1. etc. All in all I think +/- 96 package are affected. A little over 11%.
Re: [GSoC] Mir.random.flex - Generic non-uniform random sampling
On Monday, 22 August 2016 at 15:34:47 UTC, Seb wrote: Hey all, I am proud to publish a report of my GSoC work as two extensive blog posts, which explain non-uniform random sampling and the mir.random.flex package (part of Mir > 0.16-beta2): http://blog.mir.dlang.io/random/2016/08/19/intro-to-random-sampling.html http://blog.mir.dlang.io/random/2016/08/22/transformed-density-rejection-sampling.html It's really nice to see that GSoC has been such a huge success so far. Everyone has done some really great work. Over the next weeks and months I will continue my work on mir.random, which is supposed to supersede std.random, so in case you aren’t following the Mir project [1, 2], stay tuned! Best regards, Seb [1] https://github.com/libmir/mir [2] https://twitter.com/libmir I'm curious, have you come up with a solution to what is probably the biggest problem with std.random, i.e., it uses value types and copying? I remember a lot of discussion about this and it seemed at the time that the only really solid solution was to make all random generators classes, though I think DIP1000 *may* help here.
Re: [GSoC] Mir.random.flex - Generic non-uniform random sampling
On Monday, 22 August 2016 at 15:34:47 UTC, Seb wrote: Hey all, I am proud to publish a report of my GSoC work as two extensive blog posts, which explain non-uniform random sampling and the mir.random.flex package (part of Mir > 0.16-beta2): http://blog.mir.dlang.io/random/2016/08/19/intro-to-random-sampling.html http://blog.mir.dlang.io/random/2016/08/22/transformed-density-rejection-sampling.html Thanks for the well-done blog posts, especially the first one. Does your implementation make any use of CTFE?
[GSoC] Mir.random.flex - Generic non-uniform random sampling
Hey all, I am proud to publish a report of my GSoC work as two extensive blog posts, which explain non-uniform random sampling and the mir.random.flex package (part of Mir > 0.16-beta2): http://blog.mir.dlang.io/random/2016/08/19/intro-to-random-sampling.html http://blog.mir.dlang.io/random/2016/08/22/transformed-density-rejection-sampling.html Before I start my personal retrospect, I wanted to use this opportunity to give a huge thanks and acknowledgement to my two awesome mentors Ilya Yaroshenko (9il) and Joseph Wakeling (WebDrake). As I wrote my first line of D code this February, I have learned quite a lot during the last few months. Github allows to list all merged contributions, which might show that I got quite familiar with dlang over the time: https://github.com/search?l=&o=desc&q=author%3Awilzbach+is%3Amerged+user%3Adlang&ref=advsearch&s=comments&type=Issues&utf8=%E2%9C%93 … and with other D repositories: https://github.com/search?l=D&o=desc&q=author%3Awilzbach+is%3Amerged&ref=searchresults&s=comments&type=Issues&utf8=%E2%9C%93 I am pretty sure you now know me from the NG, Github, IRC, Twitter, Bugzilla, DConf16, the DWiki, #d at StackOverflow or /r/d_language, so I will skip a further introduction ;-) Over the next weeks and months I will continue my work on mir.random, which is supposed to supersede std.random, so in case you aren’t following the Mir project [1, 2], stay tuned! Best regards, Seb [1] https://github.com/libmir/mir [2] https://twitter.com/libmir
Re: D support for the Meson build system
On Monday, 22 August 2016 at 11:45:37 UTC, Matthias Klumpp wrote: On Monday, 22 August 2016 at 01:34:36 UTC, jkpl wrote: On Sunday, 21 August 2016 at 19:08:59 UTC, Matthias Klumpp wrote: for a project like Terminix, dub with LDC builds in 8.6s, while Meson and ninja take only 6s here. Did you try to build with DUB but with WIFI or ethernet interface toggled off ? I ran these a few times, and the results were comparable, although I think if I would perform proper statistics the variance would be relatively high. Compiler was LDC 1.0.0 (on a Xeon E3-1231 v3). Sorry I was thinking to something, that could have slowed down the DUB build, but this was obviouslt wrong.
Re: DIP1000: Scoped Pointers
On Thursday, 18 August 2016 at 17:05:05 UTC, Dicebot wrote:
On 08/11/2016 04:38 PM, Sönke Ludwig wrote:
That will just leave one hole in conjunction with the @trusted
destructor, which is (presumably) not easy to fix without much
larger changes to the type system, as well as to how container
types are built. It is still vulnerable to artificial
shortening of the elements' lifetime, e.g. by using opAssign()
or destroy():
@safe {
RefCountedSlice!int s = ...;
scope int* el;
el = &s[0];
s = RefCountedSlice.init;
*el = 12; // oops
}
I asked Walter about this in more details and right now plan is
to address it in a separate DIP that provides more integration
between reference counting and compiler. Within DIP1000 terms
such destructor must not be marked as @safe - essentially, it
will only enable @safe usage of stack allocated data in its
initial form.
I think RefCountedSlice can have a @trusted destructor so long as
opAssign is @system. (I'll likely make a PR to the DIP soon).
Re: D support for the Meson build system
On Monday, 22 August 2016 at 01:34:36 UTC, jkpl wrote: On Sunday, 21 August 2016 at 19:08:59 UTC, Matthias Klumpp wrote: for a project like Terminix, dub with LDC builds in 8.6s, while Meson and ninja take only 6s here. Did you try to build with DUB but with WIFI or ethernet interface toggled off ? No, but I obviously excluded any download times, and also dependency build-times to be fair to dub. But, with network access toggled off: Terminix: debug build: dub: 0m8.60s ninja: 0m6.36s release build (standard args): dub: 0m12.923s ninja: 0m11.740s asgen: debug build: dub: 0m13.00s ninja: 0m13.04s release build: dub: 0m25.72s ninja: 0m19.19s I ran these a few times, and the results were comparable, although I think if I would perform proper statistics the variance would be relatively high. Compiler was LDC 1.0.0 (on a Xeon E3-1231 v3). One important thing about Ninja is that it will perform split-builds by default, so if you change something, only the changed piece needs to be recompiled. I *think* dub can do that too, but for some reason it never does it (even when using --parallel). That behavior drastically reduces compile times when working on a project. Also, Ninja knows about all the source files and generated files in advance, while dub needs to search for them on every run. That of course also has the drawback that one needs to specify the source files prior to building in the meson.build file.
Re: On the future of DIP1000
On Monday, 22 August 2016 at 06:44:11 UTC, Jacob Carlborg wrote: It would be nice to have the whole picture now, before implementing DIP1000. It can be reviewed after the spec is inferred from implementation. But yes, it can be unclear how the implementation can affect the review process. Do you have an alternative design for scope?
Re: QtE5 - is a wrapping of Qt-5 for D
On Monday, 22 August 2016 at 08:38:12 UTC, MGW wrote: The excellent programming language is D. I all the projects make, nearly two years, only on D (dmd) + Qt (QtE4 and QtE5). What are the advantages and drawbacks you faced and face while working with D? How are old D programs compiled with new versions of D compiler? Did you rewrite old D programs using new D features during 2 years?
Re: QtE5 - is a wrapping of Qt-5 for D
On Sunday, 21 August 2016 at 17:21:14 UTC, eugene wrote: On Sunday, 21 August 2016 at 13:18:04 UTC, MGW wrote: Hello, could you share your experience with D language? How it feels to work with it? The excellent programming language is D. I all the projects make, nearly two years, only on D (dmd) + Qt (QtE4 and QtE5). All projects and tools, including the D compiler and QtE5 library for all OS, can be stored on one flash drive. It is very pleasant as I work with different organizations and I not always have with myself my main computer. Short video about my latest work. It is QtE5 installer for D (dmd). https://youtu.be/G_b2SAYqIWI installer QtE5 https://yadi.sk/d/sqhTCMneuN7rj QtE5 on github https://github.com/MGWL/QtE5
