Re: dmt: Python-like indentation in D programming language
On Wednesday, 17 November 2021 at 11:00:46 UTC, JN wrote: On Tuesday, 16 November 2021 at 21:58:24 UTC, Witold Baryluk wrote: Hi, `dmt` is an old project of mine from around year 2006. I ported it recently from D1 to D2, and added some extra features and support for extra keywords, and fixed few bugs here and there. `dmt` is a converter (offline or auto-invoking compiler after conversion) from Python-like indention style to curly braces for D programming language. I love the idea. Never been a fan of braces to define blocks and I find them to be much more of a pain to match than whitespace. These days however, I just set dfmt to autorun on file save and never worry about formatting again. I am programming in Python mostly on my job and sometimes in C++ and JavaScript. Personally I like syntax with braces to define blocks more that Python's syntax without blocks. One of the reasons - why?1 Is that very often when I copy-paste some fragments of code then some editors sometimes just tries to autoindent programme and does it wrong. Then it breaks entirely and I get some errors from production just because of this. And just for aestetic reasons I like when blocks are explicitly delimitered by braces. Syntax with braces also allows write "one-liners" easier when it's needed. So personall I shall not use this in D
Re: Release D 2.090.0
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))
])
]);
}
Re: Release D 2.090.0
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[]))@0x55d35317
(/home/uranuz/sources/webtank/src/webtank/net/utils.d:112)
_D4core7runtime16DefaultTraceInfo7opApplyMxFMDFKxAaZiZ__T9__lambda2TmZQnMFKmKxQBdZi@0x55e1a4ac
(Unknown Source:0)
rt.backtrace.dwarf.traceHandlerOpApplyImpl(const(void*[]), scope
int(ref ulong, ref const(char[])) delegate)@0x55e1c65c
(Unknown Source:0)
core.runtime.DefaultTraceInfo.opApply(scope int(ref ulong, ref
const(char[])) delegate) const@0x55e1a501 (Unknown
Source:0)
core.runtime.DefaultTraceInfo.opApply(scope int(ref
const(char[])) delegate) const@0x55e1a47e (Unknown
Source:0)
webtank.net.utils.errorToJSON(object.Throwable)@0x55d34fa6
(/home/uranuz/sources/webtank/src/webtank/net/utils.d:111)
_D7webtank3net6server6common17makeErrorResponseFC6object9ThrowableCQCnQCi4http6output10HTTPOutputZv@0x55d349bb
(/home/uranuz/sources/webtank/src/webtank/net/server/common.d:50)
_D7webtank3net6server6common14processRequestFC3std6socket6SocketCQClQCgQCf5iface10IWebServerZv@0x55d16f96
(/home/uranuz/sources/webtank/src/webtank/net/server/common.d:113)
_D3std11parallelism__T3runTPFCQBc6socket6SocketC7webtank3net6server5iface10IWebServerZvTQChTCQBtQBoQBn11thread_pool16ThreadPoolServerZQEiFQEhKQEjKQCcZv@0x55cc27cf
(/usr/include/dmd/phobos/std/parallelism.d:761)
_D3std11parallelism__T4TaskSQBaQz3runTPFCQBn6socket6SocketC7webtank3net6server5iface10IWebServerZvTQChTCQBtQBoQBn11thread_pool16ThreadPoolServerZQEt4implFPvZv@0x55cc2171
(/usr/include/dmd/phobos/std/parallelism.d:444)
std.parallelism.AbstractTask.job()@0x55dbb423 (Unknown
Source:0)
_D3std11parallelism8TaskPool5doJobMFPSQBkQBj12AbstractTaskZv@0x55dbb574
(Unknown Source:0)
std.parallelism.TaskPool.executeWorkLoop()@0x55dbb6ea
(Unknown Source:0)
std.parallelism.TaskPool.startWorkLoop()@0x55dbb690
(Unknown Source:0)
core.thread.osthread.Thread.run()@0x55da74de (Unknown
Source:0)
thread_entryPoint@0x55de9016 (Unknown Source:0)
start_thread@0x772176db
(/build/glibc-OTsEL5/glibc-2.27/nptl/pthread_create.c:463)
clone@0x7657e88f
(/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.
Re: Release D 2.090.0
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?
Re: Release D 2.090.0
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.
Re: Release D 2.090.0
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.
Re: Release D 2.090.0
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 ;-)
Re: release of code-d 0.21.0 + serve-d 0.5.1
Hello! When code-d attempts self upgrade it prints the followinf output to console of VS Code: """ Installing DCD: DCD is outdated. Expected: 0.11.1, got none Downloading from https://github.com/dlang-community/DCD/releases/download/v0.11.1/dcd-v0.11.1-linux-x86_64.tar.gz to /home/uranuz/.local/share/code-d/bin Zip file already exists! Trying to install existing zip. Extracting download... tar xvfz dcd-v0.11.1-linux-x86_64.tar.gz gzip: stdin: not in gzip format /bin/tar: Child returned status 1 /bin/tar: Error is not recoverable: exiting now Successfully downloaded DCD, but could not find the executables. Please open your user settings and insert the paths for dcd-client and dcd-server manually. Download base location: /home/uranuz/.local/share/code-d/bin Tried "dcd-client", "dcd-server", "bin/dcd-client", "bin/dcd-server" Successfully installed DCD """ Looks like something went wrong with extracting archive: dcd-v0.11.1-linux-x86_64.tar.gz. This archive is not opening with standart Kubuntu GUI archiver like "Ark", but still I was able to "unzip" in through "unar" programme. Maybe you just archived it with some exotical settings of compression so it doesn't open everywhere.
Re: Beta 2.088.1
On Friday, 4 October 2019 at 05:58:03 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.088.1 point release, ♥ to the 6 contributors. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.088.1.html As usual please report any bugs at https://issues.dlang.org -Martin Could anybody consider this problemme? It is quite annoying: https://issues.dlang.org/show_bug.cgi?id=19864
Re: Release D 2.087.0
On Sunday, 7 July 2019 at 10:09:50 UTC, Johannes Pfau wrote:
Am Sun, 07 Jul 2019 08:06:57 + schrieb uranuz:
After updating compiler to 2.087 I got a lot of deprecation
warnings
linked to std.json module. I have found all of the usages of
deprecated
symbols in my project and changed them to the new ones. All
these
warnings are about changing JSON_TYPE to JSONType
JSON_TYPE.STRING to
JSONType.string and etc...
But after eleminating deprecated symbols from my project I
still have
deprecation warnings. Seems that these symbols being accessed
from
Phobos, because I am pretty sure that I don't have other
external
dependencies that use std.json. The problem it that because of
this
`spamming` messages I can miss `real` deprecation warnings. Is
there
some way to `fix` it? The is some part of compiler output (all
of it is
too long): /usr/include/dmd/phobos/std/conv.d(987,34):
Deprecation: enum
member `std.json.JSONType.INTEGER` is deprecated - Use .integer
/usr/include/dmd/phobos/std/conv.d(987,34): Deprecation: enum
member
I think phobos does not explicitly use these deprecated
symbols, but the reflection code in format triggers the
deprecation messages:
import std.json, std.stdio;
void main()
{
JSONType c;
writefln("%s", c);
}
I'm not sure if this can be solved, maybe deprecated members
can be explicitly ignored in format, but maybe the reflection
code itself is triggering the deprecation (which would then
probably be a DMD bug).
Yes. It looks like it, because seems that `format` and `conv` use
the same approach to convert data to string and in process of
iterating reflection code `touches` deprecated symbols and it
`starts to smell`... Maybe some special `compilation context`
should exists where these deprecation warnings are ignored or
ignore them when we access or iterate symbols using __trait(...)
Should I file a bugreport?
Re: Release D 2.087.0
After updating compiler to 2.087 I got a lot of deprecation warnings linked to std.json module. I have found all of the usages of deprecated symbols in my project and changed them to the new ones. All these warnings are about changing JSON_TYPE to JSONType JSON_TYPE.STRING to JSONType.string and etc... But after eleminating deprecated symbols from my project I still have deprecation warnings. Seems that these symbols being accessed from Phobos, because I am pretty sure that I don't have other external dependencies that use std.json. The problem it that because of this `spamming` messages I can miss `real` deprecation warnings. Is there some way to `fix` it? The is some part of compiler output (all of it is too long): /usr/include/dmd/phobos/std/conv.d(987,34): Deprecation: enum member `std.json.JSONType.INTEGER` is deprecated - Use .integer /usr/include/dmd/phobos/std/conv.d(987,34): Deprecation: enum member `std.json.JSONType.INTEGER` is deprecated - Use .integer /usr/include/dmd/phobos/std/conv.d(987,34): Deprecation: enum member `std.json.JSONType.UINTEGER` is deprecated - Use .uinteger /usr/include/dmd/phobos/std/conv.d(987,34): Deprecation: enum member `std.json.JSONType.UINTEGER` is deprecated - Use .uinteger /usr/include/dmd/phobos/std/conv.d(987,34): Deprecation: enum member `std.json.JSONType.FLOAT` is deprecated - Use .float_ /usr/include/dmd/phobos/std/conv.d(987,34): Deprecation: enum member `std.json.JSONType.FLOAT` is deprecated - Use .float_ /usr/include/dmd/phobos/std/conv.d(987,34): Deprecation: enum member `std.json.JSONType.ARRAY` is deprecated - Use .array /usr/include/dmd/phobos/std/conv.d(987,34): Deprecation: enum member `std.json.JSONType.ARRAY` is deprecated - Use .array /usr/include/dmd/phobos/std/conv.d(987,34): Deprecation: enum member `std.json.JSONType.OBJECT` is deprecated - Use .object /usr/include/dmd/phobos/std/conv.d(987,34): Deprecation: enum member `std.json.JSONType.OBJECT` is deprecated - Use .object /usr/include/dmd/phobos/std/format.d(4373,24): Deprecation: enum member `std.json.JSONType.NULL` is deprecated - Use .null_ /usr/include/dmd/phobos/std/format.d(4373,24): Deprecation: enum member `std.json.JSONType.NULL` is deprecated - Use .null_ /usr/include/dmd/phobos/std/format.d(4373,24): Deprecation: enum member `std.json.JSONType.STRING` is deprecated - Use .string /usr/include/dmd/phobos/std/format.d(4373,24): Deprecation: enum member `std.json.JSONType.STRING` is deprecated - Use .string /usr/include/dmd/phobos/std/format.d(4373,24): Deprecation: enum member `std.json.JSONType.INTEGER` is deprecated - Use .integer /usr/include/dmd/phobos/std/format.d(4373,24): Deprecation: enum member `std.json.JSONType.INTEGER` is deprecated - Use .integer /usr/include/dmd/phobos/std/format.d(4373,24): Deprecation: enum member `std.json.JSONType.UINTEGER` is deprecated - Use .uinteger /usr/include/dmd/phobos/std/format.d(4373,24): Deprecation: enum member `std.json.JSONType.UINTEGER` is deprecated - Use .uinteger /usr/include/dmd/phobos/std/format.d(4373,24): Deprecation: enum member `std.json.JSONType.FLOAT` is deprecated - Use .float_ /usr/include/dmd/phobos/std/format.d(4373,24): Deprecation: enum member `std.json.JSONType.FLOAT` is deprecated - Use .float_ /usr/include/dmd/phobos/std/format.d(4373,24): Deprecation: enum member `std.json.JSONType.ARRAY` is deprecated - Use .array /usr/include/dmd/phobos/std/format.d(4373,24): Deprecation: enum member `std.json.JSONType.ARRAY` is deprecated - Use .array /usr/include/dmd/phobos/std/format.d(4373,24): Deprecation: enum member `std.json.JSONType.OBJECT` is deprecated - Use .object /usr/include/dmd/phobos/std/format.d(4373,24): Deprecation: enum member `std.json.JSONType.OBJECT` is deprecated - Use .object
Re: Voting for std.experimental.allocator
On Thursday, 16 July 2015 at 10:02:17 UTC, Dicebot wrote: On Wednesday, 8 July 2015 at 11:33:03 UTC, Dicebot wrote: Voting ends in 2 weeks, on July 22. ~1 week remains Yes. It's time to have this functionality in standart library.
