<leeward>
andrewrk: 114 doesn't make any mention of where `try` belongs. Personally, I think it should bind more tightly than arithmetic operations. `SomeErrors!u32` * u32 doesn't make any sense, and no arithmetic operators result in error unions.
<andrewrk>
it's going to require parens with arithmetic ops
<leeward>
It also adds symmetry, since `a + try foo()` if a is u32 and foo returns !u32
<leeward>
Is that mentioned anywhere in 114? I can't find it.
<andrewrk>
well I see your point, especially because there is no operator overloading. it would be abundantly obvious how to resolve that order of operations
<leeward>
Yeah, operator overloading would change the picture dramatically, but it's completely off the table for Zig.
<leeward>
Holy crap I just saw the timestamps. I should not be awake. To be continued.
marnix has joined #zig
KKRT has joined #zig
ur5us has joined #zig
dermetfan has joined #zig
ur5us has quit [Ping timeout: 260 seconds]
ifreund has quit [Read error: Connection reset by peer]
ifreund has joined #zig
Biolunar has quit [Ping timeout: 272 seconds]
<shakesoda>
the need for parentheses on `try` has been one of those things i run into frequently that feels a bit absurd/unambiguous
marnix has quit [Ping timeout: 264 seconds]
cren has joined #zig
cren has quit [Read error: Connection reset by peer]
cren has joined #zig
cren has quit [Read error: No route to host]
cren has joined #zig
marnix has joined #zig
dermetfan has quit [Ping timeout: 256 seconds]
<Ristovski>
What's the reason Zigs compiler doesnt do multithreaded compiling?
<Ristovski>
even external C/C++ files seem to be compiled one by one
heitzmann has quit [Quit: WeeChat 2.9]
heitzmann has joined #zig
<ifreund>
Ristovski: because the zig compiler you are currently using is the stage1 compiler written in C++
<ifreund>
it's also horribly slow and a memory hog
<ifreund>
the main focus of development currently is writing a self-hosted stage2 complier in Zig which will be much faster
<Ristovski>
aah, I see
marnix has quit [Read error: Connection reset by peer]
ifreund has quit [Read error: Connection reset by peer]
ifreund has joined #zig
dermetfan has joined #zig
Biolunar has joined #zig
dermetfan has quit [Ping timeout: 260 seconds]
Ashpool_ has joined #zig
Ashpool has quit [Ping timeout: 265 seconds]
frmdstryr has quit [Ping timeout: 240 seconds]
pmwhite has quit [Remote host closed the connection]
pmwhite has joined #zig
wootehfoot has joined #zig
r4pr0n has quit [Quit: r4pr0n]
wootehfoot has quit [Read error: Connection reset by peer]
<danyspin97>
How can I cast a []const u8 to []u8?
<Nypsie[m]>
Create a new slice and copy over the bytes from the original []const u8 into the new []u8 slice. Altho, what are you trying to do?
<danyspin97>
Nypsie[m]: i am trying to call std.fs.basename
<ifreund>
hmm? fs.path.basename() takes a []const u8
cren has quit [Ping timeout: 246 seconds]
<danyspin97>
ifreund: yup, but the problem is that exe is a []u8
<Nypsie[m]>
I think what he's trying to achieve is to set the exe
<Nypsie[m]>
basename returns a []const u8, but he's trying to save it as a []u8
<danyspin97>
yea, that's the issue
<Nypsie[m]>
You could resize exe using an allocator and then copy over the bytes into it from the result you got from basename()
<danyspin97>
about the copy
<danyspin97>
is it @memcpy?
<Nypsie[m]>
Not sure if that works in this case, but std.mem.copy definitely does
<Nypsie[m]>
(I never used @memcopy before)
<Nypsie[m]>
std.mem.copy basically just loops over the slice and sets each value individually, so not the fastest way
<danyspin97>
it compiles, thanks!
<danyspin97>
the slice is 10-15 chars max, so it is fine
<Nypsie[m]>
Architecture wise, you could probably solve this in an easier way
<ifreund>
std.mem.copy() optimizes to @memcpy()
<ifreund>
don't use @memcpy() without good reason
<ifreund>
here you should just dupe() the slice that you get returned
<Nypsie[m]>
Ooh good to know
<Nypsie[m]>
Oof, completely forgot about dupe()
<danyspin97>
yea, dupe is exactly what I needed
<danyspin97>
thanks guys :)
KoljaKube has joined #zig
Ashpool__ has joined #zig
Ashpool_ has quit [Ping timeout: 240 seconds]
Ashpool__ is now known as Ashpool
cole-h has joined #zig
gpanders has quit [Read error: Connection reset by peer]
gpanders has joined #zig
<andrewrk>
Ristovski, multithreaded compilation is on the todo list for self-hosted
<ronsor>
I think using (try doFoo()) * bar is less confusing personally
<ronsor>
hmm. I forgot to scroll dwon.
gruebite has quit [Quit: WeeChat 2.9]
waleee-cl has joined #zig
KoljaKube has quit [Ping timeout: 244 seconds]
<scientes>
MLIR is built for multi-threaded
<scientes>
(of course LLVM, which was designed for it, has mistakes that prevent it)
<andrewrk>
MLIR is not the right tool for the job for zig
craigo has quit [Ping timeout: 264 seconds]
Ashpool_ has joined #zig
Ashpool has quit [Ping timeout: 264 seconds]
cren has joined #zig
KKRT has quit [Quit: KKRT]
cren has quit [Client Quit]
Ashpool__ has joined #zig
Ashpool__ is now known as Ashpool
wootehfoot has joined #zig
Ashpool_ has quit [Ping timeout: 264 seconds]
klltkr has joined #zig
<andrewrk>
hmmmmm if Windows VirtualAlloc is giving us 64K aligned pages, that kind of implies that the page size is 64K not 1K
<Sahnvour>
you mean 4K, not 1 ?
<andrewrk>
yes, oops
<andrewrk>
I think the tests will pass on #5998 now
<andrewrk>
think about it: if you request 32K only from the page allocator, you basically have 32K of memory inaccessible. since VirtualAlloc will never return that second 32K because it is not 64K aligned
<andrewrk>
may as well ask for all of it, right?
<Sahnvour>
right, I remember bringing the point for the allocator allocating pages directly from the OS (don't remember the name)
<andrewrk>
yeah. I think we have a lot of interesting improvements yet to be made to allocation in zig. I think the next step here is going to be making a series of gotta-go-fast benchmarks for allocation
<Sahnvour>
also I discovered recently there's a VirtualAlloc2 that handles alignment, we might get rid of that loop in PageAllocator with it ? alas it's windows 10 only