Re: LDC 1.15.0
On Sunday, 7 April 2019 at 15:14:59 UTC, kinke wrote: On Sunday, 7 April 2019 at 14:26:16 UTC, Thomas Mader wrote: Were there some changes to the shared phobos unittest runners between beta2 and the final release? I ask because I have the problem on macOS with the final release that libphobos2-ldc-unittest-shared.85.dylib is not fixed by my fixing step to switch to absolute paths referencing. I use install_name_tool and run this step after I do 'make all-test-runners'. It used to work previously and also with beta2. My guess is that libphobos2-ldc-unittest-shared.85.dylib is getting created after my fixing step now for some reason. No changes wrt. the test runners, especially none wrt. build order. The only CMake change was the frontend version. See https://github.com/ldc-developers/ldc/compare/v1.15.0-beta2...v1.15.0. In [1] you mentioned that it might be an order problem because I used make instead of ninja but the problem occurred again. I got it working now by setting the DYLD_LIBRARY_PATH variable to the build/lib directory. For some reason the phobos2-test-runner-debug-shared binary didn't have the full path to libphobos2-ldc-unittest-debug-shared.85.dylib [2]. The druntime test didn't have this problem and the problem was also not always reproducible I believe. For me it's not a problem anymore but maybe it's a pointer to something problematic. [2] otool -L /private/var/folders/wq/m1dnr42s42n5msqk2v8l0lfcgn/T/nix-build-ldc-1.15.0.drv-4/ldc-1.15.0-src/build/runtime/phobos2-test-runner-debug-shared /private/var/folders/wq/m1dnr42s42n5msqk2v8l0lfcgn/T/nix-build-ldc-1.15.0.drv-4/ldc-1.15.0-src/build/runtime/phobos2-test-runner-debug-shared: libphobos2-ldc-unittest-debug-shared.85.dylib (compatibility version 85.0.0, current version 2.0.85) /private/var/folders/wq/m1dnr42s42n5msqk2v8l0lfcgn/T/nix-build-ldc-1.15.0.drv-4/ldc-1.15.0-src/build/lib/libdruntime-ldc-debug-shared.2.0.85.dylib (compatibility version 85.0.0, current version 2.0.85) /nix/store/mkfq1a1i6n66fahlcjvw890xj32zvlqp-Libsystem-osx-10.11.6/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1) [1] https://forum.dlang.org/post/rsfddgngewcloqucy...@forum.dlang.org
Re: New DConf Blog Post
On Saturday, 23 March 2019 at 10:09:12 UTC, Ali Çehreli wrote: Thank you but this is only about software development tools. I know. But that's still a good marketing. And I'm fan of your tech talks as well. Coding guidelines like MISRA and AUTOSAR have been developed and matured for C++ for years. There is no equivalent for D for it to be even considered by the automotive industry. Well, MISRA is an evidance that C (C++) is quite error prone by desing. I think, D can do better, . And the lack of dedicated tools is just a consequence of shortage on funds. And I always say that the fact that C needs so many different tools (including those for AUTOSAR) is its disadventage actually (they consumes a lot of money and development time). But it is how the World works now. But who knows the furure? ;) Cheers, Piotrek
Re: LDC 1.15.0
On Friday, 12 April 2019 at 13:54:05 UTC, kinke wrote: [snip] I'd use something like version (LDC) import ldc.attributes : restrict; else enum restrict = null; Excellent. Thanks.
Re: LDC 1.15.0
On Friday, 12 April 2019 at 13:54:05 UTC, kinke wrote: [snip] I'd use something like version (LDC) import ldc.attributes : restrict; else enum restrict = null; Much better, thanks.
DConf 2019: 50% Education/Open Source Discount
Symmetry has recently let me know that they're covering a 50% discount off the standard DConf registration rate to students, academics, and major open source contributors. If that's you and you'd like to take advantage of it, please contact me (aldac...@gmail.com) and let me know.
Re: LDC 1.15.0
On Friday, 12 April 2019 at 13:26:14 UTC, jmh530 wrote:
The @llvmAttr("noalias") compiled on run.dlang.org, but I
couldn't get the @restrict to work. I assume that uses the most
recent version of LDC, but I don't really know.
--version as cmdline switch tells you the run.dlang.io version is
still at v1.14 (as is the ldc-beta there).
unless you have other recommendations.
I'd use something like
version (LDC) import ldc.attributes : restrict;
else enum restrict = null;
Re: LDC 1.15.0
On Saturday, 6 April 2019 at 17:40:39 UTC, kinke wrote:
* New generic @llvmAttr("name") parameter UDAs, incl. @restrict
with C-like semantics.
[snip]
I think I had passed over this when I first read the
announcement. The @llvmAttr("noalias") compiled on run.dlang.org,
but I couldn't get the @restrict to work. I assume that uses the
most recent version of LDC, but I don't really know.
Hmm, given that these work in LDC and not DMD, making code that
uses it compiler-agnostic might be a little more roundabout. The
best I could think of was something like below, unless you have
other recommendations.
version(LDC) {
import ldc.attributes;
}
mixin template fooImpl() {}
version(LDC) {
void foo(@llvmAttr("noalias") void* p) {
mixin fooImpl;
}
} else {
void foo(void* p) {
mixin fooImpl;
}
}
void main()
{
}
Re: New DConf Blog Post
On Thursday, 11 April 2019 at 16:56:27 UTC, Nick Sabalausky (Abscissa) wrote: On 4/11/19 10:11 AM, wjoe wrote: No offense, but http://motherfuckingwebsite.com/ That is the best website EVER. Times a billion. Says exactly the things I've been wanting to scream at jet-engine volume straight into the faces of every web designer and full-stacker in the world. "Responsive web" always made me cringe. HTML-freaking-version-ONE was responsive. And semantic. It was specifically *designed* to be. But then the designers and the know-nothing software managers came, hated that stuff, and killed it all with fire. Then when the sausage-finger small screens came (not to mention browser diversity and "emerging markets"), they shit a brick and started over-re-engineering everything that was already there all along (plus some extra garbage nobody needs). Idiots. Yeah, that, and it respects a browser's font and size configuration :) Visiting a web-site I often think to myself: Fail! You can still manage to read that 7pt font by attaching your eyeballs to the screen! If you don't want people to be able to read it, you should remove that text altogether! Saves you all the effort, too. These so called web designers who work s hard to find all possible ways to stop you from comfortably reading the thing with tons of useless java script "coolness" and distracting banners and drop downs and otherwise hidden information you need to find the spot to tickle to make it appear (is that a secret cry for help?) and pictures that stalk you but can't make text flow around a picture without using DIV - and then need to nail everything else in place with more DIVs. Amusing :) They can't even make normal hyperlinks work and spend tons of effort trying to imitate it with java script. Delicious :) And their white on black design which makes you see nothing but zebras for the rest of the day or so after spending 2 minutes on it...love it! :)
Re: LDC 1.15.0
On Saturday, 6 April 2019 at 17:40:39 UTC, kinke wrote:
Glad to announce LDC 1.15:
* Based on D 2.085.1.
* Support for LLVM 8.0. The prebuilt packages ship with LLVM
8.0.0 and include the Khronos SPIRV-LLVM-Translator, so that
dcompute can now emit OpenCL too.
* New -lowmem switch to enable the GC for the front-end,
trading compile times for less required memory (in some cases,
by more than 60%).
* New generic @llvmAttr("name") parameter UDAs, incl. @restrict
with C-like semantics.
* Dropped support for 32-bit macOS. Min macOS version for
prebuilt package raised to 10.9.
* Prebuilt packages don't depend on libtinfo/libedit and don't
require SSSE3 anymore.
* Fix: functions annotated with `pragma(inline, true)` are
implicitly cross-module-inlined again.
[...]
Thank you!
Re: Visual D 0.49.0 released
On Sunday, 7 April 2019 at 19:41:43 UTC, Rainer Schuetze wrote: Hello, the new release of Visual D has just been uploaded. Some major improvements of 0.49.0: * support for Visual Studio 2019 * parallel compilation supported by VC projects * catch up with recent language changes * new "Language" configuration page for -transition=/-preview=/-revert= options See http://rainers.github.io/visuald/visuald/VersionHistory.html for the full list of changes. Visual D is a Visual Studio extension that adds D language support to VS2008-2019. It is written in D, its source code can be found on github: https://github.com/D-Programming-Language/visuald, pull requests welcome. The installer can be found at http://rainers.github.io/visuald/visuald/StartPage.html Rainer Great work, thanks! Found some issues in Visual Studio 2019 when debugging I get an occasional crash. Will post a bug once I can isolate the issue.
Re: OpenWL/DL - two foundation libraries for building a cross-platform GUI with non-C++ languages
On Friday, 12 April 2019 at 10:02:53 UTC, DanielG wrote: Oh, and I see now you were only asking about OpenWL, not the both of them. Derp. So yeah, just the complete lack of OpenGL support really :P Well I don't mind you telling more about OpenDL either. :) My first reaction to "I made a cross-platform windowing library with C API" was "glfw already got that covered", but I now see how this focuses more on static windows for GUI's rather than hardware-accelerated drawing. I've worked with high-level GUI libraries and with low-level OpenGL canvasses before, but I'm not familiar with platform-native CPU drawing so this project actually piqued my interest now.
Re: OpenWL/DL - two foundation libraries for building a cross-platform GUI with non-C++ languages
On Friday, 12 April 2019 at 08:03:01 UTC, Dennis wrote: I'm currently using glfw for that, how does OpenWL compare? Oh, and I see now you were only asking about OpenWL, not the both of them. Derp. So yeah, just the complete lack of OpenGL support really :P
Re: OpenWL/DL - two foundation libraries for building a cross-platform GUI with non-C++ languages
On Friday, 12 April 2019 at 08:03:01 UTC, Dennis wrote: I'm currently using glfw for that, how does OpenWL compare? Good question. I've not spent much time with OpenGL-y things, but from what little I know: - OpenWL doesn't use or provide OpenGL contexts. I'm sure it will be added eventually, but at this time it's meant to provide a canvas for platform-native drawing - such as Quartz2D (still CPU-rendered AFAIK), Direct2D (GPU accelerated), and Cairo (CPU). - With OpenDL, you ideally don't have to write any of your own drawing-primitives code. Need beziers, gradients, fancy masking with text outlines? If Quartz2D/CoreText supports it, then it's either already present, or I can add it quickly. - OpenWL/DL aren't designed for games or insane frame rates. I *do* think a smooth, 60fps experience is worth shooting for, but because it's CPU-bound with Quartz2D on Mac, and Cairo on Linux, that will depend entirely on the user's resolution / CPU. (But Direct2D is GPU-accelerated and already crazy fast) When I get a chance, I do plan on looking into how difficult it would be to implement a Core Animation compatible API, to allow for smooth scrolling / scaling / etc of large pre-rendered areas via GPU. (MacOS uses CoreAnim to speed up things like scrolling, which would otherwise be choppy when CPU-rendered on a 5K display). - OpenWL is event-based, not polling-based. In the OpenGL demos I've seen in the past, the render loop goes as fast as it can. Whereas OpenWL waits for the platform windowing system to notify it of whatever events have occurred. If nothing is happening, there is no drawing/activity. Now, an alternative to OpenWL/DL might be something GLFW+NanoVG. And I certainly looked into those kinds of options before going this route. But ultimately I decided against it, because I wanted to build on top of what Apple/Microsoft/GNOME are actively working on. I figured, let the big companies focus on making what they feel are the best drawing APIs for their respective platforms, and I'll just ride on their coattails (and optimizations) ... At this time, a purely OpenGL drawing library is still a little too DIY for me. Now maybe if the Slug text rendering library were open source, and a number of people were actively trying to integrate it with NanoVG, then I could be persuaded... Another benefit of not using OpenGL, is that I can eventually support esoteric platforms with no modern OpenGL support, but for which Cairo/Pango can be compiled. Things like: MorphOS/Amiga, QNX Photon, OS/2, Mac OS9/Carbon, etc. Pretty much anything with a conventional single-threaded GUI, really.
Re: New and Unofficial OpenCV binding for D programming language
On Wednesday, 10 April 2019 at 14:44:49 UTC, Andrea Fontana wrote: On Tuesday, 9 April 2019 at 17:22:12 UTC, Ferhat Kurtulmuş wrote: Since I could build the library on Windows 10 in addition to Ubuntu, I have decided to put it on code.dlang.org: https://code.dlang.org/packages/opencvd. It sounds interesting. I think you should make those examples compilable with dub! Andrea Client apps need generated libs in the root folder of app. I could not find a solution to copy them automagically yet. Maybe dub has a feature doing it. Helps are welcome.
Re: OpenWL/DL - two foundation libraries for building a cross-platform GUI with non-C++ languages
On Friday, 12 April 2019 at 06:45:01 UTC, DanielG wrote: These aren't written in D, but they are *for* D (or any other non-C++ language in need of its own canonical, language-native GUI). They export a C API for maximum ease of use. OpenWL[1] - cross-platform top-level windowing library, with native menus, events, clipboard/DnD. OpenDL[2] - cross-platform drawing library (with Quartz2D/CoreText-compatible API), built on the native APIs for each platform: Quartz2D/CoreText for Mac, Direct2D/DirectWrite for Windows, and GTK/Pango for Linux. Nice!
Re: OpenWL/DL - two foundation libraries for building a cross-platform GUI with non-C++ languages
On Friday, 12 April 2019 at 06:45:01 UTC, DanielG wrote: OpenWL[1] - cross-platform top-level windowing library, with native menus, events, clipboard/DnD. I'm currently using glfw for that, how does OpenWL compare?
OpenWL/DL - two foundation libraries for building a cross-platform GUI with non-C++ languages
These aren't written in D, but they are *for* D (or any other non-C++ language in need of its own canonical, language-native GUI). They export a C API for maximum ease of use. OpenWL[1] - cross-platform top-level windowing library, with native menus, events, clipboard/DnD. OpenDL[2] - cross-platform drawing library (with Quartz2D/CoreText-compatible API), built on the native APIs for each platform: Quartz2D/CoreText for Mac, Direct2D/DirectWrite for Windows, and GTK/Pango for Linux. There is still plenty of work to be done on these, but they're ready to make public and start getting some feedback / bug reports / etc. Right now only Windows/Mac/Linux are (equally!) tested/supported, and I'll have to focus on those for the time being to really polish these libraries, but I fully intend to port them to more niche platforms in the future. Why? I know there are some people who want to start GUI projects with their language of choice (D/Nim/Haskell/Rust/etc), but trying to lay the foundation to abstract away platform differences is a big, annoying detour for people who just want to get started. So I did all that annoying work because I'm a weird dude and find this kind of thing enjoyable ... to an extent :) You can ask any questions here, or on the Gitter[3] I've created for both projects: [1] https://github.com/dewf/openwl [2] https://github.com/dewf/opendl [3] https://gitter.im/GUImakers/OpenWL-DL?utm_source=share-link_medium=link_campaign=share-link
