dvmason/zag-smalltalk

Smalltalk VM Written in Zig with methods stored as type-annotated ASTs

zag-smalltalk's Issues

weird compilation issue

cd zig/zag
zig test -freference-trace --test-filter fubar arenas.zig

output

arenas.zig:69:26: error: struct 'arenas.Arena' depends on itself
pub const Arena = extern struct {
                  ~~~~~~~^~~~~~
referenced by:
    NurseryArena(509): arenas.zig:121:33
    NurseryArena: arenas.zig:116:19
    nurseryType: thread.zig:22:31
    Thread: thread.zig:18:15
    Self: thread.zig:21:18
    thread_size: thread.zig:23:48
    threadAvail: thread.zig:24:43
    nursery_size: thread.zig:25:31

fails repeatedly for me on linux-x86_64-gnu. Not only spuriously.

Related: #14353 ziglang/zig#14147 ziglang/zig#12325 ziglang/zig#8050

Compilation?

Any clues about how to compile/use this project?

Zig tracking issue

This is a tracking issue for upstream Zig. (see Third Party Tracking Issues)
Overall, Zig is really great and its cross-compilation abilities are great, but some (planned) proposals and bug fixes would make it better:

• issue ziglang/zig#12325 (regression introduced in stage2) is blocking me being able to test conveniently. I have so far been able to avoid *anyopaque/@ptrCast but zig test foo.zig fails with circular definition error, so I have to zig test bar.zig (where foo.zig and bar.zig (correctly) refer to each other actually there are about six files that mutually refer to each other) and I worry that one day there won't be one I can start the test from.

Mist memory model for Zag

Re: https://www.youtube.com/watch?v=iw4FPqe8KdY&t=1093s 22:05 to 36:05

The above section of Martin McClure's Mist video describes a very simple, fast, exponential memory model involving binary-powers-of-2-sized bins for allocating objects. We need not lift this GC mechanism into the Smalltalk itself, at this early stage, as he is proposing for Mist. We could instead implement this GC design as C primitives on the VM side. In this way, objects on the heap will never move. This fact alone will increase execution speed and create more deterministic latencies.

Thoughts anyone?