December 15

On Thursday, 14 December 2023 at 18:26:40 UTC, Siarhei Siamashka wrote:

>

On Thursday, 14 December 2023 at 18:18:21 UTC, matheus wrote:

>

Allocate();
GC.disable();
run_the_game();
GC.enable();

Is the run_the_game() part of code supposed to be annotated with the @nogc attribute?

It depends, I guess. If it is not @nogc annotated, it can still allocate and if it does it can run out of memory, unless it calls GC.collect at the right moments. If it is @nogc annotated, it cannot allocate and then the whole GC.disable and GC.enable become unnecessary.

-- Bastiaan.

December 15

On Friday, 15 December 2023 at 10:53:44 UTC, Bastiaan Veelo wrote:

>

On Thursday, 14 December 2023 at 18:26:40 UTC, Siarhei Siamashka wrote:

>

On Thursday, 14 December 2023 at 18:18:21 UTC, matheus wrote:

>

Allocate();
GC.disable();
run_the_game();
GC.enable();

Is the run_the_game() part of code supposed to be annotated with the @nogc attribute?

It depends, I guess. If it is not @nogc annotated, it can still allocate and if it does it can run out of memory, unless it calls GC.collect at the right moments. If it is @nogc annotated, it cannot allocate and then the whole GC.disable and GC.enable become unnecessary.

That's exactly my concern and the compiler isn't very helpful in this scenario.

Would it be useful to have something like @vettedgc attribute, for annotating the part of code, where each GC allocation needs to be pedantically reported by the compiler as a warning? And some sort of @permitgc attribute to suppress these warning in a few selected places inside of this code if really necessary?

I would suggest to maybe somehow differentiate between "hard" @nogc variety, where the garbage collector isn't even linked at all. And "soft" @nogc variety, where GC allocations are generally strongly discouraged, but allowed as explicitly annotated exceptions in a few selected places after careful review. The former is useful for hardcore bare metal embedded use cases and that's what the compiler supports right now. The latter would be maybe useful for game developers.

December 16
My suggestion up to this point has been ``@localnogc``.

Disallows GC operations accidentally happening in a function body, but does allow calling GC functions.

Simple, easy to implement and understand. While also ensuring you don't accidentally do something in a hot path that you were not expecting (like creating a closure on the heap).
December 15

On Friday, 15 December 2023 at 10:53:44 UTC, Bastiaan Veelo wrote:

>

On Thursday, 14 December 2023 at 18:26:40 UTC, Siarhei Siamashka wrote:

>

On Thursday, 14 December 2023 at 18:18:21 UTC, matheus wrote:

>

Allocate();
GC.disable();
run_the_game();
GC.enable();

Is the run_the_game() part of code supposed to be annotated with the @nogc attribute?

It depends, I guess. If it is not @nogc annotated, it can still allocate and if it does it can run out of memory, unless it calls GC.collect at the right moments. If it is @nogc annotated, it cannot allocate and then the whole GC.disable and GC.enable become unnecessary.

-- Bastiaan.

First thing, if a game won't run out of memory this fast. You typically have many scenarios where it is desirable the GC to run. On level loading, when a level finishes, even at checkpoints are the main places which you can make the GC run, if you run out of memory doing that, it means your game ought to be slow no matter the language you're using since there is a lot of strategies to make it more efficiente (Pool objects).

Regarding the soft nogc, this is achievable by doing that one:


    void main()
    {
        void main()
        {
            () scope @nogc
            {
                writeln("Hello World");
            }();
            writeln("Hello World");
        }
    }
    ```
December 15
Am 14.12.2023 um 14:59 schrieb bachmeier:
> On Thursday, 14 December 2023 at 08:38:02 UTC, solidstate1991 wrote:
>> After losing a battle with trying to get Lua 5.4 working on my own end, with problems I previously solved kept reappearing, and other problems just were unable to fix for no good reason, I've decided to drop it from my own game engine in favor of some replacement.
>>
>> I need a lightweight scripting language with integer support that is either easy to interface with D (preferrably as a DLL/SO file, so I don't have to deal with godawful C/C++ build systems), or at least would be easy to port within a few weeks. Most scripting languages nowadays are de-facto application languages for people that are scared of compilers and type systems, thus are coming with 25-50MB worth of standard libraries, which I obviously would like to avoid packing with my way smaller game engine. At the very worst, I'll try to port pocketpy or something like that to D or make it a DLL file.
> 
> If you're willing to go with Lisp, there are small, embeddable Schemes: [s7](https://ccrma.stanford.edu/software/snd/snd/s7.html) and [Chibi](https://github.com/ashinn/chibi-scheme), one that is more Clojure-like: [Janet](https://janet-lang.org/), and one that's more like Lua: [Squirrel](http://www.squirrel-lang.org/).

I've used Squirrel as a LUA replacement about 20 years ago and liked it quite a bit. It's actually positively surprising that it is still (or again) receiving updates.
December 15
On Friday, 15 December 2023 at 14:30:43 UTC, Sönke Ludwig wrote:
> I've used Squirrel as a LUA replacement about 20 years ago and liked it quite a bit. It's actually positively surprising that it is still (or again) receiving updates.

I also used Squirrel as a Lua replacement many years ago and also liked it in general. It was nice to have a companion scripting language with a C-style syntax for modding/extending the main C++ code. Unlike dealing with Lua, moving pieces of code between Squirrel and C++ required only minimal modifications. But I wasn't impressed with Squirrel's reliability and sandboxing capabilities. For example, having deep recursion in Squirrel could crash the host C++ application back then and I encountered other gotchas.

Today I would also possibly consider https://mruby.org as a possible Lua or Squirrel replacement. The security researchers had a field trip thoroughly looking for security/reliability problems in it: https://brandur.org/fragments/shopify-mruby
December 15
On Friday, 15 December 2023 at 13:33:45 UTC, Richard (Rikki) Andrew Cattermole wrote:
> My suggestion up to this point has been ``@localnogc``.
>
> Disallows GC operations accidentally happening in a function body, but does allow calling GC functions.
>
> Simple, easy to implement and understand. While also ensuring you don't accidentally do something in a hot path that you were not expecting (like creating a closure on the heap).

What can be done to make it happen? Is there a DIP proposal?
December 16
I'll see if I can talk to Walter about it this BeerConf, if not I'll get Adam Wilson to have a talk with him during one of their in real life meet ups.

It's an easy addition (although would need a DIP follow up).
December 17

On Thursday, 14 December 2023 at 15:44:21 UTC, IGotD- wrote:

>

Which has GC (reference counting/tracing hybrid) and yet it is used in video games. If D can improve the GC implementation it will be suitable for games as well.

GC isn't as evil as people make it out to be. Using the same tactical preallocation methods that are recommended for real-time applications in general fixes most of the issues people have with the GC. Now only if we had a way to run this GC on a background thread...

December 17

On Thursday, 14 December 2023 at 09:19:00 UTC, Alexandru Ermicioi wrote:

>

Maybe a bit offtopic, but you may try webassembly interpreter, then you'd not be limited to only one scripting language but have available all languages that compile down to webassembly, and have them sandboxed.

Although I've not used it, but wasm3 api seems simple to use (has c/c++ api), though there are other libs as well.

This made me look up some VMs as I want to examine all possible options, and I remembered QScript, which itself has a VM more active in development than QScript itself. I'll see if either can write a modified Lua interpreter for it, or even just use QScript itself (which is very not Lua-like, but maybe will work).