On 22/04/2024 9:55 AM, Brad Roberts wrote:
> Before github we used dsource.org and subversion:
>      http://dsource.org/projects/druntime/browser
> 
> It looks like the history on github retains that history, which matches with my memory of how we transitioned over.  The history seems to start at about 2008.
> 
> What I'm not seeing is much pre-D2 history.  There's some, but I thought I'd built up a full D1 history, or mostly full -- at least a per-release snapshot.  Did those early release tarball/zips not contain the druntime code maybe?
> 
> On 4/21/2024 1:58 PM, Walter Bright via Digitalmars-d wrote:
>> Quite an awesome bit of detective work! A fine and most entertaining read it is. I recommend you include that text in any PR to fix it.
>>
>>  > So maybe, the solution Walter came up with (and I'm just guessing here), is hey, we are shutting down anyways, just avoid scanning the main thread stack, and we can satisfy the unwashed masses.
>>
>> If I did write that function, I don't remember doing so, or why I would. Unfortunately, D1 predates our use of github, so it wouldn't be easy trying to figure out who wrote that.

The oldest version of D that is in the release archive is 0.5, which has it.

That is from 17/11/2002

So wayyyyy before dsource.

On 4/21/2024 2:58 PM, Richard (Rikki) Andrew Cattermole via Digitalmars-d wrote:
> On 22/04/2024 9:55 AM, Brad Roberts wrote:
>> Before github we used dsource.org and subversion:
>>      http://dsource.org/projects/druntime/browser
>>
>> It looks like the history on github retains that history, which matches with my memory of how we transitioned over.  The history seems to start at about 2008.
>>
>> What I'm not seeing is much pre-D2 history.  There's some, but I thought I'd built up a full D1 history, or mostly full -- at least a per-release snapshot.  Did those early release tarball/zips not contain the druntime code maybe?
>>
>> On 4/21/2024 1:58 PM, Walter Bright via Digitalmars-d wrote:
>>> Quite an awesome bit of detective work! A fine and most entertaining read it is. I recommend you include that text in any PR to fix it.
>>>
>>>  > So maybe, the solution Walter came up with (and I'm just guessing here), is hey, we are shutting down anyways, just avoid scanning the main thread stack, and we can satisfy the unwashed masses.
>>>
>>> If I did write that function, I don't remember doing so, or why I would. Unfortunately, D1 predates our use of github, so it wouldn't be easy trying to figure out who wrote that.
> 
> The oldest version of D that is in the release archive is 0.5, which has it.
> 
> That is from 17/11/2002
> 
> So wayyyyy before dsource.

Ok, the older code is in the phobos repository and goes back to phobos 0.1.  I did that import, and the commit is dated september 9, 2007.  The exact same history as on dsource.org for phobos, just to double check. So, that's the best history that Walter was able to dig up for me.

So, it's been there that way from the earliest history I ever saw.

On 22/04/2024 9:58 AM, Richard (Rikki) Andrew Cattermole wrote:
> The oldest version of D that is in the release archive is 0.5, which has it.
> 
> That is from 17/11/2002
> 
> So wayyyyy before dsource.

Found an even older one!

dmdalpha19.zip from ftp.digitalmars.com

Contains fullcollectNoStack still.

But this time its in C.

Also:

```
//
// Copyright (C) 2001 by Digital Mars
// All Rights Reserved
// Written by Walter Bright
// licensed to Chromium Communications
```

Interesting header.

I've gone through that ftp server. Doesn't appear to be anything older.

At this point somebody is gonna have to get lucky, perhaps booting up some old machines or backups.

On 22/04/2024 10:26 AM, Richard (Rikki) Andrew Cattermole wrote:
> On 22/04/2024 9:58 AM, Richard (Rikki) Andrew Cattermole wrote:
>> The oldest version of D that is in the release archive is 0.5, which has it.
>>
>> That is from 17/11/2002
>>
>> So wayyyyy before dsource.
> 
> Found an even older one!
> 
> dmdalpha19.zip from ftp.digitalmars.com
> 
> Contains fullcollectNoStack still.
> 
> But this time its in C.
> 
> Also:
> 
> ```
> //
> // Copyright (C) 2001 by Digital Mars
> // All Rights Reserved
> // Written by Walter Bright
> // licensed to Chromium Communications
> ```
> 
> Interesting header.
> 
> I've gone through that ftp server. Doesn't appear to be anything older.
> 
> At this point somebody is gonna have to get lucky, perhaps booting up some old machines or backups.

I've been able to find an alternative GC implementation.

August 21 2002, https://web.archive.org/web/20170913015932/http://opend.org/

Unfortunately that GC doesn't look like alpha19.zip's and that is older as its from February 8 2002.

So that is a complete dead end (it doesn't have it).

Welp I'm out of ideas, looks like that is it.

On 22/04/2024 9:21 AM, Richard (Rikki) Andrew Cattermole wrote:
> On 22/04/2024 9:07 AM, Walter Bright wrote:
>> On 4/21/2024 1:01 PM, Richard (Rikki) Andrew Cattermole wrote:
>>> I can't even get Walter to agree to have RC in the language (even if it is reluctantly), let alone that...
>>
>> A few years back, we really tried to find a way to do it that was memory safe. We failed. Timon presented us with a use-after-free case that we couldn't resolve. Re-orienting D around a memory-unsafe construct is not the future for D.
>>
>> There's also the problem that the decrement has to be in a finally block, because of exceptions, which makes things bloated and slow.
> 
> I suspect that I need to learn more about the exception hooks.
> 
> My current understanding is that there is a subset that are entirely optional and are only needed to be called if cleanup occurs. Not quite the same thing as an exception catch.

After reviewing Windows documentation and assembly for linux, it appears my previous understanding is correct.

You only have to deal with cleanup which is checked for anyway, if you throw an exception.

So in other words, slow path only. I don't understand the issue here.

It is equivalent to a struct stored on the stack having its destructor called when an exception is thrown.

On 4/21/24 21:57, Daniel N wrote:
> On Sunday, 21 April 2024 at 19:28:11 UTC, Steven Schveighoffer wrote:
> 
> Why do we even support destructors for GC allocated objects? You can't depend on it closing file-descriptors or other resources.
> 
> 
> 

Closing non-memory resources is not the only use case for destructors on GC-allocated objects. Another use case is freeing non-GC-allocated memory that the object encapsulates. Non-deterministic destruction is perfectly fine for such a use case. An example of this in Phobos is std.zlib.Compress.