From spam at here.lot  Sun Jun  1 13:09:30 2025
From: spam at here.lot (Kagamin)
Date: Sun, 01 Jun 2025 13:09:30 +0000
Subject: flagging unsigned subtraction assigned to bigger signed number?
In-Reply-To: <ghqjnudwyztzrdpxqvsa@forum.dlang.org>
References: <opyorabfgveronufsnjn@forum.dlang.org>
 <100jlne$2d6$1@digitalmars.com> <fbaufbskkrskdnrkoaaw@forum.dlang.org>
 <100l5f0$14e0$1@digitalmars.com> <ghqjnudwyztzrdpxqvsa@forum.dlang.org>
Message-ID: <zpjwnloltpngrhscqsut@forum.dlang.org>

> On Wednesday, 21 May 2025 at 18:19:19 UTC, Walter Bright wrote:
>> An unsigned type is of less utility in a language like Java 
>> that is not a systems programming language (trying to make a 
>> memory allocator with no unsigned types is going to wind up 
>> pretty ugly).

Just found: https://man7.org/linux/man-pages/man3/malloc.3.html
> Attempting to allocate more than PTRDIFF_MAX bytes is 
> considered an error, as an object that large could cause later 
> pointer subtraction to overflow.
> malloc() and related functions rejected sizes greater than 
> PTRDIFF_MAX starting in glibc 2.30.

From newshound2 at digitalmars.com  Sun Jun  1 16:16:42 2025
From: newshound2 at digitalmars.com (Walter Bright)
Date: Sun, 1 Jun 2025 09:16:42 -0700
Subject: flagging unsigned subtraction assigned to bigger signed number?
In-Reply-To: <zpjwnloltpngrhscqsut@forum.dlang.org>
References: <opyorabfgveronufsnjn@forum.dlang.org>
 <100jlne$2d6$1@digitalmars.com> <fbaufbskkrskdnrkoaaw@forum.dlang.org>
 <100l5f0$14e0$1@digitalmars.com> <ghqjnudwyztzrdpxqvsa@forum.dlang.org>
 <zpjwnloltpngrhscqsut@forum.dlang.org>
Message-ID: <101huda$94n$1@digitalmars.com>

I bet that implementation of malloc is using unsigned types.

From mayaava055 at gmail.com  Mon Jun  2 09:06:51 2025
From: mayaava055 at gmail.com (myaava)
Date: Mon, 02 Jun 2025 09:06:51 +0000
Subject: RFC: 2 enhancement DIPs that need feedback
In-Reply-To: <1008u1p$30vc$1@digitalmars.com>
References: <mdvsglsonceqtotnwjel@forum.dlang.org>
 <ccgewlwssffuanhlyexb@forum.dlang.org> <jhfrxdtwobvujunaigda@forum.dlang.org>
 <uqvualtprtvxftnqyrop@forum.dlang.org> <1002hvn$2ld5$1@digitalmars.com>
 <rjqlalppdwisadygsrhk@forum.dlang.org> <1007pbi$h35$1@digitalmars.com>
 <1007pup$i87$1@digitalmars.com> <mukdniqlxdkazohwauwp@forum.dlang.org>
 <1008u1p$30vc$1@digitalmars.com>
Message-ID: <kndpklzubauuqjszxhbx@forum.dlang.org>

"Glad to see these enhancement DIPs being opened up for community 
input ? it?s a crucial step in making sure updates are 
well-rounded and serve real needs. Looking forward to diving into 
both proposals and seeing how they address current limitations or 
introduce new efficiencies. Just like in game economies where <a 
href="https://fifamobilefc.com/">unlimited money gems and 
coins</a>
  can disrupt balance if not thought through, it?s important these 
enhancements are carefully evaluated. Constructive feedback now 
can really shape the future functionality and adoption. Are there 
any particular areas in the DIPs where deeper review is 
especially needed?"



