On Sunday, 16 January 2022 at 18:03:53 UTC, Paul Backus wrote:
On POSIX, you can use the `sigaction` function to install a
signal handler for `SIGINT`, the signal generated by CTRL+C. To
terminate the program with a stack trace, simply have the
signal handler `throw` an `Error`.
I never
On Sunday, 16 January 2022 at 15:32:41 UTC, Salih Dincer wrote:
If count is not equal to 8 I get weird results! The reason of
course, is the free():
// [93947717336544, 1, 2, 3, 4, 5, 6]
I wonder if you're seeing something you're not suppose to as part
of the internals; Typically malloc for
On Monday, 17 January 2022 at 03:11:50 UTC, Steven Schveighoffer
wrote:
The profile=gc appears to only show GC allocations that the
*compiler* initiates (i.e. via `new`, array operations (like
appending) or closure allocations). It does not detect that the
functions that actually allocate
On 1/16/22 9:42 PM, forkit wrote:
On Monday, 17 January 2022 at 00:54:19 UTC, forkit wrote:
// mArr2 is a dynamic array allocated on the gc heap
// although compiling with '-profile=gc' incorrectly suggests otherwise.
if add @nogc to above code:
(8): Error: array literal in
On Monday, 17 January 2022 at 00:54:19 UTC, forkit wrote:
..
module test;
import std;
@safe void main()
{
// mArr1 is a dynamic array allocated on the gc heap.
int[][] mArr1 = [[1, 2], [3, 4], [5, 6], [7, 8]];
static assert(is(typeof(mArr1.array(;
alias R1 =
On Sun, Jan 16, 2022 at 01:42:21PM -0500, Steven Schveighoffer via
Digitalmars-d-learn wrote:
> On 1/16/22 1:33 PM, Paul Backus wrote:
[...]
> > ```d
> > extern(C) void handleCtrlC(int)
> > {
> > import core.stdc.stdlib: exit;
> > import std.stdio: writeln;
> >
> > try throw new
On 1/16/22 17:51, H. S. Teoh wrote:
>> In practice, malloc'ed memory is cleared e.g. by memset(). Or, there is
>> calloc() which returns memory filled with zeros.
>
> Correction: malloc() is not guaranteed to clear the allocated memory.
Agreed. What I meant is, the programmer ordinarily clears
On Monday, 17 January 2022 at 01:06:05 UTC, Salih Dincer wrote:
```d
// Taaata, magic...
// Your eyes don't surprise you!
typeid(range).writeln(": ", range);
typeid(slices).writeln(": ", slices);
```
In fact, although range and slice seem to be equal to each other,
they are not!
On Sun, Jan 16, 2022 at 08:21:29AM -0800, Ali Çehreli via Digitalmars-d-learn
wrote:
> On 1/16/22 07:32, Salih Dincer wrote:
> > On Sunday, 16 January 2022 at 11:43:40 UTC, Ali Çehreli wrote:
> >>
> >> void main() {
> >> enum count = 7;
> >>
> >> // Allocate some memory
> >> void* rawData =
On 1/16/22 7:54 PM, forkit wrote:
On Sunday, 16 January 2022 at 23:34:41 UTC, Ali Çehreli wrote:
Definitely a -profile=gc bug. Here are the existing ones:
https://issues.dlang.org/buglist.cgi?quicksearch=profile%20gc
Ali
yeah, a bug makes more sense ... otherwise I really would have had
```d
import std; // If we summarize in code...
void main()
{
// It's a dynamic array and its copy below:
size_t[] arr = [1, 2, 3, 4, 5, 6];
auto arrCopy = arr.dup;
// This is its lazy range:
auto range = arr.chunks(2);
typeid(range).writeln(": ", range);
// But this is its copy
On Sunday, 16 January 2022 at 23:34:41 UTC, Ali Çehreli wrote:
Definitely a -profile=gc bug. Here are the existing ones:
https://issues.dlang.org/buglist.cgi?quicksearch=profile%20gc
Ali
yeah, a bug makes more sense ... otherwise I really would have
had a slice to data that doesn't exist
On 1/16/22 15:14, forkit wrote:
> But -profile=gc .. says no. It's not.
>
> int[][] mArr = [[1, 2], [3, 4], [5, 6], [7, 8]]; // GC allocation occurs.
> int[][] mArr = iota(1, 9).chunks(2).map!array.array; // No GC allocation
> occurs.
Definitely a -profile=gc bug. Here are the existing ones:
On Sunday, 16 January 2022 at 23:03:49 UTC, Ali Çehreli wrote:
That's not correct. There are many range algorithms that are
lazy to defer memory allocation but array() is not one of
those. array() does eagerly allocate memory, which is it's
whole purpose:
On 1/16/22 14:43, forkit wrote:
> Well, it's fair to say, that 'range-based programming' is kinda new
to me.
I hope it will be useful to you. :)
> int[][] mArr2 = [[1, 2], [3, 4], [5, 6], [7, 8]]; // GC allocation
>
> But it turns out:
>
> int[][] mArr = iota(1, 9).chunks(2).map!array.array;
On Sunday, 16 January 2022 at 11:43:40 UTC, Ali Çehreli wrote:
So, in all three examples it is the same D feature, a slice,
that references data but the data is managed in different ways.
Ali
Well, it's fair to say, that 'range-based programming' is kinda
new to me.
With this statement:
On Saturday, 15 January 2022 at 02:52:20 UTC, Steven
Schveighoffer wrote:
you probably can fix the issue via:
```d
class C
{
shared:
... // everything
}
```
This seems like a good solution. To achieve implicit sharing on
the aggregate itself, I can use this approach to define a
On Saturday, 15 January 2022 at 23:15:16 UTC, JN wrote:
Is there some way I could improve this with some D features? My
main gripes with it are:
Managed to dramatically simplify it to 10 lines of code with
variadic templates.
```d
import std.stdio;
struct Event(T...)
{
void
On 1/16/22 1:33 PM, Paul Backus wrote:
It worked when I tested it,
Yeah, but your example is designed specifically to only encounter the
signal in one specific spot (inside a D function).
but I'm not sure how reliable it is. A more
conservative implementation would be something like
On 1/16/22 1:42 PM, Steven Schveighoffer wrote:
This too is not going to be a good idea. writeln(e.info) is going to
possibly start allocating. A signal can come at any time, even when
locks are held or things are in an intermediate state.
That being said, if this is being used for
On Sunday, 16 January 2022 at 18:22:04 UTC, Steven Schveighoffer
wrote:
Does this work normally? The memory error handler for Linux
jumps through a lot of hoops to be able to throw an error from
a signal handler. See
https://github.com/dlang/druntime/blob/master/src/etc/linux/memoryerror.d
On Sunday, 16 January 2022 at 18:03:53 UTC, Paul Backus wrote:
extern(C) void handleCtrlC(int)
{
throw new Error("Killed by CTRL+C");
}
This is really iffy since signals can come to random threads at
random times.
The best thing to do is typically to just set a "user requested
On 1/16/22 1:03 PM, Paul Backus wrote:
On Sunday, 16 January 2022 at 15:15:07 UTC, Hipreme wrote:
Is there some way to throw a stack trace when killing the program from
the CTRL+C from the terminal?
It would help a lot into debugging occasional infinity loops
On POSIX, you can use the
On Sunday, 16 January 2022 at 15:15:07 UTC, Hipreme wrote:
Is there some way to throw a stack trace when killing the
program from the CTRL+C from the terminal?
It would help a lot into debugging occasional infinity loops
On POSIX, you can use the `sigaction` function to install a
signal
On 1/16/22 07:15, Hipreme wrote:
> Is there some way to throw a stack trace when killing the program from
> the CTRL+C from the terminal?
I am interested in how to add Ctrl+C support for a D program as well.
> It would help a lot into debugging occasional infinity loops
One way of achieving
On 1/16/22 07:32, Salih Dincer wrote:
> On Sunday, 16 January 2022 at 11:43:40 UTC, Ali Çehreli wrote:
>>
>> void main() {
>> enum count = 7;
>>
>> // Allocate some memory
>> void* rawData = malloc(int.sizeof * count);
In practice, malloc'ed memory is cleared e.g. by memset(). Or, there is
On Sunday, 16 January 2022 at 11:43:40 UTC, Ali Çehreli wrote:
void main() {
enum count = 7;
// Allocate some memory
void* rawData = malloc(int.sizeof * count);
If count is not equal to 8 I get weird results! The reason of
course, is the free():
// [93947717336544, 1, 2, 3, 4, 5, 6]
Is there some way to throw a stack trace when killing the program
from the CTRL+C from the terminal?
It would help a lot into debugging occasional infinity loops
On 1/16/22 01:43, forkit wrote:
> On Sunday, 16 January 2022 at 04:58:21 UTC, Ali Çehreli wrote:
>>
>> I have a problem with calling type[] a dynamic array because it is a
>> slice, which may be providing access to the elements of a dynamic array.
>>
>
> Yes. A more useful way of describing []
On Monday, 27 December 2021 at 10:59:07 UTC, Ali Çehreli wrote:
...my DConf Online 2020 presentation here:
https://dconf.org/2020/online/#ali1
Ali
Hey, that is a really great presentation!
Many more people should watch it, and learn ;-)
On Sunday, 16 January 2022 at 04:58:21 UTC, Ali Çehreli wrote:
I have a problem with calling type[] a dynamic array because it
is a slice, which may be providing access to the elements of a
dynamic array.
Yes. A more useful way of describing [] would be to say:
"[] represents a dynamic
The program does nothing probably because of that continue. (?)
No, it does work inside the loop.
So, the event loop is in a separate thread. What should happen
when the events trigger? Do you want this thread to handle the
events or should this thread send a > message to the main
thread
32 matches
Mail list logo
