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
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 `
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 pr
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
ary with my dll. Ctypes is the fastes FFI in my
experience. I tested Cython, Pybind11 and CFFI. But None can
beat the speed of ctypes. Currently the fastest experiments
were the dlls created in Odin & C3. Both are non-GC languages.
It is probably not that well maintained, but it definitely
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 a
I tested Cython, Pybind11 and CFFI. But None can beat
the speed of ctypes. Currently the fastest experiments were the
dlls created in Odin & C3. Both are non-GC languages.
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
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
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
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
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
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.
On Monday, 26 February 2024 at 12:33:02 UTC, Richard (Rikki)
Andrew Cattermole wrote:
On 27/02/2024 1:28 AM, Dakota wrote:
When I use importC to build a c library, there is a lot unused
symbol missing.
I try add `-L--gc-sections` to dmd to workaround this issue.
This removes symbols, not
On 27/02/2024 1:28 AM, Dakota wrote:
When I use importC to build a c library, there is a lot unused symbol
missing.
I try add `-L--gc-sections` to dmd to workaround this issue.
This removes symbols, not keeps them.
You want the linker flag: ``--no-gc-sections``
"Enable garbage colle
When I use importC to build a c library, there is a lot unused
symbol missing.
I try add `-L--gc-sections` to dmd to workaround this issue.
I also try `-L-dead_strip` on macOS, it work as expected.
I do some google, some one suggestion use with
`-ffunction-sections`, `-f fdata-sections
gc?
just dont allocate new memory or invoke,
you can use scopes to temporry do stuff on immutable slices
that will auto clean up
the list goes on
and you dont need to use pointers at all...!!
i honesty see nothing wrong with gc,
I don't think there is any wrong having GC in language e
On Friday, 22 December 2023 at 22:33:35 UTC, H. S. Teoh wrote:
IMNSHO, if I had very large data files to load, I wouldn't use
JSON. Precompile the data into a more compact binary form
that's already ready to use, and just mmap() it at runtime.
I wondered about that decision as well, especially
"line after line" of manual memory management, I
> assume you're dealing with micro-allocations on the heap - which are
> performance poison in any language.
Depends on what you're dealing with. Some micro-allocations are totally
avoidable, but if you're manipulati
On Friday, 22 December 2023 at 16:51:11 UTC, bachmeier wrote:
Given how fast computers are today, the folks that focus on
memory and optimizing for performance might want to apply for
jobs as flooring inspectors, because they're often solving
problems from the 1990s.
*Generally* speaking, I d
On Fri, Dec 22, 2023 at 07:22:15PM +, Dmitry Ponyatov via
Digitalmars-d-learn wrote:
> > It's called GC phobia, a knee-jerk reaction malady common among
> > C/C++ programmers
>
> I'd like to use D in hard realtime apps (gaming can be thought as one
> of t
It's called GC phobia, a knee-jerk reaction malady common among
C/C++ programmers
I'd like to use D in hard realtime apps (gaming can be thought as
one of them, but I mostly mean realtime dynamic multimedia and
digital signal processing).
So, GC in such applications commonl
On Friday, 22 December 2023 at 12:53:44 UTC, bomat wrote:
If you use (or even feel tempted to use) a GC, it means that
you don't care about your memory. Neither about its layout nor
its size, nor when chunks of it are allocated or deallocated,
etc.
And if you don't care about th
On Friday, 22 December 2023 at 12:53:44 UTC, bomat wrote:
I think the problem most "old school" programmers have with
automatic garbage collection, or *any* kind of "managed" code,
really, is not the GC itself, but that it demonstrates a wrong
mindset.
If you use (or even
On Monday, 18 December 2023 at 16:44:11 UTC, Bkoie wrote:
but what is with these ppl and the gc?
[...]
I'm a C++ programmer in my day job. Personally, I have no problem
with a GC, but one of my colleague is a total C fanboy, so I feel
qualified to answer your question. :)
I thin
On Monday, 18 December 2023 at 17:22:22 UTC, H. S. Teoh wrote:
On Mon, Dec 18, 2023 at 04:44:11PM +, Bkoie via
Digitalmars-d-learn wrote: [...]
but what is with these ppl and the gc?
[...]
It's called GC phobia, a knee-jerk reaction malady common among
C/C++ programmers (I'm o
On Mon, Dec 18, 2023 at 04:44:11PM +, Bkoie via Digitalmars-d-learn wrote:
[...]
> but what is with these ppl and the gc?
[...]
It's called GC phobia, a knee-jerk reaction malady common among C/C++
programmers (I'm one of them, though I got cured of GC phobia thanks to
D :-P)
just look at this i know this is overdesign im just trying to get
a visual on how a api can be design im still new though but the
fact you can build an api like this and it not break it is
amazing.
but what is with these ppl and the gc?
just dont allocate new memory or invoke,
you can use
(i; 0 .. 2048)
x[i] = new Foo;
}
```
When the GC stops all threads, each of them registers their *current*
stack as the target to scan, so most likely not.
However, the compiler/optimizer is not trying to zero out stack
unnecessarily, and likely this leads in some cases to false pointers.
L
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 c
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 fun
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 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 {
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;
}
Ba
, the implementation is
allocating a closure on the GC even though the spec says it
shouldn't?
The opposite, the delegate doesn't force a closure, and so when
the variable goes out of scope, memory corruption ensues.
I've been writing some betterC and the lazy parameter was
p
On 2/20/23 1:50 PM, Etienne wrote:
On Monday, 20 February 2023 at 02:50:20 UTC, Steven Schveighoffer wrote:
See Adam's bug report: https://issues.dlang.org/show_bug.cgi?id=23627
So, according to this bug report, the implementation is allocating a
closure on the GC even though the spec
On Monday, 20 February 2023 at 02:50:20 UTC, Steven Schveighoffer
wrote:
See Adam's bug report:
https://issues.dlang.org/show_bug.cgi?id=23627
-Steve
So, according to this bug report, the implementation is
allocating a closure on the GC even though the spec says it
shouldn't?
On 2/19/23 9:15 PM, Steven Schveighoffer wrote:
Indeed, you can't really "save" the hidden delegate somewhere, so the
calling function knows that the delgate can't escape.
I stand corrected, you can save it (by taking the address of it).
And it's explicitly allowed by the spec.
But it sti
On 2/19/23 7:50 PM, Etienne wrote:
Hello,
I'm wondering at which moment the following would make an allocation of
the scope variables on the GC. Should I assume that the second parameter
of enforce being lazy, we would get a delegate/literal that saves the
current scope on the GC ev
Hello,
I'm wondering at which moment the following would make an
allocation of the scope variables on the GC. Should I assume that
the second parameter of enforce being lazy, we would get a
delegate/literal that saves the current scope on the GC even if
it's not needed? I'm as
On Thu, Jan 05, 2023 at 08:18:42PM +, DLearner via Digitalmars-d-learn
wrote:
> On Thursday, 5 January 2023 at 19:54:01 UTC, H. S. Teoh wrote:
[...]
> > core.stdc.stdlib.{malloc,free} *is* the exact same malloc/free that
> > C uses, it has nothing to do with the GC. The allo
s, it has nothing to do with the GC. The allocated
memory is taken from the malloc/free part of the heap, which is
disjoint from the heap memory managed by the GC.
So, it should not cause any crashes.
T
That's comforting, but there is a reference in:
https://dlang.org/blog/2017/09/25/g
e D functions that themselves call malloc/free via
> `import core.stdc.stdlib;`
>
> Assuming the malloc/free's are used correctly, does this situation
> risk crashing the D main program?
[...]
core.stdc.stdlib.{malloc,free} *is* the exact same malloc/free that C
uses, it has nothing to do
Suppose there is a D main program (not marked anywhere with
@nogc), that _both_
A: Calls one or more C functions that themselves call
malloc/free; and also
B: Calls one or more D functions that themselves call malloc/free
via `import core.stdc.stdlib;`
Assuming the malloc/free's are used cor
On Monday, 5 December 2022 at 14:48:33 UTC, cc wrote:
On Sunday, 4 December 2022 at 09:53:41 UTC, vushu wrote:
[...]
If your program runs, does some stuff, and terminates, use the
GC.
If your program runs, stays up for a while with user
occasionally interacting with it, use the GC.
If your
memory strategy should be, and then it is based on performance
concerns
D scale from microcontrollers to servers, drivers, games,
desktop apps
Your audience will determine what you should provide
For a desktop app, a GC is an advantage
For a driver or a game, it's not
I agree with
On Monday, 5 December 2022 at 10:53:33 UTC, Guillaume Piolat
wrote:
On Sunday, 4 December 2022 at 21:55:52 UTC, Siarhei Siamashka
wrote:
Is it possible to filter packages in this list by @nogc or
@safe compatibility?
You can list DUB packages for "@nogc usage"
https://code.dlang.org/?sort=scor
On Monday, 5 December 2022 at 10:48:59 UTC, Guillaume Piolat
wrote:
There are legitimate uses cases when you can't afford the
runtime machinery (attach/detach every incoming thread in a
shared library), more than not being able to afford the GC from
a performance point of
On Sunday, 4 December 2022 at 23:25:34 UTC, Adam D Ruppe wrote:
On Sunday, 4 December 2022 at 22:46:52 UTC, Ali Çehreli wrote:
That's way beyond my pay grade. Explain please. :)
The reason that the GC stops threads right now is to ensure
that something doesn't change in the mid
On Sunday, 4 December 2022 at 09:53:41 UTC, vushu wrote:
What are your thoughts about using GC as a library writer?
If your program runs, does some stuff, and terminates, use the GC.
If your program runs, stays up for a while with user occasionally
interacting with it, use the GC.
If your
On Sunday, 4 December 2022 at 21:55:52 UTC, Siarhei Siamashka
wrote:
Is it possible to filter packages in this list by @nogc or
@safe compatibility?
You can list DUB packages for "@nogc usage"
https://code.dlang.org/?sort=score&limit=20&category=library.nogc
There are legitimate uses cases when you can't afford the runtime
machinery (attach/detach every incoming thread in a shared
library), more than not being able to afford the GC from a
performance point of view.
GC gives you higher productivity and better performance with the
time g
On Sunday, 4 December 2022 at 23:37:39 UTC, Ali Çehreli wrote:
On 12/4/22 15:25, Adam D Ruppe wrote:
> which would trigger the write barrier. The thread isn't
> allowed to complete this operation until the GC is done.
According to my limited understanding of write barriers, the
th
On 12/4/22 15:25, Adam D Ruppe wrote:
> which would trigger the write barrier. The thread isn't
> allowed to complete this operation until the GC is done.
According to my limited understanding of write barriers, the thread
moving to 800 could continue because order of memory ope
On Sunday, 4 December 2022 at 22:46:52 UTC, Ali Çehreli wrote:
That's way beyond my pay grade. Explain please. :)
The reason that the GC stops threads right now is to ensure that
something doesn't change in the middle of its analysis.
Consider for example, the GC scans address 0
ALl it means is certain memory patterns (such as writes), will tell the
GC about it.
Its required for pretty much all advanced GC designs, as a result we are
pretty much maxing out what we can do.
Worth reading:
https://www.amazon.com/Garbage-Collection-Handbook-Management-Algorithms/dp
On 12/4/22 12:17, Adam D Ruppe wrote:
On Sunday, 4 December 2022 at 17:53:00 UTC, Adam D Ruppe wrote:
Interesting... you know, maybe D's GC should formally expose a mutex
that you can synchronize on for when it is running.
.. or compile in write barriers. then it doesn't mat
they embrace GC?
I looked at the projects. Except for that arsd-official thing,
that's a big mystery to me, the code is completely unreadable.
But vibe and dub use it pretty broadly. Unit-threaded and silly
are test runners, which isn't even really a library (I find it
weird
On Sunday, 4 December 2022 at 12:37:08 UTC, Adam D Ruppe wrote:
All of the top 5 most popular libraries on code.dlang.org
embrace the GC.
Do you mean the top of the
https://code.dlang.org/?sort=score&category=library list?
How do you know that they embrace GC? Is it possible to fi
On Sunday, 4 December 2022 at 17:53:00 UTC, Adam D Ruppe wrote:
Interesting... you know, maybe D's GC should formally expose a
mutex that you can synchronize on for when it is running.
.. or compile in write barriers. then it doesn't matter
if the thread is unregistered,
On Sunday, 4 December 2022 at 16:02:28 UTC, Ali Çehreli wrote:
D's GC needed to stop the world, which meant it would have to
know what threads were running. You can never be sure whether
your D library function is being called from a thread you've
known or whether the Java runtime
On Sunday, 4 December 2022 at 09:53:41 UTC, vushu wrote:
Dear dlang community.
I am unsure about what idiomatic D is.
Some of the Dconf talks tells people just to use the GC, until
you can't afford
it.
If there are documents that describes what idiomatic D is then
I would apprecia
On Sunday, 4 December 2022 at 15:57:26 UTC, Ali Çehreli wrote:
On 12/4/22 05:58, vushu wrote:
> I was worried if my library should be GC free
May I humbly recommend you question where that thinking comes
from?
Ali
P.S. I used to be certain that the idea of GC was wrong and the
creators
On 12/4/22 06:27, Sergey wrote:
> if it will be possible to write
> library in D and use it from
> C/++/Python/R/JVM(JNI)/Erlang(NIF)/nameYourChoice smoothly it will be a
> win.
Years ago we tried to call D from Java. I realized that it was very
tricky to introduce the calling thre
On 12/4/22 05:58, vushu wrote:
> I was worried if my library should be GC free
May I humbly recommend you question where that thinking comes from?
Ali
P.S. I used to be certain that the idea of GC was wrong and the creators
of runtimes with GC were simpletons. In contrast, people like
On Sunday, 4 December 2022 at 12:37:08 UTC, Adam D Ruppe wrote:
All of the top 5 most popular libraries on code.dlang.org
embrace the GC.
Interesting. It seems that most of the community suppose that
“library” should be used from D :-)
But in my opinion - “foreign library experience” is much
On Sunday, 4 December 2022 at 13:03:07 UTC, Hipreme wrote:
On Sunday, 4 December 2022 at 09:53:41 UTC, vushu wrote:
Dear dlang community.
I am unsure about what idiomatic D is.
Some of the Dconf talks tells people just to use the GC, until
you can't afford
it.
If there are documents
On Sunday, 4 December 2022 at 12:37:08 UTC, Adam D Ruppe wrote:
On Sunday, 4 December 2022 at 09:53:41 UTC, vushu wrote:
What are your thoughts about using GC as a library writer?
Do it. It is lots of gain for very little loss.
If you wan't to include a library into your project aren&
On Sunday, 4 December 2022 at 09:53:41 UTC, vushu wrote:
Dear dlang community.
I am unsure about what idiomatic D is.
Idiomatic D code produces the correct result, it's readable, and
it's easy for others to use.
Some of the Dconf talks tells people just to use the GC, until
On Sunday, 4 December 2022 at 09:53:41 UTC, vushu wrote:
Dear dlang community.
I am unsure about what idiomatic D is.
Some of the Dconf talks tells people just to use the GC, until
you can't afford
it.
If there are documents that describes what idiomatic D is then
I would apprecia
On Sunday, 4 December 2022 at 09:53:41 UTC, vushu wrote:
What are your thoughts about using GC as a library writer?
Do it. It is lots of gain for very little loss.
If you wan't to include a library into your project aren't you
more inclined to use a library which is gc free?
N
Dear dlang community.
I am unsure about what idiomatic D is.
Some of the Dconf talks tells people just to use the GC, until
you can't afford
it.
If there are documents that describes what idiomatic D is then I
would appreciate it.
So my questions are:
What are your thoughts
On Sunday, 13 November 2022 at 19:02:29 UTC, mw wrote:
BTW, can --build=profile-gc can intercept "Ctrl+C" and
generate *partial* report file?
And what's the suggested proper way to do
Is there a profile-gc plugin function I can call in the middle of
my program to generate *
On Sunday, 13 November 2022 at 18:51:17 UTC, mw wrote:
On Sunday, 13 November 2022 at 18:48:42 UTC, mw wrote:
BTW, can --build=profile-gc can intercept "Ctrl+C" and
generate *partial* report file?
And what's the suggested proper way to do early exit, and
still let --build=prof
On Sunday, 13 November 2022 at 18:48:42 UTC, mw wrote:
BTW, can --build=profile-gc can intercept "Ctrl+C" and generate
*partial* report file?
And what's the suggested proper way to do early exit, and still
let --build=profile-gc generate reports?
I tried presss "Ctrl
dering does dmd --build=profile-gc work with
core.stdc.stdlib.exit()?
And where is the output report file, and the filename? I didn't
see any report file generated in the current working dir.
BTW, can --build=profile-gc can intercept "Ctrl+C" and generate
*partial* report fi
1 - 100 of 1001 matches
Mail list logo
