Re: LDC 1.7.0
On Saturday, 6 January 2018 at 01:19:14 UTC, kinke wrote: Hi everyone, on behalf of the LDC team, I'm glad to announce 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. * LLVM for prebuilt packages upgraded to v5.0.1. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.7.0 Thanks to all contributors! Does anyone know if the ldc2 Snap is going to be updated. It is at 1.4.0 and snap refresh says no updates available. Thanks!
Re: LDC 1.7.0
Great, thank you very much! And does LDC has the plan for release an AArch64/Linux version? On Saturday, 6 January 2018 at 01:19:14 UTC, kinke wrote: Hi everyone, on behalf of the LDC team, I'm glad to announce 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. * LLVM for prebuilt packages upgraded to v5.0.1. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.7.0 Thanks to all contributors!
Re: DLang docker images for CircleCi 2.0
On Wednesday, 3 January 2018 at 13:12:48 UTC, Seb wrote: tl;dr: you can now use special D docker images for CircleCi 2.0 [snip PS: I'm aware of Stefan Rohe's great D Docker images [1], but this Docker image is built on top of the specialized CircleCi image (e.g. for their SSH login). One useful characteristic of Stefan's images is that the Dockerhub pages include the Dockerfile and github repository links. I don't know what it takes to include them. It does make it easier to see exactly what the configuration is, find the repo, and even create PRs against them. Would be useful if they can be added to the CircleCI image pages. My interest in this case - I use Stefan's LDC image in Travis-CI builds. Building the runtime libraries with LTO/PGO requires the ldc-build-runtime tool, which in turn requires a few additional things in the docker image, like cmake or ninja. I was interested if they might have been included in the CircleCI images as well. (Doesn't appear so.)
Re: Release D 2.078.0
On Thursday, 4 January 2018 at 17:40:55 UTC, David Nadlinger wrote: it would be fairly easy to manually look up the set of ModuleInfos in a druntime-less D program. ModuleInfo is declared and defined in druntime (https://github.com/dlang/druntime/blob/7bfaa8c0755771b807a8344b8c0bfcf73aec7c82/src/object.d#L1443). If one is doing a druntime-less build, how would it be possible have a set of `ModuleInfo`s to manually look up? Mike
Re: Release D 2.078.0
On Thursday, 4 January 2018 at 17:40:55 UTC, David Nadlinger wrote: This is slightly inaccurate. Regular stack cleanup doesn't involve the runtime at all; druntime only comes into play for exception handling. Since destructors also need to be run when the scope is left by an exception, they are implemented via `try {} finally {}` internally. The EH part of these depends on druntime, but not the regular path. This is somewhat confusingly worded as well. It's actually mostly the other way around – druntime depends on ModuleInfo to be emitted, crucially for static constructor, destructors and unit tests to be run. At least without shared libraries in the picture, it would be fairly easy to manually look up the set of ModuleInfos in a druntime-less D program. — David Thanks, David!
Re: LDC 1.7.0
On Saturday, 6 January 2018 at 01:19:14 UTC, kinke wrote: Hi everyone, on behalf of the LDC team, I'm glad to announce 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. * LLVM for prebuilt packages upgraded to v5.0.1. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.7.0 Thanks to all contributors! Awesome! I need to get in touch with you, but I'm guessing no...@nowhere.com is a dead end :-) Please send something to aldac...@gmail.com. I'd like to talk about coordinating LDC release announcements on the blog.
LDC 1.7.0
Hi everyone, on behalf of the LDC team, I'm glad to announce 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. * LLVM for prebuilt packages upgraded to v5.0.1. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.7.0 Thanks to all contributors!
Re: Proposal for a standard Decimal type in alpha
On Friday, 5 January 2018 at 15:44:57 UTC, H. S. Teoh wrote: On Fri, Jan 05, 2018 at 03:38:45PM +, Jack Stouffer via Digitalmars-d-announce wrote: On Friday, 5 January 2018 at 15:22:01 UTC, H. S. Teoh wrote: > Very nice to see this taking shape. What's the link to the > code again? https://github.com/JackStouffer/stdxdecimal Thanks! Will take a look sometime. Might throw in a PR or two if I can. T Well hold off on that for a day because I just realized I have to redesign the internals of the whole thing due to a bug I found. Long story short, I'd been using a myriad of different types (depending on your chosen precision) to represent the coefficient in order to avoid the slowness of BigInt. But I realized due to a bug that this isn't really a workable solution. I'm going to change the code to always use a BigInt, and just work on making BigInt faster where I can. This will make the Decimal code about half as complex thankfully.
Re: Release D 2.078.0
On Friday, 5 January 2018 at 15:30:39 UTC, gleb wrote: user789 wrote: Unfortunally, linux x86_64 version(*) has problems: I also setup from the RH rpm and it works fine here, also in GDB. Can you reproduce it at each run ? Yes, it's fully reproducable in number of x86_64 systems: system "1",glibc-core-2.25-alt2.x86_64, AMD Athlon, kernel 4.9.56 system "2",glibc-core-2.25-alt3.x86_64, Core i5, kernel 4.9.56 system "3",glibc-core-2.25-alt3.x86_64, Core i7, kernel 4.9.42 system "4",glibc-core-2.25-alt3.x86_64 ,Xeon E5-2620, kernel 4.9.65 with the same behavior, so it is not installation -- dependent. all previous versions of dmd works good. ldc2 1.7.0-beta1 and older works ok as well. all another functionality, except of fwrite, seems to be ok. -- yours sincerely,... I've seen your report. kernel is at 4.14 and glibc is 2.26 here, although it's hard to say if this is the problem but your systems seem not to be updated since about a full year.
Re: Proposal for a standard Decimal type in alpha
On Fri, Jan 05, 2018 at 03:38:45PM +, Jack Stouffer via Digitalmars-d-announce wrote: > On Friday, 5 January 2018 at 15:22:01 UTC, H. S. Teoh wrote: > > Very nice to see this taking shape. What's the link to the code again? > > https://github.com/JackStouffer/stdxdecimal Thanks! Will take a look sometime. Might throw in a PR or two if I can. T -- Why did the mathematician reinvent the square wheel? Because he wanted to drive smoothly over an inverted catenary road.
Re: Proposal for a standard Decimal type in alpha
On Friday, 5 January 2018 at 15:22:01 UTC, H. S. Teoh wrote: Very nice to see this taking shape. What's the link to the code again? https://github.com/JackStouffer/stdxdecimal
Re: Release D 2.078.0
user789 wrote: >> >> Unfortunally, linux x86_64 version(*) has problems: > > I also setup from the RH rpm and it works fine here, also in GDB. > Can you reproduce it at each run ? Yes, it's fully reproducable in number of x86_64 systems: system "1",glibc-core-2.25-alt2.x86_64, AMD Athlon, kernel 4.9.56 system "2",glibc-core-2.25-alt3.x86_64, Core i5, kernel 4.9.56 system "3",glibc-core-2.25-alt3.x86_64, Core i7, kernel 4.9.42 system "4",glibc-core-2.25-alt3.x86_64 ,Xeon E5-2620, kernel 4.9.65 with the same behavior, so it is not installation -- dependent. all previous versions of dmd works good. ldc2 1.7.0-beta1 and older works ok as well. all another functionality, except of fwrite, seems to be ok. -- yours sincerely,...
Re: Proposal for a standard Decimal type in alpha
On Fri, Jan 05, 2018 at 02:30:21PM +, Jack Stouffer via Digitalmars-d-announce wrote: > On Thursday, 21 December 2017 at 13:59:28 UTC, Jack Stouffer wrote: > > ... > > Updated version out: > > * Added unary +,-,++,-- > * Added casting to bool and floating point types > * Added static ctors for infinite and nan for floating point type > compatibility > * Added abs, isNaN, isInfinite > * Added support to opBinary for mixing different precision levels on each > side of the operation Very nice to see this taking shape. What's the link to the code again? T -- Why do conspiracy theories always come from the same people??
Re: Release D 2.078.0
On Friday, 5 January 2018 at 14:30:13 UTC, Глеб Куликов/Gleb Kulikov wrote: Martin Nowak wrote: Glad to announce D 2.078.0. Hello and Happy New Year ! :) Unfortunally, linux x86_64 version(*) has problems: (*) from red hat rpm I also setup from the RH rpm and it works fine here, also in GDB. Can you reproduce it at each run ?
Re: Release D 2.078.0
On 05/01/2018 2:30 PM, Глеб Куликов/Gleb Kulikov wrote: Martin Nowak wrote: Glad to announce D 2.078.0. Hello and Happy New Year ! :) Unfortunally, linux x86_64 version(*) has problems: (*) from red hat rpm simplest test program: module main; import std.stdio; int main(string[] args) { writefln("Hello World\n"); return 0; } traps with follows reason: Program received signal SIGSEGV, Segmentation fault. 0x77460299 in fwrite () from /lib64/libc.so.6 Fatal error: glibc detected an invalid stdio handle Аварийный останов (gdb) bt #0 0x77460299 in fwrite () from /lib64/libc.so.6 #1 0x004046ba in std.stdio (obj=..., f=0x655160 ) at /usr/include/d/std/stdio.d:4064 #2 0x004045f1 in std.stdio.File.LockingTextWriter (this=..., writeme=...) at /usr/include/d/std/stdio.d:2775 #3 0x00403ddb in std.range.primitives (e=..., r=...) at /usr/include/d/std/range/primitives.d:269 #4 0x00403dad in std.range.primitives (e=..., r=...) at /usr/include/d/std/range/primitives.d:358 #5 0x00403d41 in std.format (this=..., writer=...) at /usr/include/d/std/format.d:1188 #6 0x00403871 in std.format (fmt=..., w=...) at /usr/include/d/std/format.d:474 #7 0x004037d1 in std.stdio.File (this=..., fmt=...) at /usr/include/d/std/stdio.d:1496 #8 0x00403759 in std.stdio (fmt=...) at /usr/include/d/std/stdio.d:3797 #9 0x0040370a in D main (args=...) at hello.d:7 Thank you, yours sincerely and etc... Please file an issue (so it doesn't get lost) thanks! http://issues.dlang.org
Re: Release D 2.078.0
Martin Nowak wrote: > > Glad to announce D 2.078.0. Hello and Happy New Year ! :) Unfortunally, linux x86_64 version(*) has problems: (*) from red hat rpm simplest test program: module main; import std.stdio; int main(string[] args) { writefln("Hello World\n"); return 0; } traps with follows reason: Program received signal SIGSEGV, Segmentation fault. 0x77460299 in fwrite () from /lib64/libc.so.6 Fatal error: glibc detected an invalid stdio handle Аварийный останов (gdb) bt #0 0x77460299 in fwrite () from /lib64/libc.so.6 #1 0x004046ba in std.stdio (obj=..., f=0x655160 ) at /usr/include/d/std/stdio.d:4064 #2 0x004045f1 in std.stdio.File.LockingTextWriter (this=..., writeme=...) at /usr/include/d/std/stdio.d:2775 #3 0x00403ddb in std.range.primitives (e=..., r=...) at /usr/include/d/std/range/primitives.d:269 #4 0x00403dad in std.range.primitives (e=..., r=...) at /usr/include/d/std/range/primitives.d:358 #5 0x00403d41 in std.format (this=..., writer=...) at /usr/include/d/std/format.d:1188 #6 0x00403871 in std.format (fmt=..., w=...) at /usr/include/d/std/format.d:474 #7 0x004037d1 in std.stdio.File (this=..., fmt=...) at /usr/include/d/std/stdio.d:1496 #8 0x00403759 in std.stdio (fmt=...) at /usr/include/d/std/stdio.d:3797 #9 0x0040370a in D main (args=...) at hello.d:7 Thank you, yours sincerely and etc...
Re: Proposal for a standard Decimal type in alpha
On Thursday, 21 December 2017 at 13:59:28 UTC, Jack Stouffer wrote: ... Updated version out: * Added unary +,-,++,-- * Added casting to bool and floating point types * Added static ctors for infinite and nan for floating point type compatibility * Added abs, isNaN, isInfinite * Added support to opBinary for mixing different precision levels on each side of the operation