On Sunday, 18 June 2023 at 20:24:10 UTC, Cecil Ward wrote:
I wasn’t intending to use DMD, rather ldc if possible or GDC
because of their excellent optimisation, in which DMD seems
lacking, is that fair? (Have only briefly looked at dmd+x86 and
haven’t given DMD’s back end a fair trial.)
Oth
On Sunday, 18 June 2023 at 20:17:50 UTC, Cecil Ward wrote:
target.obj: target.c include1.h include2.h cc.exe
cc target.c
and you either have to pray that you have kept the list of .h
files that are mentioned inside target.c and other .h files
referenced recursively from within these .h fi
On Monday, 19 June 2023 at 08:46:31 UTC, rempas wrote:
On Sunday, 18 June 2023 at 20:17:50 UTC, Cecil Ward wrote:
target.obj: target.c include1.h include2.h cc.exe
cc target.c
and you either have to pray that you have kept the list of .h
files that are mentioned inside target.c and other
On Sunday, 18 June 2023 at 05:01:16 UTC, Cecil Ward wrote:
On Sunday, 18 June 2023 at 04:54:08 UTC, Cecil Ward wrote:
Is it true that this doesn’t always work (in either branch)?
float4 a,b;
static if (__traits(compiles, a/b))
c = a / b;
else
c[] = a[] / b[];
It's because SIMD stuff
I'm doing some experiments with ldc2 GC, by instrumenting it and
printing basic information (what is allocated and freed)
My first tests are made on this sample :
```
cat test2.d
import core.memory;
class Bar { int bar; }
class Foo {
this()
{
this.bar = new Bar;
}
Bar bar;
}
On Monday, 19 June 2023 at 12:48:26 UTC, Cecil Ward wrote:
If I have sources to all the library routines, not libraries or
.obj files. I am simply completely ignorant about the D tools
including DUB, so off to do some reading. I’ve just been seeing
how good LDC and GDC are, and the answer is
On 6/19/23 12:13 PM, axricard wrote:
I'm doing some experiments with ldc2 GC, by instrumenting it and
printing basic information (what is allocated and freed)
My first tests are made on this sample :
```
cat test2.d
import core.memory;
class Bar { int bar; }
class Foo {
this()
{
On Monday, 19 June 2023 at 16:43:30 UTC, Steven Schveighoffer
wrote:
In this specific case, most likely it's a stale register or
stack reference. One way I usually use to ensure such things is
to call a function that destroys the existing stack:
```d
void clobber()
{
int[2048] x;
}
```
C
On Monday, 19 June 2023 at 16:43:30 UTC, Steven Schveighoffer
wrote:
In general, the language does not guarantee when the GC will
collect your item.
In this specific case, most likely it's a stale register or
stack reference. One way I usually use to ensure such things is
to call a function t
On 6/19/23 12:51 PM, Anonymouse wrote:
On Monday, 19 June 2023 at 16:43:30 UTC, Steven Schveighoffer wrote:
In this specific case, most likely it's a stale register or stack
reference. One way I usually use to ensure such things is to call a
function that destroys the existing stack:
```d
v
On Monday, 19 June 2023 at 16:43:30 UTC, Steven Schveighoffer
wrote:
In general, the language does not guarantee when the GC will
collect your item.
In this specific case, most likely it's a stale register or
stack reference. One way I usually use to ensure such things is
to call a function
Hi, I just saw this line:
https://github.com/dlang/dmd/blob/master/druntime/src/core/stdcpp/vector.d#LL66C5-L66C39
```
66:ref inout(T) opIndex(size_t index) inout pure nothrow
@safe @nogc { return as_array[index]; }
```
I'm wondering if the `ref` and `inout` redundant here? They both
On 6/19/23 2:01 PM, axricard wrote:
Does it mean that if my function _func()_ is as following (say I don't
use clobber), I could keep a lot of memory for a very long time (until
the stack is fully erased by other function calls) ?
```
void func()
{
Foo[2048] x;
foreach(i; 0 .. 2048
On 6/19/23 2:19 PM, mw wrote:
Hi, I just saw this line:
https://github.com/dlang/dmd/blob/master/druntime/src/core/stdcpp/vector.d#LL66C5-L66C39
```
66: ref inout(T) opIndex(size_t index) inout pure nothrow @safe
@nogc { return as_array[index]; }
```
I'm wondering if the `ref` and `i
14 matches
Mail list logo