From kornburn at yandex.ru  Mon Jun  2 19:22:47 2025
From: kornburn at yandex.ru (Sergey)
Date: Mon, 02 Jun 2025 19:22:47 +0000
Subject: [OT] Senders and Receivers
Message-ID: <uhfxnhiebqmnsbosegls@forum.dlang.org>

Wanted to share with everyone series of podcasts about the topic.
The topic is quite complicated, so maybe this helps you to better 
understand what is it all about.
They discussing it mostly from C++ perspective, with some Haskell 
ideas.

D package with this approach: 
https://code.dlang.org/packages/concurrency

Podcast series:
https://adspthepodcast.com/2025/04/25/Episode-231.html
https://adspthepodcast.com/2025/05/23/Episode-235.html
https://adspthepodcast.com/2025/05/30/Episode-236.html


From dfawcus+dlang at employees.org  Mon Jun  2 19:32:03 2025
From: dfawcus+dlang at employees.org (Derek Fawcus)
Date: Mon, 02 Jun 2025 19:32:03 +0000
Subject: [OT] Senders and Receivers
In-Reply-To: <uhfxnhiebqmnsbosegls@forum.dlang.org>
References: <uhfxnhiebqmnsbosegls@forum.dlang.org>
Message-ID: <fylzhpgfkfzduheelory@forum.dlang.org>

On Monday, 2 June 2025 at 19:22:47 UTC, Sergey wrote:
> Wanted to share with everyone series of podcasts about the 
> topic.
> The topic is quite complicated, so maybe this helps you to 
> better understand what is it all about.
> They discussing it mostly from C++ perspective, with some 
> Haskell ideas.
>
> D package with this approach: 
> https://code.dlang.org/packages/concurrency
>
> Podcast series:
> https://adspthepodcast.com/2025/04/25/Episode-231.html
> https://adspthepodcast.com/2025/05/23/Episode-235.html
> https://adspthepodcast.com/2025/05/30/Episode-236.html

Why should "Structured Concurrency" be viewed as a better 
approach than CSP (or Actors for that matter)?

DF


From snarwin at gmail.com  Tue Jun  3 06:06:24 2025
From: snarwin at gmail.com (Paul Backus)
Date: Tue, 03 Jun 2025 06:06:24 +0000
Subject: [OT] Senders and Receivers
In-Reply-To: <fylzhpgfkfzduheelory@forum.dlang.org>
References: <uhfxnhiebqmnsbosegls@forum.dlang.org>
 <fylzhpgfkfzduheelory@forum.dlang.org>
Message-ID: <rhzdlysgdejmgbwjqgdm@forum.dlang.org>

On Monday, 2 June 2025 at 19:32:03 UTC, Derek Fawcus wrote:
>
> Why should "Structured Concurrency" be viewed as a better 
> approach than CSP (or Actors for that matter)?

Here's the most popular explanation:

https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/

