Re: LDC 1.10.0 beta
On Monday, 14 May 2018 at 18:31:13 UTC, Jacob Carlborg wrote: On 2018-05-13 20:12, kinke wrote: Hi everyone, on behalf of the LDC team, I'm glad to announce the first beta for LDC 1.10. The highlights of this version in a nutshell: * Based on D 2.080.0. * Supports DragonFly BSD. * Some fixes, most notably wrt. exception stack traces on Linux. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.10.0-beta1 Thanks to all contributors! Out of curiosity, how come the Objective-C integration seem to always lack behind when LDC merges a new DMD release with some new Objective-C integration? Is it less prioritized, not so much knowledge in this area, something else? In addition to what David said, the plan is to have longer beta periods for ldc from here on out, which is why this ldc beta was released so soon after the corresponding dmd release, two weeks, a new record. You're free to test it out and submit issues or pulls before the final ldc release, as I do for Android.
Re: The #dbugfix Campaign Round 1 Report
On Monday, 14 May 2018 at 17:22:11 UTC, 12345swordy wrote: Be sure to post it in r/programming This sort of community-centric post doesn't belong there. We have to be careful not to reinforce the perception that we're spamming the sub.
DCD 0.9.7 is available
See [1]. with mostly (since v0.9.4) two possible `RangeError` fixed, completion on the `IfCondition` variables [2] (which was surprisingly not at all implemented), and freeze fixed on the windows version (32 bit OMF), which forced to build with an older DMD version. All binaries are available directly in the release. --- [1] https://github.com/dlang-community/DCD/releases/tag/v0.9.7 [2] https://dlang.org/spec/statement.html#IfCondition
Re: LDC 1.10.0 beta
On Monday, 14 May 2018 at 18:31:13 UTC, Jacob Carlborg wrote: Out of curiosity, how come the Objective-C integration seem to always lack behind when LDC merges a new DMD release with some new Objective-C integration? Is it less prioritized, not so much knowledge in this area, something else? Basically all of the latter – many of us LDC devs are not really interested in the Objective-C integration for our own/company use, and kinke (who has been doing virtually all of the frontend merging work lately) IIRC doesn't have access to an OS X box. Not breaking existing features without direct access to a target is one thing, but implementing new features off the CI only is another. Help would be very welcome, though. — David
Re: The #dbugfix Campaign Round 1 Report
On 15/05/2018 5:22 AM, 12345swordy wrote: On Monday, 14 May 2018 at 15:23:41 UTC, Mike Parker wrote: I planned an extended vacation with my wife around DConf this year and, despite my intentions before we left, fell quite far behind on my D duties. I'm in the process of getting caught up with everything, and that includes publishing the results of the first round of the #dbugfix campaign. [...] Be sure to post it in r/programming Please don't. There is no source code in said page and the rules of the subreddit make it pretty clear.
Re: The #dbugfix Campaign Round 1 Report
On Monday, 14 May 2018 at 15:23:41 UTC, Mike Parker wrote: I planned an extended vacation with my wife around DConf this year and, despite my intentions before we left, fell quite far behind on my D duties. I'm in the process of getting caught up with everything, and that includes publishing the results of the first round of the #dbugfix campaign. [...] Be sure to post it in r/programming
The #dbugfix Campaign Round 1 Report
I planned an extended vacation with my wife around DConf this year and, despite my intentions before we left, fell quite far behind on my D duties. I'm in the process of getting caught up with everything, and that includes publishing the results of the first round of the #dbugfix campaign. As far as I'm concerned, it was a successful run. Now, I'm eager to improve upon it. Send some more #dbugfix nominations out into the ether and, while you're at it, volunteer to review some PRs. The issue queue isn't going to shrink all that much until the PR queue gets smaller. Thanks to everyone who nominated an issue or voiced support for a nomination in Round 1, and thanks in advance to those who will in the future! The blog: https://dlang.org/blog/2018/05/14/the-dbugfix-campaign-round-1-report/ reddit: https://www.reddit.com/r/d_language/comments/8jcz5n/the_dbugfix_campaign_round_1_report/
Re: iopipe v0.0.4 - RingBuffers!
On Thursday, 10 May 2018 at 23:22:02 UTC, Steven Schveighoffer wrote: However, I am struggling to find a use case for this that showcases why you would want to use it. While it does work, and works beautifully, it doesn't show any measurable difference vs. the array allocated buffer that copies data when it needs to extend. I can think of a good use-case: - Audio streaming (on embedded environment)! If you have something like a bluetooth audio source, and alsa or any audio hardware API as an audio sink to speakers, you can use the ring-buffer as a fifo between the two. The bluetooth source has its own pace (and you cannot control it) and has a variable bit-rate, whereas the sink has a constant bit-rate, so you have to have a buffer between them. And you want to reduce the CPU cost has much as possible due to embedded system constraints (or even real-time constraint, especially for audio).
Re: iopipe v0.0.4 - RingBuffers!
On 5/14/18 6:02 AM, bioinfornatics wrote: On Thursday, 10 May 2018 at 23:22:02 UTC, Steven Schveighoffer wrote: OK, so at dconf I spoke with a few very smart guys about how I can use mmap to make a zero-copy buffer. And I implemented this on the plane ride home. However, I am struggling to find a use case for this that showcases why you would want to use it. While it does work, and works beautifully, it doesn't show any measurable difference vs. the array allocated buffer that copies data when it needs to extend. If anyone has any good use cases for it, I'm open to suggestions. Something that is going to potentially increase performance is an application that needs to keep the buffer mostly full when extending (i.e. something like 75% full or more). The buffer is selected by using `rbufd` instead of just `bufd`. Everything should be a drop-in replacement except for that. Note: I have ONLY tested on Macos, so if you find bugs in other OSes let me know. This is still a Posix-only library for now, but more on that later... As a test for Ring buffers, I implemented a simple "grep-like" search program that doesn't use regex, but phobos' canFind to look for lines that match. It also prints some lines of context, configurable on the command line. The lines of context I thought would show better performance with the RingBuffer than the standard buffer since it has to keep a bunch of lines in the buffer. But alas, it's roughly the same, even with large number of lines for context (like 200). However, this example *does* show the power of iopipe -- it handles all flavors of unicode with one template function, is quite straightforward (though I want to abstract the line tracking code, that stuff is really tricky to get right). Oh, and it's roughly 10x faster than grep, and a bunch faster than fgrep, at least on my machine ;) I'm tempted to add regex processing to see if it still beats grep. Next up (when my bug fix for dmd is merged, see https://issues.dlang.org/show_bug.cgi?id=17968) I will be migrating iopipe to depend on https://github.com/MartinNowak/io, which should unlock Windows support (and I will add RingBuffer Windows support at that point). Enjoy! https://github.com/schveiguy/iopipe https://code.dlang.org/packages/iopipe http://schveiguy.github.io/iopipe/ Hi Steve, It is an exciting works, that could help in bioinformatics area. Indeed in bioinformatics we are I/O bounding and we process lot of big files the amount of data can be in gigabytes, terabytes and even some times in petabytes. So processing efficiently these amount of data is critic. Some years ago I got a request 'How to parse fastq file format in D?' and monarch_dodra wrote a really fast parser (code: http://dpaste.dzfl.pl/37b893ed ) It could be interesting to show how iopipe is fast. Yeah, I have been working on and off with Vang Le (biocyberman) on using iopipe to parse such formats. He gave a good presentation at dconf this year on using D in bioinformatics, and I think it is a great fit for D! At dconf, I threw together a crude fasta parser (with the intention of having it be the base for parsing fastq as well) to demonstrate how iopipe can perform while parsing such things. I have no idea how fast or slow it is, as I just barely got it to work (pass unit tests I made up based on wikipedia entry for fasta), but IMO, the direct buffer access makes fast parsing much more pleasant than having to deal with your own buffering (using phobos makes parsing a bit difficult, however, I still see a need for some parsing tools for iopipe). You can find that library here: https://github.com/schveiguy/fastaq Not being in the field of bioinformatics, I can't really say that I am likely to continue development of it, but I'm certainly willing to help with iopipe for anyone who wants to use it in this field. -Steve
Re: serialport v1.0.0
On Sun, 2018-05-13 at 12:05 -0600, Jonathan M Davis via Digitalmars-d-announce wrote: […] > > Really? If the consensus is that it should go in, then okay, but I don't > think that I've ever seen a standard library with anything like > functionality for talking to serial ports. And what would having it be in > Phobos buy you over just grabbing it from code.dlang.org? Python is a batteries included distribution. PySerial and PySerial-AsyncIO are packages in PyPI, not in the distibution, and sometime packaged in OS package repositories.. -- Russel. == Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: iopipe v0.0.4 - RingBuffers!
On Thursday, 10 May 2018 at 23:22:02 UTC, Steven Schveighoffer wrote: OK, so at dconf I spoke with a few very smart guys about how I can use mmap to make a zero-copy buffer. And I implemented this on the plane ride home. However, I am struggling to find a use case for this that showcases why you would want to use it. While it does work, and works beautifully, it doesn't show any measurable difference vs. the array allocated buffer that copies data when it needs to extend. If anyone has any good use cases for it, I'm open to suggestions. Something that is going to potentially increase performance is an application that needs to keep the buffer mostly full when extending (i.e. something like 75% full or more). The buffer is selected by using `rbufd` instead of just `bufd`. Everything should be a drop-in replacement except for that. Note: I have ONLY tested on Macos, so if you find bugs in other OSes let me know. This is still a Posix-only library for now, but more on that later... As a test for Ring buffers, I implemented a simple "grep-like" search program that doesn't use regex, but phobos' canFind to look for lines that match. It also prints some lines of context, configurable on the command line. The lines of context I thought would show better performance with the RingBuffer than the standard buffer since it has to keep a bunch of lines in the buffer. But alas, it's roughly the same, even with large number of lines for context (like 200). However, this example *does* show the power of iopipe -- it handles all flavors of unicode with one template function, is quite straightforward (though I want to abstract the line tracking code, that stuff is really tricky to get right). Oh, and it's roughly 10x faster than grep, and a bunch faster than fgrep, at least on my machine ;) I'm tempted to add regex processing to see if it still beats grep. Next up (when my bug fix for dmd is merged, see https://issues.dlang.org/show_bug.cgi?id=17968) I will be migrating iopipe to depend on https://github.com/MartinNowak/io, which should unlock Windows support (and I will add RingBuffer Windows support at that point). Enjoy! https://github.com/schveiguy/iopipe https://code.dlang.org/packages/iopipe http://schveiguy.github.io/iopipe/ -Steve Hi Steve, It is an exciting works, that could help in bioinformatics area. Indeed in bioinformatics we are I/O bounding and we process lot of big files the amount of data can be in gigabytes, terabytes and even some times in petabytes. So processing efficiently these amount of data is critic. Some years ago I got a request 'How to parse fastq file format in D?' and monarch_dodra wrote a really fast parser (code: http://dpaste.dzfl.pl/37b893ed ) It could be interesting to show how iopipe is fast. You can grab a fastq file from ftp://ftp.1000genomes.ebi.ac.uk/vol1/ftp/phase3/data/HG00096/sequence_read/ and take a look at iopipe perf . fastq file is plain test format and it is usually a repetition of four lines: 1/ title and description this line starts with @ 2/ sequence line this line contains ususally DNA letters (ACGT) 3/ comment line this line starts with + 4/ quality of amino acids this line has the same length as the sequence line (n°2) Rarely, the comment section is over multiple lines. Warning the @ and + characters can be found inside the quality line, thus I search a pattern of two characters '\n@' and '\n+'. I never split file by line as it is a waste of time instead I read the content as a stream. I hope this show case help you Good luck :-)
Re: LDC 1.10.0 beta
On Sunday, 13 May 2018 at 18:12:51 UTC, kinke wrote: Hi everyone, on behalf of the LDC team, I'm glad to announce the first beta for LDC 1.10. The highlights of this version in a nutshell: * Based on D 2.080.0. * Supports DragonFly BSD. * Some fixes, most notably wrt. exception stack traces on Linux. Fantastic! And the time flies, wasn’t it 1.4 just recently? ;) Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.10.0-beta1 Thanks to all contributors!
