Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On 10/15/2018 2:23 PM, Walter Bright wrote: I'm giving a presentation at: http://nwcpp.org/ See you there! Had a nice crowd there last night. Apparently lots of people were interested in this topic! Video: https://www.youtube.com/watch?v=lbp6vwdnE0k=youtu.be Slides: http://nwcpp.org/talks/2018/code_smells.pdf
Re: LDC 1.12.0
On Friday, 19 October 2018 at 02:13:15 UTC, Shigeki Karita wrote: On Sunday, 14 October 2018 at 22:16:47 UTC, jmh530 wrote: On Saturday, 13 October 2018 at 16:05:31 UTC, kinke wrote: * New, Easy::jit-like interface for dynamic/JIT compilation. I'm not familiar with Easy::jit. Would it make sense to do some kind of simple tutorial? Or maybe blog post? I'm also interested in the new JIT. I found some useful links - LLVM based C++ JIT library https://github.com/jmmartinez/easy-just-in-time - LDC's doc https://github.com/ldc-developers/ldc/tree/master/docs - LDC's some simple test snippets https://github.com/ldc-developers/ldc/blob/master/tests/dynamiccompile/simple.d https://github.com/jmmartinez/easy-just-in-time/blob/master/doc/slides/cppcon'18.pdf
Re: LDC 1.12.0
On Sunday, 14 October 2018 at 22:16:47 UTC, jmh530 wrote: On Saturday, 13 October 2018 at 16:05:31 UTC, kinke wrote: * New, Easy::jit-like interface for dynamic/JIT compilation. I'm not familiar with Easy::jit. Would it make sense to do some kind of simple tutorial? Or maybe blog post? I'm also interested in the new JIT. I found some useful links - LLVM based C++ JIT library https://github.com/jmmartinez/easy-just-in-time - LDC's doc https://github.com/ldc-developers/ldc/tree/master/docs - LDC's some simple test snippets https://github.com/ldc-developers/ldc/blob/master/tests/dynamiccompile/simple.d
Re: Beta 2.082.0
On Wednesday, 17 October 2018 at 12:14:55 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.083.0 release, ♥ to the 48 contributors for this release. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.083.0.html As usual please report any bugs at https://issues.dlang.org - Highlights: BetterC build option in dub - https://dlang.org/changelog/2.083.0.html#betterC_build_option CppRuntime_* version identifiers - https://dlang.org/changelog/2.083.0.html#cppVersions New isZeroInit trait - https://dlang.org/changelog/2.083.0.html#isZeroIn it DUB_PACKAGE_VERSION environment variable - https://dlang.org/changelog/2.083.0.html#env_var_package_version - -Martin Thanks! Is too much asking to take a look on this bug? https://issues.dlang.org/show_bug.cgi?id=18457 :)
Re: Interfacing D with C: Arrays Part 1
On Wednesday, 17 October 2018 at 15:20:08 UTC, Mike Parker wrote: The blog: https://dlang.org/blog/2018/10/17/interfacing-d-with-c-arrays-part-1/ A good read! It’s always nice to discover new content on the blog.
Re: Interfacing D with C: Arrays Part 1
On Wednesday, 17 October 2018 at 15:20:08 UTC, Mike Parker wrote: I had intended to publish the next GC series post early this month, but after many revisions and discussions with a couple of reviewers, I've decided to put it on hold until something gets worked out about the conflation of destruction and finalization in D (something I'll be pushing for soon). Instead, I've gone back to an article I started writing months ago and put aside in favor of other things: my next post in the 'D and C' series. This post is the first of what will likely be three dealing with arrays (four if you count strings). It focuses primarily on declaration and initialization and is intended to be beginner friendly, assuming little or no knowledge of either C or D. [snip] The original interfacing C and D series on gamedev and in the Learning D book was very useful to me, but I really didn't know C. I mean, I knew the syntax and stuff, but there were so many details that I didn't know. For instance, there was an R library I used that called a C library. As an R user, I wasn't really exposed to any of the underlying C details. So there was quite a bit of learning curve when trying to use it in D, particularly on Windows. For instance, you don't just download the files and convert the headers. The dll the project provided was compiled with MinGW, so you have to recompile it with Visual Studio for it to link properly. My sense is that a lot of the C/D ecosystem just work(TM) a lot easier on Linux, to the extent that if I were doing it over again I would recommend people learning C/D on Windows to just use the Windows Subsystem for Linux for as long as they can.
Re: Interfacing D with C: Arrays Part 1
On Wednesday, 17 October 2018 at 15:20:08 UTC, Mike Parker wrote: but after many revisions and discussions with a couple of reviewers, I've decided to put it on hold until something gets worked out about the conflation of destruction and finalization in D (something I'll be pushing for soon). Instead, I've gone back to an article I started writing months ago and put aside in favor of other things: my next post in the 'D and C' series. Sounds like you have a lot of stuff almost finished, predicting a whole hail of entries in a short time to compensate for the quiet it has been lately. This article is also very good IMO.
Re: Interfacing D with C: Arrays Part 1
On Wednesday, 17 October 2018 at 15:20:08 UTC, Mike Parker wrote: I had intended to publish the next GC series post early this month, but after many revisions and discussions with a couple of reviewers, I've decided to put it on hold until something gets worked out about the conflation of destruction and finalization in D (something I'll be pushing for soon). [...] "article is has morphed"
Re: Spasm - webassembly libary for single page applications
https://github.com/kripken/emscripten/wiki/Pthreads-with-WebAssembly
Re: Spasm - webassembly libary for single page applications
On Wednesday, 17 October 2018 at 19:07:16 UTC, aberba wrote: A common use case for wasm is to port C++ native apps to web. e.g. is the recent autoCAD web app which does almost everything the desktop app can. That's the only reason to IMO do stuff in wasm. Games, productivity software, etc...performance. Spasm might just be perfect for that kind of stuff There are issues getting the current GC ported to webassembly, so it is hard to port D code to wasm. That is one of the reasons why spasm has taken the betterC approach. But remember, spasm is just a library to render and update html, and to respond to dom events. It won't help you in anyway to port something to wasm. If you really want to port existing D code to wasm you either need to rewrite that in betterC or port druntime, which includes writing a precise GC. Dscripten-tools is a move in that direction. The reason spasm exists is because I wanted to optimise web application's rendering code at compile-time, to reduce the runtime (setup) costs and to deliver high performant web applications. I first tried to do that by writing a javascript optimiser that can take React code as input and spit out highly optimised js code. I got pretty far with that but at one point I realised that to do it well I needed advanced things like data-flow analysis and abstract interpretation. So I decided to ditched that and just use D's static introspection and LLVM's wasm target. A couple of weeks after that spasm was born.
