<andrewrk>
argh when did debug symbols stop working on windows?
<andrewrk>
sometimes I'm not even able to get symbols with msvc debugging zig.exe
<andrewrk>
windows build of master branch should be fixed now
<daurnimator>
hryx: oh? I thought it wouldn't even conflict
<daurnimator>
nevermind... I see it does
<daurnimator>
I remember a 'parse2.zig'?
<hryx>
yeah, sorry about that, I should have mentioned
<hryx>
parse2.zig was my workspace until it was ready to replace parse.zig
<hryx>
which is probably a goofy workflow
<daurnimator>
hryx: have you fixed the allocator usage bug in your branch?
<daurnimator>
nope
<hryx>
daurnimator: mind leaving a comment on the PR? I'll peep it tonight
<daurnimator>
hryx: comment added.
<hryx>
thanks
<daurnimator>
hryx: essentially when you do `.arena_allocator = tree_arena,` -> this makes a copy; which means that tree_arena and tree.arena_allocator can now diverge. -> so when e.g. token_list tries to .free(): the allocator blows up
<daurnimator>
the solution is to never use `tree_arena` after `tree` is copied: which requires that things are reorganised so that the `Tree` object is created *first* and slowly filled in
<hryx>
Ok, I see it now. good call
<daurnimator>
hryx: not so much a call; as that in #2424 I optimized the allocator, and suddenly the parser tests were failing
<hryx>
"good catch", perhaps then
SimonNa has joined #zig
<daurnimator>
hryx: so we expect the new parser to be merged soon? (i.e. in the next day?)
<hryx>
assuming Hejsil has a moment to bless it, within the next one or two days!
<hryx>
I should have time for finishing touches tonight, but if I have a late work night then tomorrow night for sure
<daurnimator>
hryx: k. I'll block #2424 on that for now. Hopefully it's soon :)
xbat has joined #zig
xbat has quit [Remote host closed the connection]
<daurnimator>
andrewrk: idea to come out of that parser allocation patch: what if taking the address of a member marked the structure as 'fixed'?
<daurnimator>
const foo = SomeStruct{.x=42}; const foo_x = &foo.x; const bar = foo; // error: cannot copy fixed object 'foo' (fixed due to open reference 'foo_x')
<andrewrk>
daurnimator, I think this needs a more general idea of the concept of "escape analysis". even a simple variable store technically uses a pointer under the hood. var x = 1; // this uses a pointer in zig ir
scientes has quit [Ping timeout: 245 seconds]
<daurnimator>
andrewrk: yeah I thought as much.... but was wondering if a more simplistic form could be supported
<daurnimator>
e.g. maybe '&foo.x' marks 'foo' as 'escaped', but the internal "reference to" for the assignment operation doesn't?
<andrewrk>
tgschultz, I think after LemonBoy's latest fix, you won't even need gdb to find out which assert would need upgraded to src_assert/ir_assert
qazo has quit [Ping timeout: 245 seconds]
avoidr has quit [Quit: leaving]
very-mediocre has joined #zig
n_1-c_k has quit [Read error: Connection reset by peer]
n_1-c_k has joined #zig
jjido has joined #zig
jjido has quit [Client Quit]
Ichorio has joined #zig
very-mediocre has quit [Ping timeout: 256 seconds]
Ichorio has quit [Ping timeout: 258 seconds]
xbat has joined #zig
hio has joined #zig
IntoxicatedHippo has joined #zig
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
SamTebbs33 has quit [Remote host closed the connection]
SamTebbs33 has joined #zig
very-mediocre has joined #zig
n_1-c_k has quit [Read error: Connection reset by peer]
n_1-c_k has joined #zig
zahary has joined #zig
gamester has joined #zig
<gamester>
andrewrk: Sorry I don't have github or use git (I use mercurial which I find simpler). Did you take a look at the /usr/lib64 issue? It's definitely a separate directory on fedora. I had to copy libs from /usr/lib64 to /usr/lib to make zig find them.
<gamester>
btw coroutines in C++ are brutal. I've never used coroutines before, but in C++ you can easily pass a reference to the coroutine which won't exist when the coroutine is continued. Also the return type is non-void even when it returns nothing (really confusing). The entire thing is SO confusing. I can't understand a thing. I need a classroom lecture every time I revisit my c++ coroutine stuff. It looks like Zig's coroutines will be simpler.
<tgschultz>
that's the goal anyway
<gamester>
In C++ they're going with the approach where only a few "elite" developers know the details necessary to design coroutine types or whatever, while the rest are expected to gloss over the details. That's literally what it says in their papers on coroutines.
<gamester>
not verbatim
mouldysammich has joined #zig
<gamester>
You can't make this up: "4.4 Are coroutines expert only feature" - "Luckly only a few (say, a thousand) C++ developers in the entire world would have to know or use any of the coroutine customization points"
<gamester>
"Who: Everybody (millions) - Uses coroutines via high level syntax...."
<gamester>
"Who: Cream of the crop (200) - Defines metafunctions, utilities and adapters...."
<very-mediocre>
although i guess that falls under footguns.
<very-mediocre>
i think i'd actually prefer using a JIT'd scripting-ish language and just manipulate the GC than go back to C++
<companion_cube>
so you could use D
<very-mediocre>
or something transpiled like nim
<very-mediocre>
but the point will become moot once zig is ready :)
TheLemonMan has joined #zig
Ichorio has joined #zig
scientes has quit [Remote host closed the connection]
<TheLemonMan>
andrewrk, (wrt #2459) do you want me to change the numbering behaviour then?
scientes has joined #zig
<andrewrk>
TheLemonMan, just a sec I have an almost complete review
<TheLemonMan>
sure thing, take your time
scientes has quit [Max SendQ exceeded]
scientes has joined #zig
n_1-c_k has quit [Read error: Connection reset by peer]
n_1-c_k has joined #zig
halosghost has joined #zig
<andrewrk>
TheLemonMan, review posted. regarding automatic numbering, definitely feel free to make the extern enum logic match C ABI. I want to get your opinion for other enums -
<andrewrk>
if I remember correctly my reasoning is to try to fill up the slots starting at 0 so that switch expressions could likely be optimized to jump tables
<andrewrk>
I think it's good to guarantee that enums with no explicit numbering and no explicit type will get an unsigned int, and indexes starting at 0, 1, 2...
<andrewrk>
but as for enums that have some values specified, what to choose for the non-specified values, I think is up for discussion. do you think the C way of doing it is better than the "try to fill holes starting at 0" way?
very-mediocre has quit [Ping timeout: 256 seconds]
<TheLemonMan>
better codegen is possibly the same reason why C enums start at zero, I guess. Picking the numbering scheme that's already familiar to most developers (and that's also been adopted by new PLs such as Rust and Swift just to name two of them) IMO helps as is more "predictable" (as-in, a newcomer expects it to work that way)
<TheLemonMan>
and using two different schemes for extern & non-extern enums is asking for trouble heh, I feel that'd be against Zig's koans
<TheLemonMan>
I hope I managed to get my point across, I'm better with code than with words
<andrewrk>
I do see your point. I'm thinking about it
<andrewrk>
I'm wondering whether we want to guarantee/define enum ordering for non-extern enums
<halosghost>
I have mixed feelings about wasm becoming a universal platform though
gamester has quit [Quit: Leaving]
<andrewrk>
TheLemonMan, I am conflicted and I don't want to make a decision about it right now
<andrewrk>
feel free to do the C enum ordering for all enums for now, we can revisit later
redj has joined #zig
<TheLemonMan>
great, will do later
<tgschultz>
halosghost: my feelings are less mixed. I'm by no means an expert in the subject but it appears to me that wasm is kinda crap for that goal. I've thought about making a new OS (environment more than kernel) before and one idea I had was, in addition to support for multi-arch binaries, guaranteeing a virtual-arch target that is supported no matter what the real arch is, so even brand new processors could run any application without
<tgschultz>
recompilation as long as it included support for the virutal-arch. I looked at wasm a bit for that but it seems inadequate just from the memory model alone.
<tgschultz>
andrewrk: does the definition of "field", in the ZigType and related structures sense, include definitions within a struct, or just actual fields? If the latter, how does one go about finding the former?
<companion_cube>
tgschultz: but wasm is promising because it doesn't require new OSes nor new processors
<tgschultz>
companion_cube: no, just new runtimes on top of every OS instead. The idea wasn't that the OS "required" new processors, but that it could support running the virtual-arch on them as soon as the OS itself was ported. Obviously native binaries would be better, but until that gap is filled no one has to deal with the chicken-egg problem of not having applications on the new arch.
<tgschultz>
and unlike a runtime that abstracts away the OS, it instead provides the actual OS ABI.
<companion_cube>
so it'd be better because hypothetically, people would eventually adopt processors for this new arch?
SamTebbs33 has quit [Remote host closed the connection]
<tgschultz>
it'd be better because it would allow experimentation in the physical arch space without the chicken-egg problem. well, not as severe of one anyway.
<companion_cube>
not sure why it's better than having new archs + wasm runtimes on them, anyway; the world will keep having several architectures for a while :)
<tgschultz>
which wasm runtimes?
<tgschultz>
there are like 5 now, and growing
<andrewrk>
zig has one planned too
<tgschultz>
I want less abstraction, not more.
<andrewrk>
at the very least so that we can test wasi target
<andrewrk>
speaking of tgschultz I thought of an idea yesterday regarding the planned safety features that I think hopefully can satisfy you
<tgschultz>
I was coming around to the idea of hidden allocation of stack frames in debug/safe mode, but if that can be avoided so much the better.
<companion_cube>
personally I'd be happy with more abstraction (wasi) as long as it's a way out of the current electron+js bloat
<andrewrk>
much like the panic handler being overridable, the safety features for escaped stack variables can go through a minimal user-defined allocation interface which is overridable and disableable
<tgschultz>
companion_cube: lesson from history: it's only un-bloated now because it doesn't do much. Web browsers were once lightweight too.
<andrewrk>
so it would be on by default but in the same way that panicking dumps a stack trace by default
<andrewrk>
this would make it easy to opt out of in your codebase, and it would also make it possible to opt in to the safety in freestanding mode with some glue code
<tgschultz>
so I could swap out my own alloctor tuned for that kind of work instead of relying on the native one? I like it.
<companion_cube>
well I doubt wasm will slow down as much as JS
<andrewrk>
yes or disable the safety entirely, potentially by having your custom implementation just return error.OutOfMemory (or maybe set it to null, idk yet)
<tgschultz>
I do like that idea.
<andrewrk>
tgschultz, regarding "field" are you looking at .cpp code?
<tgschultz>
yes
<andrewrk>
in this context "fields" are exclusively the struct fields, e.g. a: i32, b: bool, c: f64
<andrewrk>
so you want to get the globals from the namespace of the struct?
<tgschultz>
ok, so how do I get from container to definition? specifically an fn within it?
<tgschultz>
yeah.
<andrewrk>
is this in ir.cpp?
<tgschultz>
yes
<andrewrk>
search that file for find_container_decl
<tgschultz>
'decl', that's a term I hadn't considered. thanks.
<tgschultz>
get_container_scope(container) => find_container_decl(scope, name) => Tld => ZigType looks like the path I need.
<tgschultz>
overall this is remarkably clear code for cpp, it's just been a long time since I've worked in it and I've never looked at the compiler code before.
<andrewrk>
I avoid most c++ features
<andrewrk>
ain't nobody got time for that shit
<tgschultz>
agreed
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<andrewrk>
can you work around it with @ptrCast(*c_void, some_function)?
<TheLemonMan>
let's see, gimme a few mins
<TheLemonMan>
I definitely love zig fmt, I'd love it even more if it would wrap the looong lines
<andrewrk>
TheLemonMan, so far zig fmt has avoided all logic regarding column count
<andrewrk>
you can put `,` at the end of stuff to hint to break things into multiple lines
<andrewrk>
function calls, declarations, struct inits, arrays, etc
<andrewrk>
idk how to solve the line length problem. the style guide says "aim for 100" but that's a completely arbitrary number
<andrewrk>
I kinda want to say "no line limit, your IDE should wrap for you as appropriate"
jevinskie has joined #zig
<andrewrk>
even though nobody has a zig IDE that does that yet
<TheLemonMan>
good luck with that, vim is dumb as a brick when it comes to indentation
<andrewrk>
yeah I'm all too familiar with that
jevinskie has quit [Client Quit]
<TheLemonMan>
wrt #661 do you think there's a better syntax than those hideous square brackets?
jevinskie has joined #zig
<andrewrk>
yeah, got any ideas?
<tgschultz>
well angle brackets were a leading candidate for that sort of thing since async introduced them, but I'm not so sure that's the plan anymore. Maybe since it is an enum, fn.Ccc?
<TheLemonMan>
off the top of my head `pub call_cc(builtin.CallingConvention.C) fn oh_well() void { ... }`
<TheLemonMan>
but it gets messy pretty quick
<andrewrk>
enum literals help a lot, and they work today: pub call_cc(.C) fn oh_well() void { ... }
flasheater has joined #zig
<andrewrk>
we just need a place for an expr to go
<andrewrk>
functions already have align(expr) after the args
<andrewrk>
so that you can use comptime parameters in expr
<andrewrk>
if we follow this (and I choose a different keyword): fn ohWell() align(4) callconv(.stdcall) {...}
<andrewrk>
I think that makes the most sense - considering align() is important
<TheLemonMan>
hmm, that looks nice
<andrewrk>
I'm confident that's better than the accepted proposal so I'm going to edit it
<andrewrk>
builtin.TypeInfo.CallingConvention should be pulled out into builtin.CallingConvention
wootehfoot has joined #zig
<andrewrk>
updated. that's still greenlit
rain1 has joined #zig
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<tgschultz>
andrewrk, thanks for that tip on locating the source line number the other day. now that I know enough gdb to get by it has been very handy.
jeremycw has joined #zig
<TheLemonMan>
tgschultz, the backtraces should not crash anymore now
<tgschultz>
I haven't rebased my branch yet and I've made changes to the compiler.
scientes has left #zig ["Leaving"]
scientes has joined #zig
jjido has joined #zig
flasheater has quit [Quit: WeeChat 2.4]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
very-mediocre has joined #zig
scientes has quit [Remote host closed the connection]
scientes has joined #zig
scientes has quit [Max SendQ exceeded]
scientes has joined #zig
scientes has quit [Max SendQ exceeded]
scientes has joined #zig
scientes has quit [Remote host closed the connection]
n_1-c_k has quit [Read error: Connection reset by peer]
n_1-c_k has joined #zig
very-mediocre has quit [Quit: Page closed]
plude_ has joined #zig
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]