The main thesis (quoted from the article's conclusion) is this:

> These [unstructured concurrency] primitives are dangerous even 
> if we don't use them directly, because they undermine our 
> ability to reason about control flow and compose complex 
> systems out of abstract modular parts, and they interfere with 
> useful language features like automatic resource cleanup and 
> error propagation.

From dfawcus+dlang at employees.org  Tue Jun  3 14:10:07 2025
From: dfawcus+dlang at employees.org (Derek Fawcus)
Date: Tue, 03 Jun 2025 14:10:07 +0000
Subject: [OT] Senders and Receivers
In-Reply-To: <rhzdlysgdejmgbwjqgdm@forum.dlang.org>
References: <uhfxnhiebqmnsbosegls@forum.dlang.org>
 <fylzhpgfkfzduheelory@forum.dlang.org> <rhzdlysgdejmgbwjqgdm@forum.dlang.org>
Message-ID: <kvyvefttkmcmayrcfimo@forum.dlang.org>

On Tuesday, 3 June 2025 at 06:06:24 UTC, Paul Backus wrote:
> On Monday, 2 June 2025 at 19:32:03 UTC, Derek Fawcus wrote:
>>
>> Why should "Structured Concurrency" be viewed as a better 
>> approach than CSP (or Actors for that matter)?
>
> Here's the most popular explanation:
>
> https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/
>
> The main thesis (quoted from the article's conclusion) is this:
>
>> These [unstructured concurrency] primitives are dangerous even 
>> if we don't use them directly, because they undermine our 
>> ability to reason about control flow and compose complex 
>> systems out of abstract modular parts, and they interfere with 
>> useful language features like automatic resource cleanup and 
>> error propagation.

Thanks.  I'll have a read of that later.

The flaw I've seen to date in the arguments against CSP (and 
Actors) in favour of 'Structured Concurrency', but which I do 
view as valid against raw threads, async/await type abstractions 
is the scope of application.

The way I approach CSP and Actors is to apply them to 'large' 
chunks of natural concurrency, and hence generally avoid shared 
data access.

Whereas the raw threads + locks, async/await and friends and 
implicitly 'Structured Concurrency' seem to be targetting 'fine 
grained' conncurrency decomposition, even to the level of 
individual functions calls.  This I view as inherently difficult 
to reason about, and possibly SC then provides some form of aid 
in reasoning.

Now one could use CSP and Actors in a similar way, and there they 
would likewise be equally difficult to reason about, but I 
suggest they tend to encourage different and higher level form of 
decomposition.

There the same reasoning issues don't arise, and moreover there 
are tools one to apply to prove the network/graph one has for 
CSP. (I'm not sure if the same applies for Actors).

The obvious trade off which one makes when using CSP is the risk 
of deadlock.

However the above tools are supposed to avoid that. I've not yet 
tried them, since I've yet to hit/create a sufficiently difficult 
graph which challenges manual analysis.  However it may still be 
worth using such tools if the graph may change under long term 
support of the program.

Even without such use I find that with sufficient logging (which 
is not really a lot) it is easy to reason through any remaining 
deadlocks once the arise during testing. Whereas it is incredibly 
difficult to reason through the trigger cause with shared data 
update (even under locks) when it occurs from multiple concurrent 
call graphs, which would happen under the other methodologies 
(including, I believe, SC).


So I generally see SC as tackling the wrong problem, however I 
shall give your reference a fair crack of the whip.

(I listened to the first podcast above; I've yet to get to the 
other two)

From f at abc.com  Tue Jun  3 16:19:50 2025
From: f at abc.com (f)
Date: Tue, 03 Jun 2025 16:19:50 +0000
Subject: [OT] Senders and Receivers
In-Reply-To: <uhfxnhiebqmnsbosegls@forum.dlang.org>
References: <uhfxnhiebqmnsbosegls@forum.dlang.org>
Message-ID: <wtqbvyjsqsqhrtnltbur@forum.dlang.org>

On Monday, 2 June 2025 at 19:22:47 UTC, Sergey wrote:
> Wanted to share with everyone series of podcasts about the 
> topic.
> The topic is quite complicated, so maybe this helps you to 
> better understand what is it all about.
> They discussing it mostly from C++ perspective, with some 
> Haskell ideas.
>
> D package with this approach: 
> https://code.dlang.org/packages/concurrency
>
> Podcast series:
> https://adspthepodcast.com/2025/04/25/Episode-231.html
> https://adspthepodcast.com/2025/05/23/Episode-235.html
> https://adspthepodcast.com/2025/05/30/Episode-236.html

another OT idea . perhaps D needs some kind of 2nd tier package 
bundle or even 3rd tier package. I mean that this kind of package 
must be somewhat impoertant that it gets downloaded for 137217  
times.

Otherwise it get lost somewhere in the forum, and int 
code.dlang.org, never be found and be used. Especially for newbie 
. Like me.

So maybe the download has some extra batteries

From crazymonkyyy at gmail.com  Tue Jun  3 19:00:40 2025
From: crazymonkyyy at gmail.com (monkyyy)
Date: Tue, 03 Jun 2025 19:00:40 +0000
Subject: [OT] Senders and Receivers
In-Reply-To: <wtqbvyjsqsqhrtnltbur@forum.dlang.org>
References: <uhfxnhiebqmnsbosegls@forum.dlang.org>
 <wtqbvyjsqsqhrtnltbur@forum.dlang.org>
Message-ID: <cjgwopumukvzgdsgxqfy@forum.dlang.org>

On Tuesday, 3 June 2025 at 16:19:50 UTC, f wrote:
> 
> another OT idea . perhaps D needs some kind of 2nd tier package 
> bundle

come join the dark side of opend

From jdegenhardt at ebay.com  Tue Jun  3 19:13:24 2025
From: jdegenhardt at ebay.com (Jon Degenhardt)
Date: Tue, 03 Jun 2025 19:13:24 +0000
Subject: Segmentation DMD segmentation faults after updating macOS Sequoia
 to version 15.4.1
In-Reply-To: <vhugaxbspfrrfkeisjhb@forum.dlang.org>
References: <1004106$d5p$1@digitalmars.com> <1004a9t$18nq$1@digitalmars.com>
 <vhugaxbspfrrfkeisjhb@forum.dlang.org>
Message-ID: <chgtfllhmeoviqgiiend@forum.dlang.org>

On Thursday, 15 May 2025 at 16:46:49 UTC, Ben Jones wrote:
> Also, as I learned on discord, the fix was backported to the 
> ldc version in homebrew.  I had to `brew reinstall ldc` and now 
> ldc works again on macos.

Thanks for posting. Had the same problem after upgrading to 
15.4.1. This solution allowed me to continue.

--Jon

From mail at skoppe.eu  Tue Jun  3 19:32:48 2025
From: mail at skoppe.eu (Sebastiaan Koppe)
Date: Tue, 03 Jun 2025 19:32:48 +0000
Subject: [OT] Senders and Receivers
In-Reply-To: <uhfxnhiebqmnsbosegls@forum.dlang.org>
References: <uhfxnhiebqmnsbosegls@forum.dlang.org>
Message-ID: <clhmbvrmtowfjxxfeabr@forum.dlang.org>

On Monday, 2 June 2025 at 19:22:47 UTC, Sergey wrote:
> Wanted to share with everyone series of podcasts about the 
> topic.
> The topic is quite complicated, so maybe this helps you to 
> better understand what is it all about.
> They discussing it mostly from C++ perspective, with some 
> Haskell ideas.
>
> D package with this approach: 
> https://code.dlang.org/packages/concurrency
>
> Podcast series:
> https://adspthepodcast.com/2025/04/25/Episode-231.html
> https://adspthepodcast.com/2025/05/23/Episode-235.html
> https://adspthepodcast.com/2025/05/30/Episode-236.html

Implementer here. Thanks for the link and ama.

From mail at skoppe.eu  Tue Jun  3 19:34:02 2025
From: mail at skoppe.eu (Sebastiaan Koppe)
Date: Tue, 03 Jun 2025 19:34:02 +0000
Subject: [OT] Senders and Receivers
In-Reply-To: <fylzhpgfkfzduheelory@forum.dlang.org>
References: <uhfxnhiebqmnsbosegls@forum.dlang.org>
 <fylzhpgfkfzduheelory@forum.dlang.org>
Message-ID: <jsyjinexrzgwrexanaaj@forum.dlang.org>

On Monday, 2 June 2025 at 19:32:03 UTC, Derek Fawcus wrote:
> On Monday, 2 June 2025 at 19:22:47 UTC, Sergey wrote:
>> Wanted to share with everyone series of podcasts about the 
>> topic.
>> The topic is quite complicated, so maybe this helps you to 
>> better understand what is it all about.
>> They discussing it mostly from C++ perspective, with some 
>> Haskell ideas.
>>
>> D package with this approach: 
>> https://code.dlang.org/packages/concurrency
>>
>> Podcast series:
>> https://adspthepodcast.com/2025/04/25/Episode-231.html
>> https://adspthepodcast.com/2025/05/23/Episode-235.html
>> https://adspthepodcast.com/2025/05/30/Episode-236.html
>
> Why should "Structured Concurrency" be viewed as a better 
> approach than CSP (or Actors for that matter)?
>
> DF

Some more reading: https://skoppe.github.io/dconf-2022/6

In short: "Structured concurrency organizes concurrent tasks as 
tree-like hierarchies. This means that any child task is 
logically nested within its parent. When a parent task finishes, 
it waits for all its child tasks to complete or is automatically 
cancelled if the parent task fails."

This tree-like hierarchy achieves 2 important things:

- It improves reasoning of the code, like structured programming 
did;
- It ensures lifetimes of concurrent tasks follow the same 
structure, instead of the fire-and-forget approach.

From albert.guiman at protonmail.com  Wed Jun  4 16:56:32 2025
From: albert.guiman at protonmail.com (AlbertG)
Date: Wed, 04 Jun 2025 16:56:32 +0000
Subject: [GSoC 2025] Introduction
Message-ID: <heplapbuijquvyitqois@forum.dlang.org>

Hi everyone,

I'm Albert, a 2nd year CS student at Politehnica University of 
Bucharest and I am excited to introduce myself as one of this 
year's GSoC contributors.

The project I am working on[1], mentored by Teo Dutu, aims to 
finalize the templatization of runtime hooks he previously worked 
on.

So far, I have successfully templated some of the targeted hooks, 
namely 
[`_d_arraysetcapacity`](https://github.com/dlang/dmd/pull/21143), 
[`_d_arrayappendcTX`](https://github.com/dlang/dmd/pull/21205), 
[`_d_arrayshrinkfit`](https://github.com/dlang/dmd/pull/21373) 
and [`_d_dynamic_cast`](https://github.com/dlang/dmd/pull/21402). 
Currently I am working on the remaining casting hooks, with a PR 
open for 
[`_d_paint_cast`](https://github.com/dlang/dmd/pull/21427). At 
the same time, I am also trying to add benchmarks to evaluate the 
performance gains[2].

Throughout the GSoC period, I plan on posting weekly updates on 
my progress.

Looking forward to sharing more soon!

Thanks,
Albert

[1] https://dlang.github.io/GSoC/gsoc-2025/template-hooks.html
[2] https://github.com/teodutu/druntime-hooks-benchmarks/pull/1

From acehreli at yahoo.com  Wed Jun  4 19:59:27 2025
From: acehreli at yahoo.com (=?UTF-8?Q?Ali_=C3=87ehreli?=)
Date: Wed, 4 Jun 2025 12:59:27 -0700
Subject: [OT] Senders and Receivers
In-Reply-To: <rhzdlysgdejmgbwjqgdm@forum.dlang.org>
References: <uhfxnhiebqmnsbosegls@forum.dlang.org>
 <fylzhpgfkfzduheelory@forum.dlang.org> <rhzdlysgdejmgbwjqgdm@forum.dlang.org>
Message-ID: <101q8j0$1fif$1@digitalmars.com>

On 6/2/25 11:06 PM, Paul Backus wrote:

 > The main thesis (quoted from the article's conclusion) is this:
 >
 >> These [unstructured concurrency] primitives are dangerous even if we
 >> don't use them directly, because they undermine our ability to reason
 >> about control flow and compose complex systems out of abstract modular
 >> parts, and they interfere with useful language features like automatic
 >> resource cleanup and error propagation.

The garbage collector wins in that scenario because it removes the need 
for "automatic resource cleanup" e.g. of C++.

That fact was pointed out to me by a colleague years ago: The sender 
threads generate messages, the receiver threads use those messages, and 
thanks to the garbage collector, nobody cares about the ownership of 
messages.

Ali


From mail at skoppe.eu  Wed Jun  4 21:48:07 2025
From: mail at skoppe.eu (Sebastiaan Koppe)
Date: Wed, 04 Jun 2025 21:48:07 +0000
Subject: [OT] Senders and Receivers
In-Reply-To: <101q8j0$1fif$1@digitalmars.com>
References: <uhfxnhiebqmnsbosegls@forum.dlang.org>
 <fylzhpgfkfzduheelory@forum.dlang.org> <rhzdlysgdejmgbwjqgdm@forum.dlang.org>
 <101q8j0$1fif$1@digitalmars.com>
Message-ID: <scdlfqxflixepjhgqock@forum.dlang.org>

On Wednesday, 4 June 2025 at 19:59:27 UTC, Ali ?ehreli wrote:
> On 6/2/25 11:06 PM, Paul Backus wrote:
>
> > The main thesis (quoted from the article's conclusion) is
> this:
> >
> >> These [unstructured concurrency] primitives are dangerous
> even if we
> >> don't use them directly, because they undermine our ability
> to reason
> >> about control flow and compose complex systems out of
> abstract modular
> >> parts, and they interfere with useful language features like
> automatic
> >> resource cleanup and error propagation.
>
> The garbage collector wins in that scenario because it removes 
> the need for "automatic resource cleanup" e.g. of C++.
>
> That fact was pointed out to me by a colleague years ago: The 
> sender threads generate messages, the receiver threads use 
> those messages, and thanks to the garbage collector, nobody 
> cares about the ownership of messages.
>
> Ali

It is not the lifetimes of the messages that is interesting, it's 
that of the producer and consumer themselves instead.

This is because they are different sides of the same coin; one 
without the other wouldn't work. The essential point is thus to 
model that relationship correctly - to ensure their lifetimes are 
coupled and avoid one going off without the other. Getting that 
guarantee is the big benefit of SC. Just look at the link I 
posted and read the papers it links to. Almost all those bugs are 
variations of mishaps in ensuring that invariant manually, not a 
good way to go about it.

Now, it must be said, the GC does help a lot in lock-free 
algorithms. Just look into hazard pointers to see what madness 
you have to resort to without a GC.

From snarwin at gmail.com  Thu Jun  5 01:29:21 2025
From: snarwin at gmail.com (Paul Backus)
Date: Thu, 05 Jun 2025 01:29:21 +0000
Subject: [OT] Senders and Receivers
In-Reply-To: <101q8j0$1fif$1@digitalmars.com>
References: <uhfxnhiebqmnsbosegls@forum.dlang.org>
 <fylzhpgfkfzduheelory@forum.dlang.org> <rhzdlysgdejmgbwjqgdm@forum.dlang.org>
 <101q8j0$1fif$1@digitalmars.com>
Message-ID: <ftfecshlzodcvffplujw@forum.dlang.org>

On Wednesday, 4 June 2025 at 19:59:27 UTC, Ali ?ehreli wrote:
> On 6/2/25 11:06 PM, Paul Backus wrote:
>
> > The main thesis (quoted from the article's conclusion) is
> this:
> >
> >> These [unstructured concurrency] primitives are dangerous
> even if we
> >> don't use them directly, because they undermine our ability
> to reason
> >> about control flow and compose complex systems out of
> abstract modular
> >> parts, and they interfere with useful language features like
> automatic
> >> resource cleanup and error propagation.
>
> The garbage collector wins in that scenario because it removes 
> the need for "automatic resource cleanup" e.g. of C++.
>
> That fact was pointed out to me by a colleague years ago: The 
> sender threads generate messages, the receiver threads use 
> those messages, and thanks to the garbage collector, nobody 
> cares about the ownership of messages.

The linked article mostly talks about Python and Go, which are 
both garbage-collected languages. The "resources" referred to 
here are things like open files and network connections, which 
are not reclaimed by the GC.

From rumpf_a at web.de  Thu Jun  5 08:00:35 2025
From: rumpf_a at web.de (Araq)
Date: Thu, 05 Jun 2025 08:00:35 +0000
Subject: [OT] Senders and Receivers
In-Reply-To: <scdlfqxflixepjhgqock@forum.dlang.org>
References: <uhfxnhiebqmnsbosegls@forum.dlang.org>
 <fylzhpgfkfzduheelory@forum.dlang.org> <rhzdlysgdejmgbwjqgdm@forum.dlang.org>
 <101q8j0$1fif$1@digitalmars.com> <scdlfqxflixepjhgqock@forum.dlang.org>
Message-ID: <dxhnvkiicevunzrbsiur@forum.dlang.org>

On Wednesday, 4 June 2025 at 21:48:07 UTC, Sebastiaan Koppe wrote:
> Now, it must be said, the GC does help a lot in lock-free 
> algorithms. Just look into hazard pointers to see what madness 
> you have to resort to without a GC.

It's not a big deal, you can use a library for it (C++ is getting 
it in its stdlib: 
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p1121r3.pdf) just like your GC which lives in the code space you didn't write yourself.

From mail at skoppe.eu  Thu Jun  5 14:30:09 2025
From: mail at skoppe.eu (Sebastiaan Koppe)
Date: Thu, 05 Jun 2025 14:30:09 +0000
Subject: [OT] Senders and Receivers
In-Reply-To: <dxhnvkiicevunzrbsiur@forum.dlang.org>
References: <uhfxnhiebqmnsbosegls@forum.dlang.org>
 <fylzhpgfkfzduheelory@forum.dlang.org> <rhzdlysgdejmgbwjqgdm@forum.dlang.org>
 <101q8j0$1fif$1@digitalmars.com> <scdlfqxflixepjhgqock@forum.dlang.org>
 <dxhnvkiicevunzrbsiur@forum.dlang.org>
Message-ID: <jrenvnzutsvtgavmcdjv@forum.dlang.org>

On Thursday, 5 June 2025 at 08:00:35 UTC, Araq wrote:
> On Wednesday, 4 June 2025 at 21:48:07 UTC, Sebastiaan Koppe 
> wrote:
>> Now, it must be said, the GC does help a lot in lock-free 
>> algorithms. Just look into hazard pointers to see what madness 
>> you have to resort to without a GC.
>
> It's not a big deal, you can use a library for it (C++ is 
> getting it in its stdlib: 
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p1121r3.pdf) just like your GC which lives in the code space you didn't write yourself.

There is probably a parallel universe where I did actually end up 
writing a GC for D.

From rumpf_a at web.de  Thu Jun  5 14:41:09 2025
From: rumpf_a at web.de (Araq)
Date: Thu, 05 Jun 2025 14:41:09 +0000
Subject: [OT] Senders and Receivers
In-Reply-To: <jrenvnzutsvtgavmcdjv@forum.dlang.org>
References: <uhfxnhiebqmnsbosegls@forum.dlang.org>
 <fylzhpgfkfzduheelory@forum.dlang.org> <rhzdlysgdejmgbwjqgdm@forum.dlang.org>
 <101q8j0$1fif$1@digitalmars.com> <scdlfqxflixepjhgqock@forum.dlang.org>
 <dxhnvkiicevunzrbsiur@forum.dlang.org> <jrenvnzutsvtgavmcdjv@forum.dlang.org>
Message-ID: <azrvrsprluiyryvvvbhi@forum.dlang.org>

On Thursday, 5 June 2025 at 14:30:09 UTC, Sebastiaan Koppe wrote:
> There is probably a parallel universe where I did actually end 
> up writing a GC for D.

On Thursday, 5 June 2025 at 14:30:09 UTC, Sebastiaan Koppe wrote:

I fail to see the point. So write a hazard pointer implementation 
too and see what is easier.

From mail at skoppe.eu  Thu Jun  5 15:58:14 2025
From: mail at skoppe.eu (Sebastiaan Koppe)
Date: Thu, 05 Jun 2025 15:58:14 +0000
Subject: [OT] Senders and Receivers
In-Reply-To: <azrvrsprluiyryvvvbhi@forum.dlang.org>
References: <uhfxnhiebqmnsbosegls@forum.dlang.org>
 <fylzhpgfkfzduheelory@forum.dlang.org> <rhzdlysgdejmgbwjqgdm@forum.dlang.org>
 <101q8j0$1fif$1@digitalmars.com> <scdlfqxflixepjhgqock@forum.dlang.org>
 <dxhnvkiicevunzrbsiur@forum.dlang.org> <jrenvnzutsvtgavmcdjv@forum.dlang.org>
 <azrvrsprluiyryvvvbhi@forum.dlang.org>
Message-ID: <gnpffyxknvavfnnhfcpa@forum.dlang.org>

On Thursday, 5 June 2025 at 14:41:09 UTC, Araq wrote:
> On Thursday, 5 June 2025 at 14:30:09 UTC, Sebastiaan Koppe 
> wrote:
>> There is probably a parallel universe where I did actually end 
>> up writing a GC for D.
>
> On Thursday, 5 June 2025 at 14:30:09 UTC, Sebastiaan Koppe 
> wrote:
>
> I fail to see the point. So write a hazard pointer 
> implementation too and see what is easier.

My point was that I am grateful there is a GC and that I don't 
have to write a hazard pointer library because of it.

It would be a bit odd to follow that up by implementing one, so 
I'm not going to. Maybe in the nogc-verse though ;)

From richard at cattermole.co.nz  Fri Jun  6 10:10:23 2025
From: richard at cattermole.co.nz (Richard (Rikki) Andrew Cattermole)
Date: Fri, 6 Jun 2025 22:10:23 +1200
Subject: [GSoC 2025] Introduction
In-Reply-To: <heplapbuijquvyitqois@forum.dlang.org>
References: <heplapbuijquvyitqois@forum.dlang.org>
Message-ID: <101ueqe$ccf$1@digitalmars.com>

On 05/06/2025 4:56 AM, AlbertG wrote:
> Hi everyone,
> 
> I'm Albert, a 2nd year CS student at Politehnica University of Bucharest 
> and I am excited to introduce myself as one of this year's GSoC 
> contributors.
> 
> The project I am working on[1], mentored by Teo Dutu, aims to finalize 
> the templatization of runtime hooks he previously worked on.
> 
> So far, I have successfully templated some of the targeted hooks, namely 
> [`_d_arraysetcapacity`](https://github.com/dlang/dmd/pull/21143), 
> [`_d_arrayappendcTX`](https://github.com/dlang/dmd/pull/21205), 
> [`_d_arrayshrinkfit`](https://github.com/dlang/dmd/pull/21373) and 
> [`_d_dynamic_cast`](https://github.com/dlang/dmd/pull/21402). Currently 
> I am working on the remaining casting hooks, with a PR open for 
> [`_d_paint_cast`](https://github.com/dlang/dmd/pull/21427). At the same 
> time, I am also trying to add benchmarks to evaluate the performance 
> gains[2].
> 
> Throughout the GSoC period, I plan on posting weekly updates on my 
> progress.
> 
> Looking forward to sharing more soon!
> 
> Thanks,
> Albert
> 
> [1] https://dlang.github.io/GSoC/gsoc-2025/template-hooks.html
> [2] https://github.com/teodutu/druntime-hooks-benchmarks/pull/1

Welcome and very nice work so far!


From matheus-catarino at hotmail.com  Fri Jun  6 17:11:25 2025
From: matheus-catarino at hotmail.com (Matheus Catarino)
Date: Fri, 06 Jun 2025 17:11:25 +0000
Subject: [GSoC 2025] Introduction
In-Reply-To: <heplapbuijquvyitqois@forum.dlang.org>
References: <heplapbuijquvyitqois@forum.dlang.org>
Message-ID: <yqmmsnamovwohwybgexo@forum.dlang.org>

On Wednesday, 4 June 2025 at 16:56:32 UTC, AlbertG wrote:
> Hi everyone,
>
> I'm Albert, a 2nd year CS student at Politehnica University of 
> Bucharest and I am excited to introduce myself as one of this 
> year's GSoC contributors.
>

Awesome! Nice work.