ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
fsateler_ has quit [Quit: ZNC 1.7.1+deb2 - https://znc.in]
<andrewrk>
that thing that happened on stream where llvm8 branch didn't work, is an LLD bug. a regression since 7.0.0
<andrewrk>
I didn't find it until now because we didn't have thread local storage until 3 days ago :)
<emekankurumeh[m]>
should the logic for #1911 go in `ir_render_instruction` or in `ir_render_fence`, `ir_render_atomic_rmw`, and `ir_render_atomic_load`?
<daurnimator>
andrewrk: computed goto is mostly useful in bytecode vms. Until someone e.g. ports lua to zig, then I don't think you'll find a need for it
<emekankurumeh[m]>
does anything depend on the order of the fields of `IrInstructionAtomicLoad`?
<daurnimator>
andrewrk: I'm watching your screen. I noticed in your strace of your threaded program that you called exit() rather than exit_group(). intentional?
<emekankurumeh[m]>
is andrewrk streaming right now?
<daurnimator>
emekankurumeh[m]: no. a couple of hours ago.
<andrewrk>
emekankurumeh[m], in the latter 3. now that you ask the question though, the other possibility is to put the logic in the ir_analyze_* functions
<andrewrk>
I think putting the logic in codegen.cpp as you suggested is good
<andrewrk>
daurnimator, I never sat down and solved the exit vs exit_group problem. we had exit in there since the beginning and then added threads and haven't changed it yet
<daurnimator>
andrewrk: I'm not sure what happens exactly.... but I didn't see an exit() to match the thread.wait() calls: are threads cleaned up at all? (do they need to be on linux?)
<andrewrk>
daurnimator, I didn't pass -f to strace so you don't see the syscalls from the threads
<andrewrk>
I didn't realize that until just now
<daurnimator>
oh. I thought -f was only for 'fork' following
<andrewrk>
the difference between a subprocess and thread on linux is subtle
<daurnimator>
indeed.
<daurnimator>
really the only difference is "do they share a pid"
<andrewrk>
daurnimator, here's the same program, but strace -f output: https://clbin.com/BmuvA
<andrewrk>
it looks noiser but the only extra syscalls were the 2 exits(0)'s that happened from the threads
<daurnimator>
andrewrk: okay good :)
<andrewrk>
I'll be back in a bit
<daurnimator>
so you may need to answer the question: when main() ends and threads are still running...... do you want to let the threads keep running? or do you want to end the process?
<daurnimator>
and I think we currently have a *different* answer to that on linux vs windows
darithorn has joined #zig
kristate has joined #zig
hio has quit [Quit: Connection closed for inactivity]
<MajorLag>
andrewrk, I think explicit tail call might give us a route to computed goto anyway.
<andrewrk>
MajorLag, oh yeah, I vaguely remember discussing this with you
<emekankurumeh[m]>
andrewrk: how would i emit the binary ops for a non-atomic version of `@atomicRmw` here?
<andrewrk>
note that all the arithmetic will be the wrapping versions
<emekankurumeh[m]>
will the shifts be lossy or exact?
<andrewrk>
I don't see shift in there
<emekankurumeh[m]>
sorry i was looking at the wrong function.
<andrewrk>
oh, neat - llvm 8 (or is it trunk?) added float add and float subtract to the atomic rmw operations
<emekankurumeh[m]>
i was just about to ask about that.
scientes has joined #zig
<emekankurumeh[m]>
would there be runtime safety for the non-atomic versions?
<andrewrk>
which operations?
<emekankurumeh[m]>
nvm, you said it would be wrapping
<daurnimator>
andrewrk: > 3\. However language support for valgrind will probably emit inline assembly directly, without going through the trouble of a C ABI or parsing .zig code
<daurnimator>
andrewrk: ^ what do you mean by that
<andrewrk>
emekankurumeh[m], I know I tagged #1911 with `contributor-friendly` - but now I'm reconsidering if it is a good idea - I would recommend to hold off until I collect more data on whether there is a use case for @fence, @atomicLoad, @atomicRmw even when it is guaranteed there will be no threads
<andrewrk>
emekankurumeh[m], apologies for misleading you
<andrewrk>
daurnimator, I mean that in codegen.cpp, we will build a string and use LLVMGetInlineAsm for the valgrind client requests, rather than std/special/valgrind.zig and trying to hook into it
<daurnimator>
andrewrk: is it worth just ignoring that until stage 2/3?
<andrewrk>
my personal priority would be to work on finalizing and stabilizing the language before this kind of ergonomic polishing
<daurnimator>
agreed
<daurnimator>
in the mean time I think my PR provides "enough"
<andrewrk>
of course, I want to enable contributors to work on whatever you want to work on :)
<daurnimator>
andrewrk: re: testing done. I confirmed that runningOnValgrind() works in every situation, and then checked that the others do vaguely the right thing as I wrote them
<daurnimator>
no in-depth testing.
<andrewrk>
interesting. I'm surprised that inline assembly works, given it's supposed to be a compile error to pass a slice
noonien has quit [Quit: Connection closed for inactivity]
<andrewrk>
and the equivalent 64 bit version
<andrewrk>
I was also confused by makeMemNoAccess in FixedBufferAllocator.init
<andrewrk>
because it never marks the memory as accessible upon allocation
<daurnimator>
andrewrk: it does in alloc()
<andrewrk>
oh I see
<daurnimator>
i.e. the memory you pass to FixedBufferAllocator is initially marked as "not allowed to access". until you alloc out of it. and then only the part returned by alloc is marked as usable.
<andrewrk>
I think that's not quite right either- you would make the memory accessible before it gets set to undefined (which in debug mode sets to 0xaa's) and then after that tell valgrind it's undefined
<andrewrk>
anyway this is a great proof of concept. really nice to see valgrind's API will give us good tooling support
<andrewrk>
...riiiight after we fix their bug for them :)
<daurnimator>
andrewrk: it *is* accessible originally when it e.g. comes from the stack in main()
<andrewrk>
understood - I'm talking about the code in std.mem.Allocator.alignedAlloc now. I think it should be 1. mark accessible to valgrind. 2. the for loop setting to undefined 3. mark undefined to valgrind
<andrewrk>
this is how we achieve undefined memory set to 0xaa and also valgrind knows it's undefined
<andrewrk>
note that the memory when returned from an allocation is undefined
<daurnimator>
undefined in valgrind means "the address is valid"
<daurnimator>
not "the contents is valid"
<daurnimator>
--> valgrind doesn't let you *write* to undefined memory
<andrewrk>
you mean it doesn't let you write to *unaddressable* memory?
<daurnimator>
ah yeah
<daurnimator>
but yeah... turning from undefined->defined on write isn't possible from zig itself. and possibly too expensive even in the general case?
<daurnimator>
wouldn't it mean that *every* write to memory would be post-fixed with "and tell valgrind that region defined"
<andrewrk>
My claim is that is what valgrind does automatically for every write to memory
<andrewrk>
Which is why zig initializing undefined memory to 0xaa in debug mode actually has a downside
<andrewrk>
But that downside is fixed with a client request to valgrind after writing 0xaa's
<andrewrk>
Plus it actually makes setting a variable/field to undefined a helpful debugging technique that isn't available in C
<daurnimator>
So I'm confused: what do you want to do in the short term?
<daurnimator>
I think we need the valgrind client requests api availble in the std library in any case.
<andrewrk>
Valgrind client requests API in the std lib is great, agreed on that
<daurnimator>
Any blockers on merging that now?
jevinskie has joined #zig
<andrewrk>
A small, meaningful short term improvement would be as simple as, inline assembly after that memset in codegen.cpp that I linked above, with the client request marking the memory to undefined
<andrewrk>
That can exist independent of the client request API in the std lib
<andrewrk>
Blockers on merging: it's not semantically correct as discussed above, the inline assembly needs auditing (I can do that), and the CI tests have a failure that looks legit
<andrewrk>
Whether to actually use it in the standard library... I think we can try it out. I'd like to have an eventual goal of allocators working at comptime though, so that's something to consider
<daurnimator>
The bits in the allocator could be left out for now
<andrewrk>
Also, thanks for doing this! This is a really cool contribution
<daurnimator>
there's a few other places in the std library that should gain calls. e.g. thread creation should use the "mark as stack" api calls
<andrewrk>
Ooh nice, what does valgrind do with that info?
<daurnimator>
I think it only allows you to read/write below the stack pointer
<andrewrk>
That sounds useful
<daurnimator>
also for things that come from the stack, it notes which function they belong to
<daurnimator>
oh..... > Warning: Unfortunately, this client request is unreliable and best avoided.
<daurnimator>
so, uh, maybe not.
<daurnimator>
andrewrk: what was this in reference to? > ...riiiight after we fix their bug for them :)
<andrewrk>
"really nice to see valgrind's API will give us good tooling support...riiiight after we fix their bug for them :)" -> https://github.com/ziglang/zig/issues/896
<andrewrk>
it's reproducible using only clang and LLD
<scientes>
andrewrk, you should come to Costa Rica so you can make that grant money last longer
<daurnimator>
oh you mean the ro-segment thing. gotcha
<andrewrk>
scientes, yeah. my significant other needs to be in NYC for school/career stuff for now
scientes has quit [Remote host closed the connection]
scientes has joined #zig
scientes has quit [Remote host closed the connection]
marmotini_ has joined #zig
darithorn has quit [Remote host closed the connection]
marmotini_ has quit [Ping timeout: 250 seconds]
schme245 has joined #zig
marmotini_ has joined #zig
schme245 has quit [Remote host closed the connection]
<shachaf>
I'm pretty sure this isn't appropriate for Zig, but I wonder whether the suggestion of using tuples for all function arguments has been brought up.
<shachaf>
I.e. making all functions single-argument, where the argument can be a tuple, and the calling convention for a tuple matches the usual multi-argument calling convention.
<shachaf>
I was thinking about that feature for a different language.
<daurnimator>
shachaf: aside from a conceptual change.... what would that actually change?
<shachaf>
Depending on the tuple/struct literal syntax, it could allow for nicer named arguments, default arguments, etc.
<shachaf>
Well, that's not much of a reason on its own (?), it's just the issue I was reading when I came across the tuple thing
<shachaf>
I should probably read entire threads rather than a few scattered comments.
schme245 has joined #zig
schme245 has quit [Remote host closed the connection]
schme245 has joined #zig
schme245 has quit [Remote host closed the connection]
schme245 has joined #zig
Zaab1t has joined #zig
schme245 has quit [Ping timeout: 246 seconds]
schme245 has joined #zig
schme245 has quit [Ping timeout: 268 seconds]
schme245 has joined #zig
schme245 has quit [Remote host closed the connection]
schme245 has joined #zig
schme245 has quit [Remote host closed the connection]
schme245 has joined #zig
forgot-password has joined #zig
schme245 has quit [Ping timeout: 250 seconds]
<forgot-password>
Is it intentational that the compiler can't figure out that a branch with @compileError doesn't return? I manually have to add a `unreachable` to stop it from complaining about attempting to return `void`
schme245 has joined #zig
forgot-password has quit [Read error: Connection reset by peer]
forgot-password has joined #zig
marmotini_ has quit [Ping timeout: 250 seconds]
steveno_ has joined #zig
Hejsil has joined #zig
<Hejsil>
Uuh, just pushed some code that allows me to disassemble the custom 'byte code' used in gen3 pokemon games, using comptime reflection
<Hejsil>
It's probably more optimal than no syntax highlighting :)
<andrewrk>
Hejsil, wait so you're parsing that entire file you linked above at compile-time?
<Hejsil>
Ooh no
<Hejsil>
Not exactly
<Hejsil>
I generated a struct from that file, and uses that + comptime reflection to decode
<Hejsil>
The struct i generated using some ugly shell magic
<andrewrk>
ahhh cool
darithorn has joined #zig
<Hejsil>
So when I decode a slice of bytes, i do @bytesToSlice(Command, mem)[0], calculate the encode length (comptime reflection), then do mem = mem[command_len..]; repeat
<Hejsil>
Maybe it would be cool to parse the asm macros at comptime
<Hejsil>
But it's not really worth it
<andrewrk>
not yet at least. the compiler needs to be faster, more memory efficient, more incremental, before that becomes worth it
<andrewrk>
we'll get there eventually
<Hejsil>
Well, even soo. Doing a hacky shell script got me 90% of the way, and it's not like it'll ever need to change
<Hejsil>
hmm. Now that I have the power to decode the scripts, maybe I should make all NPCs only ever wark down
<Hejsil>
walk*
<andrewrk>
hahaha
schme245 has quit [Remote host closed the connection]
Ichorio has joined #zig
kristate has quit [Remote host closed the connection]
schme245 has joined #zig
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Akuli>
how do i convert std.ArrayList(T) to []T, so that i can free it later using the allocator that was passed to the arraylist?
<andrewrk>
use the deinit() method
<Akuli>
let me tell more about the problem
<andrewrk>
you would use toSlice() to get a []T, or you can use toOwnedSlice() to get a []T that you can free with the allocator
<Akuli>
i have a function, and i believe the correct return type for it is []T because the result list's length should never be changed after calling the function
<Akuli>
but i want to use an arraylist in the function to make creating the result array easier
steveno has quit [Remote host closed the connection]
<Akuli>
what does this code do? while(true) { switch(1){ 1 => break; else => unreachable; } }
<Akuli>
does the break end the while loop? or does it do something to the switch like it would in c? is it guaranteed that the behaviour won't change in the future?
<andrewrk>
`break` does not interact with switch at all
Zaab1t has quit [Quit: bye bye friends]
<Akuli>
awesome, i think i'll need to add a comment about this to my code though
<andrewrk>
it's unfortunate - that is a reasonable question to ask
<Akuli>
currently i have code like: const thing: ?ThingType = switch(byte) { case END_BYTE => null, ... }; if (thing == null) {break;} ...
<Akuli>
in a loop
<Akuli>
if i have: const lol = []*T{ }; what happens if i do some_allocator.free(lol)? is that guaranteed to do nothing?
<emekankurumeh[m]>
I think the problem would be with passing the allocator memory it doesn't own.
<Akuli>
yes, i'm asking whether an empty slice is a special case
<andrewrk>
yes empty slice with undefined pointer can be safely passed to free
<andrewrk>
also... nice that's a much better way to get an empty slice than what I was doing
<andrewrk>
I was doing (([*]T)(undefined))[0..0]
<andrewrk>
you will note this is what is returned from std.mem.Allocator.alloc if n == 0
<Akuli>
:D
<Akuli>
how do you not know everything about your own language? :D
steveno has joined #zig
<Akuli>
i hope that all these details will be well documented when the stdlib will have documentation
<andrewrk>
the main reason for lack of documentation is that the language is still changing, which invalidates documentation
<andrewrk>
so it's overall more efficient of my time to stabilize the language first, then write docs second
<andrewrk>
of course there is a balance, as I want people to try the language out even before it is finalized
<companion_cube>
do you have a timeline to 1.0? I suppose it may take a while :)
<andrewrk>
you can infer the timeline from the milestones on github. every issue is tagged with a milestone. I will tackle every issue that is 1.0.0 or lower before 1.0.0 is released
<andrewrk>
however note that even if an issue is tagged, for example, 0.5.0, I may get to the issue and decide to not do it, or decide it can be done after 1.0.0
<andrewrk>
even before 1.0.0 though - every release brings us closer to stability
<companion_cube>
do you think there's a chance of multiple implementations of the language at some point (like a gcc frontend)?
<andrewrk>
yes, in the distant future, if zig accomplishes its goal of replacing C. it's planned to have a detailed language specification
<andrewrk>
specifically so that there can be competing implementations
<companion_cube>
totally replacing C, good luck :D
<companion_cube>
but eating a good chunk of its cake would be cool
steveno_ has joined #zig
steveno has quit [Ping timeout: 250 seconds]
<Akuli>
is there a type that represents a function that can take any number of arguments, all arguments are of type T1, and returns type T2? is there a way to call a function with arguments from a []T1?
<Akuli>
i'd like to have a struct that contains a member, which is a function that takes a bunch of T1s and returns a T2