Re: Proposed: start DConf days one hour later
On Thursday, 28 April 2016 at 04:47:38 UTC, Rory McGuire wrote: On 28 Apr 2016 6:30 AM, "Mithun Hunsur via Digitalmars-d-announce" < digitalmars-d-announce@puremagic.com> wrote: On Thursday, 28 April 2016 at 03:44:51 UTC, Mike Parker wrote: On Wednesday, 27 April 2016 at 18:36:54 UTC, Andrei Alexandrescu wrote: The folks at Sociomantic suggested to start at 10:00 AM instead of 9:00 AM, therefore shifting the end time by one as well. Please reply with thoughts on this! We're particularly concerned about folks who need to take off early on Friday. -- Andrei +1 Hmm; my talk's at 3:30pm on Friday (4:30pm after this change), which means I'd leave at 5:30pm. My flight out of Berlin is at 9:30pm; how long does it take to get from the venue to the airport? (I'll probably have to skip the last talk of Friday, which is a shame.) Check Google maps. Google maps can even guess how long it will take at the time you specify. Aha - if Google Maps is accurate, I have nothing to worry about :) For reference, the number it gives me is 37 minutes. In that case, +1 to starting late; that being said, I feel like announcing a sweeping change like this days before the conference seems fraught to end poorly.
Re: Proposed: start DConf days one hour later
On 28 Apr 2016 6:30 AM, "Mithun Hunsur via Digitalmars-d-announce" < digitalmars-d-announce@puremagic.com> wrote: > > On Thursday, 28 April 2016 at 03:44:51 UTC, Mike Parker wrote: >> >> On Wednesday, 27 April 2016 at 18:36:54 UTC, Andrei Alexandrescu wrote: >>> >>> The folks at Sociomantic suggested to start at 10:00 AM instead of 9:00 AM, therefore shifting the end time by one as well. Please reply with thoughts on this! We're particularly concerned about folks who need to take off early on Friday. -- Andrei >> >> >> +1 > > > Hmm; my talk's at 3:30pm on Friday (4:30pm after this change), which means I'd leave at 5:30pm. My flight out of Berlin is at 9:30pm; how long does it take to get from the venue to the airport? (I'll probably have to skip the last talk of Friday, which is a shame.) Check Google maps. Google maps can even guess how long it will take at the time you specify.
Re: Proposed: start DConf days one hour later
On Thursday, 28 April 2016 at 03:44:51 UTC, Mike Parker wrote: On Wednesday, 27 April 2016 at 18:36:54 UTC, Andrei Alexandrescu wrote: The folks at Sociomantic suggested to start at 10:00 AM instead of 9:00 AM, therefore shifting the end time by one as well. Please reply with thoughts on this! We're particularly concerned about folks who need to take off early on Friday. -- Andrei +1 Hmm; my talk's at 3:30pm on Friday (4:30pm after this change), which means I'd leave at 5:30pm. My flight out of Berlin is at 9:30pm; how long does it take to get from the venue to the airport? (I'll probably have to skip the last talk of Friday, which is a shame.)
Re: Proposed: start DConf days one hour later
On Wednesday, 27 April 2016 at 18:36:54 UTC, Andrei Alexandrescu wrote: The folks at Sociomantic suggested to start at 10:00 AM instead of 9:00 AM, therefore shifting the end time by one as well. Please reply with thoughts on this! We're particularly concerned about folks who need to take off early on Friday. -- Andrei +1
Re: Proposed: start DConf days one hour later
On Wednesday, 27 April 2016 at 18:36:54 UTC, Andrei Alexandrescu wrote: The folks at Sociomantic suggested to start at 10:00 AM instead of 9:00 AM, therefore shifting the end time by one as well. Please reply with thoughts on this! We're particularly concerned about folks who need to take off early on Friday. -- Andrei +1 (my flight arrives at 08:30)
Re: Commercial video processing app in D (experience report)
On 4/27/2016 5:42 AM, thedeemon wrote: I just wanted to share some experience of using D in industry. Wonderful, thanks for taking the time to write this up. I'm especially pleased that you found great uses for a couple features that were a bit speculative because they are unusual - the user defined attributes, and the file binary data imports.
Re: Proposed: start DConf days one hour later
On Wednesday, 27 April 2016 at 18:36:54 UTC, Andrei Alexandrescu wrote: The folks at Sociomantic suggested to start at 10:00 AM instead of 9:00 AM, therefore shifting the end time by one as well. Please reply with thoughts on this! We're particularly concerned about folks who need to take off early on Friday. -- Andrei Like!
Re: Proposed: start DConf days one hour later
On Wednesday, 27 April 2016 at 18:36:54 UTC, Andrei Alexandrescu wrote: The folks at Sociomantic suggested to start at 10:00 AM instead of 9:00 AM, therefore shifting the end time by one as well. Please reply with thoughts on this! We're particularly concerned about folks who need to take off early on Friday. -- Andrei Doesn't affect me too much, so I guess it's ok as long as everyone knows. Might even be worth a big notice on the main conference page?
Re: Proposed: start DConf days one hour later
On Wednesday, 27 April 2016 at 18:36:54 UTC, Andrei Alexandrescu wrote: The folks at Sociomantic suggested to start at 10:00 AM instead of 9:00 AM, therefore shifting the end time by one as well. Please reply with thoughts on this! We're particularly concerned about folks who need to take off early on Friday. -- Andrei +1 so the breakfast is from 9:30 to 10:00 at the location?
Re: Minecraft written in D - on Android
On Tuesday, 26 April 2016 at 16:46:16 UTC, Vadim Lopatin wrote: On Tuesday, 26 April 2016 at 14:25:05 UTC, Benjamin Thaut wrote: On Tuesday, 26 April 2016 at 08:42:21 UTC, Vadim Lopatin wrote: Demo of DlangUI Scene3D engine - Minecraft-like voxel rendering - is available for Android/ARM. Post screenshots please. Screenshot from my android device: http://imgur.com/gallery/7wVBk8E How are the frames?
Re: Google Summer of Code
On Monday, 25 April 2016 at 21:58:33 UTC, CRAIG DILLABAUGH wrote: Joseph. If you are interested in becoming a mentor (ideally each project has multiple mentors) I may still be able to add you to our GSoC mentors list. Ilya (Sebastian's mentor) is the lead mentor on the project, but having a second mentor is valuable. If you are interested email me and I will see what we can do: craig dot dillabaugh at gmail dot com Hi Craig, I'm very interested, but concerned about general ability to consistently commit time. I'll email you so that we can follow up on this. Thanks & best wishes, -- Joe
Re: LZ4 decompression at CTFE
On Wednesday, 27 April 2016 at 07:51:30 UTC, Dejan Lekic wrote: That is brilliant! I need LZ4 compression for a small project I work on... The decompressor is ready to be released. It should work for all files compressed with the vanilla lz4c -9 please regard this release as alpha quality. https://github.com/UplinkCoder/lz4-ctfe P.S and I did not tweak the source. The compressed file size just happens to be 1911. I take this as a sign of correctness. P.P.S Actually LZ4 is a much more interesting topic then SQLite. If you don't mind I am going to talk about that :)
Re: Proposed: start DConf days one hour later
On Wednesday, 27 April 2016 at 18:36:54 UTC, Andrei Alexandrescu wrote: The folks at Sociomantic suggested to start at 10:00 AM instead of 9:00 AM, therefore shifting the end time by one as well. Please reply with thoughts on this! We're particularly concerned about folks who need to take off early on Friday. -- Andrei Good Idea! +1
Re: Proposed: start DConf days one hour later
On Wednesday, 27 April 2016 at 18:36:54 UTC, Andrei Alexandrescu wrote: The folks at Sociomantic suggested to start at 10:00 AM instead of 9:00 AM, therefore shifting the end time by one as well. Please reply with thoughts on this! We're particularly concerned about folks who need to take off early on Friday. -- Andrei from my experience hardly anyone is fully awake before 10am in berlin anyway. :P
Re: Proposed: start DConf days one hour later
On 4/27/16 2:36 PM, Andrei Alexandrescu wrote: The folks at Sociomantic suggested to start at 10:00 AM instead of 9:00 AM, therefore shifting the end time by one as well. Please reply with thoughts on this! We're particularly concerned about folks who need to take off early on Friday. -- Andrei As someone whose time zone will put that at 4 am instead of 3 am (and I know there are those who have it worse), sounds good to me :) But I'm concerned about those who don't always read all the forum posts. Should this be asked as a general email to conference-goers? -Steve
Re: Web page listing all D compilers (and DMDFE version!) on travis-ci
On 04/26/2016 02:42 AM, Nick Sabalausky wrote: https://semitwist.com/travis-d-compilers ... - Auto-trigger an update check on a regular basis (I'm thinking once daily?) so I don't have to stay on top of new compiler versions and trigger an update manually. (I can use Travis's API to do this.) The page is now set to automatically check for updates every 24 hours. So it should always be automatically up-to-date now. No intervention needed by myself or any of the DMD/LDC/GDC developers.
Proposed: start DConf days one hour later
The folks at Sociomantic suggested to start at 10:00 AM instead of 9:00 AM, therefore shifting the end time by one as well. Please reply with thoughts on this! We're particularly concerned about folks who need to take off early on Friday. -- Andrei
Re: Commercial video processing app in D (experience report)
On 04/27/2016 01:17 PM, thedeemon wrote: On Wednesday, 27 April 2016 at 12:42:05 UTC, thedeemon wrote: full build of GUI app takes 7 seconds Forgot to mention one anecdote: the build time increases by another 7 seconds if I use std.net.curl.get() function instead of std.net.curl.HTTP struct for doing a simple GET from our site. What is the reason for this, could you please investigate a bit? -- Andrei
Re: Minecraft written in D - on Android
On Tuesday, 26 April 2016 at 16:33:51 UTC, Vadim Lopatin wrote: Edit paths in file android_build_config.mk export DLANGUI_DIR=$HOME/src/d/dlangui export NDK=$HOME/android-ndk-r11c export SDK=$HOME/android-sdk-linux export LDC=$HOME/ldc2-android-arm-0.17.0-alpha2-linux-x86_64 export NDK_ARCH=x86_64 export JAVA_HOME=/usr/lib/jvm/java-8-oracle/ To build package, you will need Android NDK, SDK, LDC2 for android. In Android SDK manager, download platform android-19 (Android 4.4.X) Build is tested only on Linux X64. More build instructions: https://github.com/buggins/dlangui/blob/master/examples/dminer/android_project/README.md I think I will just skip on the android build... Anyway, dminer starts but um... are the controls and graphics supposed to be like that? Still well done integrating OpenGL into dlangui, thats gonna make it much more interesting for me to use!
Re: Commercial video processing app in D (experience report)
On Wednesday, 27 April 2016 at 15:57:19 UTC, Christof Schardt wrote: Just a question: When working with C++, did you use VisualAssist? I've used it previously in earlier VS versions but not in VS2010. VisualAssist is really great, I agree. VisualD is far from it but at least it's better than C++ support in plain VS2010 without VA.
Re: Commercial video processing app in D (experience report)
On Wednesday, 27 April 2016 at 12:42:05 UTC, thedeemon wrote: IDE Visual Studio 2010 with VisualD. I've used this combo for many years, generally quite successively. Last year its D parser had Thanks for this excellent contribution. It gives a lot of insights. Just a question: When working with C++, did you use VisualAssist? I find this VisualC++-AddOn so incredibly useful, that the lack of something comparable for D is one of the biggest obstacles for switching to D (another obstacle is the number of ~500kloc of my project, music notation).
Re: Commercial video processing app in D (experience report)
On Wednesday, 27 April 2016 at 12:42:05 UTC, thedeemon wrote: Hi, I just wanted to share some experience of using D in industry. Recently my little company released version 2.0 of our flagship product Video Enhancer, a video processing application for Windows, and this time it's written in D. http://www.infognition.com/VideoEnhancer/ [...] Thanks for the great writeup! :)
Re: Commercial video processing app in D (experience report)
On Wednesday, 27 April 2016 at 14:14:02 UTC, FreeSlave wrote: On Wednesday, 27 April 2016 at 14:07:18 UTC, FreeSlave wrote: On Wednesday, 27 April 2016 at 13:58:13 UTC, thedeemon wrote: On Wednesday, 27 April 2016 at 13:04:27 UTC, FreeSlave wrote: Screenshots are so blurred. They are not. Just click to enlarge, your browser blurred them while resizing. They are. Well, maybe blurred is not the right word, but screenshots have obvious jpeg artifacts. Even those that have png extension. Just look at window title in window header. Ok, I'm not right about png ones. They look ok if I download them to computer and open in photo viewer. Weird Google Chrome renders them worse then they are (in 100% scale). Images look good (even jpeg ones) if I use open original image in new tab. Though both have the same address. Can't explain what the issue here.
Re: Commercial video processing app in D (experience report)
On Wednesday, 27 April 2016 at 14:07:18 UTC, FreeSlave wrote: On Wednesday, 27 April 2016 at 13:58:13 UTC, thedeemon wrote: On Wednesday, 27 April 2016 at 13:04:27 UTC, FreeSlave wrote: Screenshots are so blurred. They are not. Just click to enlarge, your browser blurred them while resizing. They are. Well, maybe blurred is not the right word, but screenshots have obvious jpeg artifacts. Even those that have png extension. Just look at window title in window header. Ok, I'm not right about png ones. They look ok if I download them to computer and open in photo viewer. Weird Google Chrome renders them worse then they are (in 100% scale).
Re: Commercial video processing app in D (experience report)
On Wednesday, 27 April 2016 at 13:04:27 UTC, FreeSlave wrote: Screenshots are so blurred. They are not. Just click to enlarge, your browser blurred them while resizing.
Re: Commercial video processing app in D (experience report)
That's great. I'm surprised someone used DlangUI for commercial app. I would not say it's quite ready even for free ones. It's cool you merged your changes. On Wednesday, 27 April 2016 at 12:42:05 UTC, thedeemon wrote: Couple of screenshots: http://data.infognition.com/VideoEnhancer/ve2d-filters.jpg http://data.infognition.com/VideoEnhancer/ve2e-save.jpg Screenshots are so blurred. Do you encourage us to use video enhancer to get better image quality? :)
Commercial video processing app in D (experience report)
Hi, I just wanted to share some experience of using D in industry. Recently my little company released version 2.0 of our flagship product Video Enhancer, a video processing application for Windows, and this time it's written in D. http://www.infognition.com/VideoEnhancer/ Couple of screenshots: http://data.infognition.com/VideoEnhancer/ve2d-filters.jpg http://data.infognition.com/VideoEnhancer/ve2e-save.jpg Version 1 was born like 10 years ago and was of course written in C++. It consisted of main GUI executable and 5 dynamically loaded DirectShow filters. For GUI version 1 used MFC and a third-party skinning engine. This skinning engine had its own problems but since we didn't have its sources we couldn't fix them, meanwhile its author disappeared in sands of time. So when time has come to create version 2 I chose the best available language and an open source GUI library with 100% control and customizability - DLangUI. Overall, I'm pretty happy with this choice. Version 2 is quite different from v1 in feature set and internal structure, it's not a direct translation. It consists of two executables running in tandem (one does GUI, the other deals with video) and 2 dynamically loaded DirectShow filters. Both main executables are purely in D, while the DirectShow filters are still in C++. Heavy number crunching, including our main feature - motion-based video upscaler - is still in C++, because of heavy SIMD usage and Intel compiler. Main executable of version 1 was ~34K lines of C++ (half of which were libraries like pugixml) and full build took ~90 seconds. Main executables of version 2 are in total ~7.5K lines of D (of which 2K are auto generated by IDL2D tool) and full build of GUI app takes 7 seconds (and the worker app builds in 3-4 seconds), so that's a really nice improvement. Thanks to Phobos we don't need many libraries: things like XML parsing, ZIP unpacking and many others are all covered by the standard library. Only two additional libraries were used: Cerealed for serialization of messages the two processes exchange, and DLangUI. Some things to reflect on: Compiler Compiler used is DMD 2.070, 32-bit target. Video Enhancer supports 200+ plugins from VirtualDub and they happen to be 32-bit, so our app has to be 32-bit too. Speed of code generated by DMD is more than enough, even debug builds were fast enough. The default linker is used (not the MS one), and I was worried there might be some troubles with antivirus false positives (that happened before when using optlink) but no, everything went smooth and no problems with optlink arose whatsoever. IDE Visual Studio 2010 with VisualD. I've used this combo for many years, generally quite successively. Last year its D parser had some problems that made it crash on code that used DLangUI, and that was painful. I even made a patch that made the crash silent, so VisualD would silently reload the parser and continue working. It worked, but luckily authors of D parser and VisualD quickly found the crash cause and fixed it, since then everything works smoothly out of the box. I like how well DML works there, with syntax highlighting and autocompletion: http://data.infognition.com/VideoEnhancer/dml.png Builds We're not using Dub to build the app, it tends to be slow and rebuild dependencies too often (or maybe I just haven't learnt to use it properly). Instead we use Dub to build the libraries and produce .lib files, then reference libraries sources and lib files in VisualD project of the main apps and then use VisualD's simple building process that just invokes DMD. Cerealed This compile-time-introspection-based serializaition lib is really great: powerful and easy to use. We're probably using an old version, haven't updated for some time, and the version we use sometimes had problems serializing certain types (like bool[], IIRC), so sometimes we had to tweak our message types to make it compile, but most of the time it just works. DLangUI Very nice library. Documentation is very sparse though, so learning to use DLangUI often means reading source code of examples and the lib itself, and sometimes even that's not enough and you need to learn some Android basics, since it originates from Android world. But once you learn how to use it, how to encode what you need in DML (a QML counterpart) or add required functionality by overriding some method of its class, it's really great and pleasant to use. Many times I was so happy the source code is available, first for learning, then for tweaking and fixing bugs. I've found a few minor bugs and sent a few trivial fixes that were merged quickly. DLangUI is cross-platform and has several backends for drawing and font rendering. We're using its minimal build targeted to use Win32 API (had to tweak dub.json a bit). We don't use OpenGL, as it's not really guaranteed to work well on any Windows box. Using just WinAPI makes our app
Re: simple VFS implementation
iv.vfs gained ability to list files in all registered VFSes, and it now can open disk files regardless of name case on POSIX systems (this is controlled by global flags, or additional letters «i» and «I» in file mode arg).
Re: LDC 1.0.0-beta1 has been released! Please help testing!
On Wednesday, 27 April 2016 at 08:48:48 UTC, Sönke Ludwig wrote: Am 25.04.2016 um 08:42 schrieb Kai Nacke: Hi everyone, LDC 1.0.0-beta1, the LLVM-based D compiler, is available for download! This BETA release is based on the 2.070.2 frontend and standard library and supports LLVM 3.5-3.8. The 1.0 release will be a major milestone. Please help testing to make it the best release ever! We provide binaries for Linux, OX X, Win32 & Win64, Linux/ARM (armv7hf). :-) As usual, you can find links to the changelog and the binary packages over at digitalmars.D.ldc: http://forum.dlang.org/post/bwrnvztwkzhhwhzsk...@forum.dlang.org Regards, Kai Just tried and now fails to find "libconfig.so.8" on Travis-CI (worked for alpha1): https://travis-ci.org/rejectedsoftware/vibe.d/jobs/126048861 See: https://github.com/ldc-developers/ldc/issues/1460 https://github.com/travis-ci/travis-ci/issues/5952
Re: LDC 1.0.0-beta1 has been released! Please help testing!
Am 25.04.2016 um 08:42 schrieb Kai Nacke: Hi everyone, LDC 1.0.0-beta1, the LLVM-based D compiler, is available for download! This BETA release is based on the 2.070.2 frontend and standard library and supports LLVM 3.5-3.8. The 1.0 release will be a major milestone. Please help testing to make it the best release ever! We provide binaries for Linux, OX X, Win32 & Win64, Linux/ARM (armv7hf). :-) As usual, you can find links to the changelog and the binary packages over at digitalmars.D.ldc: http://forum.dlang.org/post/bwrnvztwkzhhwhzsk...@forum.dlang.org Regards, Kai Just tried and now fails to find "libconfig.so.8" on Travis-CI (worked for alpha1): https://travis-ci.org/rejectedsoftware/vibe.d/jobs/126048861
Re: LZ4 decompression at CTFE
On Tuesday, 26 April 2016 at 22:05:39 UTC, Stefan Koch wrote: Hello, originally I want to wait with this announcement until DConf. But since I working on another toy. I can release this info early. So as per title. you can decompress .lz4 flies created by the standard lz4hc commnadline tool at compile time. No github link yet as there is a little bit of cleanup todo :) Please comment. That is brilliant! I need LZ4 compression for a small project I work on...
Beta release DUB 0.9.25-beta.2
This is the first beta of 0.9.25, which should be considered an extended beta for 1.0.0, which will follow shortly afterwards. The API has now been cleaned up and is in a state that is acceptable for a stable release, even if it still isn't particularly idiomatic in many places (e.g. no ranges or @safe/@nogc annotations are used). Other major changes: - Builds on frontend versions up to 2.071.0 now - Implements proper optional dependency semantics, where using an optional dependency can now be controlled using dub.selections.json - "dub init" is now interactive by default (use -n to disable) - Contains some critical changes regarding path based dependencies Full change log: https://github.com/D-Programming-Language/dub/blob/master/CHANGELOG.md Download (Latest Preview): http://code.dlang.org/download
Re: LZ4 decompression at CTFE
On 4/26/2016 3:05 PM, Stefan Koch wrote: Hello, originally I want to wait with this announcement until DConf. But since I working on another toy. I can release this info early. So as per title. you can decompress .lz4 flies created by the standard lz4hc commnadline tool at compile time. No github link yet as there is a little bit of cleanup todo :) Please comment. Sounds nice. I'm curious how it would compare to: https://www.digitalmars.com/sargon/lz77.html https://github.com/DigitalMars/sargon/blob/master/src/sargon/lz77.d
