<pixelherodev>
r4pr0n, there's probably a flush function or something, 1 sec
<pixelherodev>
Yep
<pixelherodev>
For future reference: I just check /usr/local/lib/zig/std/ files to answer these questions :P
<foobles>
oh right
<pixelherodev>
`try buffered_stream.flush();`
<foobles>
thank you very much for helping me
<foobles>
mikdusan it still does take a `source_instr` and a `base_ptr`
<pixelherodev>
r4pr0n, re: "why not just have the functions directly", it allows various streams to implement a single function (write) and expose the standard functionality (e.g. `print`)
<mikdusan>
foobles: but now you can give it the instrction from which ZigValue came from?
<pixelherodev>
I do think mixins would be nicer though, since it would remove the need to call` .outStream` and shhuold ideally not be a burden to the compiler
<pixelherodev>
s/hh/h
<foobles>
I have an `IrInstrSrcBinOp`, and I have determined that `op1` and `op2` are both optional non-pointer types
<r4pr0n>
oh yeah it works now, thanks
<mikdusan>
foobles: one moment,
<foobles>
and at compile time, once ive checked that neither are null, i want to recursively create a new comparison instruction of the inner values
<r4pr0n>
what do you mean with mixins?
<foobles>
this will be even harder when they are runtime values :(
<foobles>
since ill have to generate a ton of instructions in the second pass, testing if both are null, or if both are non-null and their inner values are the same
<pixelherodev>
r4pr0n, basically, instead of having a function which returns the interface type, you use `pub usingnamespace InterfaceType` and pull the interface's methods into the implementor
<pixelherodev>
IIRC anyways
darithorn has quit [Remote host closed the connection]
nephele_ has joined #zig
<r4pr0n>
yeah that'd be kinda nice
<pixelherodev>
There were definitely issues with it though even if I can't remember them
<pixelherodev>
Otherwise it'd have been merged :P
<mikdusan>
foobles: my thoughts so far; you want to create SrcOptionalUnwrapPtr via ir_build_optional_unwrap_ptr()
nephele has quit [Ping timeout: 250 seconds]
<r4pr0n>
Is it possible to use std.fmt.format() to format into a string?
<foobles>
alright that would make sense. it seems like all the other unwraps use that under the hood mikdusan
<pixelherodev>
r4pr0n, bufPrint
<mikdusan>
so what I did to focus on that was this little reduction:
<mikdusan>
so basically do the bare minimum in comptime context.
<mikdusan>
just like what you need. then the compiler will tell you how it does it :)
<mikdusan>
because comptime, you're not going to see those in a nice listing, rather it's going to be analyze ~ lines and then const results "->" lines
<mikdusan>
so it helps to use real catchy id names. hence aaa, 333
<foobles>
what am i suppossed to do with the gist yuor posted?
<foobles>
s/yuor/your
<mikdusan>
oh hehe I should hit that green comment button lol
<mikdusan>
there ya go
<r4pr0n>
pixelherodev: but you can't format at comptime, can you?
<foobles>
thats so cool!!
<foobles>
wow!
<pixelherodev>
r4pr0n, whyever not? ;)
<foobles>
so do you know the purpose of source_instr and base_ptr are?
<foobles>
i can guess that base_ptr is the pointer to the option thats being unwrapped
<foobles>
but im not sure what the source_instr is supposed to be
<foobles>
mikdusan
<mikdusan>
k which os are you on?
<foobles>
windows
<foobles>
does that matter? :0
<mikdusan>
oh noes. I don't debug on that platform. what I would do with questions like this is put breakpoints in the code. and follow.
<mikdusan>
so the unobvious part here is... how do you even find the breakpoint in .cpp code, for something in .zig code?
<r4pr0n>
pixelherodev: well i get a "unable to evaluate constant expression"
<mikdusan>
it just so happens andrew made that somewhat easier by adding some functions that can be called / evaluated from your debug session
<r4pr0n>
also, how would i know the size the buffer has to have
<foobles>
awesome sauce
<mikdusan>
in our very recent release notes here's a text copy
<mikdusan>
in gist
<mikdusan>
so the overall idea is... add some early breakpoint around main or whatever, then call this function in debugger while running. dbg_ir_break(src_file_zig, line)
<mikdusan>
and expect that line to be hit multiple times. lots of things get analyzed on each line of zig code
<mikdusan>
i suppose you could use whitespace to your advantage and isolate
<foobles>
oh cool! so put the break points in the zig program?
<mikdusan>
no, you do it in debugger
<mikdusan>
are you familiar at all with gdb or lldb?
<foobles>
somewhat
<foobles>
like im vaguely competent
<foobles>
so i would be putting the breakpoints in the C++ source?
<mikdusan>
nope
<mikdusan>
it's transient whlie you run debug sesssion
<mikdusan>
I dunno, is it dirt simple to setup a twitch session on mac?
<mikdusan>
I could do that
<foobles>
that would be super helpful!
<foobles>
i mean if you have the time, i would be super grateful
<mikdusan>
hmm ok that looks involved. I'll just screen shot something from my terminal
<r4pr0n>
well i was pretty sure that it wont work like that
<r4pr0n>
but i'm not sure how it would
<pixelherodev>
r4pr0n, where's test123 defined?
<pixelherodev>
That has to be comptime known for it to work
<pixelherodev>
Also
<pixelherodev>
buffer has to be comptime defined
<r4pr0n>
it is
<pixelherodev>
THe buffer sure isn't
<pixelherodev>
Can't write to a runtime address (the buffer) at comptime
<pixelherodev>
Can do `comptime var buffer` though
<pixelherodev>
and then it'll continue being present at runtime
<pixelherodev>
At least, AFAIK
<r4pr0n>
oh that works yeah
<pixelherodev>
:D
<r4pr0n>
but it has one issue
<r4pr0n>
i have to specify a buffer size, but i want it to be exactly as big as it needs to be
<r4pr0n>
else if i do something with it it'll contain a bunch of garbage at the end
<pixelherodev>
Could add \x00 to null-terminate
<fengb>
Let it have some garbage. bufPrint returns the correctly sized slice
<pixelherodev>
^
<pixelherodev>
Sorry, forgot about that
<mikdusan>
foobles: window 1: setup debugger with exact command line, note --verbose-ir must be passed to zig
<r4pr0n>
well that fixes the garbage
<r4pr0n>
but i still have to set a limit for it
<mikdusan>
window 1: setup initial break at main; run; and it traps at main. then lldb syntax to call the .cpp function andrew added, is "p dbg_ir_break(...)" and then tell debugger to continue
<foobles>
so use the zig debugger? or is that lldb
<foobles>
like set the intitial break in zig code right?
<mikdusan>
window2: breakpoint when ir_analyze() code sees that source/line comibination. then I just use some lldb to show locals, and use another helper func to print the src() location
<mikdusan>
and we can see hey it stopped line 5, col 16. that's the equal sign!
<mikdusan>
foobles: that's lldb
<mikdusan>
foobles: nope. i didn't do a thing to unwrap.zig -- or any other zig source code.
<foobles>
wait so what file is the breakpoint set in?
<foobles>
thats the part im confused about
<foobles>
thank you for being so patient with me '=D
<mikdusan>
birds eyeview is: this is a native debug session. we aren't actually running unwrap.zig itself. we're run/debugging the zig.exe
<mikdusan>
we use lldb to run zig.exe with all the correct command line args and say stop at main. that is... don't do anything except startup zig.exe
<foobles>
oh ok!
<mikdusan>
once it's running, but stopped at main, it's a live process. we then, live, manually call a function called dbg_ir_break that is already compiled into zig.exe
<foobles>
awesome, i think i understand
<foobles>
thats rad, thanks, ill try it out now
<mikdusan>
so then this gets us close, but not all the way there.
<mikdusan>
you may have to break, examine the frame ... I chose to look at old_instruction->base.src() to give me col number
<mikdusan>
and first several ones bounced around that line 5... until I got to the token that is at colum 18
<mikdusan>
which is our right-hand-side operand forcably unwrapping an optional
<mikdusan>
so the unwrap.zig should probably be used like an optional properly. because that's what your PR will do right? it wants to do the equivalent somewhere of `if (maybe_value) |value| { }`
<foobles>
yeah!
<mikdusan>
another good excercise is.. right real zig code in a reduction that does EXACTLY what you want to do in the IR.
<foobles>
oh thats a good idea
<mikdusan>
s/right/write lol
<r4pr0n>
is there also a nonfixedbufferstream?
<pixelherodev>
Yeah write.
<pixelherodev>
r4pr0n, a wat?
<pixelherodev>
Ohhh
<pixelherodev>
You mean a stream backed by a dynamic array?
<r4pr0n>
yeah
<fengb>
Dynamic arrays require the heap
<pixelherodev>
You can probably trivially implement one using a FIFO
<pixelherodev>
std.fifo
<r4pr0n>
well it wouldn't really care, i'd use it comptime
<pixelherodev>
It's in the plans but there's a couple bugs
<fengb>
Can’t use it in comptime yet
<foobles>
gaah turns out I dont hav LLDB :( i think im going to call it a night
<foobles>
thank you so much for the tips
<foobles>
this will be super helpful
<fengb>
Anything that depends on using an allocator has some blocking bugs in comptime, unfortunately
<fengb>
But realistically, using a fixed buffer is probably faster and more efficient anyway
<r4pr0n>
i would actually be able to set a good limit
<pixelherodev>
^
<mikdusan>
foobles: I just added more.zig to comments. this would be super useful to examine as runtime
<pixelherodev>
I mean
<pixelherodev>
`<fengb> But realistically, using a fixed buffer is probably faster and more efficient anyway` That.
<pixelherodev>
Very much tat.
<pixelherodev>
that
<fengb>
Just don’t pad too big. Start at like 100 and go from there
<r4pr0n>
is there a function to get the biggest amount of bytes a type can be formatted at?
<foobles>
this is so awesome
<fengb>
At worst, you’d waste 100 bytes during the compile
<mikdusan>
foobles: and I guess that logic might be a subset of your solve
<r4pr0n>
like u8 -> 3
<foobles>
i really appreciate it. i feel like if I can do this, i can probably implement the rest
<r4pr0n>
i8 -> 4
<fengb>
There’s a way to calculate it. I don’t remember if we ended up exposing it
<mikdusan>
foobles: so remember with --verbose-ir you'll see 2 passes on the same entry() and somewhere inbetween them will be line-by-line comptime analysis and execution going on
<fengb>
But that basically requires printing twice
<mikdusan>
foobles: also the "panic()" override function is helpful. if you don't have that, too much IR is generated because it brings in a lot more code.
<foobles>
interesting
<foobles>
even though panic is never called?
<mikdusan>
correct
<r4pr0n>
yeah i could also use that
<mikdusan>
zig is lazy. so this panic override doesn't even use StackTrace. thus StackTrace and all that it entails is never resolved. that includes reading elf/debug/sorting and all that
r4pr0n has quit [Quit: r4pr0n]
<foobles>
thats cool!
<foobles>
wow hehe
<mikdusan>
foobles: which analysis function were you looking at?
<foobles>
i think im too tired to try and set up lldb like you suggested tonight, i think ill do that part tomorrow
<foobles>
but i am trying to implement comparison of non-pointer optionals
<foobles>
so im looking at ir_analyze_bin_op_cmp
<mikdusan>
there's probably an equiv setup for windows but I don't have exp debugging on windows
<mikdusan>
ah so do you have thoughts on an high level logic for what ir_analyze_bin_op_cmp will do?
<foobles>
yeah:
<foobles>
so if op1 and op2 are both non-pointer optional types, then if they are both comptime: if they are both null, or one is null but not the other, return a const bool. If they both have values, recurse and return the result of comparing those.
<mikdusan>
so this is just shooting from the hip, but we enter ir_analyze_bin_op_cmp which I'll just call _cmp(),
<mikdusan>
and you basically have the instr that gives you op1,op2 instructions that represent expressions
<mikdusan>
my word choices are probably poor but bear with me,
<foobles>
im following
<mikdusan>
so let's check for case inside _cmp(op1,op2) that both op1,op2 are optionals
<foobles>
i already have done that
<foobles>
hold on let me make a gist or something to show you what i have
<mikdusan>
if they are, get a ptr to each of op1,op2
<mikdusan>
then use that _build_unwrap_ptr function for each op1,op2 to give you unwrapped_op1, unwrapped_op2 and then op1 = unwrapped_op1; op2 = unwrapped_op2 let you're done? naturally this would have to come before meat of cmp()
<foobles>
alright that makese sense with me
<foobles>
s/makese/makes
<foobles>
but i just dont know what to put for the source_node parameter
<foobles>
im not sure what that means
<mikdusan>
and what's the recurse logic? only recurse when BOTH unwrapped_op1 and unwrapped_op2 are still optionals?
<mikdusan>
s/recurse/unwrap_again
<foobles>
here is some pseudocode:
<foobles>
if (op1 is comptime && op2 is comptime): if (op1_is_not_null && op2_is_not_null) { return _cmp(op1.unwrap(), op2.unwrap()); }
<foobles>
this would be inside of the `_cmp` function itself
ur5us has joined #zig
<daurnimator>
06:25:11 <foutrelis>daurnimator: success! (I think). got rid of libclangHandleLLVM from libclang-cpp since it was unused anyway, so now clang-cpp doesn't contain any conflicting symbol thingies and zig happily compiles against it (with ZIG_PREFER_CLANG_CPP_DYLIB=ON)
<mikdusan>
source_node for op1 should be op1->base->source_node
<mikdusan>
daurnimator: yeah I'm seeing some kind of eventloop hang on an real tiny example andrew put for rel0.6.0 notes re: Async I/O
<foobles>
mikdusan hmm ok
<foobles>
that would make sense
<foobles>
but then why does the function need it to be passed as another parameter?
<foobles>
if it can just access it directly from the IrInstGen thats passed as one of its other parameters?
<mikdusan>
I can only assume it's because that's not always the case
<foobles>
hmmm
<mikdusan>
also there have been some rapid advances in zig compiler inernals... some of the things that fall through the cracks are redundancies. so _if_ this is indeed universally redundant, it may have may emerged that way after some changes
<mikdusan>
foobles: as an aside, if you are going to try a debugger, I assume it will be on linux... probably want to go with gdb. I use lldb because macos.
<foobles>
aah ok
<foobles>
i cant find any tutorial on using msvc debugger through the command line without the IDE =#
<mikdusan>
pretty sure you can use the IDE with a window for command-line apps?
<mikdusan>
but yeah, linux/gdb is probably the best supported for debug right now. iirc there was an open issue about breakpoints on wrong-lines on windows recently
darithorn has joined #zig
ur5us has quit [Remote host closed the connection]
ur5us has joined #zig
ur5us has quit [Ping timeout: 260 seconds]
klltkr has joined #zig
foobles has quit [Ping timeout: 240 seconds]
<andrewrk>
I wonder how well RemedyBG works for developing zig on windows
<daurnimator>
andrewrk: see messages from foutrelis above
<andrewrk>
daurnimator, happy to see that. look at b8796be79d11
<daurnimator>
ah ha :)
<andrewrk>
the policy on flaky tests is: file bug report, disable test immediately
<daurnimator>
andrewrk: did you want that release party in ~10 hours?
waleee-cl has quit [Quit: Connection closed for inactivity]
<daurnimator>
andrewrk: and PM me your address :)
<andrewrk>
here's what the timeline looks like: I'm going to finish the release notes in about 6 hours from now. then I will sleep for ~6 hours. none of those remaining 0.6.0 bugs are going to get solved. after that, the release process will take ~2 hours, maybe up to 4 if any issues occur. then hopefully we'll have a nice media day. the next day after, would be a good release party day
<andrewrk>
depending on what you had planned
<daurnimator>
I'm making things up on the fly :P
ur5us has joined #zig
<andrewrk>
anyway, tuesday would be good for me, unless the activity didn't conflict with any release-day situations that arise
darithorn has quit [Quit: Leaving]
ur5us has quit [Ping timeout: 260 seconds]
sternmull has joined #zig
nephele_ is now known as nephele
klltkr has quit [Ping timeout: 256 seconds]
dddddd has quit [Remote host closed the connection]
ur5us has joined #zig
_Vi has joined #zig
ur5us has quit [Ping timeout: 260 seconds]
<daurnimator>
so with the arch clang fix I can now compile zig against system LLVM as long as I pass `ZIG_PREFER_CLANG_CPP_DYLIB=on`
<daurnimator>
is that the desired outcome?
<daurnimator>
(compiling without it I get: http://sprunge.us/sbGJ2d which I guess is due to missing -l arguments for static compilation?)
frett27 has joined #zig
frett27_ has joined #zig
<andrewrk>
I haven't been able to make zig detect in a clean way whether it should be trying to do -lclang-cpp or not. every system is different, it seems
<pixelherodev>
If clang-cpp exists, it should be used, shouldn't it?
opidopiopi has joined #zig
<andrewrk>
one would think. however, it is misconfigured on several systems and causes linker errors
<andrewrk>
arch just fixed a bug for example. they got it wrong until today
<andrewrk>
even apt.llvm.org was misconfigured and didn't fix it for their own release
dermetfan has joined #zig
_Vi has quit [Ping timeout: 260 seconds]
jjido has joined #zig
<andrewrk>
I finished the release notes
<pixelherodev>
Nice!
<pixelherodev>
One thought on a future package repository
<pixelherodev>
If we have a language-specific package repo, can I request that it be curated by Zig team members?
<pixelherodev>
I don't think there's anything wrong with a language-specific package repo, but e.g. NPM has made me wary of just allowing unchecked submissions
<pixelherodev>
This is a bit early to worry about it, I know :P
<andrewrk>
package curation will fall onto a third party, since we plan to have decentralized package management
ur5us has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<pixelherodev>
Ruhroh
<pixelherodev>
(That's probably a good thing)
<daurnimator>
andrewrk: wait really? wow
cole-h has quit [Ping timeout: 260 seconds]
<pixelherodev>
I still say "Zig isn't better because we're perfect but because we're willing to iterate as much as it takes" should be refined and added to `zig zen`
ur5us has quit [Ping timeout: 260 seconds]
marijnfs has joined #zig
criloz has joined #zig
FireFox317 has joined #zig
_Vi has joined #zig
squeek502_ has joined #zig
squeek502 has quit [Ping timeout: 256 seconds]
ifreund has joined #zig
Xavi92 has joined #zig
Biolunar has joined #zig
<mikdusan>
he is a machine: `grep TODO src/download/0.6.0/release-notes.html | wc` -> 0
kenaryn has joined #zig
* pixelherodev
is stunned
<kenaryn>
pixelherodev: "We shall embrace change if it serves the end user's needs."
<kenaryn>
"Refinement is not a breaking backward compatibility, it's a necessity."
<pixelherodev>
I like the former, less so the latter
<Xavi92>
So do I :)
<pixelherodev>
Eh, I think it's not needed
<pixelherodev>
`zig zen|tail -n2|head -n1`
<pixelherodev>
Also
<pixelherodev>
`* Incremental improvements`
<pixelherodev>
:)
jjido has joined #zig
mahmudov has joined #zig
BeardPower has joined #zig
<kenaryn>
I think it would account for a great deal of publicity if zig lang could appear in the last Overview's subpart (alongside Rust) on the github page's emscripten (i.e. https://github.com/emscripten-core/emscripten) when support will reach Tier 2.
<BeardPower>
Hi everyone! With 0.6.0 to be released soon, will it be production ready? If not, what's missing?
<daurnimator>
in some ways yes: you can write working code with it.
<daurnimator>
in most ways no: the language is not stable yet; and there are known bugs
<BeardPower>
daurnimator: is it stable enough to create a reliable client/server (e.g. trading bots), GUI, business app with it?
<daurnimator>
probably not?
<daurnimator>
networking APIs are not complete at all
<daurnimator>
and there are no GUI libraries that are known to work perfectly yet
<BeardPower>
That would not be an issue because I could use C libs for networking. I want to use Blend2D for a GUI.
<daurnimator>
that said, you *could* create other types of libraries pretty happily in zig right now. e.g. something like libpsl could easily be rewritten fully in zig and be stable
<BeardPower>
I read that deflate and inflate should be part of the zig lang so I thought about porting a high-performance C implementation.
<BeardPower>
It's MIT like zig.
<daurnimator>
BeardPower: please do; we'd like deflate in the standard library!
<BeardPower>
It would be a nice project to get used to zig and compare it's performance.
<ifreund>
i beleive BaroqueLarouche had something in progress for inflate?
<daurnimator>
ifreund: I can't see it in their repository.
<BeardPower>
Yeah, I read the GitHub issue but it seems he did not move forward with it. IIRC he was porting some implementation which was not tailored for performance.
<ifreund>
daurnimator: i may just be remembering discussion here
<ifreund>
porting a high performance c implementation would be awesome
<BeardPower>
Anyway. I thought it would be a nice project.
<daurnimator>
BeardPower: looks reasonable to me; go for it!
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<BeardPower>
There is also an Intel implementation using Assembler, which is the most performant one but maybe not that ideal for having it in the language.
<BeardPower>
daurnimator: Nice. I need to dig more into that one.
klltkr has joined #zig
<daurnimator>
BeardPower: just have a look at the existing crc implementation(s) and you should figure itout
<BeardPower>
daurnimator: Will do. 0.6.0 should be released any moment, right?
<daurnimator>
BeardPower: in ~8 hours I think.
<BeardPower>
Nice!
<marijnfs>
exciting
dddddd has joined #zig
marijnfs_ has joined #zig
jjido has joined #zig
marijnfs has quit [Ping timeout: 264 seconds]
mahmudov has quit [Ping timeout: 258 seconds]
FireFox317 has quit [Quit: Leaving]
kenaryn has quit [Quit: WeeChat 2.3]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<daurnimator>
> In this release, the minimum supported Windows version is bumped from 7+ to 8.1+, following the extended support lifecycle of Microsoft.
<daurnimator>
^ (sadly) windows server 2008 (based on vista!) is supported on azure for 3 more years...
<ifreund>
why do people do things like run windows on a server
<daurnimator>
ifreund: need to run Active Directory server somewhere...
<daurnimator>
there's enough windows-only software that sysadmins need something to manage all the end user devices
<ifreund>
i'm sure there're valid reasons, i know very little about the windows sysadmin world
<ifreund>
i never would by choice though
zfoo has quit [Remote host closed the connection]
marijnfs has joined #zig
<marijnfs>
how do I define the specific error set a function returns?
marijnfs_ has quit [Ping timeout: 240 seconds]
criloz has quit [Remote host closed the connection]
<Xavi92>
mikdusan: nope, 'const de = DisplayEnable{}; _ = puts(fmt.fmtZ("{}", .{@bitCast(u32, de)}));' would still crash -> TODO buf_read_value_bytes enum packed
<fengb>
I think this is caused by a bit cast in anon tuples. Can you try assigning the bitcast into a temp?
<daurnimator>
Xavi92: missing .{} around your `tmp`?
mahmudov has joined #zig
slowtyper has joined #zig
<Xavi92>
daurnimator: you're right, but still has the same effect. -> TODO buf_read_value_bytes enum packed
<Xavi92>
daurnimator: BTW, before submitting my proposal about anonymous padding bits, I've read https://github.com/ziglang/zig/issues/676 , where it looks like it was already suggested a couple of years ago
<daurnimator>
Xavi92: one question is going to be: "what does the padding have to be"
<Xavi92>
andrewrk suggests using '_: ux = default_value', but I don't know if it was implemented into the language finally
<daurnimator>
e.g. some apis require that padding bytes are `0`; to me that's more reserved than padding
<daurnimator>
Xavi92: default values exist now.
<Xavi92>
daurnimator: the default value syntax would fix that, but the idea is forbid the user from accessing these padding bits directly
<Xavi92>
Naming it '_' would make sense, but AFAIK the user can access it by 'struct_name._ = value;'
<daurnimator>
Xavi92: how would an api verify that the padding/reserved bits are set correctly?
<Xavi92>
daurnimator: thanks to the default value e.g.: '_: u5 = 0'
<Xavi92>
I hope I didn't misunderstand something
<companion_cube>
morning y'all
<daurnimator>
Xavi92: say I have 3 reserved fields, the first one must be 0, the second must be 42, the third can be undefined for all I care. how can I verify that argument my function receives meets those requirements?
<companion_cube>
I wonder if zig will give birth to a set of new "design patterns" around custom allocators
<companion_cube>
(per request is easy, but there might be so many others)
<daurnimator>
companion_cube: I expect that we'll e.g. have a "main" http framework that provides that sort of thing for handlers.
<companion_cube>
sure, the handler takes an allocator, etc.
<companion_cube>
but for other things, really…
<companion_cube>
say you write an IRC bot, you could have an allocator per incoming message
<daurnimator>
Xavi92: I just finished reading your linked issue :) seems like andy said exactly what I was thinking: padding and reserved fields are different.
<Xavi92>
Would 'const Name = packed struct { _: ux = 0, _: uy = 0, _uz = undefined}' fit?
<daurnimator>
Xavi92: you have two fields there both called _. how do I check each one?
<Xavi92>
I understand. Thanks for your help :)
<marijnfs>
i have a function that accepts a function: add_thread(comptime function: fn(var) anyerror!void)
<Xavi92>
daurnimator: BTW, the compiler also crashes with 'const a:u32 = @bitCast(u32, DisplayEnable{});' -> TODO buf_read_value_bytes enum packed
<marijnfs>
but if i pass one of that type, i get expected type 'fn(var) var', found 'fn(i64) anyerror!void
frett27 has quit [Ping timeout: 264 seconds]
frett27_ has quit [Ping timeout: 264 seconds]
<Xavi92>
So it is not related to fmt or anything
<daurnimator>
Xavi92: sorry, you'll have to file it away with the rest of the `packed struct` bugs
* daurnimator
is out of knowledge to help
<daurnimator>
maybe mikdusan?
waleee-cl has joined #zig
layneson has joined #zig
dermetfan has joined #zig
TheLemonMan has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
xackus has joined #zig
foobles has joined #zig
marijnfs has quit [Ping timeout: 240 seconds]
<daurnimator>
andrewrk: I think the "Slicing with Comptime Indexes" section needs to be higher
marijnfs has joined #zig
<TheLemonMan>
oh today is the release day
<foobles>
:O
<fengb>
🤞
marijnfs has quit [Client Quit]
marijnfs has joined #zig
frett27 has joined #zig
frett27_ has joined #zig
zfoo has quit [Ping timeout: 240 seconds]
zfoo has joined #zig
<foobles>
a
<companion_cube>
🎉
zfoo has quit [Remote host closed the connection]
<fengb>
Hey we are the third result from Google search for Zig
<fengb>
Unfortunately we’re below a million “semantic results” :(
<ikskuh>
<TheLemonMan> oh today is the release day
<ikskuh>
\o/
<ikskuh>
i'm totally "out of date" on zig due to demo-partying the whole weekend
<ikskuh>
i've seen the whole revision live, hanging out in voice chats and chats
zfoo has joined #zig
<daurnimator>
speaking of party; who is up for a zig release party
<daurnimator>
(in maybe 10 hours-ish?)
<ikskuh>
\o/
<ikskuh>
i'm still in party mood, so why not
<fengb>
🎉
<daurnimator>
I suspect we'll get a bit of press off the release
<daurnimator>
so we can hang out and help the newbies as they file through
<fengb>
Gotta contain my snark
<ifreund>
i just adding building instructions to my project in case anyone gets a link from the release and tries to compile it :D
<fengb>
Ah good point
<foobles>
half-implemented compiler feature im testingworks only on comptime values, so i make an assertion instr_is_comptime()run a behavior test with a comptime blockassertion failed X)
<foobles>
wow that formatting got messed up
gazler__ is now known as gazler
* daurnimator
bed
* daurnimator
should wake up to a fresh release :D
<ifreund>
ah shoot it's gonna be right in the middle of the night for me i think
<fengb>
We need to invent a timezone where everyone is available :P
<ifreund>
maybe i just won't sleep :D
<TheLemonMan>
sleep is overrated
opidopiopi has quit [Remote host closed the connection]
layneson has quit [Quit: WeeChat 2.8]
<nephele>
fengb, we already have that, it's called sleep deprivation :DD
<fengb>
Australia, Americas, Europe, pick 2
<fengb>
Of course, here in 'murica, we only pick 1 anyway
Biolunar has quit [Quit: leaving]
<nephele>
Well, then the choice seems clear :) Let's hold a meeting in Atlantis
Biolunar has joined #zig
<marijnfs>
where can i find an example of a struct being used to create a closure?
<andrewrk>
docs are experimental and don't handle generics fully yet
<andrewrk>
in this case "var" means the type depends on previous parameters
<r4pr0n>
oh good to know
<r4pr0n>
thank you
<companion_cube>
"zig is a dependently typed, multi-stage impure language" is how you should pitch to academics, andrewrk
<andrewrk>
companion_cube, nice, that's perfect. I'm terrible at pitching to academics
<companion_cube>
:DDD
<andrewrk>
my usual pitch is, "I'm sorry I don't know what any of those words mean"
<companion_cube>
(well it'd talk to the type theorist crowd)
<companion_cube>
it's funny to see how you converged on a bunch of known things by trimming fat from C
<companion_cube>
I like it
<r4pr0n>
speaking about c, i understand that c uses dst,src for many things, but isn't it kind of counter-intuitive? wouldn't it be *simpler* to use src,dst in std.mem.copy e.g.?
<companion_cube>
or named arguments^W^W a struct
<andrewrk>
either way: src,dst or dst,src is a convention. so is your convention coming from C or from elsewhere? there's not really an objective answer
<TheLemonMan>
assignments use the `dst = src` form
<andrewrk>
the constness helps a bit. as long as your src is const, you can't mess it up
<r4pr0n>
well i guess for me it's coming from human languages: you normally say "copy this into that", not "copy into that from this"
<companion_cube>
copy that
omglasers2 has quit [Read error: Connection reset by peer]
<fengb>
It also matches C and Intel assembly fwiw
<fengb>
Oh you mentioned that. Shows how aware I am
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dddddd has quit [Ping timeout: 240 seconds]
klltkr has joined #zig
<alva>
In many human languages (e.g. Finnish) you can put the words in either order.
<r4pr0n>
well you can also in english, as I showed, but I (a non-native english speaker) think it's more idiomatic to use the src,dst variant
<r4pr0n>
but the c,intel asm syntax argument is also a good one
<r4pr0n>
so i'm not sure
<fengb>
English almost always does subject-verb-object
<fengb>
So doing verb(object, subject) is a bit backwards
<fengb>
Workaround is using a different verb
<r4pr0n>
well src is the subject in the sentence "copy src into dst"
<fengb>
Right, I'm agreeing with you :P
<r4pr0n>
oh yeah, then it makes sense xD
<fengb>
Hmm, now that I'm looking at it, these aren't subjects. "src" is the object, and "into dst" is a prepositional phrase
<fengb>
Verb object prepositional-phrase is also more natural though so you're still right :P
<r4pr0n>
oh yeah, right
<andrewrk>
zig and english are not very related
<fengb>
Yeah, Zig is actually sane
<fengb>
English is a bastard child of 3 different language families
<fengb>
Also literally because William the ~Bastard~ Conquerer :P
<r4pr0n>
Well for me the argument is kind of about if you focus more on being idiomatic for people coming from C or people new to systems programming
<r4pr0n>
which I'm not really sure about what the answer is
<alva>
Very thankful that Zig is not like English :)
<andrewrk>
I disagree that the order of dest,src parameters in mem.copy ties zig to C in any way
<foobles>
so 0.6.0 is officially released now?
<andrewrk>
nah not until the download page is updated
<r4pr0n>
no that's not really my point, I just think that for people that have experience with C, dst,src will be familiar, but for people new to the topic, src,dst will be easier
<andrewrk>
then it's 🎉 time
jjido has joined #zig
* andrewrk
watches the CI server race against zig-bootstrap building riscv64
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dingenskirchen has quit [Remote host closed the connection]
<redj>
ci.speed++;-)
joey152 has joined #zig
<r4pr0n>
Syntax Error, stopping CI Build.
<redj>
(special accepted syntax on release day)
<Snektron>
server ram module got hit by a cosmic ray and crashed
<r4pr0n>
server was running with overcommit enabled, other user allocated 100 petabyte, zig build was killed by oom killer
jjido has joined #zig
<andrewrk>
noooo
<r4pr0n>
btw, why did you use the tests for generating the docs and didn't just add a flag to analyze all of it?
<andrewrk>
because it would cause a compilation error
<andrewrk>
whether fd_t is an i32 or HANDLE for example depends on the target
<andrewrk>
it's also possible to have types depend on whether the compilation is a test run or not
<andrewrk>
test runs tend to reference more declarations
<andrewrk>
so more things make it into the docs
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<r4pr0n>
ah ok that makes sense
Xavi92 has quit [Remote host closed the connection]
dingenskirchen has joined #zig
<companion_cube>
could there be a doc page per target?
<companion_cube>
like a scrollbar to pick the target you want (and a sane default)
dingenskirchen has quit [Client Quit]
<andrewrk>
the merge_anal_dumps tool isn't done, but the goal is to have docs that support all targets at once
dingenskirchen has joined #zig
<andrewrk>
if that idea fails then yes we'll do the "pick the target" thing
<companion_cube>
ah yeah, so you could say "this field is in debug-*-*
<andrewrk>
yeah
<companion_cube>
pretty cool, you could see what's portable and what's… less portable
<andrewrk>
yep
<andrewrk>
it's vaporware tho
<andrewrk>
but hey, so was everything in the 0.6.0 release notes which is now released
<andrewrk>
err sorry I didn't publish it yet. don't party yet
<foobles>
vaporwave D:
<r4pr0n>
> but the goal is to have docs that support all targets at once
<r4pr0n>
and how would this look?
<r4pr0n>
would you have multiple definitions where the target is specified at for multiple fields/functions/structs?
Xavi92 has joined #zig
<r4pr0n>
oh the azure ci is done
sternmull has quit [Quit: Leaving.]
<ifreund>
time to party?
<andrewrk>
wait for it
<xackus>
spamming F5
marijnfs_ has quit [Ping timeout: 264 seconds]
<andrewrk>
fun fact: download/index.json is maintained by hand
<mikdusan>
me and trailing commas don't mix well with editing .json
<andrewrk>
same
foobles has quit [Remote host closed the connection]
<andrewrk>
the source tarball is smaller from 0.5.0 -> 0.6.0
<foobles>
wow! cool
<fengb>
Typo: "Format decmial 0.0" => decimal
<mikdusan>
0.5.0 - sizeof(lld) < 0.6.0
<Snektron>
0.6.0 newer than master
<Snektron>
hmm
<TheLemonMan>
"Now, stack traces work even in release builds" -> nah, they now work with PIE binaries (eg. clang-built stage1)
<TheLemonMan>
I didn't have enough time to polish the dwarf unwinder in time for this release :(
zfoo has joined #zig
<andrewrk>
ah, my bad
<andrewrk>
will update
<marijnfs>
how does comparison between different types work? with a float < int comparison, the int get converted?
dermetfan has quit [Ping timeout: 246 seconds]
<mikdusan>
marijnfs: allowed for comptime. disallowed for non-comptime.
<companion_cube>
oh, I didn't see `noasync`, awesome
<fengb>
I don't care what the release notes say. Your last name is totally Ikdusan
<mikdusan>
haha
<r4pr0n>
are release builds supposed to have stacktraces? i thought they'd be going in undefined behaviour? or do you just mean for errors returned in main?
<Sphax>
Congrats on the release, I'm excited to try out the async stuff in my project
<andrewrk>
alva, I'm not sure I've properly uploaded it to a keyserver. I should probably figure that out
<andrewrk>
I agree though, should switch to pgp signatures not sha256sum
<andrewrk>
pmwhite, it'll be fine, next CI run will update it
<Cadey>
andrewrk: i got zig using llvm 10 in nix-build, but now i'm getting a weird error in cmake: https://clbin.com/m8edz
<andrewrk>
Could NOT find lld (missing: LLD_LIBRARIES LLD_INCLUDE_DIRS)
<andrewrk>
looks like a missing buildInput
<Cadey>
oh
<Cadey>
i added lld and it's compiling now
<Cadey>
/nix/store/sq2b0dqlq243mqn4ql5h36xmpplyy20k-binutils-2.31.1/bin/ld: /nix/store/hkb0hmxmgkq27p6akzr1fjsnjma3xii5-clang-10.0.0/lib/libclangCodeGen.a(BackendUtil.cpp.o): in function `(anonymous namespace)::EmitAssemblyHelper::EmitAssemblyWithNewPassManager(clang::BackendAction, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream> >)':
<Cadey>
(.text._ZN12_GLOBAL__N_118EmitAssemblyHelper30EmitAssemblyWithNewPassManagerEN5clang13BackendActionESt10unique_ptrIN4llvm17raw_pwrite_streamESt14default_deleteIS5_EE+0xc33): undefined reference to `getPollyPluginInfo()'
<Cadey>
oh someone has a patch in the bug report thread
<Cadey>
let's try that!
<mikdusan>
marijnfs: basically you're going to need to see `--pkg-begin a a.zig --pkg-begin b b.zig --pkg-end --pkg-end` and then same thing but inverted if both packages depend on eachother
<marijnfs>
mikdusan: ah I see, so the dependencies part?
<marijnfs>
yeah that's not too bad
<Cadey>
seems to be building
<marijnfs>
thanks
<Cadey>
it built!
<fengb>
Yay!
<Cadey>
andrewrk: how do i run the zig test suite?
<andrewrk>
Cadey, you need a source checkout to run the test suite
<Cadey>
yeah i'm assuming nix-build does
<andrewrk>
since there is some rather lengthy test data, it's not shipped
<Cadey>
oh, it's snipped from tagged releases?
<andrewrk>
tagged releases have source, that counts as a source checkout
<Cadey>
cool
<Cadey>
gogo checkPhase
frett27 has quit [Ping timeout: 256 seconds]
frett27_ has quit [Ping timeout: 256 seconds]
ninjacato has joined #zig
foobles has joined #zig
<euantor>
Chocolatey package for 0.6.0 submitted, looks like a good release - thanks! Just awaiting automated checks and moderator approval now: https://chocolatey.org/packages/zig/0.6.0
<fengb>
🎉
<companion_cube>
andrewrk: so is the package manager for this cycle? would help attract more people I guess
<companion_cube>
yeah, but that's my point: if the compiler is self hosted, the PM is unlocked
<squeek502_>
the compiler is not fully self-hosted yet
<squeek502_>
"The theme of the 0.7.0 release cycle will be stabilizing the language, creating a first draft of the language specification, and self-hosting the compiler."
<Cadey>
/build/source/build/zig test /build/source/test/stage1/behavior.zig --library c --test-name-prefix behavior-x86_64-linux-gnu-Debug-c-multi --cache-dir /build/source/zig-cache --name test -target x86_64-linux-gnu --override-lib-dir /build/source/lib
<andrewrk>
companion_cube, the package manager is already unlocked, just needs zig code for networking, downloading, untarring, etc
<Cadey>
this fails but it doesn't have a stacktrace because debug info is stripped
<foobles>
can someone help me debug my feature Im trying to add to the compiler? I can explain the greater steps I tried to take. there is some issue with values I know at comptime not being seen as comptime-known
<foobles>
also making ir_analyze_bin_op_cmp recursive :p
<andrewrk>
Cadey, you passed -target x86_64-linux-gnu which means you are cross compiling
<andrewrk>
and you are on nixos, so the standard dynamic linker path is wrong
<andrewrk>
you can choose -target x86_64-linux-musl instead, or don't -lc, or pass -dynamic-linker with the correct path
<mikdusan>
foobles: suggest avoid recursive until one-time is working
<andrewrk>
Cadey, you can find a dynamic linker path with `ldd /usr/bin/env`
<foobles>
the whole feature is making it recursive '=D
<foobles>
im trying to add optional comparison
<foobles>
so if at comptime, both optionals have values, Im trying to recurse
<foobles>
on their values and compare them with each other
<andrewrk>
Cadey, what are you trying to do?
<mikdusan>
foobles: ah yes right
<foobles>
oh yes you are the one who i was talking with last night :)
<Cadey>
andrewrk: run the zig test suite in the nix-build so that i can verify the compiler as part of the build
<foobles>
i got it working (as in, compiling), but it is telling me that the values are not comptime known
<pmwhite>
Is the point of writing a *box just enjoyment? There's no benefit except perhaps code quality due to a better language, right?
<afontain_>
well, you may be using a better language, but your solution is less tested
<afontain_>
I think enjoyment is a valuable goal, that's how you learn after all.
<ifreund>
i mean the original busybox is great for embedded stuff due to the much smaller binary size since the various tools can share code
<r4pr0n>
is it possible to disable caching for zig cc?
<daurnimator>
pmwhite: its the dream of a no-$OTHERLANG-required OS
<daurnimator>
also, morning everybody :)
<daurnimator>
I see the release occured!
<fengb>
Hi good morning!
<r4pr0n>
good morning, i guess, it's 01:45 at night for me :P
<ifreund>
hah same r4pr0n
<r4pr0n>
has anyone tried to use zig cc with cgo yet?
<afontain_>
daurnimator: a no-C-required OS feel quite hard :P
<daurnimator>
afontain_: why?
<ifreund>
afontain_: redox has gotten pretty far without c
<afontain_>
well, depends if you want it to be daily-driver grade, of course
<afontain_>
also depends if you count programs in that goal or not
<daurnimator>
afontain_: you can write a kernel in zig; and then if you had a ziggybox you'd have a basic POSIX OS: on top of which you can have many normal apps
<pixelherodev>
`<andrewrk> it's deceitful because it changes the prompt to sh-4.4$` GAH I know it's so annoying
<daurnimator>
afontain_: kernel and core-utils is enough to claim it IMO.
<r4pr0n>
well the problem with zig cc is, that cgo for some reason moves the arguments in the CC variable away from the $0, so zig cc doesn't really work
<andrewrk>
r4pr0n, did you check that link
<terinjokes>
hopefully the first of many
<r4pr0n>
oh i'm sorry i only read the comment you linked to, not your answer, found the solution
<r4pr0n>
but i already tried that
<r4pr0n>
and got `unable to check cache when compiling C object: access denied`
<andrewrk>
you can affect the cache directory with XDG_CACHE_HOME
<r4pr0n>
that does work, it also creates it, but i still get that error