<hazeycode>
hmmm `const options = @import("build_options");` isn't working for me. I get `error: unable to find 'build_options'`. Just built and installed master, PATH is correct, no luck
<hazeycode>
version 0.5.0+3c7f030a6
rjtobin has quit [Remote host closed the connection]
ur5us has joined #zig
hazeycode has quit [Ping timeout: 260 seconds]
mahmudov has quit [Ping timeout: 258 seconds]
dwdv has quit [Quit: quit]
mahmudov has joined #zig
Snetry has joined #zig
_Vi has quit [Ping timeout: 252 seconds]
<daurnimator>
andrewrk: turns out the buffer in the TEB is only 261 bytes in size (MAX_PATH+1). Rather than the actual maximum of 32K
ur5us has quit [Ping timeout: 256 seconds]
<daurnimator>
alexnask: but yes, the TEB is per thread... the T stands for Thread :)
<daurnimator>
uh wrong ping; sorry alexnask
<alexnask>
How dare you /s
<alexnask>
:)
mahmudov has quit [Ping timeout: 255 seconds]
mahmudov has joined #zig
LakeByTheWoods has quit [Ping timeout: 260 seconds]
dimenus has joined #zig
<fengb>
daurnimator: would you know of a good way of hooking stream based fmt.format onto fifo?
<daurnimator>
fengb: because std.Buffer should really be called "0-terminated-growable-vector" unless you need zero termination you should never use it
<mikdusan>
BufferZ
<fengb>
Eh really? Then Buffer.allocPrint has a bug
<fengb>
Oh wait maybe I’m wrong
<daurnimator>
Though I do see a memory leak!
waleee-cl has quit [Quit: Connection closed for inactivity]
<fengb>
Oh I see
<fengb>
(Not the leak. The zeroing happens on resize)
alexnask has quit [Ping timeout: 240 seconds]
<daurnimator>
nevermind the leak was an illusion
<fengb>
I feel like we need a better interface. Buffer and Fifo both implement an adhoc outstream, probably because implementing it for real is annoying
<fengb>
Making it harder to convert format over >_>
<daurnimator>
fengb: the intention of my whole mixins thing was to unite it all
<daurnimator>
std.Buffer is almost always the wrong answer
<daurnimator>
you really want either ArrayList or LinearFifo
<daurnimator>
depending on if you ever delete from the start
<fengb>
I'm just converting the print function to work with the stream based format
<fengb>
And trying to figure out what it does because I don't want to break things >_>
<daurnimator>
should make your std.fmt tests easier to figure out
<fengb>
Oh... I deleted those in favor of using a SliceOutStream
<fengb>
Not deleted. Converted to SliceOutStream since it was easier
<wilsonk>
point of interest: mimalloc (https://github.com/microsoft/mimalloc) speeds up compilation of zig by about 5%, whether building single or multi-threaded (up to 64 cores). That is just by simply setting LD_PRELOAD to use mimalloc. Slight increase in memory usage due to the way it allocates...about 2%. So it might not be the best for the CI machines but might be worth it on your home machines. (P.S. only about 3% faster build of llvm-9.0 on
rjtobin has quit []
<daurnimator>
`zig test lib/std/event.zig --test-filter event.Loop` is currently failing 1 out of every ~5 tests for me
<daurnimator>
andrewrk: ^^
<wilsonk>
what does it fail with daurnimator?
<daurnimator>
wilsonk: it just hangs waiting on a futex
<wilsonk>
I just get 'no tests to run'
<daurnimator>
wilsonk: you should see: Test [1/1] event.loop.test "std.event.Loop - basic"..
<wilsonk>
hmm, I just updated zig ten minutes ago but no...I am just getting 'no tests to run'.
<wilsonk>
ok, massaged it with a sledgehammer to run that one test...seems to work fine here after 30 tests (removing any cache each time)
<daurnimator>
wilsonk: I can even re-run the same test binary
<daurnimator>
happy to send over to you to see if you can replicate
<wilsonk>
sure
<daurnimator>
how should I send the file to you? >.<
<wilsonk>
one sec here...hmm, my IRC client must be a little borked. Can you PM me? I can't seem to PM you
metaleap has joined #zig
jmiven has quit [Quit: bye]
jmiven has joined #zig
<andrewrk>
daurnimator, yep that's the main reason it's not covered by CI yet
<daurnimator>
andrewrk: heh.... just found another usage of std.Buffer you put in. Why do you keep reaching for it?
<metaleap>
daurnimator: would suggest a brute-force rename of "Buffer" in std, and once that's merged then for all users the habit will fade / be revisited on a per-case basis
<andrewrk>
daurnimator, you seem to think std.Buffer is deprecated? why?
<daurnimator>
andrewrk: and #4405 is proof of those claims....
<andrewrk>
I don't think this is going to get merged as is
<daurnimator>
Most of that PR is swapping out std.Buffer for std.ArrayList(u8)
<daurnimator>
there was no reason for std.Buffer with it's "keep a null bytes appended" behaviour to be used in those locations
<andrewrk>
I see
<andrewrk>
I'll take a careful look
<andrewrk>
right now though - bedtime. good night. sorry I keep catching you with no brain power left
<daurnimator>
andrewrk: these are my prime hacking hours :P
<LakeByTheWoods>
How in love is everyone with the the comma getting un-indented after a multiline string literal in array initialisers and argument lists? It seems odd to me.
<LakeByTheWoods>
eg:
<LakeByTheWoods>
const a = [][]const u8{ \\aaa, \\bbb};
<LakeByTheWoods>
Well that was a fail
<daurnimator>
LakeByTheWoods: where else would it go?
<LakeByTheWoods>
const a = [][]const u8{ \\aaa, \\bbb};```
<LakeByTheWoods>
```const a = [][]const u8{ \\aaa, \\bbb};```
<daurnimator>
LakeByTheWoods: use a pastebin to demonstrate.
<LakeByTheWoods>
(actually that example is wrong, shouldn't have a trailing comma)
jjido has joined #zig
jjido has quit [Client Quit]
jjido has joined #zig
ur5us has quit [Ping timeout: 256 seconds]
_Vi has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
alexnask has joined #zig
LakeByTheWoods has quit [Remote host closed the connection]
jjido has joined #zig
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
mahmudov has quit [Ping timeout: 255 seconds]
dddddd has quit [Ping timeout: 260 seconds]
APic has quit [Ping timeout: 268 seconds]
frmdstryr has quit [Ping timeout: 258 seconds]
itszath has joined #zig
<itszath>
hey, I'm really new to zig though I have known about the project for quite a while; I was wondering if somebody could point me towards an idiomatic way of adding more information to an error
<itszath>
e.g. including column/row with an error in a tokenizer
<itszath>
thanks, I'm gonna go with the modified second workaround with the struct field then
waleee-cl has joined #zig
<metaleap>
itszath: can also sniff in lib/std/zig/ast.zig --- in this case, the Ast struct keeps a list of error details and parse() only really returns error.OutOfMemory or none at all (as of today). in a scenario of errors the ast's root is un-set and the errors.len != 0. easy to work with and every sort of error has as much detail as it needs
<metaleap>
plus in general you might wanna differentiate between "domain errors" (high level) and "operational errors" (low level / kernel / syscall or bad inputs) anyway, with try/catch/error-unions being a great fit for the latter
dwdv has joined #zig
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
dimenus has joined #zig
APic has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dimenus has quit [Remote host closed the connection]
mahmudov has joined #zig
jjido has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
redj has quit [Read error: Connection reset by peer]
redj has joined #zig
dddddd has joined #zig
jessermeyer has joined #zig
<jessermeyer>
What's the cast I should use when I'm passing a string to a function expecting a c-string? pointer type child '*const [27:0]u8' cannot cast into pointer type child '[*c]const u8'
<jessermeyer>
var validation_layer = "VK_LAYER_KHRONOS_validation";
<TheLemonMan>
jessermeyer, you're missing the outer `const`, try making validation_layer a `const`
<mq32>
i think there is just a whole pointer indirection missing
<mq32>
"&validation_layer" is a pointer to *u8, not to **u8
<jessermeyer>
I thought that was a **u8
alexnask has quit [Ping timeout: 240 seconds]
<jessermeyer>
Since the zig string is a pointer to an array.
<jessermeyer>
(Right?)
<jessermeyer>
Ah, the constness hits me again.
<TheLemonMan>
yep, literals are pointer to arrays
<jessermeyer>
I've been avoiding const since those tend to disappear from the debugger's view.
<TheLemonMan>
the error message is correct but could be improved to point out what's the difference between the two types
<jessermeyer>
But that didn't appear to fix the issue actually...
<jessermeyer>
\win32_tbd.zig:101:9: error: expected type '[*c]const [*c]const u8', found '*const *const [27:0]u8' const validation_layer = "VK_LAYER_KHRONOS_validation";
<jessermeyer>
In terms of implicit casting expectations..
<jessermeyer>
Is that a reportable issue?
alexnask_ is now known as alexnask
<TheLemonMan>
bleh, spent an awful lot of time hunting down a nasty bug in a linker script
<TheLemonMan>
and it turns out it was lld that was royally fucking up some address computation
<jessermeyer>
Poor linker =(
<TheLemonMan>
yeah, linkers are hard
<TheLemonMan>
the implicit casting only acts on a single layer
<TheLemonMan>
and so it tries to convert [*c] to * but fails miserably because the child types are not compatible
<jessermeyer>
Should it be opened up to N layers?
<jessermeyer>
As a proposal?
<TheLemonMan>
*shrug* don't know if that's supposed to work or not
<jessermeyer>
Why are the child types not compatible? Doesn't [*c]const u8 map to *const[N:0]u8 semantics (but not the other way around)?
o_O has joined #zig
o_O is now known as Guest15436
<TheLemonMan>
nah, there's an implicit cast from *[N]T to [*c]T
metaleap has quit [Ping timeout: 258 seconds]
<jessermeyer>
I'll open an issue for wider discussion, if not for visibility for future programmers. A pointer to an array of strings is not an unusual interface parameter for C libraries, so at least people who hit this can search for it.
klltkr has joined #zig
keithdc has joined #zig
_Vi has quit [Ping timeout: 272 seconds]
Guest15436 has quit [Quit: Leaving]
ashn has joined #zig
metaleap has joined #zig
recombinant has joined #zig
_Vi has joined #zig
<jessermeyer>
var extension_names_to_enable = {"VK_KHR_win32_surface", "VK_KHR_surface"};
<jessermeyer>
Is there a reason that doesn't just work?
<TheLemonMan>
you're missing the leading dot?
<jessermeyer>
Well I don't know if anon-structs is how I want to, in general, represent an array of comptime known strings.
<jessermeyer>
And in this situation that doesn't seem appropriate. All I want is to pass Vulkan the address to an array of strings.
<TheLemonMan>
then you're missing the leading type
<jessermeyer>
But the string lengths here are different from each other, and if I tell Zig to infer it, it doesn't want to.
<metaleap>
[2]Str{"one","two"} where Str = []const u8
<metaleap>
and _ for auto-length should work, whats the err msg?
<alexnask>
[_][]const u8 { ... } should work
<jessermeyer>
Let me double check I didn't typo.
<jessermeyer>
Yeah I typo'd and misread orientation of the array syntax from the documentation.
<jessermeyer>
var extension_names_to_enable = [2][:0]const u8{"VK_KHR_win32_surface", "VK_KHR_surface"}; works.
<alexnask>
Cheers
<jessermeyer>
Thanks for spotting my mistakes!
<jessermeyer>
Is there a reason why the type [2][:0]const u8 couldn't have been inferred by the compiler from the context?
<jessermeyer>
I understand if the user doesn't _want_ null-termination then that's one consideration.
<TheLemonMan>
an anonymous tuple may work better there if you don't want to waste too much energy typing
<jessermeyer>
How do I ptrCast the tuple to a pointer to an array of strings?
<jessermeyer>
The compiler gave me some caution with note: '*struct:104:42' has no in-memory bits
<TheLemonMan>
you write `var foo: T = .{ ... }` ?
<fengb>
Ugh that annoying thing
<fengb>
You can’t make a runtime tuple with literals since the compiler turns them into comptime fields
<jessermeyer>
Ok, good to know that would work, but it's much too much baggage for this straight forward problem.
<metaleap>
jessermeyer: each string literal gets "inferred" to a fixed-len+1-sized u8 array, so an array of string literals at this point doesnt get "inferred" (more like coerced-inferred) into an array-of-[*:0]const u8
<metaleap>
(about your question why it couldnt infer)
ashn has left #zig [#zig]
<jessermeyer>
Yeah, this may be related to the child-type inference issue I posted about earlier today.
<metaleap>
although i think there's no inferring array types from anon-literals *at all* at this point, i always write them out. but in the string-case, it'd be even trickier
<jessermeyer>
In general I do not expect syntax discontinuities going from a single element type to an array of that type like this.
<alexnask>
fengb This bug is probably gone with PR #4573, I will try it and add it as a testcase
<metaleap>
jessermeyer am actually quite content with no inference of slice/arr types. currently i can scan code and immediately tell just from anon-ness that it's a struct-or-union.
frmdstryr has joined #zig
<jessermeyer>
I agree that too much inference is a poison.
<metaleap>
and [x]X{..} is easily recognizable as slice/arr initializer. no "manual type-resolving via looking at result location" required :D
<jessermeyer>
In this case, the [n]X is just redundant and obvious, and I imagine that follows for the common case.
<fengb>
Not quite. It’s ambiguous if it’s an array of slices or array of pointers
<jessermeyer>
I wouldn't call that a common case.
<fengb>
In this case I mean
<jessermeyer>
And an instance of inference poison.
<jessermeyer>
Could you elaborate? This case is just an array of strings.
<fengb>
Literals “foo” are array pointers that can either be coerced into `[]u8` slices or `[*]u8` multi pointers
<fengb>
In most Zig code, I’d expect slices, but then you can’t pass that to C
<alexnask>
I don't think there is any place in the compiler atm that uses the types of multiple expressiosn to infer a common type (not an argument either way, just an observation)
<TheLemonMan>
not really, peer result location is used for eg. if/switch expressions
<alexnask>
Ah, good point
<alexnask>
I knew I'd probably missed smth
<jessermeyer>
I see, array of strings -> array of pointers.
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
<jessermeyer>
Yeah, almost every 'wtf' I've encountered in Zig so far as been at the intersection of Zig and C.
<mq32>
hm
<mq32>
how can i add a package import for a package import?
<mq32>
just declaring two packages with the same name does not work
<mq32>
is --pkg-begin recursive?
<frmdstryr>
yes
<frmdstryr>
nest them
<mq32>
oh
<mq32>
looks like zig build does not support that yet?
<alexnask>
I'm hitting a really weird bug, using std.testing.allocator in a tuple initializer crashes on windows (access violation in copy_const_val when copying the allocator field) and works on linux
<mq32>
ah so addPackagePath does not expose that yet