<daurnimator>
1. junctions (not real symlinks) 2. real symlinks (almost no one uses these; they also only can be created from admin accounts... but not system accounts; microsoft is really weird about them). 3. real-fake symlinks (used by WSL)
<andrewrk>
FireFox317, I can reproduce the c import failure
<andrewrk>
ahh right symlinks. the zig-sdl package can do without them
<andrewrk>
I'll make that improvement
<FireFox317>
i guess its symlinks, not sure tho
mq32 has joined #zig
<FireFox317>
andrewrk, will try it tomorrow again :) goodnight y´all
FireFox317 has quit [Read error: Connection reset by peer]
FireFox317 has joined #zig
<FireFox317>
andrewrk, cross compiling worked tho, thats so cool! I just restarted my laptop, booted linux, cross compiled for windows, copied the exe to the other disk, restarted, booted windows and ran clashproto.exe and it works!!
<andrewrk>
it works the other way too, windows => linux. would just need to make more zig packages for the C libs that soundio & sdl2 depend on
<alexnask>
@andrewrk, @call with async_kw modifier works for comptime known function pointers (since it allocates the stack frame for us)
<alexnask>
I will open an issue to modify @asyncCall to accept a tuple parameter instead of varargs
<andrewrk>
alexnask, sounds good
mahmudov has quit [Remote host closed the connection]
adamkowalski has joined #zig
doublex__ has quit [Ping timeout: 256 seconds]
<adamkowalski>
andrewrk: is there a way to profile the compiler while it's compiling your code? my compile times are starting to get longer, and I want to know what's causing it. Is it because i'm doing to much work at compile time or whats going on
<adamkowalski>
-ftime-report doesn't tell me what semantic analysis is spending it's time on
<andrewrk>
adamkowalski, compare it with -ftime-report for std lib tests, the percentages
<fengb>
andrewrk: how’s the zig software foundation going?
<shachaf>
Is the plan for recursion still to disallow recursion on the call stack entirely, and require you to allocate stack frames yourself?
<shachaf>
What about indirect calls? Would those also be required to be async?
<adamkowalski>
andrewrk: here is the report for zig test lib/std/std.zig -ftime-report https://pastebin.com/Qdnq8GMi
<adamkowalski>
Semantic Analysis ~12 seconds
<adamkowalski>
LLVM Emit ~44 seconds
<adamkowalski>
the runtime code is crazy fast though. i'm just worried that as I keep adding more compile time features will my build times balloon
<mikdusan>
adamkowalski: stage1 comptime is not really optimized for speed at all; self-hosted is where that effort will go
<andrewrk>
adamkowalski, this is one of the primary concerns the self-hosted compiler is intended to address, and the main reason that progress is so delayed
<mq32>
andrewrk: got my build.zig to build C++ code :)
<adamkowalski>
I'm not complaining just curious. I know that D approached this by using a jit for compile time code rather then interpreting
<andrewrk>
yeah I'm with you. the perf of stage1 is abysmal compared to where I want to get to eventually
<andrewrk>
but consider: that runtime code being crazy fast, will be the *compile-time* code of self-hosted :D
alexnask has quit [Ping timeout: 255 seconds]
<andrewrk>
fengb, I'm planning to do a big announcement for ZSF within the next few months
<andrewrk>
but as a sneak preview: it's in the new york state database and the lawyer is working on getting non-profit status
<fengb>
Oh so I’m ruining it :P
<fengb>
Oh congrats!
<andrewrk>
the announcement will come when I can offer a way for people to donate to the org rather than to myself
<andrewrk>
shachaf, runtime-known function pointers will be annotated with minimum stack space they require (sort of like alignment metadata in pointers today)
<andrewrk>
there will be a safety check when you call a runtime-known function pointer, to make sure the actual stack space of the function you called matches the amount the pointer was tagged with
<andrewrk>
extern functions will default to something like 7 MiB stack space
adamkowalski has quit [Quit: Lost terminal]
<andrewrk>
maybe there can be a tool which can analyze object files and help automate coming up with more accurate numbers
<shachaf>
You mean maximum?
<shachaf>
Putting all this information in the type (effectively) is interesting.
<andrewrk>
maximum they could use; minimum they require
<andrewrk>
point being if your fn ptr is annotated as needing 100 KB but it only needs 10 KB that's OK
<andrewrk>
you just can't guess too low
<fengb>
Would it make sense for an stdlib type that converts functions to frame size + pointer?
alexnask has joined #zig
<shachaf>
OK, sure.
<andrewrk>
fengb, not sure I follow
<fengb>
I have a need to convert comptime known functions into function pointers. Be sorta nice to have a standard data structure to store the frame size and pointer next to each other
jzelinskie is now known as jzelinskie1
<andrewrk>
I see
doublex has joined #zig
nepugia has quit [Ping timeout: 256 seconds]
jzelinskie has joined #zig
adamkowalski has joined #zig
alexnask has quit [Ping timeout: 268 seconds]
<adamkowalski>
Do we already have something like this in the standard library? I feel like I might be reinventing the wheel.
<adamkowalski>
I'm building a function "invoke" which can take a "callable" and some arguments
<adamkowalski>
a callable can either be a function pointer, or a struct with a "call" method which accepts the same number of arguments as were passed into "invoke"
<adamkowalski>
pretty much it allows you to abstract over closures and function pointers. it will determine which one got passed in and then either call with f(arg1, arg2) syntax or with f.call(arg1, arg2) syntax appriorpiately
<adamkowalski>
the usage would look like invoke(f, .{arg1, arg2})
<andrewrk>
@call ?
blueberrypie has quit [Quit: leaving]
<daurnimator>
adamkowalski: sounds like you're inventing a new way to call functions because zig doesn't allow you to overload the call operator... think about why that might be :)
<adamkowalski>
andrwerk: that looks like a great building block for this thanks!
<adamkowalski>
daurnimator: it's necessary. I have some callers which just want to use a function pointer, and others which need to "close" over a value
<adamkowalski>
I don't want to have two copies of the function which only differ in how they invoke the function
<adamkowalski>
but i'm open to alternatives
blueberrypie has joined #zig
alexnask has joined #zig
jzelinskie1 has quit []
blueberrypie has quit [Quit: leaving]
blueberrypie has joined #zig
alexnask has quit [Ping timeout: 265 seconds]
blueberrypie has quit [Quit: leaving]
mokafolio has quit [Quit: Bye Bye!]
waleee-cl has quit [Quit: Connection closed for inactivity]
<Cadey>
adamkowalski: let's think about it from an xy problem standpoint, what are you trying to do with that?
<adamkowalski>
before we get to that. lets just appreciate how amazing Zig is that the solution is this trivial: https://pastebin.com/xksAxr6Z
<adamkowalski>
Cadey: i'm implementing a machine learning library (think numpy, tensorflow, pytorch) and I'm writing out all sorts of different operations on tensors.
<adamkowalski>
the backward pass for elementwise multiplication (local partial derivative) requires multiplying the incoming gradient by the corresponding input elementwise
<adamkowalski>
however, in the special case of broadcasting, one of the tensors is actually a scalar, and then you want to multiply each element of the gradient by that scalar
<adamkowalski>
however, you do this sort of elementwise traversal of tensors quite often so I implemented map and treat the tensors like a functor
<adamkowalski>
so I want to map over the tensor, scaling each element by the scalars value
daurnimator has quit [Remote host closed the connection]
daurnimator has joined #zig
_Vi has quit [Ping timeout: 272 seconds]
ur5us has joined #zig
artifth has joined #zig
artifth has quit [Quit: issued !quit command]
<daurnimator>
all so quiet now >.<
artifth has joined #zig
artifth has quit [Client Quit]
artifth has joined #zig
alichay has joined #zig
dhawkie has quit [Ping timeout: 260 seconds]
return0e has joined #zig
_Vi has joined #zig
ur5us has quit [Ping timeout: 240 seconds]
mahmudov has joined #zig
dddddd has quit [Ping timeout: 260 seconds]
<Snektron>
Its oh so still
<mq32>
hello Snektron
<mq32>
hello rest!
<Snektron>
Hi mq32
* mq32
got his C++17 + Zig build working :)
<mq32>
now i'm building my project with zig build instead of qmake
_Vi has quit [Ping timeout: 256 seconds]
<alexnask>
hihi
<mq32>
hey alexnask
<alexnask>
stage1 backtraces are so noice
waleee-cl has joined #zig
<artifth>
Hi all, I'm trying to use zig to make a win32 application and I'm struggling with passing utf16le strings to WinAPI functions, particularly the CreateWindowExW function. I've converted string to utf16le using std.unicode.utf8ToUtf16LeWithNull and then I'm passing the result to CreateWindowExW, but it seems that it only takes first letter from the string. Does anyone have an idea what could cause that? Also, when I pass the exact
<artifth>
same string to MessageBoxW it displays it as intended
<alexnask>
Hmm, weird
<alexnask>
What is the string you are trying to pass? (And I assume you are passing it as a windows name?)
<alexnask>
Googling around it seems to be a fairly common issue (truncated titles) let me see if I can find some solution ppl agree on
<artifth>
hm, that wasn't a zig error
<artifth>
I was using DefWindowProc instead of DefWindowProcW :)
<alexnask>
Right was just gonna suggest that :D
<artifth>
had too much struggle with zig already that forgot to look into other direction
<artifth>
thanks :)
<alexnask>
cheers
karrick has quit [Read error: Connection reset by peer]
tracernz has quit [Ping timeout: 260 seconds]
karrick has joined #zig
tracernz has joined #zig
ave_ has joined #zig
a_chou has joined #zig
waleee-cl has quit [Ping timeout: 240 seconds]
procnto has quit [Ping timeout: 272 seconds]
procnto has joined #zig
waleee-cl has joined #zig
<alichay>
In relation to issue #4591, implementing self-hosted CPU feature detection, would it be useful to have an implementation if it was only for x86 right now?
<alichay>
(I don't really have any ARM or RISC devices to tinker with lmao)
<mq32>
yeah, every bit helps :)
mahmudov has quit [Ping timeout: 265 seconds]
a_chou has quit [Ping timeout: 256 seconds]
marmotini_ has joined #zig
marmotini_ has quit [Ping timeout: 255 seconds]
blueberrypie has joined #zig
<alexnask>
Is anyone familiar with the InferredStructField mechanism used to initialize anonymous literals?
<mq32>
Is anyone familier with importing symbols from C/C++ defined in Zig?
<mq32>
using @export or pub export doesn't help
<BaroqueLarouche>
search for a generated header file in your zig-cache
<alexnask>
in ir_resolve_result, when we try to resolve an inferred struct field that has already been resolve, I don't see why we shouldn't error "duplicate field" right there
<mq32>
BaroqueLarouche, i'm writing an executable and getting linker errors, not writing a library
frmdstryr has quit [Ping timeout: 255 seconds]
<mikdusan>
alexnask: I haven't looked at it closely, but anon-array-literal might use that too?
<alexnask>
Yes it does but you can never end up on that branch (I think)
<mikdusan>
oh wait even if it did, they have diff field names (@"0", @"1", ...)
<alexnask>
Right, exactly
<alexnask>
I'm struggling with #4597 rn
<alexnask>
But I think I'm close
<mq32>
BaroqueLarouche: I'm just stupid, that's all :D
<alexnask>
Well, I'm struggling to fix it while also not breaking anonymous struct literals :p
frmdstryr has joined #zig
<mq32>
aaargh
<mq32>
as soon as you do things right, it will work!
return0e has quit [Remote host closed the connection]
<mikdusan>
yeah I cannot reproduce #4597 on linux right now. let me get my house in order
<alexnask>
Ok let me test your diff on windows too
<alexnask>
Thanks
return0e has joined #zig
dddddd has joined #zig
<alexnask>
While this does work I feel like it is fishy. I mean, it should work with any allocator
<alexnask>
Besides I'm 90% sure what happens is that `struct_val->data.x_struct.fields` on ir.cpp:18487 is only ever called with a new_field_count=1 and then, when copy_const_val we try to copy both fields
<alexnask>
is only every allocated with new_field_count=1*
<alexnask>
(because the if block above returns early if the value is comptime, so if the tuple contains a comptime and a runtime value the runtime value is initialized but the comptime value is not, which is why I moved the block bellow the part that reallocates the value's fields)
<mikdusan>
ok so that's a legit memory corruption. never mix allocators when reallocating :)
<mikdusan>
(this is my doing)
<mikdusan>
but how it relates to #4597 I'm not really sure.
<alexnask>
I don't see how this is a memory corruption error, it is using one allocator to allocate the list of pointers
<alexnask>
And one allocator to allocate the ZigValue's
<alexnask>
mikdusan, #4597 happens because we try to copy_cosnt_val a struct with 2 fields but only 1 fields has been allocated
<alexnask>
Because we skip the realloc of the struct value's fields if the value is comptime
<mikdusan>
one thing is, realloc is always called from size 0. and it could be I have a bug in c_allocator's realloc. and shifting it to the arena impl which does realloc's differently
<alexnask>
I dont think it's always called from size 0
<alexnask>
We do 1 realloc for every InferredStructField
<alexnask>
(but we skip it if the value is comptime)
<alexnask>
Anyway I will check again but I'm pretty sure we only ever realloc with new_field_count=1 here and then copy_const_val() fields[1]
<mikdusan>
does it get to size 1 via alloc_const_vals_ptrs or realloc_Const_vals_ptrs?
<mikdusan>
but anyway the crash on macos for me was when copying field[1] so realloc is in play
<alexnask>
realloc_const_vals_ptrs
* mikdusan
reviews c_allocator realloc
<alexnask>
We do a single realloc_const_vals_ptrs from 0 -> 1, then try to access fields[1] to copy_const_val it
<alexnask>
We never realloc_const_vals_ptrs from 1 -> 2
<mikdusan>
hmm I thought I checked that with an assert
<andrewrk>
remember when we didn't have to free stuff? that was nice
<alexnask>
Basically we generate two InferredStructField's, resolve the first one, it is not comptime so we realloc the struct_val's fields 0 -> 1, then when resolving the second one we exit eearly since it's comptime
<alexnask>
So we never realloc the fields from 1->2 and we try to copy fields[1] in copy_const_val when copying struct_val
<alexnask>
Does that make sense?
<alexnask>
I really don't think its an issues with realloc_const_vals_ptrs
<alexnask>
an issue*
<alexnask>
My PR fixes this (as well as passing tuples to comptime var arguments) but breaks something else atm :/
<fengb>
Should I have a temporary use-after-free or leak? 🤔
<mikdusan>
alexnask: you've went into this far further than me, maybe my assert is wrong? `copy_const_val()` for the struct it alloc's dest fields[] according to src_field_count. i've verified is 2. then it copies each field. field[1] gets segfault. how is x_struct.fields not properly sized?
<alexnask>
mikdusan, src_field_count is correct since it's a property of the struct type
<alexnask>
However the value only ever gets 1 field allocated
<alexnask>
Consider what happens if one of the fields has `value && instr_is_comptime(value) == true` and the other does not
<mq32>
but i think i want to try a struct-based approach
<fengb>
need moar comptime
<fengb>
I worked around tags by injecting my metadata into function names. It's so janky bit it works :D
ur5us has joined #zig
<companion_cube>
where's your "simpler than C" now? :p
<mq32>
it's simpler to get the function name than in C! :
_Vi has joined #zig
daex has quit [Ping timeout: 256 seconds]
daex has joined #zig
<alexnask>
ComptimeClap sounds like a really bad disease /s
ur5us has quit [Ping timeout: 240 seconds]
frmdstryr has quit [Ping timeout: 256 seconds]
return0e has joined #zig
return0e has quit [Client Quit]
waleee-cl has joined #zig
_whitelogger has joined #zig
doublex_ has joined #zig
doublex has quit [Ping timeout: 256 seconds]
_whitelogger has quit [Ping timeout: 256 seconds]
_whitelogger has joined #zig
marmotini_ has joined #zig
marmotini_ has quit [Remote host closed the connection]
marmotini_ has joined #zig
TheLemonMan has joined #zig
frett27 has joined #zig
FireFox317 has joined #zig
<fengb>
"zig test" seems to be eating some of the output: Tests failed. Use the following command to reproduce the failure:
<fengb>
If I run the test executable manually, it gives me: Test [1/1] test "module with function body"...Segmentation fault: 11
<andrewrk>
fengb, maybe try printing a newline before your content
<fengb>
It's the "Segmentation fault: 11" that got eaten
<TheLemonMan>
there are no segfaults if you can't see the error messages
<andrewrk>
fengb, are you running zig test in a child process? in this case you have to look for the termination data to see that there is a segfault. the "Segmentation fault: 11" message is printed by your shell
Akuli has quit [Quit: Leaving]
jjido has joined #zig
<mikdusan>
a few malloc tidbits: tried mimalloc (again) against stage1; here's a few words on it:
<mikdusan>
1. mimalloc is not ready for anything macos. crash. corruption.
<mikdusan>
2. mimalloc on linux links and works as expected; and lives up to some of the hype wrt. RSS. it reduced RSS by 10% when I simply switched out malloc calls (stage1's mem::os namespace)
<mq32>
since when has bpaste zig highlighting?! \o/
jessermeyer has quit [Remote host closed the connection]
<meowray>
just so that FB people can immediately take "darwin"
<andrewrk>
well old-darwin basically unmaintained, so as long as the new version is at least as capable as the old version, I don't see why not to do that
<andrewrk>
why even keep old-darwin around? if the new one is better then replace it
<meowray>
there is reference value
<fengb>
This line causes a segfault: `var stack: [1 << 20]Op.Fixval align(16) = undefined;`
<andrewrk>
IMO it should be new-darwin until it is feature-compatible, then it should `mv new-darwin darwin`
<fengb>
Not a compiler segfault though. An execution segfault
<andrewrk>
fengb, I think you overflowed the stack
<fengb>
Oh
<andrewrk>
we don't have stack upper bound detection yet, which would cause zig to notice this and request a bigger stack from the OS
<andrewrk>
(at compile time)
<fengb>
16 MB too stronk?
<fengb>
Ah okay it's working again
<fengb>
Thanks
<andrewrk>
np
<fengb>
I guess I should create a stack out of heap memory. That sounds so weird
<meowray>
They want to add tests as `lld -flavor darwinnew`. I just want to save a step that does sed -i 's/darwinnew/darwin/'
<andrewrk>
mikdusan, ah, thanks, this is interesting
<andrewrk>
so it does resize the stack, but it resizes into a new contiguous one and then copies data over
<mikdusan>
yes they rewrite pointers
<mikdusan>
*refs*
<andrewrk>
the property remains that calling a function in go can OOM
lunamn_ has joined #zig
<andrewrk>
ha that's funny they cite rust also not using segmented stacks - the link is from 2013 when rust had green threads
<andrewrk>
it's pretty crazy how different rust was planned to be
<andrewrk>
there are only 4 months between rust removing green threads and the first commit to zig
<fengb>
But Zig was also a different beast ;)
<andrewrk>
was it?
<fengb>
%%maybe 🙃
<andrewrk>
according to my own memory I've been pressing the petal to the metal on the same highway going the same direction the whole time
<andrewrk>
%% had the same semantics as catch
<andrewrk>
it was like 20 lines to change it to a keyword
<mikdusan>
i suspect the stack problem will largely be solved in the future with huge address spaces and real smart mmu and nobody will ever care again
<mikdusan>
(Aside from statically determining it before hand of course)
<mikdusan>
maybe something like a vm-zone for each stack
<andrewrk>
mikdusan, I think that's a wise prediction. The problem I have with that solution is that it doesn't support the use case of making sure you have all the (memory) resources available to complete a task before attempting to start it
<mikdusan>
true
<mikdusan>
no problem. when you can't call a function because stack is exhausted, just handle it... by calling another function to handle it :)
<andrewrk>
fengb, ah maybe this was before your time. zig switched from &T to *T and from *x to x.* because otherwise these operations on types is ambiguous
<mikdusan>
fengb: i don't know why it mentions that I mentioned #33. it could be that stack trace had "#33" in it and I pasted it raw
<mikdusan>
#588, it looks to me like `var a: type = 32` breaks the "copy" rule in zig. if you see a "=" you make a copy. but not in this case, type is just a ref or alias?
<mikdusan>
typo: `var a: type = i32;`
<mikdusan>
protty: line #124. push it outside/before line #123.
<andrewrk>
mikdusan, given that types are immutable and have infinite lifetime, copies and references are indistinguishable
<mikdusan>
protty: meh i'm wrong. nevermind
protty has quit [Remote host closed the connection]
protty has joined #zig
<andrewrk>
5 weeks until the release. it's almost crunch time
<andrewrk>
0.6.0 milestone issue counts are on schedule
<fengb>
I saw that you already have some written notes ;)
<protty>
This mutex bug in particular has been my only show stopper so far with the worst part being that it acts like a race condition
<andrewrk>
fengb, oh, that zig-0.6.0 file on my desktop? here are the contents: https://clbin.com/cL00U
<andrewrk>
protty, I'll take a look later tonight or tomorrow
<andrewrk>
I'm about to go afk
<protty>
thanks (to mikdusan as well) for checking it out
<andrewrk>
protty, I also want to consider making language tools to help diagnose these kinds of bugs
<andrewrk>
maybe the language could specify "debug extensions" or something like this