www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Release D 2.090.0

reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
Glad to announce D 2.090.0, ♥ to the 48 contributors.

This release comes with the ability to convert lazy parameters to
delegates, new intrinsics to force rounding to specific floating point
precision, unittest builds that no longer execute main by default, a new
GC.inFinalizer API, and various other changes.

http://dlang.org/download.html
http://dlang.org/changelog/2.090.0.html

-Martin
Jan 07 2020
next sibling parent reply JN <666total wp.pl> writes:
On Tuesday, 7 January 2020 at 10:30:09 UTC, Martin Nowak wrote:

 Glad to announce D 2.090.0, ♥ to the 48 contributors.

 This release comes with the ability to convert lazy parameters 
 to delegates, new intrinsics to force rounding to specific 
 floating point precision, unittest builds that no longer 
 execute main by default, a new GC.inFinalizer API, and various 
 other changes.

 http://dlang.org/download.html 
 http://dlang.org/changelog/2.090.0.html

 -Martin


Loving the JSON getter :)
Jan 07 2020
parent Andrea Fontana <nospam example.com> writes:
On Tuesday, 7 January 2020 at 11:12:09 UTC, JN wrote:

 Loving the JSON getter :)


<adv>
Did you give jsonwrap[1] a try?
</adv>

[1] https://code.dlang.org/packages/jsonwrap
Jan 07 2020
prev sibling next sibling parent reply Simen =?UTF-8?B?S2rDpnLDpXM=?= <simen.kjaras gmail.com> writes:
On Tuesday, 7 January 2020 at 10:30:09 UTC, Martin Nowak wrote:

 Glad to announce D 2.090.0, ♥ to the 48 contributors.

 This release comes with the ability to convert lazy parameters 
 to delegates, new intrinsics to force rounding to specific 
 floating point precision, unittest builds that no longer 
 execute main by default, a new GC.inFinalizer API, and various 
 other changes.

 http://dlang.org/download.html 
 http://dlang.org/changelog/2.090.0.html

 -Martin


Something seems to be wrong with the 2.090.0 Windows installer. 
After successfully installing, it proceeds to delete every file 
it has just added.

Looking closely at how it happens, it seems that it might 
actually be caused by the uninstaller deleting itself and the 
directory it's in. If I wait long after the previous version has 
been uninstalled before clicking 'next', it doesn't happen.

So, how to reproduce:

1) have a previous DMD version installed
2) start the 2.090.0 installer
3) answer yes to uninstalling the previous version
4) quickly finish installing 2.090.0

If you do this with the install folder open in an explorer 
window, you should see the files disappearing during the 
uninstall of the previous version, until the only item in the D 
folder is uninstall.exe. As the new install proceeds more files 
and folders will be added, and finally they will all be deleted 
again, sometimes leaving an empty folders, other times a partial 
installation (I've only once managed to get a partial 
installation).

--
   Simen
Jan 08 2020
parent suncarpet <suncarpet firemail.cc> writes:
On Wednesday, 8 January 2020 at 12:13:50 UTC, Simen Kjærås wrote:

 Something seems to be wrong with the 2.090.0 Windows installer. 
 After successfully installing, it proceeds to delete every file 
 it has just added.

 Looking closely at how it happens, it seems that it might 
 actually be caused by the uninstaller deleting itself and the 
 directory it's in. If I wait long after the previous version 
 has been uninstalled before clicking 'next', it doesn't happen.

 So, how to reproduce:

 1) have a previous DMD version installed
 2) start the 2.090.0 installer
 3) answer yes to uninstalling the previous version
 4) quickly finish installing 2.090.0

 If you do this with the install folder open in an explorer 
 window, you should see the files disappearing during the 
 uninstall of the previous version, until the only item in the D 
 folder is uninstall.exe. As the new install proceeds more files 
 and folders will be added, and finally they will all be deleted 
 again, sometimes leaving an empty folders, other times a 
 partial installation (I've only once managed to get a partial 
 installation).

 --
   Simen


