bachmeier kirjoitti 14.6.2024 klo 16.48:
See the example I posted elsewhere in this thread:
https://forum.dlang.org/post/mwerxaolbkuxlgfep...@forum.dlang.org
I defined
```
@nogc ~this() {
free(ptr);
printf("Data has been freed\n");
}
```
and that gets called when the reference count hit
On Friday, 14 June 2024 at 07:52:35 UTC, Dukc wrote:
Lance Bachmeier kirjoitti 14.6.2024 klo 4.23:
We must be talking about different things. You could, for
instance, call a function in a C library to allocate memory at
runtime. That function returns a pointer and you pass it to
SafeRefCounted
Lance Bachmeier kirjoitti 14.6.2024 klo 4.23:
We must be talking about different things. You could, for instance, call
a function in a C library to allocate memory at runtime. That function
returns a pointer and you pass it to SafeRefCounted to ensure it gets
freed. Nothing is known about the a
On Thursday, 13 June 2024 at 07:18:48 UTC, Dukc wrote:
Lance Bachmeier kirjoitti 13.6.2024 klo 1.32:
Why would it be different from calling malloc and free
manually? I guess I'm not understanding, because you put the
same calls to malloc and free that you'd otherwise be doing
inside this and
Dukc kirjoitti 13.6.2024 klo 10.18:
So for example, if you have a program that sometimes needs 600Mib and
sometimes needs 1100MiB, you can in any case allocate all that in one go
with one `malloc` or one `new`, but you'll need at least 38/59
`SafeRefCounted` static arrays, and therefore `malloc
Lance Bachmeier kirjoitti 13.6.2024 klo 1.32:
Why would it be different from calling malloc and free manually? I guess
I'm not understanding, because you put the same calls to malloc and free
that you'd otherwise be doing inside this and ~this.
Because with `SafeRefCounted`, you have to deci
On Wednesday, 12 June 2024 at 16:50:04 UTC, Vinod K Chandran
wrote:
On Wednesday, 12 June 2024 at 01:35:26 UTC, monkyyy wrote:
rather then worring about the gc, just have 95% of data on the
stack
How's that even possible ? AFAIK, we need heap allocated memory
in order to make GUI lib as a D
On Wednesday, 12 June 2024 at 21:59:54 UTC, drug007 wrote:
Yes, but you get all the benefits of `double[]` for free if
you do it that way, including the more concise foo[10] syntax.
I meant you do not need to add `ptr` field at all
I see. You're right. I thought it would be easier for someon
On Wednesday, 12 June 2024 at 21:36:30 UTC, Dukc wrote:
bachmeier kirjoitti 12.6.2024 klo 18.21:
You're splitting things into GC-allocated memory and manually
managed memory. There's also SafeRefCounted, which handles the
malloc and free for you.
I suspect `SafeRefCounted` (or `RefCounted`) i
On 12.06.2024 23:56, bachmeier wrote:
On Wednesday, 12 June 2024 at 20:37:36 UTC, drug007 wrote:
On 12.06.2024 21:57, bachmeier wrote:
On Wednesday, 12 June 2024 at 18:36:26 UTC, Vinod K Chandran wrote:
On Wednesday, 12 June 2024 at 15:33:39 UTC, bachmeier wrote:
A SafeRefCounted example with
bachmeier kirjoitti 12.6.2024 klo 18.21:
You're splitting things into GC-allocated memory and manually managed
memory. There's also SafeRefCounted, which handles the malloc and free
for you.
I suspect `SafeRefCounted` (or `RefCounted`) is not the best fit for
this scenario. The problem with i
On Wednesday, 12 June 2024 at 20:37:36 UTC, drug007 wrote:
On 12.06.2024 21:57, bachmeier wrote:
On Wednesday, 12 June 2024 at 18:36:26 UTC, Vinod K Chandran
wrote:
On Wednesday, 12 June 2024 at 15:33:39 UTC, bachmeier wrote:
A SafeRefCounted example with main marked @nogc:
```
import std;
im
On Wednesday, 12 June 2024 at 20:31:34 UTC, Vinod K Chandran
wrote:
On Wednesday, 12 June 2024 at 18:57:41 UTC, bachmeier wrote:
Try `foo[10] = 1.5` and `foo.ptr[10] = 1.5`. The first
correctly throws an out of bounds error. The second gives
`Segmentation fault (core dumped)`.
We can use it
On 12.06.2024 21:57, bachmeier wrote:
On Wednesday, 12 June 2024 at 18:36:26 UTC, Vinod K Chandran wrote:
On Wednesday, 12 June 2024 at 15:33:39 UTC, bachmeier wrote:
A SafeRefCounted example with main marked @nogc:
```
import std;
import core.stdc.stdlib;
struct Foo {
double[] data;
doub
On Wednesday, 12 June 2024 at 18:57:41 UTC, bachmeier wrote:
Try `foo[10] = 1.5` and `foo.ptr[10] = 1.5`. The first
correctly throws an out of bounds error. The second gives
`Segmentation fault (core dumped)`.
We can use it like this, i think.
```
struct Foo {
double * ptr;
uint capacity
On Wednesday, 12 June 2024 at 18:58:49 UTC, evilrat wrote:
the only problem is that it seems to leak a lot PydObjects so i
have to manually free them, even scope doesn't helps with that
which is sad.
Oh I see. I did some experiments with nimpy and pybind11. Both
experiments were resulted in
On Wednesday, 12 June 2024 at 18:58:49 UTC, evilrat wrote:
On Wednesday, 12 June 2024 at 17:00:14 UTC, Vinod K Chandran
wrote:
[...]
It is probably not that well maintained, but it definitely
works with python 3.10 and maybe even 3.11, i use it to
interface with pytorch and numpy and PIL, bu
On Wednesday, 12 June 2024 at 17:00:14 UTC, Vinod K Chandran
wrote:
On Wednesday, 12 June 2024 at 10:16:26 UTC, Sergey wrote:
Btw are you going to use PyD or doing everything manually from
scratch?
Does PyD active now ? I didn't tested it. My approach is using
"ctypes" library with my dll.
On Wednesday, 12 June 2024 at 18:36:26 UTC, Vinod K Chandran
wrote:
On Wednesday, 12 June 2024 at 15:33:39 UTC, bachmeier wrote:
A SafeRefCounted example with main marked @nogc:
```
import std;
import core.stdc.stdlib;
struct Foo {
double[] data;
double * ptr;
alias data this;
@nogc t
On Wednesday, 12 June 2024 at 15:33:39 UTC, bachmeier wrote:
A SafeRefCounted example with main marked @nogc:
```
import std;
import core.stdc.stdlib;
struct Foo {
double[] data;
double * ptr;
alias data this;
@nogc this(int n) {
ptr = cast(double*) malloc(n*double.sizeof);
dat
On Wednesday, 12 June 2024 at 15:33:39 UTC, bachmeier wrote:
A SafeRefCounted example with main marked @nogc:
Thanks for the sample. It looks tempting! Let me check that.
On Wednesday, 12 June 2024 at 15:21:22 UTC, bachmeier wrote:
You're splitting things into GC-allocated memory and manually
managed memory. There's also SafeRefCounted, which handles the
malloc and free for you.
Thanks, I have read about the possibilities of "using malloc and
free from D" in
On Wednesday, 12 June 2024 at 10:16:26 UTC, Sergey wrote:
Btw are you going to use PyD or doing everything manually from
scratch?
Does PyD active now ? I didn't tested it. My approach is using
"ctypes" library with my dll. Ctypes is the fastes FFI in my
experience. I tested Cython, Pybind11
On Wednesday, 12 June 2024 at 09:44:05 UTC, DrDread wrote:
also just slap @nogc on your main function to avoid accidential
allocations.
Thanks for the suggestion. Let me check that idea.
On Wednesday, 12 June 2024 at 01:35:26 UTC, monkyyy wrote:
rather then worring about the gc, just have 95% of data on the
stack
How's that even possible ? AFAIK, we need heap allocated memory
in order to make GUI lib as a DLL. So creating things in heap and
modify it, that's the nature of m
A SafeRefCounted example with main marked @nogc:
```
import std;
import core.stdc.stdlib;
struct Foo {
double[] data;
double * ptr;
alias data this;
@nogc this(int n) {
ptr = cast(double*) malloc(n*double.sizeof);
data = ptr[0..n];
printf("Data has been allocated\n");
}
On Tuesday, 11 June 2024 at 17:15:07 UTC, Vinod K Chandran wrote:
On Tuesday, 11 June 2024 at 16:54:44 UTC, Steven Schveighoffer
wrote:
Two reasons.
1. I am writting a dll to use in Python. So I am assuming that
Btw are you going to use PyD or doing everything manually from
scratch?
On Tuesday, 11 June 2024 at 17:15:07 UTC, Vinod K Chandran wrote:
On Tuesday, 11 June 2024 at 16:54:44 UTC, Steven Schveighoffer
wrote:
I would instead ask the reason for wanting to write D code
without the GC.
-Steve
Hi Steve,
Two reasons.
1. I am writting a dll to use in Python. So I am
On Tuesday, 11 June 2024 at 17:15:07 UTC, Vinod K Chandran wrote:
On Tuesday, 11 June 2024 at 16:54:44 UTC, Steven Schveighoffer
wrote:
I would instead ask the reason for wanting to write D code
without the GC.
-Steve
Hi Steve,
Two reasons.
1. I am writting a dll to use in Python. So I am
On Tuesday, 11 June 2024 at 16:54:44 UTC, Steven Schveighoffer
wrote:
I would instead ask the reason for wanting to write D code
without the GC.
-Steve
Hi Steve,
Two reasons.
1. I am writting a dll to use in Python. So I am assuming that
manual memory management is better for this project
On Tuesday, 11 June 2024 at 13:00:50 UTC, Vinod K Chandran wrote:
Hi all,
I am planning to write some D code without GC. But I have no
prior experience with it. I have experience using manual memory
management languages. But D has so far been used with GC. So I
want to know what pitfalls it ha
On 11.06.2024 17:59, Kagamin wrote:
1) arena allocator makes memory manageable with occasional cache
invalidation problem
2) no hashtable no problem
[OT] could you elaborate what problems they cause?
3) error handling depends on your code complexity, but even in complex
C# code I found excep
On Tuesday, 11 June 2024 at 14:59:24 UTC, Kagamin wrote:
1) arena allocator makes memory manageable with occasional
cache invalidation problem
2) no hashtable no problem
3) error handling depends on your code complexity, but even in
complex C# code I found exceptions as boolean: you either have
1) arena allocator makes memory manageable with occasional cache
invalidation problem
2) no hashtable no problem
3) error handling depends on your code complexity, but even in
complex C# code I found exceptions as boolean: you either have an
exception or you don't
4) I occasionally use CTFE, w
On Tuesday, 11 June 2024 at 13:35:19 UTC, matheus wrote:
On Tuesday, 11 June 2024 at 13:00:50 UTC, Vinod K Chandran
wrote:
...
Similar posts that may help:
https://forum.dlang.org/thread/hryadrwplyezihwag...@forum.dlang.org
https://forum.dlang.org/thread/dblfikgnzqfmmglwd...@forum.dlang.org
On Tuesday, 11 June 2024 at 13:00:50 UTC, Vinod K Chandran wrote:
...
Similar posts that may help:
https://forum.dlang.org/thread/hryadrwplyezihwag...@forum.dlang.org
https://forum.dlang.org/thread/dblfikgnzqfmmglwd...@forum.dlang.org
Matheus.
36 matches
Mail list logo
