Re: Beta 2.076.1

[Eugene Wissner via Digitalmars-d-announce]

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

[zabruk70 via Digitalmars-d-announce]

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

[Martin Nowak via Digitalmars-d-announce]

-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

[Martin Nowak via Digitalmars-d-announce]

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

[Peter Jacobs via Digitalmars-d-announce]

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

[Eugene Wissner via Digitalmars-d-announce]

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

[Iain Buclaw via Digitalmars-d-announce]

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

[Eugene Wissner via Digitalmars-d-announce]

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.