Through three iterations, I couldn't reproduce this problem by 
following the provided steps. I used checksums of a clean 2.090.0 
installation to ensure there was no partial installation after 
each upgrade. ╮(￣ω￣;)╭
Jan 08 2020
prev sibling next sibling parent reply Meta <jared771 gmail.com> writes:
On Tuesday, 7 January 2020 at 10:30:09 UTC, Martin Nowak wrote:

 Glad to announce D 2.090.0, ♥ to the 48 contributors.

 This release comes with the ability to convert lazy parameters 
 to delegates, new intrinsics to force rounding to specific 
 floating point precision, unittest builds that no longer 
 execute main by default, a new GC.inFinalizer API, and various 
 other changes.

 http://dlang.org/download.html 
 http://dlang.org/changelog/2.090.0.html

 -Martin


Deprecated module std.experimental.all was removed
All symbols contained in Phobos can now be used with import std

Maybe I'm wrong, but this seems like a bad idea to me (unless 
we're getting rid of std.experimental).
Jan 08 2020
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Jan 08, 2020 at 09:43:05PM +0000, Meta via Digitalmars-d-announce wrote:
[...]

 Deprecated module std.experimental.all was removed
 All symbols contained in Phobos can now be used with import std
 
 Maybe I'm wrong, but this seems like a bad idea to me (unless we're
 getting rid of std.experimental).


I think you misunderstood what happened here.  Originally
std.experimental.all *was* the same thing as today's std/package.d; the
only reason it was put in std.experimental was because it was still an
experiment to see if importing all of Phobos is actually feasible in
practice.  Since it apparently worked quite well, it was moved from
std/experimental/all.d to std/package.d.

Ergo, import std.experimental.all != import std.experimental.*; rather,

	import std.experimental.all == import std.*

in the past, and now we've just made it official by allowing you to
write:

	import std;


T

-- 
May you live all the days of your life. -- Jonathan Swift
Jan 08 2020
parent Meta <jared771 gmail.com> writes:
On Wednesday, 8 January 2020 at 21:58:29 UTC, H. S. Teoh wrote:

 On Wed, Jan 08, 2020 at 09:43:05PM +0000, Meta via 
 Digitalmars-d-announce wrote: [...]

 Deprecated module std.experimental.all was removed
 All symbols contained in Phobos can now be used with import std
 
 Maybe I'm wrong, but this seems like a bad idea to me (unless 
 we're
 getting rid of std.experimental).


 I think you misunderstood what happened here.  Originally 
 std.experimental.all *was* the same thing as today's 
 std/package.d; the only reason it was put in std.experimental 
 was because it was still an experiment to see if importing all 
 of Phobos is actually feasible in practice.  Since it 
 apparently worked quite well, it was moved from 
 std/experimental/all.d to std/package.d.

 Ergo, import std.experimental.all != import std.experimental.*; 
 rather,

 	import std.experimental.all == import std.*

 in the past, and now we've just made it official by allowing 
 you to write:

 	import std;


 T


Ah, I misunderstood. Thanks.
Jan 08 2020
prev sibling next sibling parent uranuz <neuranuz gmail.com> writes:
On Tuesday, 7 January 2020 at 10:30:09 UTC, Martin Nowak wrote:

 Glad to announce D 2.090.0, ♥ to the 48 contributors.

 This release comes with the ability to convert lazy parameters 
 to delegates, new intrinsics to force rounding to specific 
 floating point precision, unittest builds that no longer 
 execute main by default, a new GC.inFinalizer API, and various 
 other changes.

 http://dlang.org/download.html 
 http://dlang.org/changelog/2.090.0.html

 -Martin


Now multiple deprecation warnings (about deprecated enum members) 
caused by passing std.json: JSONType value to `format` are fixed. 
It looks like that. Thanks for this very much ;-)
Jan 14 2020
prev sibling parent reply uranuz <neuranuz gmail.com> writes:
On Tuesday, 7 January 2020 at 10:30:09 UTC, Martin Nowak wrote:

 Glad to announce D 2.090.0, ♥ to the 48 contributors.

 This release comes with the ability to convert lazy parameters 
 to delegates, new intrinsics to force rounding to specific 
 floating point precision, unittest builds that no longer 
 execute main by default, a new GC.inFinalizer API, and various 
 other changes.

 http://dlang.org/download.html 
 http://dlang.org/changelog/2.090.0.html

 -Martin


