Please see this shortened snippet: https://godbolt.org/z/j8f3x5
I've ran into annoyances before when using aliases to member
fields, but something subtle like this was rather annoying to
figure out.
Why does the compiler feel the need to embed a context pointer
anytime you provide an to
On Friday, 11 December 2020 at 18:18:35 UTC, kdevel wrote:
On Friday, 11 December 2020 at 16:49:18 UTC, Adam D. Ruppe
wrote:
libc-2.30.so
The bug was fixed in 2.28 IIRC.
so i guess i have the fixed libc. Can you confirm what version
you have?
Various. I tested the code on a machine
On Wednesday, 14 September 2011 at 12:16:02 UTC, Steven
Schveighoffer wrote:
In any case, have you tried this? Works on unixen only.
import core.stdc.signal;
extern(C) void handleSegv(int) { assert(0); }
void main()
{
signal(SIGSEGV, );
...
}
Not sure if it prints a stack trace on a
On Fri, Dec 11, 2020 at 07:49:12PM +, vnr via Digitalmars-d-learn wrote:
> For a project with good performance, I would need to be able to
> analyse text. To do so, I would write a parser by hand using the
> recursive descent algorithm, based on a stream of tokens. I started
> writing a lexer
On Friday, 11 December 2020 at 17:32:54 UTC, Adam D. Ruppe wrote:
On Friday, 11 December 2020 at 17:29:12 UTC, Panke wrote:
But somehow my process gets signalled with USR1 and USR2 all
the time. If I do
The garbage collector uses sig usr1/2 to pause threads so it
can do its collection work.
For a project with good performance, I would need to be able to
analyse text. To do so, I would write a parser by hand using the
recursive descent algorithm, based on a stream of tokens. I
started writing a lexer with the d-lex package
(https://code.dlang.org/packages/d-lex), it works really
On Thursday, 10 December 2020 at 21:01:30 UTC, Marcone wrote:
In this very generic example && not work to finalize the
instruct and start a new instruct. Yes, I know dmd can build
and run without it, but this is only a example.
execute(["cmd", "/c", "dmd test.d", "&&", "start test.exe"]);
Hi,
I've just made this unicode wordreplacer function working, but It
seems not too nice and functional-ish.
Are there ways to make it more simple?
import std.stdio, std.range, std.algorithm, std.uni, std.utf,
std.conv;
bool isWordChar(dchar ch){
return isAlphaNum(ch) || ch=='_';
}
On Friday, 11 December 2020 at 16:49:18 UTC, Adam D. Ruppe wrote:
libc-2.30.so
The bug was fixed in 2.28 IIRC.
so i guess i have the fixed libc. Can you confirm what version
you have?
Various. I tested the code on a machine running the yet EOL
CENTOS-6
having glibc 2.12.
On Friday, 11 December 2020 at 17:32:54 UTC, Adam D. Ruppe wrote:
On Friday, 11 December 2020 at 17:29:12 UTC, Panke wrote:
But somehow my process gets signalled with USR1 and USR2 all
the time. If I do
The garbage collector uses sig usr1/2 to pause threads so it
can do its collection work.
On Friday, 11 December 2020 at 17:29:12 UTC, Panke wrote:
But somehow my process gets signalled with USR1 and USR2 all
the time. If I do
The garbage collector uses sig usr1/2 to pause threads so it can
do its collection work.
When debugging just ignore them. My .gdbinit has these lines:
I have as vibe.d application that opens some websockets, reads
messages and does something with them (currently mostly writing
them to disk).
The processing happens in background threads started with
runWorkerTask, the websocket code runs as a normal task
(runTask), everything is
On Friday, 11 December 2020 at 16:37:42 UTC, kdevel wrote:
expected: program ends
found: program still reading
works for me looks like i have
libc-2.30.so
so i guess i have the fixed libc. Can you confirm what version
you have? I did `ls /lib/libc*` to pick that out but it might be
On Friday, 11 December 2020 at 15:57:37 UTC, frame wrote:
On Friday, 11 December 2020 at 12:34:19 UTC, kdevel wrote:
My code cannot do that because the function byChunk has
control over the
file descriptor.
What do you mean by control?
The error happens while the cpu executes code of the D
On Friday, 11 December 2020 at 12:34:19 UTC, kdevel wrote:
My code cannot do that because the function byChunk has control
over the
file descriptor.
What do you mean by control? It just has the file handle, why do
you cannot call eof() on the file handle struct?
You should not check
On Friday, 11 December 2020 at 11:05:59 UTC, frame wrote:
On Friday, 11 December 2020 at 02:31:24 UTC, kdevel wrote:
auto s = cast (string) stdin.byChunk(4).join;
As strace reveals the resulting program sometimes reads twice
zero
characters before it terminates:
read(0, a
On Friday, 11 December 2020 at 11:32:09 UTC, rikki cattermole
wrote:
string is not a built in type. It is an alias defined by
druntime.
https://github.com/dlang/druntime/blob/master/src/object.d#L35
int on the other hand is defined by the compiler. It
understands it.
It doesn't magically
On Friday, 11 December 2020 at 11:36:05 UTC, vit wrote:
alias f1 = (string ) {}
"string" isn't type, but name of variable with generic type:
alias f1 = (/*auto type*/ string) {}
This makes it clear, thanks!
Just checked that this fails as expected: alias f1 =
(immutable(char)[]) {}
On Friday, 11 December 2020 at 11:25:22 UTC, Andrey Zherikov
wrote:
Here is the example:
alias f1 = (string ) {}; f1(int .init);
alias f2 = (string s) {}; f2(int .init);
alias f3 = (int ) {}; f3(string.init);
alias f4 = (int i ) {}; f4(string.init);
"f1" case compiles
On 12/12/2020 12:32 AM, rikki cattermole wrote:
Further, when the parameter name is not provided it will infer based
upon what is passed in. In effect it is templated.
What I meant was: the type is inferred if you only provide a single
identifier in a parameter.
string is not a built in type. It is an alias defined by druntime.
https://github.com/dlang/druntime/blob/master/src/object.d#L35
int on the other hand is defined by the compiler. It understands it.
Further, when the parameter name is not provided it will infer based
upon what is passed in.
Here is the example:
alias f1 = (string ) {}; f1(int .init);
alias f2 = (string s) {}; f2(int .init);
alias f3 = (int ) {}; f3(string.init);
alias f4 = (int i ) {}; f4(string.init);
"f1" case compiles successfully and all others are not (error is
"is not callable
On Friday, 11 December 2020 at 02:31:24 UTC, kdevel wrote:
auto s = cast (string) stdin.byChunk(4).join;
As strace reveals the resulting program sometimes reads twice
zero
characters before it terminates:
read(0, a <-- A,
return
"a\n", 1024)
23 matches
Mail list logo
