ChanServ changed the topic of #zig to: zig programming language | https://ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
Aransentin has quit [Remote host closed the connection]
ur5us has quit [Ping timeout: 260 seconds]
<Snektron> VLAs are evil
ur5us has joined #zig
guan has quit [Ping timeout: 250 seconds]
guan has joined #zig
swoogan has joined #zig
lunamn has joined #zig
lunamn_ has quit [Ping timeout: 260 seconds]
lunamn has quit [Ping timeout: 240 seconds]
lunamn has joined #zig
lunamn has quit [Ping timeout: 268 seconds]
lunamn has joined #zig
<daurnimator> Snektron: howso? I need one for e.g. my allocator
Aransentin has joined #zig
<daurnimator> andrewrk: wasn't https://github.com/ziglang/zig/pull/3683 waiting for llvm10?
THFKA4 has joined #zig
lunamn has quit [Ping timeout: 260 seconds]
lunamn has joined #zig
lunamn has quit [Ping timeout: 240 seconds]
lunamn has joined #zig
dddddd has quit [Ping timeout: 260 seconds]
<andrewrk> daurnimator, nah, we have zig_llvm.cpp/zig_llvm.h so that we don't have to rely on the llvm-c API wrapper
<andrewrk> the official llvm-c API wrapper doesn't keep up with the c++ API fast enough
<andrewrk> this is the main reason zig is written in C++
<andrewrk> s/zig/stage1/
<daurnimator> > comptime parameters are in scope for the calling convention expression.
<daurnimator> makes sense
<daurnimator> though I wish it didn't :P
<daurnimator> sort of makes me want to have the `->` symbol back
<andrewrk> yeah it doesn't look amazing syntactically
WendigoJaeger has quit [Quit: Connection closed for inactivity]
BaroqueLarouche has quit [Quit: Connection closed for inactivity]
<daurnimator> as a hack.... `pub usingnamespace if (builtin.os == .windows) struct { extern stdcallcc fn debugCallback(....... ) } else struct { stdcallcc fn debugCallback(....... ) };`
<daurnimator> or whatever I meant to write :P
<daurnimator> but yeah I know why we need it
<daurnimator> andrewrk: what's next on your priority list?
<andrewrk> 1. internal ir.cpp stuff to solve some technical debt with regards to comptime variables
<andrewrk> 2. minimal viable implementation of #2765. possibly with #3804 for safety
<andrewrk> 3. rewrite std.fmt.format to not use a function pointer or error set. make it return an iterator of `[]const u8` items
<andrewrk> 4. integrate std.os.write with async I/O
<andrewrk> 5. improve robustness of async I/O in std
<andrewrk> and then there's a fork in the path, either networking/package manager, or progress on self-hosted
<andrewrk> each of these numbered items is a prerequisite for the next one
<daurnimator> thanks
<hryx> sup andrewrk ! long time no see
<andrewrk> howdy hryx! how've you been?
<daurnimator> FWIW I'm hoping to remove blockers from writing a good linux kernel module (would be great to have ready for conference in <2 weeks)
<hryx> I've missed working on zig super bad, so time to get back into it :)
<andrewrk> I can try to help with that. I see https://github.com/ziglang/zig/projects/5
<andrewrk> daurnimator, ah, looking at these blockers, I was planning on trying to get #3973 merged tomorrow
<andrewrk> hryx, did you see that Vexu finished self-hosted translate-c? can't wait to delete all this c++ code
<hryx> Yeah, that work was so badass
<daurnimator> andrewrk: yeah its probably worth merging #3973 sooner rather than later and fixing regressions later
<hryx> vexu is on fire
<andrewrk> daurnimator, that's a good point, but I do want to get the CI green
<andrewrk> now that I have access to all my computers, it should be easy :)
<daurnimator> true
<andrewrk> daurnimator, bitfields in translate-c in under two weeks is a stretch. can you do without?
<daurnimator> set vexu on it ;)
<daurnimator> andrewrk: not without some way to override bits of a @cImport
<andrewrk> I'll see what I can do
<andrewrk> I do want your conference to go well
<daurnimator> I don't have a formal talk planned; so it's not major
<daurnimator> Was just going to slot in for a lightning talk
<daurnimator> But also probably keep talking about zig to kernel developers; make sure we're on their radar for when the language is more stable
<hryx> Finally caught up on months of GitHub notifications and thinking of starting #1717 -- andrewrk any reason I shouldn't start that yet?
<hryx> could also warm up with some bugs
<hryx> daurnimator: oh neat, where/when are you presenting?
WendigoJaeger has joined #zig
BaroqueLarouche has joined #zig
<daurnimator> hryx: https://linux.conf.au/
<andrewrk> hryx, prereq of #1717 is to re-evaluate https://github.com/ziglang/zig/issues/181 which I just re-opened
<andrewrk> I'll try to speed that re-evaluation along to get an accepted/rejected status on #181 to unblock you for #1717
<hryx> gotcha, I'll read that thread so I understand it
<hryx> I was catching up on (among everything else) the comments on 1717, mainly around `extern`. I think it's totally solveable
<daurnimator> isn't extern part of the calling convention?
<hryx> after digesting it, it looks like extern means a few things, one of which is a calling convention
<andrewrk> daurnimator, not after #3977. I have a review about to press send with some more details
<hryx> it also means a data layout for struct/enum/union, and it can also mean that a value is defined externally (other object)
<andrewrk> `extern` is about to stop being related to calling conventions
<hryx> oh! sweet
<daurnimator> hryx: right. its overloaded :(
<andrewrk> I do think there are a few prereqs before it makes sense to start on #1717
<andrewrk> I'll try to get those out of your way
<daurnimator> I'd love to see #1669 accepted/rejected
<hryx> yeah, looks like there are some things that are changing. I am totally down to hold off on 1717 and help in some other way
<daurnimator> hryx: things are always changing round here ;)
<hryx> true! it's for the greater good of course :)
adamkowalski has joined #zig
<hryx> daurnimator: I was eyeballing that one super hard recently. I think it is important to figure out the "interface/trait pattern" thing since it might affect the "pinned memory" proposals et. al
<daurnimator> hryx: did you see my mixin proposal?
<hryx> afraid I can't recall it - link?
<daurnimator> hryx: https://github.com/ziglang/zig/pull/3785 was meant to be phase 1...
<andrewrk> re: 1669 - it looks like a very popular proposal, but I have a hard time understanding the value proposition. is it different than `comptime assert(...);` in the first line of the function?
<andrewrk> because it is a user definable function, the compiler has to treat it as a black box; it wouldn't solve the error sets problem, for example
<andrewrk> I have a list of problems that the interface language feature should address (error sets being one of them). I'll make this list explicitly visible on #130 so that people can measure their proposals against it
<daurnimator> andrewrk: I've linked to 1669 from a few places where I felt it would be cleaner
<andrewrk> hryx, what kinds of things are you interested? another project which could be quite interesting would be the self-hosted assembler. it's a large project, but self-contained, and necessary for inline assembly to work for the non-llvm backend
<hryx> Ooh, that does sound fun. I should admit that I have barely touched anything like that, but of course down to learn
<andrewrk> there's a bunch of std lib legwork that has to be done for package manager - supporting various compression formats, and networking
<hryx> is that andrewrk/zasm?
<daurnimator> Re; 1717 "Roughly speaking, assigning a function to a const would equate to existing behavior, while assigning to a var would equate to assigning a function pointer." -> shouldn't they *all* be function pointers? and have it transparent to call a function pointer?
<andrewrk> yes
<hryx> dope, I'll check out zasm for an idea if I could potentially handle something like that
<andrewrk> daurnimator, yes all functions are function pointers, and it matters whether the value is comptime known
<andrewrk> that's status quo and will remain true after the proposal is implemented
<hryx> daurnimator: Oh my wording was weird. I meant that it's the difference between today's `fn f() void {...}` and `var f = someFunction`
<andrewrk> hryx, the project is barely started, it's a minimum viable thingie to pass the "hello world" test
adamkowalski has quit [Ping timeout: 240 seconds]
<andrewrk> part of the goal is to build a multi-architecture database of instructions, both for inline assembly to work, and for instruction selection in the non-llvm backend of the self-hosted compiler. whether that database is a .zig file, another text file format, binary format, or something else entirely is up for consideration. that project is a bit greenfield; you'd sort of have to become a pioneer
<andrewrk> good if you like freedom and want to explore, bad if you want something more focused and with a clear direction
<hryx> andrewrk: this looks super fun - let me take a couple days to mess around with it and see if I can click with it
<hryx> Be warned I will probably have a lot of questions, heh
<hryx> If it doesn't work out I can always pick up something in another direction
<andrewrk> I live streamed some of the coding on it
<andrewrk> the readme has a roadmap section with some ideas of directions to explore
<hryx> ah great, I almost forgot to watch the live streams I'd missed - I'll check'm
<andrewrk> hryx, one more little thing, I did a one day hack demo thing with a friend, and we got the symbol table working in an ELF file, if you want to see some very messy code that adds that functionality: https://github.com/MasonRemaley/calc64
<andrewrk> the symbol table makes tools such as gdb, objdump, and readelf work
adamkowalski has joined #zig
ur5us has quit [Ping timeout: 260 seconds]
<andrewrk> part of that project is PortableExecutable format as well
<hryx> all great material! I'm gonna dive into all this stuff tonight
swoogan has left #zig ["Konversation terminated!"]
adamkowalski has quit [Ping timeout: 258 seconds]
<daurnimator> that reminds me... I haven't had the zig compiler give me a traceback in months....
<daurnimator> (which is to say; it's always full of ??????)
<daurnimator> yet they work fine in gdb
adamkowalski has joined #zig
adamkowalski has quit [Ping timeout: 258 seconds]
_whitelogger has joined #zig
adamkowalski has joined #zig
ur5us has joined #zig
adamkowalski has quit [Ping timeout: 268 seconds]
ur5us has quit [Remote host closed the connection]
ur5us has joined #zig
WendigoJaeger has quit []
BaroqueLarouche has quit []
ur5us has quit [Ping timeout: 260 seconds]
adamkowalski has joined #zig
adamkowalski has quit [Ping timeout: 268 seconds]
adamkowalski has joined #zig
adamkowalski has quit [Ping timeout: 265 seconds]
lunamn has quit [Ping timeout: 260 seconds]
lunamn has joined #zig
<wilsonk> was @noInlineCall removed from the language?
return0e has quit [Read error: Connection reset by peer]
return0e has joined #zig
<wilsonk> oh, got it...changed to @call with options
darithorn has quit [Remote host closed the connection]
henbr has joined #zig
daex has quit [Ping timeout: 268 seconds]
_whitelogger has joined #zig
daex_ has joined #zig
daex has quit [Ping timeout: 258 seconds]
dddddd has joined #zig
mforney has quit [Quit: quit]
mforney has joined #zig
schme245 has joined #zig
<schme245> if I have a function that contains an if statement that depends on a parameter, and I call that with a value known at compile time, will it get inlined?
<schme245> or must the parameter be marked as `comptime` for that to happen?
<mq32> schme245, i think that depends on your optimization level
<mikdusan> also (i haven't used it myself) keyword can be used to decorate a function: `inline fn foo() void {}`, and at callsite builtin `@call()` can be used with .inline
<mikdusan> (well .inline is wrong literal, but see docs for full list)
_whitelogger has joined #zig
frmdstryr has joined #zig
BaroqueLarouche has joined #zig
WendigoJaeger has joined #zig
schme245 has quit [Remote host closed the connection]
adamkowalski has joined #zig
schme245 has joined #zig
schme245 has quit [Remote host closed the connection]
adamkowalski has quit [Ping timeout: 265 seconds]
BaroqueLarouche has quit [Quit: Connection closed for inactivity]
WendigoJaeger has quit [Quit: Connection closed for inactivity]
adamkowalski has joined #zig
marmotini_ has joined #zig
adamkowalski has quit [Ping timeout: 265 seconds]
mahmudov has joined #zig
mahmudov has quit [Remote host closed the connection]
mahmudov has joined #zig
swoogan has joined #zig
adamkowalski has joined #zig
marmotini_ has quit [Remote host closed the connection]
marmotini_ has joined #zig
marmotini_ has quit [Ping timeout: 258 seconds]
adamkowalski has quit [Quit: Lost terminal]
aperezdc has joined #zig
f3n has joined #zig
lunamn_ has joined #zig
lunamn has quit [Ping timeout: 265 seconds]
f3n has quit [Quit: WeeChat 2.6]
adamkowalski has joined #zig
diltsman has joined #zig
<diltsman> Has anyone else tried to compile with WinMain or wWinMain for the main function?
<diltsman> I had it working a while ago, but the latest compilers give this error: error: root source file has no member called 'main'
<diltsman> switch (@typeInfo(@TypeOf(root.main).ReturnType)) {
schme245 has joined #zig
<andrewrk> diltsman, make it pub. it'll be a bit awkward because it will be both export and pub
<andrewrk> the logic for entry points is now entirely in userland, no longer hard-coded into the compiler
schme245 has quit [Remote host closed the connection]
<swoogan> would it be possible for the compiler to add a newline before listing errors?
<swoogan> "Semantic Analysis [739/751] /snap/zig/1..." this makes it hard to regex the errors out of the output
<andrewrk> swoogan, yes
schme245 has joined #zig
<diltsman> andrewrk That worked. Thanks.
schme245 has quit []
schme245 has joined #zig
lunamn_ has quit [Ping timeout: 268 seconds]
lunamn has joined #zig
mahmudov has quit [Remote host closed the connection]
mahmudov has joined #zig
mahmudov has quit [Remote host closed the connection]
mahmudov has joined #zig
mahmudov has quit [Remote host closed the connection]
mahmudov has joined #zig
<diltsman> Is there a way to cast a function pointer to a function pointer with stdcallcc to one with extern instead? I believe that Zig is changing the calling convention of the function pointer, and I want to experiment before I file a bug.
<andrewrk> diltsman, @ptrCast
<wilsonk> hey andrewrk or Sahnvour_: with this diff (https://pastebin.com/gJYq03FM) for https://github.com/Sahnvour/zig-benchmark/bench.zig, I am getting an error that I don't know how to fix when trying to test 'benchmark'. Error: 'bench.zig:112:45: error: unable to evaluate constant expression' Any ideas?
<wilsonk> @call( .{ .modifier = .always_inline }, f, .{&ctx}); the caret points at 'f'
<andrewrk> I'm getting 404 for the second link
<andrewrk> oh, found it though
<andrewrk> did you mean to go from "never inline" to "always inline" ?
<wilsonk> oh, woops...nope
<andrewrk> when you perform an inline call, it requires the function to be compile-time known
<andrewrk> which makes sense if you think about it
<wilsonk> changed to never, but still the same error
<wilsonk> right, I think I get the comptile-time known part, but I am just curious why it worked with @noInlineCall but doesn't work with @call
ur5us has joined #zig
<wilsonk> perhaps a comptime check for @call is more strict than it was for @noInlineCall?
<andrewrk> wilsonk, hmm, looks like zig is unconditionally requiring comptime-known function there, but that's incorrect. it should be only doing that for always_inline and a couple others
<andrewrk> looks like a pretty easy fix too. would you mind filing an issue?
<wilsonk> Ok, I will get on it
<andrewrk> or rather than easy, I should, say, a contributor friendly fix
adamkowalski has quit [Read error: Connection reset by peer]
<wilsonk> issue filed
<andrewrk> thanks!
adamkowalski has joined #zig
<Snektron> Happy new year
<adamkowalski> Happy new year!
<hryx> happy new year! (for you. I've got another 9 hours of 2019)
<wilsonk> Happy New Year to those that have passed into the new year already :)
<fengb> Happy perfect vision
adamkowalski has quit [Ping timeout: 268 seconds]
marmotini_ has joined #zig
marmotini_ has quit [Ping timeout: 260 seconds]
return0e has quit [Ping timeout: 258 seconds]
return0e has joined #zig
adamkowalski has joined #zig
adamkowalski has quit [Ping timeout: 258 seconds]