Just a heads up, I cloned Zangent's fork and Odin is not building the demo or test file. I wanted to give it a go tonight and plan to look a little deeper this weekend.
o7
o7
So I've had my eye on Odin for a while, wanting to try it out, but I'm on Arch Linux.
Forewarning, I am a college student, and not the best at programming, so don't expect much progress. And if there is progress, expect it to be not the best. Anyway...
After dicking around a bit, I've got it to compile, but the binary won't build/run anything. It dumps its core during a call to free(), saying invalid pointer.
I've narrowed it down to (apparently) when it closes the _preload.odin file. The problem is that when freeing up "old_memory", its dereferencing a generic pointer, or something like that. I haven't quite got around to figure out what you're doing with your custom allocation stuff.
I'd be more than happy to give more information if anyone wants it.
Just more or less throwing my hat into the ring.
Forewarning, I am a college student, and not the best at programming, so don't expect much progress. And if there is progress, expect it to be not the best. Anyway...
After dicking around a bit, I've got it to compile, but the binary won't build/run anything. It dumps its core during a call to free(), saying invalid pointer.
I've narrowed it down to (apparently) when it closes the _preload.odin file. The problem is that when freeing up "old_memory", its dereferencing a generic pointer, or something like that. I haven't quite got around to figure out what you're doing with your custom allocation stuff.
I'd be more than happy to give more information if anyone wants it.
Just more or less throwing my hat into the ring.
Oh, I remembered I took a screencap that may help:
I think it comes down to the line: (indicated by the breakpoint)
You can see what str and result are in the top, but basically it outputs "\000" instead of (I'm guessing) the full path for the file.
Again, I don't know if this is linked to the problem I'm having, but it's something I noticed.
I think it comes down to the line: (indicated by the breakpoint)
1 | result = cast(char *)gb_alloc_copy(a, str, len+1); |
You can see what str and result are in the top, but basically it outputs "\000" instead of (I'm guessing) the full path for the file.
Again, I don't know if this is linked to the problem I'm having, but it's something I noticed.
There is no official support for Linux yet. I will most likely do the Linux port myself soon. gb.h is not heavily tested either and it needs better support for *nix systems.
gb.h is my attempt at a standard library replacement for my needs. It's okay on Windows but no much on other systems, I need to work on it properly.
One of the goals with it was to treat all text as utf-8 so even on windows, you would not need to worry about wchar_t stuff. However, I have not yet found a thread safe method nor a method doesn't require a lot of heap allocations. Maybe, I should just use a malloc solution (like fopen) to convert `char *` (utf-8) to `wchar_t *` (ucs2) for windows use.
gb.h is my attempt at a standard library replacement for my needs. It's okay on Windows but no much on other systems, I need to work on it properly.
One of the goals with it was to treat all text as utf-8 so even on windows, you would not need to worry about wchar_t stuff. However, I have not yet found a thread safe method nor a method doesn't require a lot of heap allocations. Maybe, I should just use a malloc solution (like fopen) to convert `char *` (utf-8) to `wchar_t *` (ucs2) for windows use.
ABuffSeagull
the binary won't build/run anything
I stopped maintaining Odin for a while because there was a bug that I thought was part of master. It seems that something breaks in the port, but I can't find out where the root of the problem is.
When execution gets to `are_proc_types_overload_safe` in `types.c`, both proc types are NULL.
TO bypass this, I added a temporary solution which is just a NULL check, and when it passes it just returns `ProcOverload_ParamCount`. I have a warning message that states that proc overloading doesn't work in the port right now, but I don't know when that'll be fixed. Looking at the code, I have no idea how Odin actually checks that, but I have a slight suspicion that it may just be broken from a bad merge.
Anyway, it compiles and runs again. Sorry for the wait!
(If you want to contact me or report bugs about the Linux/macOS port, bug me on the Handmade Network discord, since I don't check here all too often)