On Monday, 12 January 2015 at 00:33:52 UTC, Andrei Alexandrescu wrote:
> Answers from others would be helpful. Thanks! -- Andrei

Usually once per beta and once per release.

On Sunday, 11 January 2015 at 18:25:39 UTC, francesco.cattoglio wrote:
> They have not broken any promise just yet! :P And I somehow hope
> they can really manage a high level of stability after
> discussing throughtly this much about every bikeshed
> topic (including the recent int/uint change).

Yes... And whether to embed 2K of poetry in the runtime or not...

https://github.com/rust-lang/rust/issues/13871

On Sunday, 11 January 2015 at 19:30:59 UTC, ponce wrote:

> When does invalidMemoryOperationError happen and how do you avoid it?

Typical example:
using (a slightly outdated version of) gfm library, I have  few gfm objects lying around on which I forget to call a close() function. When the GC collects them the destructor runs close(), which in turn calls for some allocation (e.g: allocates for a string to send to the logger), invalidMemoryOperationError pops up.
This usually only happens at the end of execution, sometimes however it happens randomly during program execution due to the randomness of GC operations.
The only way out of this is manually closing everything correctly. I.e: I'm almost back to C++ manual memory management. Catching the exception is an unsatisfactory solution because I would still be leaking resources[1]. If possible, things are made even worse in that RefCounted doesn't work for classes, but that you can work around that (class instance into refcounted struct, not really elegant and requires lots of discipline, since it's easy to escape an extra reference).

[1] For everyone who doesn't know: non trivial destructors are really useful in gfm because it wraps some C libraries, and cleaning up C allocated resources is usually important. Proper execution of gfm's close() for every class would be ideal.

On Monday, 12 January 2015 at 11:04:45 UTC, francesco.cattoglio wrote:
> On Sunday, 11 January 2015 at 19:30:59 UTC, ponce wrote:
>
>> When does invalidMemoryOperationError happen and how do you avoid it?
>
> Typical example:
> using (a slightly outdated version of) gfm library, I have  few gfm objects lying around on which I forget to call a close() function. When the GC collects them the destructor runs close(), which in turn calls for some allocation (e.g: allocates for a string to send to the logger), invalidMemoryOperationError pops up.
> This usually only happens at the end of execution, sometimes however it happens randomly during program execution due to the randomness of GC operations.
> The only way out of this is manually closing everything correctly. I.e: I'm almost back to C++ manual memory management. Catching the exception is an unsatisfactory solution because I would still be leaking resources[1]. If possible, things are made even worse in that RefCounted doesn't work for classes, but that you can work around that (class instance into refcounted struct, not really elegant and requires lots of discipline, since it's easy to escape an extra reference).
>
> [1] For everyone who doesn't know: non trivial destructors are really useful in gfm because it wraps some C libraries, and cleaning up C allocated resources is usually important. Proper execution of gfm's close() for every class would be ideal.

Yeah the current situation force much discipline vs C++, and I made it worse by having class destructors call close() which turn things to work sometimes only by chance.

I think more and more that I should have class destructors that don't call close(), and simply don't do anything.

It's what glamour does (https://github.com/Dav1dde/glamour/blob/master/glamour/shader.d#L207) and it seems way more practical. Especially since destructors called by GC would release resources from the wrong thread, at the wrong moment, etc.

It would be great if we settle on a name for this releasing function, whether it is close(), release(), dispose()... it seems it is a blocker for owning pointers of class instances.

On Monday, 12 January 2015 at 12:23:51 UTC, ponce wrote:
> Especially since destructors called by GC would release resources from the wrong thread, at the wrong moment, etc.

Yeah, I almost forgot about this: destructing GC resources interacting with OpenGL was sooooooo fun :P

On Monday, 12 January 2015 at 11:04:45 UTC, francesco.cattoglio wrote:
> On Sunday, 11 January 2015 at 19:30:59 UTC, ponce wrote:
>
>> When does invalidMemoryOperationError happen and how do you avoid it?
>
> Typical example:
> using (a slightly outdated version of) gfm library, I have  few gfm objects lying around on which I forget to call a close() function. When the GC collects them the destructor runs close(), which in turn calls for some allocation (e.g: allocates for a string to send to the logger), invalidMemoryOperationError pops up.
> This usually only happens at the end of execution, sometimes however it happens randomly during program execution due to the randomness of GC operations.
> The only way out of this is manually closing everything correctly. I.e: I'm almost back to C++ manual memory management. Catching the exception is an unsatisfactory solution because I would still be leaking resources[1]. If possible, things are made even worse in that RefCounted doesn't work for classes, but that you can work around that (class instance into refcounted struct, not really elegant and requires lots of discipline, since it's easy to escape an extra reference).
>
> [1] For everyone who doesn't know: non trivial destructors are really useful in gfm because it wraps some C libraries, and cleaning up C allocated resources is usually important. Proper execution of gfm's close() for every class would be ideal.
Sounds like an exact same problem I have run into recently: class wrappers around HDF5 C library need to do something not @nogc in a destructor and also have to call the C-level releasing functions. Can't do that in a destructor since then you get the invalidMemoryOperationError; can't make classes structs and use refcounted since there's an implied type hierarchy which becomes a mess with alias this... the only way is to put that in close() and then not forget to call it manually.

Wish there was a standardized way of running non-@nogc user code before the dtor actually runs (and anytime after it's known to be guaranteed to run).

On Monday, 12 January 2015 at 11:04:45 UTC, francesco.cattoglio wrote:
> When the GC collects them the destructor runs close(), which in turn calls for some allocation (e.g: allocates for a string to send to the logger),

Do you have to log? I've never had a problem calling C free functions in a class destructor in D.

On Monday, 12 January 2015 at 00:33:52 UTC, Andrei Alexandrescu wrote:
> On 1/11/15 4:33 PM, MattCoder wrote:
>> On Sunday, 11 January 2015 at 23:27:34 UTC, Nick B wrote:
>>> Perhaps its better to have a number (average or mean) than no number.
>>> Just ask 50 or 100 uers (or more) for their number of downloads for
>>> the last 12 or 18 months. This is turn will give you a guess-estimate
>>> as to the size of the community. If the number is small, say 4, then
>>> this will indicate that the community is near 100,000 users.
>>
>> Interesting for example, in my case I downloaded twice on the last 12
>> months (2.062 and 2.066).
>
> Answers from others would be helpful. Thanks! -- Andrei

3-4 times per release (have 3 windows machines and on mac)

On Monday, 12 January 2015 at 13:27:55 UTC, Adam D. Ruppe wrote:
> On Monday, 12 January 2015 at 11:04:45 UTC, francesco.cattoglio wrote:
>> When the GC collects them the destructor runs close(), which in turn calls for some allocation (e.g: allocates for a string to send to the logger),
>
> Do you have to log? I've never had a problem calling C free functions in a class destructor in D.

Not me personally, but gfm does that, and I'm not going to remove all the logging from the destructors :P
I know the log example is weak, but I really think this issue is still valid.
To be completely honest, it is my only real gripe with D.

On Monday, 12 January 2015 at 14:34:41 UTC, francesco.cattoglio wrote:
> On Monday, 12 January 2015 at 13:27:55 UTC, Adam D. Ruppe wrote:
>> On Monday, 12 January 2015 at 11:04:45 UTC, francesco.cattoglio wrote:

> To be completely honest, it is my only real gripe with D.

Yes, but it's at the very root of the language.