kbd has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
<andrewrk>
nice
<ifreund>
uh, I don't think ArrayListAligned respects the alignment value passed unless you use initCapacity()
<andrewrk>
I wonder if we could get away with not having ArrayListAligned
<ifreund>
I've never had a use for it
<ifreund>
andrewrk: well, I've got a basic MultiArrayList working but don't handle custom alignments on fields because the allocator interface expects the alignment at comptime
<ifreund>
doing it in a single allocation got too ugly when handling fields of varying size
kbd has joined #zig
<ifreund>
yeah I'm just going to ignore alignment of fields for now
<ifreund>
I don't see any use case
<ifreund>
and ArrayListAligned isn't actually used anywhere in the std or self-hosted, I think it should get booted to the orphanage
<ifreund>
especially since it doesn't even work currently
blueberrypie has quit [Quit: leaving]
blueberrypie has joined #zig
<andrewrk>
I bet you could do it cleanly with fields of varying size but it would involve a comptime sort on the field alignment
<andrewrk>
it's pretty neat because it would actually save memory over an array of structs when there are fields of mixed alignment
<ifreund>
hmm, that would be smart. Anyhow I'm off to bed now though I just put up a draft PR
<ifreund>
should be able to finish it up tomorrow
<andrewrk>
sweet
zags has quit [Quit: leaving]
marijnfs has quit [Read error: Connection reset by peer]
cole-h has joined #zig
nvmd has quit [Read error: Connection reset by peer]
marler8997 has joined #zig
gazler_ has joined #zig
gazler has quit [Ping timeout: 240 seconds]
<marler8997>
anyone else see that microsoft is deploying metadata about the win32 api?
osa1_ has joined #zig
osa1 has quit [Ping timeout: 260 seconds]
joey_ has joined #zig
joey_ has quit [Client Quit]
joey_ has joined #zig
joey_ has quit [Client Quit]
joey_ has joined #zig
factormystic has quit [Read error: Connection reset by peer]
jukan has joined #zig
joey_ has quit [Quit: leaving]
jukan_ has quit [Ping timeout: 272 seconds]
factormystic has joined #zig
osa1_ is now known as osa1
<daurnimator>
mikdusan: yeah. we can probably use it.... though I don't trust them to be complete. but should provide a good baseline. though might make sense as a non-core project
<daurnimator>
marler8997: yep. there's been discussion of it on both discord and here
<marler8997>
I'm working on the zig projection now :)
slact has quit [Remote host closed the connection]
knebulae has quit [Read error: Connection reset by peer]
a_chou has joined #zig
a_chou has quit [Quit: a_chou]
waleee-cl has quit [Quit: Connection closed for inactivity]
dumenci has joined #zig
dumenci has quit [Quit: Leaving]
<andrewrk>
marler8997, does it have ntdll stuff in it?
<marler8997>
I see NtCreateFile
knebulae has joined #zig
nycex- has joined #zig
knebulae has quit [Read error: Connection reset by peer]
nycex has quit [Ping timeout: 268 seconds]
knebulae has joined #zig
knebulae has quit [Read error: Connection reset by peer]
_whitelogger has joined #zig
frett27_ has joined #zig
nycex- has quit [Remote host closed the connection]
nycex has joined #zig
leon-p has joined #zig
knebulae has joined #zig
nycex has quit [Remote host closed the connection]
knebulae has quit [Read error: Connection reset by peer]
nycex has joined #zig
knebulae has joined #zig
knebulae has quit [Read error: Connection reset by peer]
knebulae has joined #zig
<pixelherodev>
andrewrk: is "the root source file is one compilation unit" intended to be part of the spec, or an implementation detail?
<pixelherodev>
My compiler currently splits the root file into pieces at the import level (potentially in the future it could be even more fine-grained) and turns each input file into a compilation unit - so e.g. each file in the standard library will get its own object file when imported with `@import("std")`. Should I be merging them back together?
knebulae has quit [Read error: Connection reset by peer]
<pixelherodev>
As I've mentioned, I want to retain 100% compatibility even before there's an official spec, so I might bugyou with a few more questions like this over the next week or so
knebulae has joined #zig
<andrewrk>
pixelherodev, the output format is target-defined
<andrewrk>
out of scope of the language specification
<pixelherodev>
andrewrk: okay, thanks for clarifying :)
<pixelherodev>
andrewrk: I was unsure, because the site mentions "zig does LTO" in a waythat left me unsureif that was intended to be part of the lang, or just an impl detail
<andrewrk>
as another example, the way that the string of an inline assembly block is interpreted is also target defined
knebulae has quit [Read error: Connection reset by peer]
<zags>
In file included from /Users/cc/projects/zigprojects/zigcompiler/src/zig_llvm.cpp:23:
<zags>
/usr/local/opt/llvm/include/llvm/Analysis/TargetLibraryInfo.h:53:10: error: unknown type name 'StringLiteral'
<zags>
Ideas? :)
jukan has joined #zig
<ugla>
Did you do the thing from the docs: "For example, macOS users may want to use cmake .. -DCMAKE_PREFIX_PATH=$(brew --prefix llvm) " ?
<zags>
yeah, same error with or without that
<zags>
if finds llvm clang 11
jukan has quit [Ping timeout: 265 seconds]
<zags>
targets libembedded_softfloat and opt_c_util builds, but it fails with the above errors on the zigcpp target
koakuma has joined #zig
nycex has quit [Remote host closed the connection]
nycex has joined #zig
<ugla>
I don't have a mac so unfortunately I don't know. But I'm pretty sure there's more mac users here. Maybe asleep. :)
<zags>
No worries, I'll wait :)
marijnfs has joined #zig
<marijnfs>
how do you normally organised your code in files? I kind of want to move code to another file but still access the functions and constants defined there
<marijnfs>
now I need to do a const somefunc = @import("other.zig").somefunc for everything
<mikdusan>
generally you treat it like a namespace. `const other = @import("other.zig"); other.somefunc(...);`
<marijnfs>
yeah I guess that's how it is
<ifreund>
I'm not afraid of large files, I only spilt stuff up if there's a clear logical division of the current file into multiple namespaces
<ifreund>
also remember that files are nothing but structs!
<marijnfs>
yeah I have everything in one file after breaking up too early before and getting lost in the code
<marijnfs>
ifreund: that's true, it's funny you can write a whole struct in a file without saying 'struct'
<zags>
@<primitive> intrinsics would be nice, I think people might start doing helpers like `pub fn U32(comptime val: anytype) u32 { return @as(u32, val); }` to clean up casts in complex code. I like the explicitness, but it can be verbose.
<zags>
if (x < @u32(5)) is sweet
<marijnfs>
would be useful indeed
<ifreund>
not sure how I feel about that. It would definitely be more concise, but not as simple as the status quo IMO
<ifreund>
and it wouldn't be able to replace @as() either
<ifreund>
I think there's a *very* slim chance of that getting accepted tbqh
<zags>
Yeah, not likely I'm sure :) I just think it's strikes a nice balance as primitive literals a very common. I really like uint64_t(5) in cpp. Explicit, yet consise.
<ifreund>
note that zig used to do casting like u16(x)
<ifreund>
but that was removed in favor of @as()
<zags>
oof
<zags>
General casting with @as is fine, love it, this is more like ergonomics for primtives which I find annoying now.
<ifreund>
it may be useful to note that .i32 and .f64 etc are valid enum literals, so a function so something like wasm.load(.i32) might be a nice api to get 0x28
<Nypsie[m]>
Aaaah I see, just like how there's std.coff etc
<Nypsie[m]>
I'll thinker with both of these in mind and see if I can come up with an elegant API. Thanks for the input, ifreund.
<ifreund>
no problem!
<ifreund>
Nypsie[m]: a single large enum would also be a totally valid approach
<Nypsie[m]>
ifreund: I see. That's actually what I did for my own compiler's wasm backend. And you can then simply do wasm.emit(writer, .i32_load); for example
<ifreund>
i'd prefer wasm.opcode(.i32_load) that returns 0x28
<ifreund>
they are all one byte after all
<Nypsie[m]>
Yeah makes sense
<Nypsie[m]>
Thanks once again :)
v0idify has quit [Ping timeout: 268 seconds]
_whitelogger has joined #zig
jukan has joined #zig
xackus has joined #zig
jukan has quit [Ping timeout: 240 seconds]
xackus_ has quit [Ping timeout: 264 seconds]
<zags>
What allocation/deallocation strategy do you guys use for shared/long-term data? Not always easy to track lifetimes/ownership. In c++ I use shared pointers for those cases.
<zags>
I don't feel like manually doing reference counting :)
<zags>
Maybe a boehmgc-style allocator would be possible?
sord937 has joined #zig
sord937 has quit [Remote host closed the connection]
<ifreund>
I don't think I have any data like that in river at least, everything has a clear owner
<ifreund>
manual reference counting is actually pretty ergonomic in zig with defer as well
<ifreund>
I'm sure you could implement a c++ std like smart pointer as well
sord937 has quit [Ping timeout: 268 seconds]
cole-h has quit [Ping timeout: 240 seconds]
<zags>
ifreund: that's nice, but some apps sometimes have shared data and harder-to-track ownership
<companion_cube>
ifreund: without RAII? How?
<zags>
companion_cube: i think it'll have to be with manual release/aquire, but you can get some type safety to help out
<companion_cube>
Right, so that's not a smart pointer
<zags>
that depends on your definition of smart pointer, COM has release/aquire for instance and they call it smart pointers because it knows when to deallocate
<ifreund>
no, zig doesn't have RAII and never will so you'd need to manually handle the ref counting
<ifreund>
the point of this is to be able to wrap arbitrary data inside this "smartish pointer"
<zags>
yeah
<ifreund>
instead of needing to add ref counting functions to your type
<zags>
ifreund: do you think a boehm allocator would be possible for stuff like closures and long-lived data?
<zags>
so you could opt-in gc where you want
<ifreund>
zags: by the way I lied, river does use some things that does manual ref counting, though they come from C libraries
<zags>
i see
<ifreund>
zags: hmm, remind me how the boehm gc thing figures out if a recource is dead or not?
<zags>
conservative scan, if it looks like a pointer to something it knows about, it's live
<zags>
usually works fine
jukan has joined #zig
<ifreund>
Yeah I don't see why that wouldn't work just as well with zig as it does in C
<zags>
could be an interesting thing to try
<ifreund>
it won't know about pointers held in memory *not* allocated with the GC though right?
<zags>
i noticed someone did for the entire compiler to deal with allocation failures
<zags>
ifreund: yeah, it only knows gc_malloc stuffs afaik
<ifreund>
seems like an all or nothing kind of solution, if you mix normal allocation in that's a huge, implicit footgun
<companion_cube>
Heh, semi smart pointer then :)
<zags>
ifreund: well, manual allocation is already a collosal footgun, defer or not
<zags>
i'd love an opt-gc to allocate closures
<zags>
opt-in gc
<ifreund>
using a gc that will free memory from under your feet if the only remaining pointers are allocated manually is a far greater footgun than the simple rules of manual memory management IMO
<ifreund>
tools like valgrind and the std's gpa make tracking down leaks and use-after-free quite straightforward
<zags>
sure, but it would only be for specific things, some language support would be helpful though
<ifreund>
I don't think you'll ever see GC built into zig :P
<zags>
sure, sanitizers and valgrind help, but i'm still going to miss c++ smart pointers, they work very well
<ifreund>
the language itself knows nothing about allocation
<zags>
yeah i know, just dreaming
<ifreund>
sounds like D tbh
<ifreund>
which is far too close to C++ for my liking, but still a step up if I had to choose between the too
<zags>
i know D and C and Nim and a lot of other things... they have other problems
<zags>
I like Zig a lot, but I'll miss c++ smart pointers for sure
<zags>
But I also recognize why they don't fit in the language
<zags>
shared_ptr allocates behind the scenes and stuff, not compatible with Zig's goal
<ifreund>
everything's a tradeoff yeah
<zags>
indeed
jukan has quit [Ping timeout: 256 seconds]
sord937 has joined #zig
<zags>
Why are colons needed when breaking to labels? Are they in a different namespace than identifiers maybe?
<mikdusan>
there is an open proposal to change that
<ifreund>
I think the reasoning why they are required by the compiler currently is to provide clarity that they aren't a variable or whatever, not because the compilier depends on them to know what code to generate
<ifreund>
I'm not sure how they are handled with regards to shadowing off the top of my head
<mikdusan>
looking at code is made easier "break op1 op2" doesn't tell me which is label. I'd have to remember a rule, if 2 operands then op1 is label,
<mikdusan>
where "break :op1 op2" tell me right away. also when writing code if you remember visually then without colon still more difficult.
<ifreund>
exactly
sord937 has quit [Ping timeout: 268 seconds]
<zags>
that's a very good point
sord937 has joined #zig
jukan has joined #zig
<zags>
ifreund: when you reference-count manually, do you keep the allocator around and then have the struct deinit itself on refcount goes to zero?
<ifreund>
zags: yes that would be the way to do it
<zags>
thanks
<ifreund>
you can either store a pointer to the allocator in your struct or just use a global as it's probably gonna be a GPA
jukan has quit [Ping timeout: 272 seconds]
<mikdusan>
if you're not using a slab, or slub (or slob even) you're doing it wrong. :P
<ifreund>
I'm linking libc, so I might as well just use that one...
<mikdusan>
that's what I would _try_ to do with stage2 (disclaimer: ignorant of what it is currently planning). have slabs for @sizeOf ranges of IR nodes. and allocate them from there. refcount.
<ifreund>
stage2 makes very heavy use of areans currently
<ifreund>
I think that may need to be reexamined for comptime evaluation though
<mikdusan>
prolly
v0idify has joined #zig
sord937 has quit [Ping timeout: 268 seconds]
<zags>
after a few days of jumping between c-like languages and Zig, I still think it's really odd that both
<zags>
const count: i32 = 1;
<zags>
and
<zags>
count: i32 = 0,
<zags>
are allowed in structs
<zags>
look almost the same, but one is a field and the other is... something else
<zags>
i keep doing the first when adding fields, oof
<zags>
or tbh, I usually try "count: i32 = 0;" and it doesn't compile and I slap my forehead thinking I should've learned to use comma instead of semicolon by now :D
<ifreund>
the other is a declaration
<ifreund>
basically a global namespaced to that struct
<ifreund>
and don't forget that files are structs
<marler8997>
ok whose got a windows box that wants to test they can build something for me?
<zags>
well, the syntax is going to bite me for a long time haha
<marler8997>
I'm working on the Zig win32 binding generation, and want to make sure my build instructions include all the dependencies that are actually required
<zags>
ifreund: yeah i like how files are implicit structs with basename naming
<marler8997>
irc doesn't seem to be a talkative these days, is there alot more activity on discord?
v0idify has quit [Remote host closed the connection]
midgard has quit [Read error: Connection reset by peer]
midgard has joined #zig
<ifreund>
yeah, there're a lot more people there but also a lot more off-topic discussion
<marler8997>
ifruend, I guess I'll have to change my stomping grounds then
<ifreund>
I think you'll certainly find more windows users there, probably mostly linux here
<marler8997>
ah..interesting
<ifreund>
zags: I think it's the single least confusing way to handle imports I've seen. Arguable a bit more complex than the C preprocessor's text-based #include but much simpler to use in practice
maier has joined #zig
hnOsmium0001 has joined #zig
xackus has quit [Ping timeout: 265 seconds]
xackus has joined #zig
maier has quit [Ping timeout: 265 seconds]
wootehfoot has joined #zig
jukan has joined #zig
jukan has quit [Ping timeout: 272 seconds]
zags has quit [Ping timeout: 246 seconds]
<Nypsie[m]>
ifreund: Wew, you're fast :P
<ifreund>
Nypsie[m]: I'm procrastinating :P
<Nypsie[m]>
Hahaha, we've all been there I think
<Nypsie[m]>
Anyway, thanks. Will quickly update it
<Nypsie[m]>
Now I get those saturating truncation instructions. Hmmm not sure what would be a great API for those.
jukan has joined #zig
jukan has quit [Ping timeout: 246 seconds]
<ifreund>
me neither, they feel super ugly
<ifreund>
could always just leave 'em out for now, zig doesn't need them
<ifreund>
or at least not yet, I suppose the language could gain saturating math at some point down the road
<Nypsie[m]>
Yeah, would rather keep them out for now than implement them incorrectly.
kbd has joined #zig
Amun_Ra has quit [Quit: Gdyby mi się chciało tak jak mi się nie chce…]
Amun_Ra has joined #zig
<Nypsie[m]>
Fixed your comments. Thanks again for reviewing so swiftly, ifreund. Time for some relaxing :)
sord937 has joined #zig
sord937 has quit [Client Quit]
nycex has quit [Remote host closed the connection]
nycex has joined #zig
kbd has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
cole-h has joined #zig
nycex has quit [Remote host closed the connection]
nycex has joined #zig
xackus has quit [Ping timeout: 256 seconds]
riba has quit [Ping timeout: 256 seconds]
ur5us has joined #zig
ur5us has quit [Ping timeout: 264 seconds]
Akuli has quit [Quit: Leaving]
frett27_ has quit [Ping timeout: 272 seconds]
<andrewrk>
marler8997, idk if you noticed but spexguy is live right now working on the win32 stuff
<marler8997>
yeah I been lurking
notzmv has joined #zig
<marijnfs>
how do I manipulate bits, can I cast to a []u1?
<justin_smith>
that's possible with @bitCast iirc, but it might be easier to just use the normal bitwise ops
<ifreund>
no, because bits aren't individually addressable that wouldn't really make sense