Re: dlang-requetst: openssl 1.1 compatible release
On Thursday, 3 August 2017 at 06:33:38 UTC, ikod wrote: Hello, Since version 0.5.0 dlang-requests has become compatible with both 1.0.x and 1.1.x versions of openssl library. Please try and report any issues on github. Thanks! dlang-requests is HTTP/FTP client library, inspired by python-requests with goals: small memory footprint performance simple, high level API native D implementation https://code.dlang.org/packages/requests https://github.com/ikod/dlang-requests Does dlang-requests support binding interface for outgoing connection, like curl --interface option?
Re: SVD_to_D: Generate over 100k lines of highly-optimized microcontroller mmapped-IO code in the blink of an eye
On Wednesday, 2 August 2017 at 13:31:40 UTC, Steven Schveighoffer wrote: On 8/1/17 8:34 PM, Mike wrote: On Tuesday, 1 August 2017 at 14:52:51 UTC, Steven Schveighoffer wrote: [...] I'm not sure my work is worthy of such kind words, but thank you. Sorry, it was awesome. You should own it. I think many people were impressed with what you were able to achieve, especially those who have dealt with embedded programming. The PDF screen utility is here: https://github.com/JinShil/stm32_datasheet_to_d. I'm not sure if it still compiles and works, but I might need to update it someday. It generates much better code and more complete documentation than svd_to_d. Most silicon vendors don't appear to invest much into their SVD files, so the SVD files are often incomplete and lacking the documentation that makes "good code + a good IDE = a substitute for the datasheet". > If I were creating a professional product, I'd probably prefer scraping the PDF over using the SVD files, or maybe some way to merge the two. Yes, if the datasheet is wrong, they probably hear about it more, and fix it more readily than some xml files. Much harder to fix etch than it is to update some software. In addition, I bet the software engineers take both into account and defer to the spec, meaning the bugs in the SVD may not get reported. I would prefer the more accurate picture if it were me. In fact, you may be able to give them a better tool to generate the SVD file from the pdf :) -Steve I'm not completely sure but I would guess that the documentation was generated from the .svd files. If you think about it doing the documentation by hand would be another thing that the chip manufactures would have to validate against. If the documentation is generated from the .svd and the documentation is correct than the .svd file is also correct.
Re: dlang-requetst: openssl 1.1 compatible release
On Friday, 4 August 2017 at 17:06:16 UTC, Jack Applegame wrote: On Thursday, 3 August 2017 at 06:33:38 UTC, ikod wrote: Hello, Since version 0.5.0 dlang-requests has become compatible with both 1.0.x and 1.1.x versions of openssl library. Please try and report any issues on github. Thanks! dlang-requests is HTTP/FTP client library, inspired by python-requests with goals: small memory footprint performance simple, high level API native D implementation https://code.dlang.org/packages/requests https://github.com/ikod/dlang-requests Does dlang-requests support binding interface for outgoing connection, like curl --interface option? No, but this can be done. It would be nice if you post issue on github. Thanks!
Re: Calling D from Ruby for GPU computing
On Saturday, 29 July 2017 at 06:54:47 UTC, Prasun Anand wrote: Hi, I wrote a Linear Mixed Model tool for Genome Wide Association Studies(GWAS) called [faster_lmm_d](https://github.com/prasunanand/faster_lmm_d). It is built on LDC and is faster than its Python alternative. Also, its the only GWAS tool with a GPU backend. I am interested in porting ` faster_lmm_d` to Ruby. Though, it is still a work in progress, I have written a blog about my findings. Blog: http://www.prasunanand.com/gpu-computing/2017/07/25/gsoc17-calling-d-from-ruby-for-gpu-computing.html I would love to hear your feedback. Regards, Prasun [Previously posted on LDC thread: http://forum.dlang.org/thread/rzrawenyssbiidsgt...@forum.dlang.org] I don't know much about your work but it sounds like an interesting application for D. How easy was it interfacing with cuda? Was it just cuda you targeted or would it also work with OpenCL? What made you choose D over going straight to C to work directly with cuda?
