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: 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.
Full release log and downloads:
https://github.com/ldc-developers/ldc/releases/tag/v1.15.0
Thanks to all contributors!
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.
Re: LDC 1.15.0-beta2
On Sunday, 24 March 2019 at 02:15:38 UTC, kinke wrote: Glad to announce the second beta for LDC 1.15, with these changes compared to beta1 (https://forum.dlang.org/thread/wavjrnwlxkkpzkqjv...@forum.dlang.org): * Based on current DMD stable. * LLVM for prebuilt packages upgraded to v8.0.0 final. * Fixed beta1 regression: prebuilt Linux x86_64 package is usable with older linkers again (e.g., on Ubuntu 14.04). * Fixed beta1 regression: dcompute is usable again. * Prebuilt packages don't depend on libtinfo and libedit anymore. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.15.0-beta2 Please help test, and thanks to all contributors! The lowmem switch tests [1] fail for me because I use ltsmaster as the bootstrap compiler. 1) I think those tests should not run in this szenario. 2) I know that I need to rebuild ldc with itself to get the lowmem switch support in the long run but I wonder if that would not be better integrated into your cmake build via an option. Otherwise the packagers out there need to do it for themselves. [1] https://github.com/ldc-developers/dmd-testsuite/blob/ldc/runnable/xtest46_gc.d https://github.com/ldc-developers/dmd-testsuite/blob/ldc/runnable/testptrref_gc.d https://github.com/ldc-developers/dmd-testsuite/blob/ldc/fail_compilation/mixin_gc.d
Re: Getting error in dmd testsuite
On Thursday, 28 December 2017 at 14:45:54 UTC, Thomas Mader wrote: gcc does not create the symbol at all on NixOS. I already created an issue for NixOS: https://github.com/NixOS/nixpkgs/issues/28896 I am not supposed to ask here but maybe someone knows about problems with gcc? I finally found out why the symbols are missing. See https://issues.dlang.org/show_bug.cgi?id=19553#c3
Re: Add D front-end, libphobos library, and D2 testsuite... to GCC
On Monday, 29 October 2018 at 03:43:49 UTC, Mike Parker wrote: Congratulations are in order for Iain Buclaw. His efforts have been rewarded in a big way. Last Friday, he got the greenlight to move forward with submitting his changes into GCC: https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01676.html That's now a reality. https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=03385ed3d679cd8125f282697a1c7cf46f8361cc Hopefully around the time of DConf next year we'll see GDC included with the release of GCC 9. How cool is that? Congratulations! I hope this will bring dlang much more of the deserved visibility and money/momentum.
Re: Updating D beyond Unicode 2.0
On Saturday, 22 September 2018 at 11:28:48 UTC, Jonathan M Davis wrote: Unicode is supposed to be a universal way of representing every character in every language. Emojis are not characters. They are sequences of characters that people use to represent images. I do not understand how an argument can even be made that they belong in Unicode. As I said, it's exactly the same as arguing that words should be represented in Unicode. Unfortunately, however, at least some of them are in there. :| At least since the incorporation of Emojis it's not supposed to be a universal way of representing characters anymore. :-) Maybe there was a time when that was true I don't know but I think they see Unicode as a way to express all language symbols. And Emojis is nothing else than a language were each symbol stands for an emotion/word/sentence. If Unicode only allows languages with characters which are used to form words it's excluding languages which use other ways of expressing something. Would you suggest to remove such writing systems out of Unicode? What should a museum do which is in need of a software to somehow manage Egyptian hieroglyphs? Unicode was made to support all sorts of writing systems and using multiple characters per word is just one system to form a writing system.
Re: Updating D beyond Unicode 2.0
On Saturday, 22 September 2018 at 10:24:48 UTC, Shachar Shemesh wrote: Thank Allah that someone said it before I had to. I could not agree more. Encoding whole words as single Unicode code points makes no sense. The goal of Unicode is to support diversity, if you argue against that you don't need Unicode at all. What you are saying is basically that you would remove Chinese too. Emojis are not my world either but it is an expression system / language.
Re: Updating D beyond Unicode 2.0
On Saturday, 22 September 2018 at 01:08:26 UTC, Neia Neutuladh wrote: ...you *do* know that not every codebase has people working on it who only know English, right? This topic boils down to diversity vs. productivity. If supporting diversity in this case is questionable. I work in a German speaking company and we have no developers who are not speaking German for now. In fact all are native speakers. Still we write our code, comments and commit messages in English. Even at university you learn that you should use English to code. The reasoning is simple. You never know who will work on your code in the future. If a company writes code in Chinese, they will have a hard time to expand the development of their codebase even though Chinese is spoken by that many people. So even though you could use all sorts of characters, in a productive environment you better choose not to do so. You might end up shooting yourself in the foot in the long run. Diversity is important in other areas but I don't see much advantage here. At least for now because the spoken languages of today don't differ tremendously in what they are capable of expressing. This is also true for todays programming languages. Most of them are just different syntax for the very same ideas and concepts. That's not very helpful to bring people together and advance. My understanding is that even life with it's great diversity just has one language (DNA) to define it.
Re: expectations 0.1.0
On Monday, 3 September 2018 at 13:00:05 UTC, aliak wrote: This would be great to have in D. Indeed, if it's really going into C++ D needs to think about how to handle that anyway if it wants to offer C++ ABI interfacing. Swift [0] has something similar, and personally after using it for a few years, I can say that I've seen next to no unhandled exception errors in iOS code at least. Thanks, didn't know that Swift is already using something like this.
Re: expectations 0.1.0
On Monday, 3 September 2018 at 00:52:39 UTC, Vladimir Panteleev wrote: There are generally two classic approaches to error handling: std::expected is not the only thing on this topic going on in C++. There is also the proposal from Herb Sutter [1]. It's not a library solution and changes even the ABI but it's an interesting approach. He also tries to get compatibility into C via an extension. (See 4.6.11 in [1]) [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r0.pdf
Re: Need help with the dmd package on NixOS
On Friday, 4 May 2018 at 20:27:33 UTC, Thomas Mader wrote: The dmd package on NixOS doesn't work anymore in their master branch. They must have changed something in the C environment or something and I don't have a clue what's going on. I found the problem. strip in binutils 2.30 is broken. Nix is stripping libs and binaries on installation. The problem will be further analyzed in https://sourceware.org/bugzilla/show_bug.cgi?id=23199
Re: Need help with the dmd package on NixOS
On Friday, 18 May 2018 at 13:15:35 UTC, Johannes Pfau wrote: As far as I know, that's correct. GCC-based compilers emit ASM code only and leave assembling of the objects files to the 'binutils as' assembler. That's probably the reason they assumed it's a binutils bug. For DMD, binutils is not involved when creating object files. So this is likely a DMD bug. That would be my understanding as well. Probably the problem exists with binutils 2.30 only because it changed the format somehow and the linking of the dmd created object files doesn't work anymore because of this. The object file format created from dmd is not compatible with binutils anymore.
Re: Need help with the dmd package on NixOS
On Friday, 11 May 2018 at 04:27:20 UTC, Thomas Mader wrote: My suspicion about the switch to glibc 2.27 being the problem was wrong. I did a very timeconsuming bisection and found the problem commit to be the one which bumped binutils to 2.30. Can somebody help me to answer the question from https://sourceware.org/bugzilla/show_bug.cgi?id=23199#c4 please. The object is created by the dmd backend but where in the code is binutils used?
Re: Need help with the dmd package on NixOS
On Wednesday, 9 May 2018 at 19:58:48 UTC, Thomas Mader wrote: Now I wonder how something like that is possible. My suspicion about the switch to glibc 2.27 being the problem was wrong. I did a very timeconsuming bisection and found the problem commit to be the one which bumped binutils to 2.30.
Re: Need help with the dmd package on NixOS
On Friday, 4 May 2018 at 20:27:33 UTC, Thomas Mader wrote: The dmd package on NixOS doesn't work anymore in their master branch. Since dmd still works correctly on the stable branch I tried to examine the differences of libphobos2.a. I switched back to version 2.079.0 on master to have the same version as on stable. First I diffed the outputs of 'ar -t libphobos2.a' but there weren't any differences. But executing 'nm libphobos2.a' results in many errors like: nm: /home/thomad/devel/nixpkgs/result/lib/libphobos2.a(object_1_257.o): no group info for section .text._D6object6Object5opCmpMFCQqZi nm: /home/thomad/devel/nixpkgs/result/lib/libphobos2.a(object_1_257.o): no group info for section .text._D6object6Object5opCmpMFCQqZi nm: object_1_257.o: Bad value nm: /home/thomad/devel/nixpkgs/result/lib/libphobos2.a(object_5_391.o): no group info for section .text._D6object9Interface9__xtoHashFNbNeKxSQBjQBfZm nm: /home/thomad/devel/nixpkgs/result/lib/libphobos2.a(object_5_391.o): no group info for section .text._D6object9Interface9__xtoHashFNbNeKxSQBjQBfZm nm: object_5_391.o: Bad value nm on the static lib of the stable branch has just one error: nm: threadasm.o: no symbols Looking into the output of both nm calls shows that a lot of sections are missing in the static phobos lib on the master branch. The first being object_1_257.o. Now I wonder how something like that is possible.
Re: Need help with the dmd package on NixOS
On Saturday, 5 May 2018 at 11:22:06 UTC, Thomas Mader wrote: I also need to skip through changes which might have introduced this problem. Has anyone tried to compile with glibc 2.27? They switched to 2.27 on Master branch and I suspect that the error has to do with that.
Re: Need help with the dmd package on NixOS
On Saturday, 5 May 2018 at 00:07:01 UTC, Johannes Loher wrote: Am 04.05.2018 um 22:27 schrieb Thomas Mader: [...] Here is a demangled version of what you posted: Here comes the entire demangled output of the Hello World build. Maybe it has something to do with ModuleInfo? I also need to skip through changes which might have introduced this problem. hello.o: In function `@safe void std.stdio.writeln!(immutable(char)[]).writeln(immutable(char)[])': hello.d:(.text.@safe void std.stdio.writeln!(immutable(char)[]).writeln(immutable(char)[])[@safe void std.stdio.writeln!(immutable(char)[]).writeln(immutable(char)[])]+0x46): undefined reference to `@safe std.stdio.File.LockingTextWriter std.stdio.File.lockingTextWriter()' hello.d:(.text.@safe void std.stdio.writeln!(immutable(char)[]).writeln(immutable(char)[])[@safe void std.stdio.writeln!(immutable(char)[]).writeln(immutable(char)[])]+0x57): undefined reference to `@safe void std.stdio.File.__dtor()' hello.d:(.text.@safe void std.stdio.writeln!(immutable(char)[]).writeln(immutable(char)[])[@safe void std.stdio.writeln!(immutable(char)[]).writeln(immutable(char)[])]+0xa4): undefined reference to `@trusted void std.stdio.File.LockingTextWriter.__aggrDtor()' hello.o:(.data.DW.ref.__dmd_personality_v0+0x0): undefined reference to `__dmd_personality_v0' hello.o: In function `@safe int std.exception.errnoEnforce!(int, "/nix/store/x9wfppgz07zgks9yfn7c96965wmrl0xd-dmdBuild-2.079.1/include/d2/std/stdio.d", 2877uL).errnoEnforce(int, lazy immutable(char)[])': hello.d:(.text.@safe int std.exception.errnoEnforce!(int, "/nix/store/x9wfppgz07zgks9yfn7c96965wmrl0xd-dmdBuild-2.079.1/include/d2/std/stdio.d", 2877uL).errnoEnforce(int, lazy immutable(char)[])[@safe int std.exception.errnoEnforce!(int, "/nix/store/x9wfppgz07zgks9yfn7c96965wmrl0xd-dmdBuild-2.079.1/include/d2/std/stdio.d", 2877uL).errnoEnforce(int, lazy immutable(char)[])]+0x20): undefined reference to `std.exception.ErrnoException.__Class' hello.d:(.text.@safe int std.exception.errnoEnforce!(int, "/nix/store/x9wfppgz07zgks9yfn7c96965wmrl0xd-dmdBuild-2.079.1/include/d2/std/stdio.d", 2877uL).errnoEnforce(int, lazy immutable(char)[])[@safe int std.exception.errnoEnforce!(int, "/nix/store/x9wfppgz07zgks9yfn7c96965wmrl0xd-dmdBuild-2.079.1/include/d2/std/stdio.d", 2877uL).errnoEnforce(int, lazy immutable(char)[])]+0x5b): undefined reference to `@trusted std.exception.ErrnoException std.exception.ErrnoException.__ctor(immutable(char)[], immutable(char)[], ulong)' hello.d:(.text.@safe int std.exception.errnoEnforce!(int, "/nix/store/x9wfppgz07zgks9yfn7c96965wmrl0xd-dmdBuild-2.079.1/include/d2/std/stdio.d", 2877uL).errnoEnforce(int, lazy immutable(char)[])[@safe int std.exception.errnoEnforce!(int, "/nix/store/x9wfppgz07zgks9yfn7c96965wmrl0xd-dmdBuild-2.079.1/include/d2/std/stdio.d", 2877uL).errnoEnforce(int, lazy immutable(char)[])]+0x63): undefined reference to `_d_throwdwarf' hello.o: In function `@safe void std.stdio.File.LockingTextWriter.put!(immutable(char)).put(immutable(char))': hello.d:(.text.@safe void std.stdio.File.LockingTextWriter.put!(immutable(char)).put(immutable(char))[@safe void std.stdio.File.LockingTextWriter.put!(immutable(char)).put(immutable(char))]+0x1b): undefined reference to `@property @trusted core.stdc.stdio._IO_FILE* std.stdio.File.LockingTextWriter.handle_()' hello.d:(.text.@safe void std.stdio.File.LockingTextWriter.put!(immutable(char)).put(immutable(char))[@safe void std.stdio.File.LockingTextWriter.put!(immutable(char)).put(immutable(char))]+0x37): undefined reference to `@property @trusted core.stdc.stdio._IO_FILE* std.stdio.File.LockingTextWriter.handle_()' hello.o: In function `@safe void std.stdio.File.LockingTextWriter.put!(char).put(char)': hello.d:(.text.@safe void std.stdio.File.LockingTextWriter.put!(char).put(char)[@safe void std.stdio.File.LockingTextWriter.put!(char).put(char)]+0x1b): undefined reference to `@property @trusted core.stdc.stdio._IO_FILE* std.stdio.File.LockingTextWriter.handle_()' hello.d:(.text.@safe void std.stdio.File.LockingTextWriter.put!(char).put(char)[@safe void std.stdio.File.LockingTextWriter.put!(char).put(char)]+0x37): undefined reference to `@property @trusted core.stdc.stdio._IO_FILE* std.stdio.File.LockingTextWriter.handle_()' hello.o: In function `main': hello.d:(.text.main[main]+0xc): undefined reference to `_d_run_main' /nix/store/x9wfppgz07zgks9yfn7c96965wmrl0xd-dmdBuild-2.079.1/lib/libphobos2.a(lifetime_68e_482.o):(.data+0x0): undefined reference to `rt.lifetime.__ModuleInfo' /nix/store/x9wfppgz07zgks9yfn7c96965wmrl0xd-dmdBuild-2.079.1/lib/libphobos2.a(lifetime_68e_482.o): In function `_d_newclass': (.text._d_newclass[_d_newclass]+0x35): undefined reference to `pure nothrow @nogc core.exception.OutOfMemoryError core.exception.staticError!(core.exception.OutOfMemoryError).staticError()' (.text._d_newclass[_d_newclass]+0x3d): undefined reference to `_d_throwdwarf'
Need help with the dmd package on NixOS
The dmd package on NixOS doesn't work anymore in their master branch. They must have changed something in the C environment or something and I don't have a clue what's going on. Building the package succeeds but when I try to build with the newly build binary I get all sorts of linker errors. Maybe someone can give me some hints? Here you see a small piece of the output if I try to build a simple hello world with it. dmd hello.d hello.o: In function `_D3std5stdio__T7writelnTAyaZQnFNfQjZv': hello.d:(.text._D3std5stdio__T7writelnTAyaZQnFNfQjZv[_D3std5stdio__T7writelnTAyaZQnFNfQjZv]+0x46): undefined reference to `_D3std5stdio4File17lockingTextWriterMFNfZSQBoQBnQBk17LockingTextWriter' hello.d:(.text._D3std5stdio__T7writelnTAyaZQnFNfQjZv[_D3std5stdio__T7writelnTAyaZQnFNfQjZv]+0x57): undefined reference to `_D3std5stdio4File6__dtorMFNfZv' hello.d:(.text._D3std5stdio__T7writelnTAyaZQnFNfQjZv[_D3std5stdio__T7writelnTAyaZQnFNfQjZv]+0xa4): undefined reference to `_D3std5stdio4File17LockingTextWriter10__aggrDtorMFNeZv' hello.o:(.data.DW.ref.__dmd_personality_v0+0x0): undefined reference to `__dmd_personality_v0' hello.o: In function `_D3std9exception__T12errnoEnforceTiVAyaa83_2f6e69782f73746f72652f783977667070677a30377a676b733979666e37633936393635776d726c3078642d646d644275696c642d322e3037392e312f696e636c7564652f64322f7374642f737464696f2e64Vmi2877ZQHqFNfiLQHhZi': hello.d:(.text._D3std9exception__T12errnoEnforceTiVAyaa83_2f6e69782f73746f72652f783977667070677a30377a676b733979666e37633936393635776d726c3078642d646d644275696c642d322e3037392e312f696e636c7564652f64322f7374642f737464696f2e64Vmi2877ZQHqFNfiLQHhZi[_D3std9exception__T12errnoEnforceTiVAyaa83_2f6e69782f73746f72652f783977667070677a30377a676b733979666e37633936393635776d726c3078642d646d644275696c642d322e3037392e312f696e636c7564652f64322f7374642f737464696f2e64Vmi2877ZQHqFNfiLQHhZi]+0x20): undefined reference to `_D3std9exception14ErrnoException7__ClassZ' hello.d:(.text._D3std9exception__T12errnoEnforceTiVAyaa83_2f6e69782f73746f72652f783977667070677a30377a676b733979666e37633936393635776d726c3078642d646d644275696c642d322e3037392e312f696e636c7564652f64322f7374642f737464696f2e64Vmi2877ZQHqFNfiLQHhZi[_D3std9exception__T12errnoEnforceTiVAyaa83_2f6e69782f73746f72652f783977667070677a30377a676b733979666e37633936393635776d726c3078642d646d644275696c642d322e3037392e312f696e636c7564652f64322f7374642f737464696f2e64Vmi2877ZQHqFNfiLQHhZi]+0x5b): undefined reference to `_D3std9exception14ErrnoException6__ctorMFNeAyaQdmZCQBxQBwQBp' hello.d:(.text._D3std9exception__T12errnoEnforceTiVAyaa83_2f6e69782f73746f72652f783977667070677a30377a676b733979666e37633936393635776d726c3078642d646d644275696c642d322e3037392e312f696e636c7564652f64322f7374642f737464696f2e64Vmi2877ZQHqFNfiLQHhZi[_D3std9exception__T12errnoEnforceTiVAyaa83_2f6e69782f73746f72652f783977667070677a30377a676b733979666e37633936393635776d726c3078642d646d644275696c642d322e3037392e312f696e636c7564652f64322f7374642f737464696f2e64Vmi2877ZQHqFNfiLQHhZi]+0x63): undefined reference to `_d_throwdwarf' hello.o: In function `_D3std5stdio4File17LockingTextWriter__T3putTyaZQiMFNfyaZv': Thanks in advance Thomas
Re: dub 2.079.1-beta.1 test failures on Mac OSX 10.13.5 Beta
On Sunday, 15 April 2018 at 00:52:21 UTC, Martin Nowak wrote: Does the dub beta work for you though? Have you tried the official binary? Dub's CI tests were so far targeted at linux and might have some issues with OS dependent differences. On other platform's we've only been running unit-tests, but not the integration test-suite. -Martin Haven't tried the official binary. It's also not useful with Nix. I package dub versions regularly on Nix and see those errors for the first time on Mac OSX. I looked at the travis script and it seems you are testing by invoking the run-unittest.sh script too. How do I just run the unittests without the integration test-suite? I packaged the final release version of 1.8.1 and everything worked fine. Strange. With 1.8.1-beta.1 I tried it two times and got the same errors. So not a big problem anymore since I only really package release versions. Still, it would be interesting to know what's going on.
dub 2.079.1-beta.1 test failures on Mac OSX 10.13.5 Beta
On Saturday, 7 April 2018 at 18:39:12 UTC, Martin Nowak wrote: First beta for the 2.079.1 patch release. Comes with a handful of fixes. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.079.1.html Please report any bugs at https://issues.dlang.org - -Martin Running the dub tests on Mac OSX 10.13.5 Beta via the Nix package manager doesn't work. I tried it two times. The overflow seems strange. [INFO] Running /private/tmp/nix-build-dubUnittests-1.8.1-beta.1.drv-0/source/test/fetchzip.sh... Fetching diet-ng 1.4.5 (getting selected version)... Fetching taggedalgebraic 0.10.11 (getting selected version)... Fetching stdx-allocator 2.77.1 (getting selected version)... Fetching vibe-d 0.8.3 (getting selected version)... Fetching vibe-core 1.4.0 (getting selected version)... Fetching eventcore 0.8.34 (getting selected version)... Performing "debug" build using dmd for x86_64. taggedalgebraic 0.10.11: building configuration "library"... eventcore 0.8.34: building configuration "kqueue"... stdx-allocator 2.77.1: building configuration "library"... vibe-core 1.4.0: building configuration "kqueue"... vibe-d:utils 0.8.3: building configuration "library"... vibe-d:data 0.8.3: building configuration "library"... vibe-d:crypto 0.8.3: building configuration "library"... diet-ng 1.4.5: building configuration "library"... vibe-d:stream 0.8.3: building configuration "library"... vibe-d:textfilter 0.8.3: building configuration "library"... vibe-d:inet 0.8.3: building configuration "library"... vibe-d:tls 0.8.3: building configuration "openssl"... vibe-d:http 0.8.3: building configuration "library"... vibe-d:mail 0.8.3: building configuration "library"... vibe-d:mongodb 0.8.3: building configuration "library"... vibe-d:redis 0.8.3: building configuration "library"... vibe-d:web 0.8.3: building configuration "library"... vibe-d 0.8.3: building configuration "vibe-core"... test_registry ~master: building configuration "application"... Linking... std.conv.ConvOverflowException@/nix/store/mns8lg3j3gy5ddv6h152l6karkpxkc13-dmdBuild-2.079.1-beta.1/include/d2/std/conv.d(2164): Overflow in integral conversion 4 test_registry 0x000106393c93 pure @safe ushort std.conv.parse!(ushort, immutable(char)[]).parse(ref immutable(char)[]) + 119 5 test_registry 0x000106393cd4 pure @safe ushort std.conv.toImpl!(ushort, immutable(char)[]).toImpl(immutable(char)[]) + 28 6 test_registry 0x000106393c17 pure @safe ushort std.conv.to!(ushort).to!(immutable(char)[]).to(immutable(char)[]) + 31 7 test_registry 0x000106423cc4 @safe vibe.http.server.HTTPServerSettings vibe.http.server.HTTPServerSettings.__ctor(immutable(char)[]) + 624 8 test_registry 0x0001063594ff @safe vibe.http.server.HTTPListener vibe.http.server.listenHTTP!(immutable(char)[]).listenHTTP(immutable(char)[], void delegate(vibe.http.server.HTTPServerRequest, vibe.http.server.HTTPServerResponse) @safe) + 59 9 test_registry 0x0001063594bd @safe vibe.http.server.HTTPListener vibe.http.server.listenHTTP!(immutable(char)[]).listenHTTP(immutable(char)[], vibe.http.server.HTTPServerRequestHandler) + 57 10 test_registry 0x000106341c09 _Dmain + 441 11 test_registry 0x00010658f1bf void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll().__lambda1() + 39 12 test_registry 0x00010658f04f void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate()) + 31 13 test_registry 0x00010658f12a void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll() + 138 14 test_registry 0x00010658f04f void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate()) + 31 15 test_registry 0x00010658efbd _d_run_main + 485 16 test_registry 0x000106341c39 main + 33 17 libdyld.dylib 0x7fff6ab81014 start + 0 18 ??? 0x0002 0x0 + 2 Trying to download gitcompatibledubpackage (1.0.4) std.conv.ConvOverflowException@/nix/store/mns8lg3j3gy5ddv6h152l6karkpxkc13-dmdBuild-2.079.1-beta.1/include/d2/std/conv.d(2164): Overflow in integral conversion 4 dub 0x000108bd0c86 pure @safe ushort std.conv.parse!(ushort, immutable(char)[]).parse(ref immutable(char)[]) + 158 5 dub 0x000108bd0cbc pure @safe ushort std.conv.toImpl!(ushort, immutable(char)[]).toImpl(immutable(char)[]) + 28 6 dub 0x000108bd0bdf pure @safe ushort
Re: D beyond the specs
On Friday, 16 March 2018 at 11:44:59 UTC, Chris wrote: Would it be possible to find out at DConf in Munich why exactly D is so popular in Germany (my impression) and in other countries of Europe (and that general post code) like France, Italy, GB, Romania and Russia etc.? My guess is that it has much to do with simple luck. It's like getting those Goldilock conditions. What I mean by that is described in the first couple minutes of this TED talk: https://www.ted.com/talks/david_christian_big_history In communities those Goldilock conditions are not of physical nature but of social nature I guess. For a movement/idea/programming language/... to grow big, it seems to be important to get the right people into it. The people who are that passionate about it that they put much afford into it to convince other people of the value of this new thing. The ones who are best candidates for something like that are the ones who are very communicative and have a large social net to popularize their things on. What might have happend in Germany is exactly that. The starters of companies like Funkwerk, Sociomantic and the like saw value in D and decided to use it heavily. They were able to create a Goldilock condition by their use and gathered more people around it. If you have more people it's more likely to get even bigger because the possibility of another even bigger Goldilock is increased. More people mean more connections to other people and the thing goes on and on. In the US it was just not that lucky yet. For sure there are technical facts to consider but if you follow trends, it doesn't always seem to be the crucial factor to choose something over the other in technical things. So finding and convincing or at least introduce such important people to your new thing might always be the key thing to do.
DConf Room Sharing
Hello, I am thinking about attending my first DConf but don't want to spend too much for the hotel. Are there people who are up for room sharing? Thomas
Re: Release D 2.078.2
On Friday, 16 February 2018 at 11:25:42 UTC, Martin Nowak wrote: On 02/10/2018 09:17 AM, Thomas Mader wrote: https://github.com/dlang/dub/releases/latest doesn't point to 1.7.2. Out of curiosity, do you have a strong use-case to install/update dub separately of the compiler? I don't even use or need latest as of yet. I need to download the exact same version in my scripts nevertheless. I just saw that it was not updated and wanted to let you know. But I package dub and the tools as a separate package from dmd. Archlinux is doing the same and I find it reasonable. dub and the tools should be buildable with other compilers too and one day I might switch to ldc as the default compiler for the distribution because of speed.
Re: Release D 2.078.2
On Friday, 9 February 2018 at 09:20:14 UTC, Martin Nowak wrote: This point release also ships with dub 1.7.2 which further improves reliability. https://github.com/dlang/dub/blob/master/CHANGELOG.md#v172---2018-02-07 - -Martin https://github.com/dlang/dub/releases/latest doesn't point to 1.7.2.
Re: Class member function calls inside ctor and dtor
On Saturday, 27 January 2018 at 14:48:08 UTC, Johan Engelen wrote: I'm working on devirtualization and for that it's crucial to know some spec details (or define them in the spec if they aren't yet). Currently, calling non-final member functions in the destructor is allowed and these indirect calls are to the possibly overridden functions of derived classes. That is, inside a base class constructor, the object's type is its final type (so possibly of a derived class). This is the same in the destructor. Thus, the object's dynamic type does not change during its lifetime. Can't answer your question but have a little question. How is the behavior different to the situation in C++? They argue that it's not good to call virtual methods in Con-/Destructors in https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rc-ctor-virtual So I guess it should better be not used in D as well?
Re: Bump the minimal version required to compile DMD to 2.076.1
On Friday, 12 January 2018 at 16:13:39 UTC, Seb wrote: Motivation -- 1) It's required for Walter's work on using -betterC for the backend conversion: https://github.com/dlang/dmd/pull/6907 2) We start to run into random failures lately, e.g. https://github.com/braddr/d-tester/issues/63 https://github.com/dlang/dmd/pull/7569#issuecomment-356992048 3) There's also WIP to move dmd-cxx to 2.076.1: https://github.com/dlang/dmd/pull/7595 So if we have to bump the minimal dmd version required to build DMD anyways for (1), let's be clear about it and state it. Anyone objecting? TLDR; I hope dmd needs a properly maintained bootstrap compiler branch with release tags of new versions every now and then as ldc does. For packaging dmd on NixOS it is important to have a bootstrap compiler because the entire package tree of the distribution is build from scratch and no custom binaries can be used. (Well you can patch binaries with patchelf but that's not very nice and should probably only used for binary blobs) Currently dmd 2.067.1 is used on NixOS as a bootstrap compiler and the last time I tried dmd-cxx it didn't work because of some build problems. dmd 2.067.1 doesn't build with gcc6 which is the default for NixOS. This is not much of a problem because it can be easily overwritten to use gcc5 for the bootstrap compiler but still. I also needed to patch things for the newest dmd version which I am slowly trying to upstream but since there are no bootstrap backports I can't get rid of those patches in the bootstrap package. Which frontend version such a bootstrap branch has doesn't matter for me as long as it is maintained and I can build the newest version of dmd and all unit tests run successfully.
Re: Getting error in dmd testsuite
On Sunday, 27 August 2017 at 14:04:18 UTC, Joakim wrote: That module tests linking with C++ files, looks like you have some symbols that don't match up. That's weird, because those normally work with gcc. For each of them, use the readelf command from binutils to compare the symbols generated and see how they differ. For example, readelf -sW /tmp/nix-build-ldc-1.3.0.drv-0/build/dmd-testsuite/runnable/cppb.cpp.o |grep foo15372 Then run the same command on the D side, ie for cppa_0.o, and compare the symbols. File a bug on the ldc github if you can't figure it out: https://github.com/ldc-developers/ldc/issues gcc does not create the symbol at all on NixOS. I already created an issue for NixOS: https://github.com/NixOS/nixpkgs/issues/28896 I am not supposed to ask here but maybe someone knows about problems with gcc?
Re: druntime memory unittest fails
On Thursday, 28 December 2017 at 10:25:01 UTC, Seb wrote: On Thursday, 28 December 2017 at 10:23:38 UTC, Thomas Mader wrote: Hello, on NixOS the druntime memory unittest fails at 'assert(z is null);' (https://github.com/dlang/druntime/blob/v2.075.1/src/core/memory.d#L899) Does anyone have a clue how that can happen? Thomas Use master: https://github.com/dlang/druntime/pull/1991 Perfect, thanks. I already tested building with 2.078.0-beta1 but don't remember if I reactivated the test or not. Nevertheless I will just wait for the final release.
druntime memory unittest fails
Hello, on NixOS the druntime memory unittest fails at 'assert(z is null);' (https://github.com/dlang/druntime/blob/v2.075.1/src/core/memory.d#L899) Does anyone have a clue how that can happen? Thomas
Re: Define enum value at compile time via compiler argument?
On Monday, 25 December 2017 at 17:46:05 UTC, aliak wrote:
On Monday, 25 December 2017 at 16:38:32 UTC, Thomas Mader wrote:
On Monday, 25 December 2017 at 16:22:11 UTC, Mengu wrote:
is it a relative path? if so:
pragma(msg,
__FILE_FULL_PATH__.split("/")[0..$-1].join("/"));
https://run.dlang.io/is/gRUAD6
Nice idea but it is an absolute path. :-/
Can you use the -J compiler flag to define a string import file?
Then you can:
string data = import("file.txt");
A little complicated but it works.
Thank you guys for your help.
Re: Define enum value at compile time via compiler argument?
On Monday, 25 December 2017 at 16:22:11 UTC, Mengu wrote:
is it a relative path? if so:
pragma(msg,
__FILE_FULL_PATH__.split("/")[0..$-1].join("/"));
https://run.dlang.io/is/gRUAD6
Nice idea but it is an absolute path. :-/
Define enum value at compile time via compiler argument?
Hello, I would like to set the path to a directory at compile time but it doesn't seem to be possible yet. I tried it with a -version=CustomPath argument and inside the version statement in the code I tried to read the value from the environment. Sadly this doesn't work because getenv can not be interpreted at compile time because it has no available source. Now my question is if this is somehow possible and I just don't see it or would it be possible to add that somehow? Thanks in advance. Thomas
Re: Maybe D is right about GC after all !
On Friday, 22 December 2017 at 04:56:57 UTC, thedeemon wrote: Making the GC more like in Go and JVM means adding write barriers, it means making general code slower (we're not fast-as-C anymore), it means losing easy C compatibility (hello FFI!), it means forbidding many current language features like unions and casts, it means changing the language to something that's not D anymore. So I think we can expect some minor improvements in GC, but nothing radical. What about a special GC mode for SafeD only processes which could probably be made precise and maybe even concurrent? If a process is entirely in SafeD the GC would run in the "safed" mode otherwise the conservative GC is being run. Go seems to make the following assumption which should be doable for D too: "Starting with Go 1.3, the runtime assumes that values with pointer type contain pointers and other values do not." [1] [1] https://golang.org/doc/go1.3#garbage_collector
Re: Maybe D is right about GC after all !
On Thursday, 21 December 2017 at 11:08:23 UTC, thedeemon wrote: A good GC requires the compiler to add special bookkeeping code to every pointer mutation in the heap, and to generate special data for each function to help GC find all the pointers in its stack and closures. Without such help from the compiler you can't make anything decent, just a slow half-conservative GC that scans whole heap every time and leaks memory being unable to tell whether some stack value is a number or a pointer. Go compiler includes that special bookkeeping, so the running code is a bit slower but GC can be fast, its GC can analyze heap concurrently, it can clean it by parts. With C you can't do that. D compiler also doesn't insert that bookkeeping code, so running code is fast as C but GC is slow and sloppy. But for D it's planned to rewrite the GC to become something like the Go GC right? The last attempt to do this was afaik a Google Summer of code project.
Re: Maybe D is right about GC after all !
On Wednesday, 20 December 2017 at 09:16:34 UTC, Timon Gehr wrote: On 20.12.2017 09:30, Thomas Mader wrote: Interestingly he doesn't know about D http://esr.ibiblio.org/?p=7724 Haven't read that one but it just shows it: "Since I’ve mentioned D, I suppose this is also the point at which I should explain why I don’t see it as a serious contender to replace C. Yes, it was spun up eight years before Rust and nine years before Go – props to Walter Bright for having the vision. But in 2001 the example of Perl and Python had already been set – the window when a proprietary language could compete seriously with open source was already closing. The wrestling match between the official D library/runtime and Tango hurt it, too. It has never recovered from those mistakes." So he doesn't know about the current state of D and I was referring to the following comment from http://esr.ibiblio.org/?p=7804: ">Eric, have you looked into D *lately*? No. What’s it got that Go does not? That’s not intended as a hostile question, I’m trying to figure out where to focus my attention when I read up on it." What I don't get is why he doesn't believe in good GC for C (my previous post) but at the same time praising Go for it's GC. What makes it easier to have a good GC in Go vs. in C? I guess the GC in D has the same problems as a GC in C.
Re: Maybe D is right about GC after all !
On Tuesday, 19 December 2017 at 09:54:05 UTC, Walter Bright wrote: "C, Python, Go, and the Generalized Greenspun Law" http://esr.ibiblio.org/?p=7804 But ESR doesn't seem to be fond of the GC idea for C like languages though. He states in a comment: ">For a long time I’ve been holding out hope for a ‘standard’ garbage collector library for C. But not gonna hold my breath. Yeah, good idea not to. People as smart/skilled as you and me have been poking at this problem since the 1980s and it’s pretty easy to show that you can’t do better than Boehm–Demers–Weiser, which has limitations that make it impractical. Sigh…" Which does not say that he is against D's philosophy to offer GC and RC. Interestingly he doesn't know about D and he hasn't answered your comment yet but instead answered another commenter about D and got some pointers. We will see if he looks into D and shares his opinion about it.
Re: LDC 1.7.0-beta1
On Sunday, 10 December 2017 at 17:33:34 UTC, kinke wrote: Hi everyone, on behalf of the LDC team, I'm glad to announce the first beta for LDC 1.7. The highlights of this version in a nutshell: * Based on D 2.077.1. * Catching C++ exceptions supported on Linux and Windows. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.7.0-beta1 Thanks to all contributors! The archive at https://github.com/ldc-developers/ldc/releases/download/v1.7.0-beta1/ldc-1.7.0-beta1-src.tar.gz is broken. The https://github.com/ldc-developers/ldc/releases/download/v1.7.0-beta1/ldc-1.7.0-beta1-src.zip works though.
Re: (Possibly paid opportunity): PyD - Win 64
On Friday, 1 December 2017 at 13:30:21 UTC, Laeeth Isharc wrote: Hi. I'd like to get PyD working on Windows 64. I think it's probably just a simple linking / library problem, but don't have time to work on it myself right now. If somebody would be interested in helping, we could pay for help on this. laeeth at kaleidic.io Thanks. Laeeth. Just found https://github.com/ariovistus/pyd/issues/67
Getting error in dmd testsuite
Hello, I am building ldc on Nix (https://nixos.org/nix/) but keep getting an error while running the cppa.d test from the dmd testsuite (https://github.com/ldc-developers/dmd-testsuite). 1588: ... runnable/cppa.d -L-lstdc++ (-g) -O 1588: Test failed. The logged output: 1588: /tmp/nix-build-ldc-1.3.0.drv-0/build/bin/ldmd2 -conf= -m64 -Irunnable -L-lstdc++ -od/tmp/nix-build-ldc-1.3.0.drv-0/build/dmd-testsuite/runnable -of/tmp/nix-build-ldc-1.3.0.drv-0/build/dmd-testsuite/runnable/cppa_0 runnable/cppa.d /tmp/nix-build-ldc-1.3.0.drv-0/build/dmd-testsuite/runnable/cppb.cpp.o 1588: /tmp/nix-build-ldc-1.3.0.drv-0/build/dmd-testsuite/runnable/cppa_0.o: In function `_Dmain': 1588: runnable/cppa.d:(.text._Dmain[_Dmain]+0x49f): undefined reference to `int foo15372(int)' 1588: runnable/cppa.d:(.text._Dmain[_Dmain]+0x4b2): undefined reference to `Foo15802::boo(int)' 1588: /tmp/nix-build-ldc-1.3.0.drv-0/build/dmd-testsuite/runnable/cppa_0.o:(.data.rel.ro._D4cppa6C131616__vtblZ[_D4cppa6C131616__vtblZ]+0x0): undefined reference to `C13161::dummyfunc()' 1588: /tmp/nix-build-ldc-1.3.0.drv-0/build/dmd-testsuite/runnable/cppa_0.o:(.data.rel.ro._D4cppa4Test6__vtblZ[_D4cppa4Test6__vtblZ]+0x0): undefined reference to `C13161::dummyfunc()' 1588: /tmp/nix-build-ldc-1.3.0.drv-0/build/dmd-testsuite/runnable/cppa_0.o:(.data.rel.ro._D4cppa7C13161a6__vtblZ[_D4cppa7C13161a6__vtblZ]+0x0): undefined reference to `C13161a::dummyfunc()' 1588: /tmp/nix-build-ldc-1.3.0.drv-0/build/dmd-testsuite/runnable/cppa_0.o:(.data.rel.ro._D4cppa5Testa6__vtblZ[_D4cppa5Testa6__vtblZ]+0x0): undefined reference to `C13161a::dummyfunc()' 1588: collect2: error: ld returned 1 exit status 1588: Error: /nix/store/df84hkmhrhx1c2zpvrhmk6aprhlzkasx-gcc-wrapper-6.4.0/bin/gcc failed with status: 1 1588: 1588: 1588: == 1588: Test failed: expected rc == 0, exited with rc == 1 1588: 1588: make[2]: *** [Makefile:335: /tmp/nix-build-ldc-1.3.0.drv-0/build/dmd-testsuite/runnable/cppa.d.out] Error 1 Apart from that all other tests pass. Any ideas? It's running on Linux with gcc 6.4.0.
Re: How about a bounty for a new windows installer using inno setup ?
On Wednesday, 7 December 2016 at 23:00:13 UTC, Jim Hewes wrote: On 12/6/2016 10:31 PM, Thomas Mader wrote: The update case could be better supported by Inno by default though I don't know how to really do it transactionally/atomic. Once everything is on the drive, how would you be able to switch from the old directory to the new one with one atomic action under Windows? I liked WiX because it was down to the metal and I don't think there's anything you can't do. With other tools (like InstallShield) I spent too much time trying to get the tool to do something I could have done really easy at the low level if I could've just gotten to it. But granted, for simpler install situations the scripting tools can work OK and have a smaller learning curve. Jim I think you might be right about using WiX. MSI seems to be build upon transactional installation. Do you think it would be possible to use D instead of C++ to write custom code?
Re: How about a bounty for a new windows installer using inno setup ?
On Wednesday, 7 December 2016 at 23:00:13 UTC, Jim Hewes wrote: On 12/6/2016 10:31 PM, Thomas Mader wrote: The update case could be better supported by Inno by default though I don't know how to really do it transactionally/atomic. Once everything is on the drive, how would you be able to switch from the old directory to the new one with one atomic action under Windows? I'm not sure what you mean by switch the directory. If you mean that the update uses a different directory for the program than the original, then you can probably just use a "major" upgrade. Windows Installer has the idea of minor upgrade and major upgrade. (So, it's independent of whatever tools your using.) A minor upgrade just updates the files that have changed. A major upgrade essentially removes the original product totally and installs the new one. Some people even use a major upgrade for _every_ new version just to avoid problems that might occur with a minor upgrade. The Update is triggered by the application itself. If the install fails or is Canceled in the middle the application can not start anymore and so the user needs to do something manually. It would be possible to update everything into a new directory and after everything is done just exchange the stuff in the already installed directory with the new update directory. But even this operation isn't atomic even though it's much better. What might work is to make it work like the Nix package manager. NixOS (Nix Package manager) provides atomic updates because the entire system environment is build by links. Replacing a version with another one is just a matter of changing the link to the proper directory. So in Windows you could do it the same. Install versions in separate directories. The installation directory is linking to the appropriate version directory. On update just install to new version directory and after everything is done just update the installation directory link to the new update directory. No matter what happens either the old or the new application version should be workable.
Re: How about a bounty for a new windows installer using inno setup ?
On Tuesday, 6 December 2016 at 17:28:25 UTC, Jim Hewes wrote: On 12/6/2016 12:21 AM, Thomas Mader wrote: You can also create a WiX installer out of an InnoSetup installer. I think it's more important to decide upon the feature set, readability and the time needed to build an installer. Have you experience with both? I only have experience with NSIS and InnoSetup and in InnoSetup the feature set for Windows is really good and the readability is good. I started out by using InstallShield some years ago and got battle scars there. I don't recommend that. I used NSIS a little because a company we partnered with required it but I'm no authority on NSIS or Inno. It really depends on how complicated your particular install is and where you expect it to go in the future. If you're just copying a few files then anything will work. I don't mean to make too big a deal out of it if the requirements are really simple. Personally I think it's better in the long run to generate an MSI for several reasons you can probably look up yourself---security, ability to rollback (installation is a transaction), appears in Programs and Features, transforms, etc. I wouldn't advise doing the coding part externally in D this makes things much more complicated than it should be. Stick with what's supported by the tool. I'm not suggesting you necessarily use D together with something like NSIS. But you do want to have a one-button automated build process, not just for convenience but for repeatability. That's important. Soon you will want to get away from the tool's own GUI and run things programmatically. After having not-so-good experiences with InstallShield I looked at things like SCons and msbuild, which was just coming out at the time. (This was a while ago). I tried msbuild but it didn't have modules to support many of the things I needed to do. Things like code-signing with a verisign signature, injecting data and files into exe resources, etc. Fortunately you can build your own custom modules using C# which is what I tried. But the process of transferring variables back and forth from the script to C# for every custom module was painful and I thought, "if I just do this all in C# it will be much easier". So I switched. I used C# not only to call on the WiX tools to run them, but to easily manipulate pathname and filename strings, which were different because I needed to build different configurations for different customer companies. And I also needed to build different combinations of language localization. I could use .NET to build a nice GUI for selecting configurations, and C# to call the Windows API when needed, move files around, anything. You may also run into issues when you need to do complicated updates and there are already earlier versions in the field. You may want to remove features, but your installer has to both update existing users in addition to supporting new users. It's hard to predict the future though so I won't say much about it except that it helps to have a more powerful tool when you run into such situations. The scripting-type tools are tempting because they're easy and no one wants to spend any time on installers. It's usually something that people hope to just slap on at the end and it often gets underestimated. But as I said, maybe it IS easy if you're just copying files and you will only ever have one configuration. So it depends. Jim Nice writeup. In our company we used NSIS and are switching over to InnoSetup. Most of the work is already done, just a few apps need to be moved. I think no one really wants NSIS because of readability issues. It's assembler like language is too low level and many common functions are just missing. InnoSetup on the other hand gives you everything you could ever want. I never missed a thing because pretty much everything is right there and if you happen to have very special needs you can do it quite nicely with the pascal scripting ability. You can call every Windows API function you just need to wrap it if it is not provided in one way or another via the InnoSetup API. I don't think you need to do that for the D Installer though. Our installers need to handle quite a few things. - Signing and timestamping of exes, dlls, Installer and Uninstaller - SendTo Handler registration (Windows doesn't provide a common SendTo directory so you need to handle it quite complicated for each users individual SendTo directory if you don't want to write a proper SendTo COM thing) - Registration of a COM server - Differentiate between 32 and 64 bit installs - User elevation for Installs and Uninstalls but Updates are done for the current User (We still use Inno for our Updates too but move away from that because it's not at all transactional and cannot be undone in the middle of the update) - Create MSI Installer from InnoSetup Installer via Wix The update case could be better supported
Re: How about a bounty for a new windows installer using inno setup ?
On Monday, 5 December 2016 at 19:33:33 UTC, Jim Hewes wrote: On 12/5/2016 3:19 AM, Kjartan F. Kvamme wrote: On Monday, 5 December 2016 at 09:24:59 UTC, Basile B. wrote: How about a bounty for a new windows installer using inno setup ? There are several issues related to the nsis-based windows installer (even on bugzilla). The problem that happened last Fall with a virus false detection may happen again. "Braddr" proposed to handle digital signatures in case it would involve payment. Programming an installer is a small job but it has a long term impact on the user experience. Worth 100€ imo. Any particular reason to use Inno Setup over for example Wix Toolset? In my last job I worked on installers (which I didn't like but someone had to do it.) I recommend WiX over Inno. The main reason is that WiX produces an MSI and Inno doesn't. An MSI is just a data file, not an executable, and is thus better for security. I normally wrapped the MSI in a bootstrap exe. But we had one customer that was part of the government and wouldn't accept anything but an MSI. If you want, you can generate the XML with a program. I just didn't because I figured it was easier to modify if you can directly see the XML. My install builder was actually a combination of C# and WiX. I never found scripts to be flexible enough and it's just one more language to know. Jim You can also create a WiX installer out of an InnoSetup installer. I think it's more important to decide upon the feature set, readability and the time needed to build an installer. Have you experience with both? I only have experience with NSIS and InnoSetup and in InnoSetup the feature set for Windows is really good and the readability is good. I wouldn't advise doing the coding part externally in D this makes things much more complicated than it should be. Stick with what's supported by the tool.
Re: Code signing to help with Windows virus false positives
On Tuesday, 11 October 2016 at 06:09:03 UTC, Thomas Mader wrote: I worked with NSIS and InnoSetup. InnoSetup is much cleaner and easier. At work we switched from NSIS to InnoSetup and we create MSI packages from NSIS and InnoSetup packages IIRC. I think it's better to go with InnoSetup because it might be more easy and probably more powerful than building MSI directly. But I don't have any experience with building an MSI installer and the feature set of MSI. We are also signing the installer and all exe and DLLs inside. I was right. We create the MSI package out of the InnoSetup executable with a minimal xml config for WiX.
Re: Code signing to help with Windows virus false positives
On Tuesday, 11 October 2016 at 01:37:55 UTC, Martin Nowak wrote: On Saturday, 20 August 2016 at 13:45:11 UTC, Basile B. wrote: "to MSI using innosetup" ? There's a misunderstanding here. Inno setup doesn't compile to MS installer, it's a complete independant solution. Whatever makes more sense. From my very limited understanding .msi installers are natively understood installers in Windows, and the weapon of choice for robust and more professional installers. If innosetup is just another NSIS like tool, it might not solve all our problems. We're fairly clueless here and could really use help here. Just signing the NSIS installers could work for now, any support for this hypothesis. I tried to submit the latest release as sample to Microsoft but their file upload had a size limit smaller than the binary. I worked with NSIS and InnoSetup. InnoSetup is much cleaner and easier. At work we switched from NSIS to InnoSetup and we create MSI packages from NSIS and InnoSetup packages IIRC. I think it's better to go with InnoSetup because it might be more easy and probably more powerful than building MSI directly. But I don't have any experience with building an MSI installer and the feature set of MSI. We are also signing the installer and all exe and DLLs inside.
Re: I'd love to see DScript one day ...
On Tuesday, 14 June 2016 at 03:31:10 UTC, H. S. Teoh wrote: It's unlikely to happen in the near future, though, if at all. But one can dream. :-) I think the big plan behind Web Assembly is to allow foreign languages an entry into the browser world. IIRC it's planned that the entire DOM will be accessible via Web Assembly at some point too. But thats quite far in the future. But with that I don't see any reason why D couldn't run directly in the browser and do the same stuff JavaScript does. Well except some technical details which are not clear to me now. :-D
Re: Reproducible builds of D compilers
On Friday, 6 May 2016 at 08:07:30 UTC, Pjotr Prins wrote: At Dconf we had a discussion on creating reproducible builds of the D compilers. One thing that is required is bootstrapping the build. In GNU Guix we start from a working C compiler which is a reasonable starting point (it could have been LISP instead ;) For D this means that even if all components of the compilers are written in D we should have a (chain of) compilation steps that can be initiated from a C or C++ compiler. This is still the case today, but I want to highlight this point here so we do not lose that facility. GNU Guix can be used as a reproducible reference build system where we capture the bootstrapping process nicely and test the builds on the build farm(s) whenever something changes. I like the idea. I thought about that too but would not use GNU Guix for it. I would suggest to use Nix -> http://nixos.org/ AFAIK GNU Guix uses some parts of Nix and I think the community behind it is not as big. There are also packages for dmd on Nix already. I also was able to get the ddmd frontent version of dmd running on Nix. Nix would be the perfect system to base all the testing on because it's very easy to distribute entire system configurations over multiple computers. So once everything is setup correctly and the knowledge is there, it makes administering entire server farms pretty comfortable.
Re: Redesign of dlang.org
On Thursday, 24 December 2015 at 06:43:32 UTC, Andrei Alexandrescu wrote: Currently dlang.org has over 62KLOC of Ddoc source, so any significant surgery on it will be a large effort. Dropping ddoc means we'd need to use another templating engine (getting back to raw html would be too much trouble), and 10 people have 11 ideas about which template engine is used by "everyone". I can give you right now an estimate - dropping ddoc and replacing it with vibe.d is unlikely to be a landslide success. When the alternate documentation was introduced using vibe.d, my hope was that everybody would be all over it like a cheap white suit on rice, and that the use of vibe.d would organically grow to make the stdlib documentation stellar, and then engulf the main site. Sadly participation was scant, and we had a couple of vibe.d-related situations in which the maintainer division (ahem... Vladimir and myself) had no idea on what to do and had nobody to rely on. Thanks for those details your decision is much more clear now for me. I didn't know that the documentation is switched to vibe.d already. So I guess everything comes down to the following question. Do you want to drop vibe.d or ddoc as a templating engine for the site? Using both doesn't seem to make any sense and for me it's not clear which way you want to go. I remember the decision being made that vibe.d should be more tightly integrated into D and if that is still true the question for the templating engine seems to already be settled. If thats correct then allowing Jacob to do the work with vibe.d seems to bring you one step further to the goal to introduce vibe.d Let me put that another way: for folks who want to improve dlang.org but for whom ddoc is an impediment, the option exists TODAY to work on large parts of the site that have nothing to do with it. Yet from what I can tell nobody is taking it. Would you have an interest? (Serious question.) At the moment my interest in Web Development is pretty low but I am interested to fix errors and add content as I see fit. For that it's nice if the hurdle is as low as possible. For me it probably doesn't make any difference if I need to use vibe.d or ddoc since I don't know them but I guess one of them is better suited for the task.
Re: Redesign of dlang.org
On Wednesday, 23 December 2015 at 17:22:25 UTC, Andrei Alexandrescu wrote: Yah. Overall I think a redesign is needed simply because it's time. Second I think the particular redesign discussed here is nice in many ways. Third I think I'm being reasonable if I ask to introduce new or custom technology dependencies only with good reason. That is very reasonable I too think but isn't it a question of viewpoint? I see the dependency chain for a Website as follows: 1) HTML 2) HTML, CSS 3) HTML, CSS, Javascript It seems that the dlang.org Homepage needs CSS and Javascript so 3 is the minimal dependency chain. Ddoc is an additional dependency already and might be more efficient to insiders but to outsiders it is an obstacle. I think you are right in saying that the site should be build with technologies you are most efficient with but you should also consider the obstacle you are building up by this. It's hard to estimate the outcome of dropping ddoc but you might get more helpers by this move. So I guess it's a question of how many contributers you get by removing ddoc which nobody is able to tell beforehand. For this reason why not just try to go without it for now and decide later on if it is worth it or not. I can't imagine that you loose that much efficiency by dropping ddoc for some time and I don't think it would be that much work to switch to ddoc later on. But on the other hand I don't have a clue and might be totally wrong. :-) By this decision you would also get a contributor who is willing to build the initial site which is propably the hardest thing to do.
Problems loading libcurl.so and running datetime unittest on NixOS package build
I created a bug but wanted to get some opinions regarding the solution. You can read about the problem in https://issues.dlang.org/show_bug.cgi?id=15391#c3 . Thomas
Re: Release D 2.069.1
On Sunday, 22 November 2015 at 23:54:55 UTC, Martin Nowak wrote: On Saturday, 21 November 2015 at 08:57:45 UTC, Thomas Mader wrote: [1] http://www.jrsoftware.org/isinfo.php Thanks this looks indeed like a good choice. Drop me a line if you decide to go that route I might be able to help a bit.
Re: Release D 2.069.1
On Wednesday, 11 November 2015 at 12:05:16 UTC, Martin Nowak wrote: This is an unplanned point release whose sole purpose is to fix a severe Windows installer bug. http://dlang.org/download.html http://downloads.dlang.org/releases/2.x/2.069.1/ http://dlang.org/changelog/2.069.1.html -Martin @Martin: In reply to https://issues.dlang.org/show_bug.cgi?id=15284#c11. I switched the installers for my workplace from NSIS to InnoSetup [1] and was very satisfied with it. In my opinion it's superior to NSIS. It might be worthwile to strive to change but I might be wrong because I never looked on the Dlang installers. [1] http://www.jrsoftware.org/isinfo.php
Has anyone created a D wrapper for wbemuuid.lib
I looked at some of the windows API wrapper projects for D on github [1][2], but none of them seems to have wrapped wbemuuid.lib right now. Do I miss something? Does anyone have wrapped this lib? Thomas [1] http://code.dlang.org/packages/windows-headers [2] https://github.com/smjgordon/bindings/tree/master/win32
Re: Has anyone created a D wrapper for wbemuuid.lib
On Tuesday, 22 September 2015 at 10:03:52 UTC, Thomas Mader wrote: Do I miss something? Does anyone have wrapped this lib? This was also asked on stackoverflow some time ago. [1] Wonder if something happend since then. [1] http://stackoverflow.com/questions/24051606/can-i-use-routines-from-comdef-h-wbemidl-h-etc-in-d
Re: This Week in D #7 - summary of reference counting discussion
On Monday, 2 March 2015 at 04:19:08 UTC, Adam D. Ruppe wrote: This was a very active week on the forums, though most of it was centered around DIP74 and its satellite discussions, leading to a somewhat thin newsletter. http://arsdnet.net/this-week-in-d/mar-01.html https://twitter.com/adamdruppe/status/572249079352299520 Typo: LDS for iOS Thanks Adam
Re: This Week in D, issue 1
On Tuesday, 13 January 2015 at 14:08:58 UTC, Adam D. Ruppe wrote: I've started writing a weekly D newsletter. Here's the first issue, any feedback welcome! http://arsdnet.net/this-week-in-d/jan-12.html In the future, I intend to have it written by Saturday for a weekend release, so if you want something to appear this week, please try to get it to by before then. Very nice, thank you! One suggestion. The link to emplace source code is done by linenumber on master. It would be better to link to a tag to keep the link correct. Instead of: https://github.com/D-Programming-Language/phobos/blob/master/std/conv.d#L3907 https://github.com/D-Programming-Language/phobos/blob/v2.067.0-b1/std/conv.d#L3847
Re: What are the worst parts of D?
On Wednesday, 24 September 2014 at 04:46:01 UTC, Sean Kelly wrote: Yes, the inference is very nice. And I do see the use for each attribute. It's just... when I look at a function and there's a line of attributes before the function declaration that have nothing to do with what the function actually does but rather with how it's implemented, it's just syntactic noise. It's information for the compiler, not me as a user. I hope we'll eventually get to the point where everything is inferred and the attributes disappear entirely. What is the problem with complete automatic inference? Wouldn't it be possible to deduce the flags in the bottom up direction of a function call hierarchy? I guess it is possible for the compiler to see the right choice of flags for a function, which doesn't call other functions. E.g. make it @safe if possible, @nogc if possible and so on. Then it should process function after function until all functions are done. Thomas
Re: Increasing D's visibility
On Tuesday, 16 September 2014 at 01:43:15 UTC, Andrei Alexandrescu wrote: That would be exactly what's needed. Who's volunteering? I guess I already somehow did. I am in the progress of building a benchmarking suite: https://github.com/ThomasMader/benchmark Currently it is possible to benchmark some of the benchmarks from benchmarksgame.alioth.debian.org. For the moment I start with Java and port the benchmarks directly to D and benchmark dmd, gdc and ldc versions. I also benchmark the compilation because I find it important for a language comparison. I plan to include other languages which make sense (like C++) to compare them against D but not the full set from the benchmarksgame. I would like to make it platform dependent. (Win, Linux, Mac) In the moment it's Linux only though and measures everything exactly the same as on http://benchmarksgame.alioth.debian.org/play.html with the exception of code-used. I tried to keep out external dependencies so I am not using libGTop for the measurement but implemented it myself. I am not sure if the code-used measurement is meaningful or not so if anybody has some arguments please elaborate. Everything is printed to stdout only for now because serialisation is missing. I have not yet decided which format I use but I don't want to implement something. It needs to be in phobos. I thought about JSON or XML but AFAIK the phobos implementations will be replaced in the future. It should be widely accepted and should have less overhead. (Don't like XML for that matter) If anybody has some remarks regarding any matter don't hesitate to put them here. This is a fun project for me to get to write and learn D and maybe help D to get some more attention. But don't expect fast progress. ;-) Thomas
Re: Dutyl - a Vim plugin for running D tools
On Wednesday, 3 September 2014 at 19:38:44 UTC, Idan Arye wrote: Version 1.1.0 is out now. It provides the :DUjump command for jumping to the declaration of the symbol under the cursor. If DCD is not running, Dscanner will be used instead. You can also give :DUjump the symbol as an argument - in this case it'll always use Dscanner(since DCD only supports getting the symbol by byte position). GitHub repo: https://github.com/idanarye/vim-dutyl vim.org page: http://www.vim.org/scripts/script.php?script_id=5003 Very nice, thanks! This seems to be the best solution for using D with vim right now, I really need to try it out. Wouldn't it be better if all this functionality you build in a vim only solution be integrated into DCD instead? This way all sorts of compilers and maybe IDEs would benefit from it and AFAIK there is already a request for DCD to add dub support. The YouCompleteMe problem would be solved too I guess.
Re: Dutyl - a Vim plugin for running D tools
On Thursday, 4 September 2014 at 10:39:34 UTC, Idan Arye wrote: On Thursday, 4 September 2014 at 05:58:19 UTC, Thomas Mader wrote: Wouldn't it be better if all this functionality you build in a vim only solution be integrated into DCD instead? This way all sorts of compilers and maybe IDEs would benefit from it and AFAIK there is already a request for DCD to add dub support. I already suggested it to Brian a year ago. That was his answer: http://forum.dlang.org/thread/icfphxuqhctbqnlgl...@forum.dlang.org#post-fxtqrnpshsnrpiumkzmh:40forum.dlang.org That was before DUB became the (de-facto) official build system so he might change his mind, but right now Dutyl actually https://github.com/Hackerpilot/DCD/issues/85 benefits from DCD's lack of DUB support, since it means you can rely on manual configured file for non-DUB projects. I don't see why the manual configured file support needs to be removed if DCD would support dub. Wouldn't it be possible to change it to a coexisting solution?
Re: Faster ways to redirect stdout of child process to file
I found out that the redirect was not responsible for the CPU time, it was some other code part which was responsible for it and totally unrelated to the redirect. I also saw that a redirect in my case is much simpler by using spawnProcess: auto logFile = File(errors.log, w); auto pid = spawnProcess([dmd, myprog.d], std.stdio.stdin, std.stdio.stdout, logFile);
Faster ways to redirect stdout of child process to file
I use auto pipes = pipeProcess( cmd, Redirect.stdout | Redirect.stderr ); to redirect stdout of the newly created subprocess via pipes to a file. The redirect itself happens in a newly created thread (because I need to wait for the subprocess to finish to take the exact elapsed time) doing basically: pipes.stdout.byChunk( 1024 * 1024 ).copy( cof.lockingTextWriter() ); This happens to use much of my CPU time (~25%). I wonder if there is no faster way to do this. I use this method because I want to be platform independent. Thomas
Re: Miscelaneous D tool updates
On Thursday, 7 August 2014 at 23:36:59 UTC, Brian Schott wrote: * Several updates to editor integration scripts (Mostly EMACS) I know that there is an integration script for vim but I wonder if it would be better to work on integrating it with 'You Complete Me'. [1] What do you think? [1] https://github.com/Valloric/YouCompleteMe/issues/521#issuecomment-48727396
Re: Something like Python's psutils for D?
On Sunday, 13 July 2014 at 01:01:16 UTC, Ellery Newcomer wrote: would psutils itself be acceptable? https://bitbucket.org/ariovistus/pyd I haven't thought about this possibility, thanks.
Something like Python's psutils for D?
The Subject says it all, is something like psutils available in D? [1] I need it to measure memory usage of a process. [1] https://github.com/giampaolo/psutil thank you Thomas
Re: Something like Python's psutils for D?
I also need to get the user and system time of a process, doesn't seem to be available in Phobos. (e.g. getrusage in Linux but platform independent)
Re: Rosettacode example collection
Nothing exciting, but I tried to port the Java implementations of the benchmark game [1] to D. [2] My focus was to use the same algorithm/abstraction used in the Java implementation. I haven't finished the porting of all benchmarks but you can use them if they help you. May I ask you what you try to do? It sounds a bit we share some intent. My intent with that repo is to build a little benchmarking platform to compare languages, compilers and algorithms. My primary goal for now is to compare the benchmark game implementations of Java to see how D performs against them in terms of compilation time and performance. But it's a hobby project to get to write some D code for learning purposes first of all. And it will come forward very slowly because I don't intent to put much effort/time into it. [1] http://benchmarksgame.alioth.debian.org/ [2] https://github.com/ThomasMader/benchmark/tree/master/src On Sunday, 15 June 2014 at 12:25:39 UTC, David Nadlinger wrote: Hi all, Somebody (I think bearophile) mentioned a while back that they had a folder with all the D solutions from Rosettacode. I'm looking for some small stand-alone compiler benchmarks, so I'd very much appreciate if whoever it was could contact me via mail. Thanks, David
Re: Rosettacode example collection
On Sunday, 15 June 2014 at 17:19:42 UTC, bearophile wrote: So you are missing most of the point of using D, and you are perhaps even relying too much on the D GC, that is much worse than the JavaVM GC. I am aware of the D GC issue and know that I need to take another route to get the most out of D, but to compare languages it's also interesting to see how they compare with similar implementation. The GC might never be as performant as Java's but it's nice if you can estimate to what extent it is slower and maybe trace improvement of the GC implementation over time. The usual way of microbenchmarking is another perspective which should be looked into too but this viewpoint might show weaknesses better and might lead to clues on what should/can be improved.