But I got another problemme:
Memory allocation failed In module src/core/exception.d:647. 
Traceback:

I have installed 2.089 back to check. And in the previous version 
there is no such error.
Jan 14 2020
parent reply uranuz <neuranuz gmail.com> writes:
 I have installed 2.089 back to check. And in the previous 
 version there is no such error.


I have tried to debug. And looks like this error occurred during 
throwing exception inside std.exception: enforce.
Jan 14 2020
parent reply uranuz <neuranuz gmail.com> writes:
Seems that I managed to slightly reduce the problemme. I suspect 
that error is somehow connected with running my code inside 
TaskPool:
https://dlang.org/library/std/parallelism/task_pool.html

`Memory allocation failed` error occurs when I throw any 
exception even trivial one:
throw new Exception(`Test`)

I have 3 modes of my small web server:
1. The main mode uses TaskPool to create fixed pool of working 
threads.
2. The second mode just creates new thread for every connection 
using class inherited from: import core.thread: Thread;
3. And the third variation is most stupid. It handles all 
requests in single thread.

The second and third variant working normally. But the first 
generates memory allocation error when I throw Exception inside 
of it. There was no such error before 2.090. I have tried 
forcibly recompile the same version of my code with 2.089 and 
2.090. And version compiled with 2.089 doesn't have this issue.

Do anybody knows what could be changed or what else to try?
Feb 25 2020
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 2/25/20 2:40 PM, uranuz wrote:

 Seems that I managed to slightly reduce the problemme. I suspect that 
 error is somehow connected with running my code inside TaskPool:
 https://dlang.org/library/std/parallelism/task_pool.html
 
 `Memory allocation failed` error occurs when I throw any exception even 
 trivial one:
 throw new Exception(`Test`)
 
 I have 3 modes of my small web server:
 1. The main mode uses TaskPool to create fixed pool of working threads.
 2. The second mode just creates new thread for every connection using 
 class inherited from: import core.thread: Thread;
 3. And the third variation is most stupid. It handles all requests in 
 single thread.
 
 The second and third variant working normally. But the first generates 
 memory allocation error when I throw Exception inside of it. There was 
 no such error before 2.090. I have tried forcibly recompile the same 
 version of my code with 2.089 and 2.090. And version compiled with 2.089 
 doesn't have this issue.
 
 Do anybody knows what could be changed or what else to try?


Have you tried valgrind or similar tools? Memory errors are the worst.

"Memory allocation failed" seems to suggest however that you are out of 
memory.

But with memory errors - it's quite possible the problem is still in 
2.089, but some small change causes the memory issue to come out.

-Steve
Feb 25 2020
next sibling parent uranuz <neuranuz gmail.com> writes:
I believe that problemme is somehow connected with 
core.runtime.DefaultTraceInfo.
I figured out that it fail inside a function that tries to get 
trace info for exception. Body is pretty simple. I created the 
case where `ex` is just an instance of standart Exception class 
in order to eliminate some side effects or errors that could be 
introduced by my code.

auto errorToJSON(Throwable ex)
{
	import std.json: JSONValue;
	import std.conv: to;

	string[] backTrace;
         // Commenting this loop removes memory error
	foreach( inf; ex.info )
		backTrace ~= inf.to!string; // Debug point is there

	JSONValue jErr = [
		"code": JSONValue(1),
		"message": JSONValue(ex.msg),
		"data": JSONValue([
			"file": JSONValue(ex.file),
			"line": JSONValue(ex.line),
			"backtrace": JSONValue(backTrace)
		])
	];

	return jErr;
}

I just tried to debug this code. And put debug point there (where 
it is commented). And programme fails after several iterations in 
this loop. There is call stack at this break point:

webtank.net.utils.errorToJSON(object.Throwable).__foreachbody2(ref
const(char[])) 0x0000555555d35317
(/home/uranuz/sources/webtank/src/webtank/net/utils.d:112)
_D4core7runtime16DefaultTraceInfo7opApplyMxFMDFKxAaZiZ__T9__lambda2TmZQnMFKmKxQBdZ
 0x0000555555e1a4ac (Unknown Source:0)
