Re: LDC 1.7.0

2018-01-05 Thread Soulsbane via Digitalmars-d-announce

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

2018-01-05 Thread 鲜卑拓跋枫 via Digitalmars-d-announce

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

2018-01-05 Thread Jon Degenhardt via Digitalmars-d-announce

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

2018-01-05 Thread Mike Franklin via Digitalmars-d-announce
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

2018-01-05 Thread Mike Parker via Digitalmars-d-announce
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

2018-01-05 Thread Mike Parker via Digitalmars-d-announce

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

2018-01-05 Thread kinke via Digitalmars-d-announce

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

2018-01-05 Thread Jack Stouffer via Digitalmars-d-announce

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

2018-01-05 Thread user789 via Digitalmars-d-announce

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

2018-01-05 Thread H. S. Teoh via Digitalmars-d-announce
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

2018-01-05 Thread Jack Stouffer via Digitalmars-d-announce

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

2018-01-05 Thread gleb via Digitalmars-d-announce
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

2018-01-05 Thread H. S. Teoh via Digitalmars-d-announce
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

2018-01-05 Thread user789 via Digitalmars-d-announce
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

2018-01-05 Thread rikki cattermole via Digitalmars-d-announce

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

2018-01-05 Thread Глеб Куликов/Gleb Kulikov via Digitalmars-d-announce
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

2018-01-05 Thread Jack Stouffer via Digitalmars-d-announce
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