Re: Beta 2.076.1
On Monday, 9 October 2017 at 18:56:13 UTC, Martin Nowak wrote: On 10/07/2017 03:20 PM, Eugene Wissner wrote: But please consider something different than github as alternative. GitHub doesn't guarantee that it always generates the same tarball for the same commit/release, so the checksum can change and the downloaded tarball looks corrupted, though it has absolutely the same content. Ah good to know, indeed seems to be a problem for GH's archive endpoints? Would of course be a nogo for distro build receipts. https://github.com/libgit2/libgit2/issues/4343#issuecomment-328631745 I had this problem about two weeks ago. As an example.. Slackware is a half-binary, half-source based Linux. The core system is provided as binary packages and the most users build other programs from slackbuilds.org which provides a huge collection of third-party packages as automated build scripts (but they don't keep the sources, only scripts that build a package from the source). There are also automation tools to compile all the dependencies if needed. It is slightly similar to how freebsd ports work. Such a tool has to verify that the downloaded source is not corrupted and it is done with md5. Actually I think that it can be a problem for many smaller linux distributions that are community-driven and not backed by commercial organizations and don't have the power to keep all sources themselves like debian does. GitHub breaks the archives very very seldom but if it happens it is very painful
Re: Release D v2.076.1
On Monday, 9 October 2017 at 19:44:24 UTC, Martin Nowak wrote: Glad to announce D v2.076.1. http://dlang.org/download.html This point release fixes a few issues over v2.076.1, see the changelog for more details. http://dlang.org/changelog/v2.076.1.html - -Martin http://dlang.org/changelog/v2.076.1.html - not found http://dlang.org/changelog/2.076.1.html - right url
Release D v2.076.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Glad to announce D v2.076.1. http://dlang.org/download.html This point release fixes a few issues over v2.076.1, see the changelog for more details. http://dlang.org/changelog/v2.076.1.html - -Martin -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEpzRNrTw0HqEtE8TmsnOBFhK7GTkFAlnb0ZcACgkQsnOBFhK7 GTlfQhAAtKFPULWZRcpnoBoZ3E5LOijGn3Xj5+08zyx2UZNt2qyZcBySK2rB6NRV /GTn6fYUPI/tePBHVYACDhmILy8NcXIjdLy0eEdMdNlNfmNRqNZUUW1tKz4Ad6Y+ hwP2CrNYy0Rw8X/udmf8nGDB1Piu4ClJ1NzTDRGC6N1M419SSnErqv1l7gZITa9B dqgbF4tgjNFHK9UTUcy744/vumoaq3aRsWoy0csytgCZd4n6Hk6BtwcQMmWzmXM5 YFbyLrqsnGDyBIoLYP180D6KKbtmlfjsmXEWouvZpGjyO/5XTlw0pG20TMe23AlZ aqPRLJ5ysPVekpGi6Rl5MoEy2G5Ml7T1JTe/Grhrwh8ryivasX2NoX6/uB47gYSW X3xHkfpDCp9GPUUiuH2DcdQkAP0TmGUDIKYbdXVySHDx6LMkVbEY43lHADU0bFru C9CJMlBTd8RJWf7xl+w/8+4xHhm6yHjDq2+9wF/pcaqV7ifGH19dS3dATabXTEuO aGESIc0siPnX47exVkV1qgH1UMAJ1odjsbEE0kgalu6cT/+eIs9R6BtBtoHNQnLq Rgnd7easM6aL3S5a8KOfuj/47gRtrmr0+d59j3x1zIIxreEfQHyfO0x3Ho0raKK3 WvWVwwpusVm1Hg5xl+41lQjRAqqkhYmTiFnouDbgE0V0w+5cMag= =+IlF -END PGP SIGNATURE-
Re: Beta 2.076.1
On 10/07/2017 03:20 PM, Eugene Wissner wrote: > But please consider something different than github as alternative. > GitHub doesn't guarantee that it always generates the same tarball for > the same commit/release, so the checksum can change and the downloaded > tarball looks corrupted, though it has absolutely the same content. Ah good to know, indeed seems to be a problem for GH's archive endpoints? Would of course be a nogo for distro build receipts. https://github.com/libgit2/libgit2/issues/4343#issuecomment-328631745
Re: Eilmer4 - a Computational Fluid Dynamics code in D
On Saturday, 7 October 2017 at 09:29:42 UTC, user1234 wrote: On Friday, 6 October 2017 at 22:16:09 UTC, Peter Jacobs wrote: Eilmer is a simulation code for studying high-speed compressible flows. Early versions were written in C and then C++. Version 4 is a complete rewrite in D, with Lua for configuration and run-time scripting. Code and documentation may be found at http://cfcfd.mechmining.uq.edu.au/eilmer/ [...] Cheers, Peter Jacobs and Rowan Gollan After reading the pdf i have a question: Is LUA scripting too complex to be replaced by, let's say, pure D code, following a compile-time interface (i.e a duck type) ? I understand that existing LUA scripts must still be supported but since D is also known for its good speed of compilation perhaps the whole thing could be recompiled from scratch for a particular set of new scripts. We did consider having the entire application in pure D code, however, we find that Lua is an easier configuration language for our users, who are mostly non-coders. Peter J.
Re: GDC in Slackware and a bit about GDC development
On Monday, 9 October 2017 at 08:10:41 UTC, Iain Buclaw wrote: On 9 October 2017 at 10:03, Eugene Wissner via Digitalmars-d-announce wrote: On Sunday, 24 September 2017 at 09:27:42 UTC, Iain Buclaw wrote: That would almost certainly only happen if you were using a different druntime. Check where your import modules are coming from, they probably aren't gdc's. Ah yes. Thanks a lot for the hint. I tried to compile with "-v" and got: importobject(/usr/include/d/object.d) importcore.stdc.stdarg (/usr/include/d/core/stdc/stdarg.d) importcore.stdc.stdlib (/usr/include/d/core/stdc/stdlib.d) importcore.stdc.config (/usr/include/d/core/stdc/config.d) importcore.stdc.stddef (/usr/include/d/core/stdc/stddef.d) semantic test entry main test.d import__entrypoint (/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/d/__entrypoint.di) "/usr/include/d/core" is the druntime of dmd. gdc's one is in: /usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/d/core But GCC wants to use "/usr/include/d/" for some reason. If I remove dmd, then the example above compiles. I wasn't able to find how to change it. I'll probably change the runtime and phobos paths for dmd and move gcc's D directories into their old place. It might be a configure flag to change that. Though I think at least Archlinux just applies local patches to all compilers to point the system directory explicitly to different locations. I'd say it's a dmd package bug for putting dmd sources in /usr/include/d, when this should be reserved for more general D application libraries. I've chosen "/usr/include/d" for dmd since freebsd seems to use it and IIRC the debian-family aswell (I'm maintaining dmd package aswell). I compared installation directories for c/c++ and gcc include files are in "/usr/include/c++/5.3.0/", llvm: "/usr/include/llvm". So the appropriate way would be probably just to put dmd stuff in "/usr/include/dmd". Maybe I'll look into it later again. At least I have a quick solution for now to get both compilers work on one system.
Re: GDC in Slackware and a bit about GDC development
On 9 October 2017 at 10:03, Eugene Wissner via Digitalmars-d-announce wrote: > On Sunday, 24 September 2017 at 09:27:42 UTC, Iain Buclaw wrote: >> >> >> That would almost certainly only happen if you were using a different >> druntime. Check where your import modules are coming from, they probably >> aren't gdc's. >> > > Ah yes. Thanks a lot for the hint. I tried to compile with "-v" and got: > > importobject(/usr/include/d/object.d) > importcore.stdc.stdarg (/usr/include/d/core/stdc/stdarg.d) > importcore.stdc.stdlib (/usr/include/d/core/stdc/stdlib.d) > importcore.stdc.config (/usr/include/d/core/stdc/config.d) > importcore.stdc.stddef (/usr/include/d/core/stdc/stddef.d) > semantic test > entry main test.d > import__entrypoint > (/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/d/__entrypoint.di) > > > "/usr/include/d/core" is the druntime of dmd. gdc's one is in: > /usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/d/core > > But GCC wants to use "/usr/include/d/" for some reason. If I remove dmd, > then the example above compiles. > I wasn't able to find how to change it. I'll probably change the runtime and > phobos paths for dmd and move gcc's D directories into their old place. It might be a configure flag to change that. Though I think at least Archlinux just applies local patches to all compilers to point the system directory explicitly to different locations. I'd say it's a dmd package bug for putting dmd sources in /usr/include/d, when this should be reserved for more general D application libraries.
Re: GDC in Slackware and a bit about GDC development
On Sunday, 24 September 2017 at 09:27:42 UTC, Iain Buclaw wrote: That would almost certainly only happen if you were using a different druntime. Check where your import modules are coming from, they probably aren't gdc's. Ah yes. Thanks a lot for the hint. I tried to compile with "-v" and got: importobject(/usr/include/d/object.d) importcore.stdc.stdarg (/usr/include/d/core/stdc/stdarg.d) importcore.stdc.stdlib (/usr/include/d/core/stdc/stdlib.d) importcore.stdc.config (/usr/include/d/core/stdc/config.d) importcore.stdc.stddef (/usr/include/d/core/stdc/stddef.d) semantic test entry main test.d import __entrypoint (/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/d/__entrypoint.di) "/usr/include/d/core" is the druntime of dmd. gdc's one is in: /usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/d/core But GCC wants to use "/usr/include/d/" for some reason. If I remove dmd, then the example above compiles. I wasn't able to find how to change it. I'll probably change the runtime and phobos paths for dmd and move gcc's D directories into their old place.