<daurnimator>
shritesh: looks like trying to print the File struct results in the functions inside getting compiled. but that fails cause they're windows-only
<shritesh>
Didn’t think of that. Thanks.
<shritesh>
What’s your go to for “dump this thing to stderr”?
<daurnimator>
shritesh: that was just a guess.. unless a function gets *called* it probably shouldn't be compiled?
<daurnimator>
andrewrk: ^ thoughts?
<shritesh>
That was it.
<shritesh>
I was also printing a File struct which probably doesn’t make sense
<shritesh>
(spoiled by REPLs)
st4ll1 has quit [Ping timeout: 272 seconds]
<fengb>
Just build size. I've tried both release-safe and release-fast and gotten slightly different results
<fengb>
Looks like the library version has a loop while @memcpy is fully unrolled
<fengb>
@memcpy also uses i64 instructions so it's probably faster
<daurnimator>
shritesh: IMO it *should* work -> printing the struct should only "check" the function prototype
<daurnimator>
emekankurumeh[m]: I hope you have backups?
<daurnimator>
after making a similar mistake recently I started using snapper (http://snapper.io/) to snapshot my system and home directories each hour/day/month
kristoff_it has quit [Remote host closed the connection]
<mikdusan>
re: big size for glibc versioning, maybe in the future, bits required for cross compiling can be treated as a lazy package
<ki9a>
you guys looked at alternative backends to llvm too ?
<ki9a>
(I was looking at cranestation myself, interesting idea, not far enough to be usable by me)
<mikdusan>
i haven't heard any talk from those who understand zig analysis, but mlir caught my attention a few weeks back
<tralamazza>
how do I pass compiler flags (e.g. --verbose-cc) to a build.zig project?
<mikdusan>
is this not working for you? `zig build --verbose-cc`
<tralamazza>
nop
<mikdusan>
things are cached in zig. if the build was already done, it won't do it again unless a dependency has changed.
<mikdusan>
you can tweak a source file to force it, or remove zig-cache directory
<mikdusan>
(by things i mean build artifcats)
<tralamazza>
aha
<tralamazza>
yes the cache
<tralamazza>
ty
<tralamazza>
is there a doc on the build.zig API?
<mikdusan>
not as of yet; i tend to look at std/build.zig looking for 'pub fn' functions. and then peek at the top-level build.zig for some hints at usage.
FireFox317 has joined #zig
<FireFox317>
mikdusan: not sure if you noticed, but andrewrk solved the issue i had yesterday :)
<mikdusan>
a side note: i ended up using my periods of "i need a distraction" to install an archlinux vm.
<mikdusan>
pretty cool. but i did bump into a weird "command-line-switch inconsistency" error of some kind using pacman llvm.
<FireFox317>
Jup archlinux is pretty cool xd
<mikdusan>
and just did my usual explicit minimal llvm in /opt and all is good.
<FireFox317>
I'm kinda new to working on a big project on git, how do you keep up with the master when i forked the project? What is your workflow for this?
<mikdusan>
first thing i like to do, is if you intend to keep up with upstream (what you forked from)
<mikdusan>
is always use a different branch.
<mikdusan>
so don't walk over branch names (like master) used in upstream. it just makes things easier imo
<mikdusan>
then you periodically checkout your fork master, do a pull. to keep it up-to-date
<mikdusan>
then switch back to your fork/branch and merge from fork/master
<FireFox317>
Ahh okay, thanks for the suggestions!
<mikdusan>
when i'm not sure about making a mess, i'll "save" my branch. like `git branch -m issue.1001 save.1001` then branch master -> issue.1001 and merge save.1001 -> issue.1001`
<mikdusan>
and then the beauty of this, at this point, i'll go to issue.1001 and `git rbase -i head~N` if needed.
<mikdusan>
rebase.
<mikdusan>
oh i never asked you, did you fork on github?
<FireFox317>
Jup, i did fork on github indeed
<mikdusan>
ah ok. there's kind of a neat way to handle that. so your local clone did you clone from fork or master?
<mikdusan>
(fork or upstream)
<FireFox317>
I cloned from my own fork and then added an extra remote to the upstream (ziglang/zig)
<mikdusan>
ok that's decent
<FireFox317>
Btw you are from the Netherlands too? xd
<mikdusan>
🇨🇦
<FireFox317>
Oh my bad ^^
<ki9a>
heh
<mikdusan>
hmm does archlinux have some kind of security? my fav `sudo zsh` just isn't going into zsh. it's always ending up in bash.
<FireFox317>
Uhm, should just work actually.
<mikdusan>
ah i got a workaround. strangely ~root needed some .zsh files to get around some poor assumption
<mikdusan>
not bad. 5GB filesystem in use, and able to build zig and muck around.
<FireFox317>
mikdusan: did you make a seperate user account or are you just using root? Because then you don't need sudo ofcourse
<mikdusan>
sep account for consistency with my unix'ish build environments.
<mikdusan>
i've got 3 vm now { ubuntu, arch, windows10 } that i can ssh into and build zig, use vim, cmake, and ruby scripting if needed
<FireFox317>
Nice, not bad. What os are you running yourself?
<mikdusan>
macos
<FireFox317>
Aaah, yeah make sense, that is the one that is missing in your vm list xd
marijnfs_ has joined #zig
<mikdusan>
after 11 years i upgraded a macpro to minimal-spec imac with big display, loaded aftermarket ram on it and running vms are actually convenient when you have globs of host ram (40GB)
Ichorio has quit [Ping timeout: 264 seconds]
marmotini_ has quit [Ping timeout: 246 seconds]
FireFox317 has quit [Ping timeout: 256 seconds]
FireFox317 has joined #zig
marmotini_ has joined #zig
return0e has quit [Remote host closed the connection]
<donpdonp>
o^O I've not see .optionA syntax before
<donpdonp>
i'll try that thx.
<andrewrk>
if the field type of optionA is `void` then you don't need the cast
<andrewrk>
unionVar == .optionA
<FireFox317>
andrewrk: How do I rebuild the std part of the compiler without rebuilding the complete compiler? Or turn off lazy analysis or something
<andrewrk>
FireFox317, `make install` only rebuilds what it needs to
<tgschultz>
donpdonp there's also a std.meta function: std.meta.activeTag(my_union)
<andrewrk>
to get help: show the code / what do you expect to happen / what is happening instead
<donpdonp>
if(@TagType(std.json.Value)(tokenKV.value) == .String) worked fine
<tgschultz>
FireFox317 it sounds like you may want to use --override-std-dir
scientes has quit [Remote host closed the connection]
scientes has joined #zig
<FireFox317>
Well, I'm working on a issue in std/zig/render.zig and if I change something in that source file and `make install`, I don't see the change in the actual compiler
<andrewrk>
what change? what do you expect to happen, and what is happening instead?
<FireFox317>
Sorry for being so vague, I'm working on `zig fmt` and I want to change the source code of that, so I add a std.debug.warn() in some code that I know is gonna run. Then I do a `make install` in zig/build and I expect that the change that i've made shows up in the new `zig fmt`, but it doesn't
<andrewrk>
FireFox317, ok I think I know what is happening here
scientes has quit [Remote host closed the connection]
<andrewrk>
zig build's caching system is solid. but cmake is controlling what happens with `make install`. unfortunately I couldn't figure out how to tell cmake, "just always run this zig build command, it does its own caching". so std/zig/render.zig (& more) need to be added to CMakeLists.txt
<andrewrk>
until then it works the same as it does in C, which would also have this behavior if you made a huge array on the stack
<marijnfs>
andrewrk: allright, so i get to try how allcoators work
<marijnfs>
ok sweet that works
allan0 has quit [Ping timeout: 245 seconds]
fengb has joined #zig
<fengb>
What should my allocator do if I call free() on unmanaged memory?
allan0 has joined #zig
<marijnfs>
how does one turn a i64 into f64? f64(x) doesn't seem to work when x is i64
<andrewrk>
fengb, unreachable
<fengb>
Ah okay
<andrewrk>
fengb, that situation is called "double-free" or "invalid free" and is not always detectable. in safe modes it's important to try to detect. in unsafe modes, assume it never happens
<andrewrk>
Xe, yes if you use build-exe. if that doesn't work then it's a bug
<Xe>
so main is a start function?
<andrewrk>
yes if you use build-exe with the wasm32 target, your main func is called from the start function
<Xe>
huh
<Xe>
so that's why it wasn't exposing a main symbol
<shritesh>
(This behavior recently changed in master)
<emekankurumeh[m]>
andrewrk: here is a patch to reproduce http://ix.io/1Kqu
<andrewrk>
emekankurumeh[m], confirmed, I can reproduce, thanks!
<andrewrk>
emekankurumeh[m], I think you may have found a way to reproduce this sneaky use bug that I've been suspecting exists
<fengb>
It's not a port. I took spiritual inspiration
<shritesh>
Umm. The start module entry isn’t actually being created for wasm. I’ll look into this.
<emekankurumeh[m]>
yeah another bug exists when trying to build example/hello_windows, in ir_analyze_instruction_import, pkg_root_src_dir changes to the cwd which is what is causing all the errors when trying to build that example
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 248 seconds]
<marijnfs>
arrays have a length in Zig right? how do i turn a [c*] and a length into such a type
<marijnfs>
so i can write it to a file
scientes has joined #zig
<fengb>
var ptr: [*c]u8; const slice = ptr[0..len]
<fengb>
arrays are compile time fixed size. Slices are runtime sized
<andrewrk>
well that's the main benefit of doing it yourself: if you realize you did it wrong you can just change it to be correct :)
<shritesh>
Yeah.
<andrewrk>
if the bug is in your own code it's a lot easier to fix
<andrewrk>
I had permissions to "reopen" the ticket so let's see if that does anything
halosghost has quit [Quit: WeeChat 2.4]
<shritesh>
I find it funny how this has rippling effects. “We won’t do start because emscripten and C++” -> “WASI needs a separate start function because nobody uses start.” https://github.com/WebAssembly/WASI/issues/19
<fengb>
Never underestimate the amount of duct tape in software
<shritesh>
Xe: a stopgap solution would be to use wasm2wat and wat2wasm to manually add the start section `(start $_start)`
<andrewrk>
my attitude towards this stuff is "ok but how *should* it work? we need to prioritize that working too, even if nobody uses it yet"
<shritesh>
Add it to our fork of lld?
<andrewrk>
yeah we can do that, but ideally work with upstream to get it merged there too
<andrewrk>
the idea is to eventually get down to 0 patches and stop maintaining a fork
<andrewrk>
right now we're at 1
<Frank-Lesser>
I have stil the problem to compile hello_windows.zig with the latest master
<andrewrk>
Frank-Lesser, I haven't looked at that yet
<Frank-Lesser>
hi andrew, thx for fast answer - just was guessing from the commit messages that windows was touched.
<Frank-Lesser>
it comes from src\ir.cpp line 17712, I am not enough into the ZIG src ( stil learning in my freetime ) to fix that
<marijnfs>
sweet my mandelbrot in zig is working, zig does develop fast
<mikdusan>
emekankurumeh[m]: 24 minutes is a very long time. may i ask which host?
<emekankurumeh[m]>
what do you mean by host?
<mikdusan>
platform
<emekankurumeh[m]>
oh, windows 7 64-bit
<Xe>
that should actually be failing a build
<Xe>
it's not
<Frank-Lesser>
sry for just putting errors here - under windows - if a zig exe is locked - I was debugging it with WinDebug - the zig compiler doesn't complain that the output can't be written
<emekankurumeh[m]>
why would it fail
<emekankurumeh[m]>
Frank-Lesser: i think there is an open issue for that
<Xe>
emekankurumeh[m]: there's no reference to the type Resource
<emekankurumeh[m]>
that means that cwa_main isn't being compiled
<Frank-Lesser>
ah ok
<Xe>
why isn't it?
<emekankurumeh[m]>
try adding export to the function declaration
<andrewrk>
so if bootstrap.zig wants to learn the subsystem value it has to check builtin and then fall back to looking to see if the root source file has those functions
<lygaret>
hi all, is there an idiomatic way to handle bitflags in 0.4.0? I'd really like to be able to push them into an enum and then OR them together, to get the base type. I've got a simple method right now that just reduces over them, but pushing this into every flag type, plus the requisite array an casting makes it pretty overkill feeling: https://gist.github.com/lygaret/d09bd3db176a664db593250477171bb9
<lygaret>
If I understand correctly, https://github.com/ziglang/zig/issues/208 will clean up the enum name and array syntax, but if that's the case, am I correct in thinking the explicit `with` is the best way to go here?
<andrewrk>
lygaret, an enum isn't a good fit for bit flags. if you want some kind of type safety on top of regular integers, maybe you could try a packed struct of u1 fields
<shritesh>
Nice.
<andrewrk>
hot code reloading might end up fitting nicely with the planned design of stage2
<andrewrk>
where the compiler itself stays running
<andrewrk>
so it would know, for example, exactly what you changed and exactly what must be updated in the live running binary
<lygaret>
would you have to provide a value for each field? I'm working through yours and AndreaOrru's zen os, and for flags in the multiboot header, there may be 75 fields, where I want to be selecting only one.
<Sahnvour>
and this is way better than dynamic libraries, i'm really hyped for this feature
<andrewrk>
lygaret, my honest opinion is that unsigned integers are the best thing zig has to offer for bit flags
<lygaret>
ok, that's fair
<emekankurumeh[m]>
so zig would patch the executable file?
<andrewrk>
emekankurumeh[m], it would be in some ways operating system-dependent. it probably wouldn't work in freestanding mode for example
<andrewrk>
this is a research topic so I can't say exactly how it will work
<Sahnvour>
andrewrk, if you didn't already, have a look at live++
lygaret has quit [Remote host closed the connection]
<andrewrk>
but some of the concepts involved are atomic function pointer swapping, leaving extra padding in structs in case fields are added
<andrewrk>
the thing that works the best will be changing function logic. the thing that will work the worst will be changing global variables which are already initialized
<andrewrk>
comptime actually works against hot code swapping, so that's a bit of cognitive dissonance
<andrewrk>
Sahnvour, noted, thanks!
lygaret has joined #zig
<lygaret>
I have seen proposals for distinct types or something too, so I'll follow those. Thanks for your feedback.
<andrewrk>
lygaret, it is planned to have default struct initialization fields btw
<andrewrk>
so you could set all your fields to 0. that might make packed structs attractive to you
<lygaret>
Yeah that would definitely work
<lygaret>
I'll search GitHub for an issue to follow there
<Sahnvour>
the biggest problem happens when modifying struct layout I think, but compiler support can definitely help where C++ hot reload is stuck, for example
hio has quit [Quit: Connection closed for inactivity]
Frank-Lesser has quit [Ping timeout: 256 seconds]
<andrewrk>
I think for build-exe -target wasm32-freestanding, we just export a start function with the understanding that it's the intended entry point
<andrewrk>
the thing you linked seems to be for initializing constructors, which we definitely don't want, and the fact that other languages need those is causing a lot of confusion and spinning in circles
<shritesh>
Makes sense. But if the memory isn’t available, I dunno if we can do much in the start function
<andrewrk>
right. we don't want to put anything in there. it's for static constructors
<andrewrk>
we don't have those. we just want to export a nice start function for the user to call
<andrewrk>
if it's just a start function by convention and not recognized by the spec, that's probably fine
<andrewrk>
the name of it can be defined somewhere else, e.g. how WASI does it
<shritesh>
Yeah. We’re assuming the programmer is aware of this restriction?
<shritesh>
The start function doesn’t even have to be named. Functions are identified by a number.
fengb has quit [Ping timeout: 256 seconds]
<shritesh>
I think wasm-lld’s correct behavior would have been to not export the _start function by name
Sahnvour has quit [Quit: Leaving]
<andrewrk>
should we always pass --no-entry and then name the function `start` (no `_`)?
<andrewrk>
build-exe just means there is a canonical entry point
<shritesh>
In the current implementation, --no-entry is only used to mark _start as exported.
<shritesh>
*unmark
<shritesh>
I think we can just stick with _start
<shritesh>
Unless we are exporting for the start segment
<andrewrk>
I don't think we care about the wasm start segment
<shritesh>
Then we don’t need to change anything
<andrewrk>
I mean we can expose it as a feature if it's a desired use case, but I don't think anyone has one
<shritesh>
We can put off on that until the spec/ecosystem figures out how to handle that
<andrewrk>
agreed
<gamester>
andrewrk: You're an excellent language designer. In the past I would have disagreed on some designs and I'm sure there have been features that I've wanted that are not in the language, but I've come around to every single feature / lack of feature in Zig. That's insane. I guess there's only that I don't understand why loop variables have to be initialized outside of the for expr, though having said that I 100% do not want initialization inside
<gamester>
if statements. That reads so badly imo.
<andrewrk>
hey thanks gamester those are kind words
<andrewrk>
it's just trial and error. you can see the design process in action with coroutines where I'm rewriting the whole thing, and I'm on my third copy-elision implementation attempt
<gamester>
yeah we're all excited for copy elision which looks to be another simple and well designed feature that will need no language lawyers to understand