Ported rxi/lite text editor to odin for fun and learning Odin

[Feoramund]

@waqar144

The port went smoothly, I did have some trouble understanding allocators (there are 3 different versions of Arena in the core lib!) and other apis.

I clarified in this post what the differences are between the arena types. I’ve had the thought that maybe the .Buffer variant of virtual.Arena is unneeded when we have mem.Arena, and I’ve shared your confusion at one point about this.

@waqar144

I first need to take my browser back to https://pkg.odin-lang.org/ or the Core library. There should be some way to search globally from anywhere.

This would be a nice addition. I’m unfamiliar with how the pkg website works, but a workaround right now is to keep the search page open and open new tabs from the search links listed.

@waqar144

context.allocator becomes nil if you call a proc “c” function. Since lite is basically written in lua there is a lot of Odin → lua ← C stuff going on. So if lua calls into a proc "c" function in Odin, it doesn’t have context.allocator for some reason. I worked around it atm by making context.allocator global during initialization. But even then, some allocations don’t get freed no matter how hard I tried, perhaps I am missing something basic

Only the odin calling convention carries the implicit context pointer with every call, so this is by design. It’s not so much that it becomes nil as much as that it’s not passed to the procedure in the first place. Every Odin odin procedure can be thought of as having an extra pointer to a runtime.Context structure.

The way you handle this for procedures with c and other contextless calling conventions is to provide it either in a global variable or along with a userdata pointer that the procedure can be made aware of.

You can also make a mem.Tracking_Allocator and hook your allocator up to that to keep track of memory leaks, which should pinpoint where they’re coming from (with some exceptions).

@waqar144

types are optional e.g., x := 1 is valid and okay. But when types are missing in complex declarations its a bit annoying.

You can do x : Type = 1 or x := Type(1). Were you aware of this, or does that not cover your need here? The := contains an implicit declaration of the type which can be made explicit between the colon and equals sign.

@waqar144

I accidentally used := to assign a a value to a global variable. Took me a while to realize that it was creating a local variable and my global was left unintialized. A warning would’ve been nice

As @zen3ger has pointed out, there’s the -vet-shadowing compile-time option, as well as a whole suite of vetting options that you can see with odin build --help. In the same family of options, there is also -strict-style.

@zen3ger

Making the allocator global is a bit iffy, AFAIK not all of the implementations are thread safe, but default allocator is fine.

The default context allocator, which uses libc malloc on *NIX-likes and HeapAlloc on Windows, should be thread-safe, but refer to your system’s manual if you’re on a *NIX system. I’m unfamiliar with the orca platform, so I can’t speak to that. That’s the one oddball in the base:runtime/heap_allocator_*.odin set of files.