rt.backtrace.dwarf.traceHandlerOpApplyImpl(const(void*[]), scope 
int(ref ulong, ref const(char[])) delegate) 0x0000555555e1c65c 
(Unknown Source:0)
core.runtime.DefaultTraceInfo.opApply(scope int(ref ulong, ref 
const(char[])) delegate) const 0x0000555555e1a501 (Unknown 
Source:0)
core.runtime.DefaultTraceInfo.opApply(scope int(ref 
const(char[])) delegate) const 0x0000555555e1a47e (Unknown 
Source:0)
webtank.net.utils.errorToJSON(object.Throwable) 0x0000555555d34fa6
(/home/uranuz/sources/webtank/src/webtank/net/utils.d:111)
_D7webtank3net6server6common17makeErrorResponseFC6object9ThrowableCQCnQCi4http6output10HTTPOutputZ
 0x0000555555d349bb (/home/uranuz/sources/webtank/src/webtank/net/server/common.d:50)
_D7webtank3net6server6common14processRequestFC3std6socket6SocketCQClQCgQCf5iface10IWebServerZ
 0x0000555555d16f96 (/home/uranuz/sources/webtank/src/webtank/net/server/common.d:113)
_D3std11parallelism__T3runTPFCQBc6socket6SocketC7webtank3net6server5iface10IWebServerZvTQChTCQBtQBoQBn11thread_pool16ThreadPoolServerZQEiFQEhKQEjKQCcZ
 0x0000555555cc27cf (/usr/include/dmd/phobos/std/parallelism.d:761)
_D3std11parallelism__T4TaskSQBaQz3runTPFCQBn6socket6SocketC7webtank3net6server5iface10IWebServerZvTQChTCQBtQBoQBn11thread_pool16ThreadPoolServerZQEt4implFPvZ
 0x0000555555cc2171 (/usr/include/dmd/phobos/std/parallelism.d:444)
std.parallelism.AbstractTask.job() 0x0000555555dbb423 (Unknown 
Source:0)
_D3std11parallelism8TaskPool5doJobMFPSQBkQBj12AbstractTaskZv 0x0000555555dbb574
(Unknown Source:0)
std.parallelism.TaskPool.executeWorkLoop() 0x0000555555dbb6ea 
(Unknown Source:0)
std.parallelism.TaskPool.startWorkLoop() 0x0000555555dbb690 
(Unknown Source:0)
core.thread.osthread.Thread.run() 0x0000555555da74de (Unknown 
Source:0)
thread_entryPoint 0x0000555555de9016 (Unknown Source:0)
start_thread 0x00007ffff72176db 
(/build/glibc-OTsEL5/glibc-2.27/nptl/pthread_create.c:463)
clone 0x00007ffff657e88f 
(/build/glibc-OTsEL5/glibc-2.27/sysdeps/unix/sysv/linux/x86_64/clone.S:95)

So I believe that bug is somewhere around there. Because there 
are some fixed size buffers in code. And have some template code, 
so symbol names could be greather in size that this buffers. And 
this case could be not handled good enough.

What dou you think about it? I shall try to create some 
representative example of smaller size to fill a bug report.
Feb 29 2020
prev sibling parent uranuz <neuranuz gmail.com> writes:
I have just added workaround of this bug in by code. And now it 
is working and returns backtrace

string[] getBacktrace(Throwable ex)
{
	import std.conv: to;
	import core.exception: OutOfMemoryError;

	string[] backTrace;
	try {
		foreach( inf; ex.info )
			backTrace ~= inf.to!string;
	} catch( OutOfMemoryError exc ) {} // Workaround for some bug in 
DefaultTraceInfo.opApply
	return backTrace;
}

auto errorToJSON(Throwable ex)
{
	import std.json: JSONValue;

	return JSONValue([
		"code": JSONValue(1),
		"message": JSONValue(ex.msg),
		"data": JSONValue([
			"file": JSONValue(ex.file),
			"line": JSONValue(ex.line),
			"backtrace": JSONValue(getBacktrace(ex))
		])
	]);
}
Feb 29 2020