<r4pr0n>
and this is the command to compile I used: `zig cc test.c -L . -lsfhandler`
<r4pr0n>
though for some reason I can't get it to compile with clang or gcc, just with zig cc
<r4pr0n>
or rather to link, I get the error `/usr/bin/ld: ./libsfhandler.a(./sfhandler.o): relocation R_X86_64_32S against `.bss' can not be used when making a PIE object; recompile with -fPIE`, maybe I'm doing something wrong after all
<r4pr0n>
oh and of course I did `zig build-lib sfhandler.zig` before the compilation
layneson has quit [Quit: WeeChat 2.8]
return0e has quit [Read error: Connection reset by peer]
return0e has joined #zig
return0e has quit [Client Quit]
<marijnfs_>
can zig do anonymous functions now? at least locally in a function?
marijnfs1 has joined #zig
<Xavi92>
Are optionals functionally similar to tagged unions with None and Some?
marijnfs has quit [Ping timeout: 260 seconds]
marijnfs has joined #zig
<fengb>
marijnfs_: yes by using a wrapping struct: `const func = (struct { fn func() void {} }).func;`
return0e has joined #zig
<Xavi92>
Which versions of llvm/lld/clang is zig able to compile under?
marijnfs_ has quit [Ping timeout: 265 seconds]
darithorn has quit [Remote host closed the connection]
<Xavi92>
Took this fork https://github.com/impiaaa/llvm-project because of the preliminary MIPS I support, but after the (really long) process of compiling llvm/lld/clang, compiling zig failed at the very beginning, much likely due to breaking changes on clang interfaces
<r4pr0n>
Xavi92: You need LLVM 10 for the latest master
<r4pr0n>
what error did you get?
r4pr0n has quit [Quit: r4pr0n]
<Xavi92>
Oh, r4pr0n left
marijnfs_ has joined #zig
marijnfs2 has joined #zig
<Xavi92>
Well, I've merged master branch from the llvm official repo and into the fork. Now I'm getting CMake-related errors when the Makefile's are being generated, probably due to an old CMake version being installed (3.10.2)
<Xavi92>
I'll try it again tomorrow - now it's bed time!
<andrewrk>
idea is just to show how the language has changed from 0.5.0 to 0.6.0
<andrewrk>
the number of contributors and contributions has doubled since last time
<pixelherodev>
andrewrk, sure
<pixelherodev>
I haven't really done much code-wise, if I can help with this I'll gladly do so
<pixelherodev>
GitHub PR is preferred method of contribution?
<pixelherodev>
also, is that rocket comment needed? :P
emekoi has joined #zig
<emekoi>
it's been a while since i last built zig from master, but i think the time has gone done by over 50%
<fengb>
Hiya welcome back!
darithorn has quit [Quit: Leaving]
<emekoi>
is building on windows, via make/ninja still supported?
<mikdusan>
emekoi: time-to-build is down because as of llvm10 we no longer build llvm sub-project `lld` with zig
<emekoi>
all our patches were incorporated?
<emekoi>
i remember reading about work on lld for macho restarting]
<mikdusan>
the upstream lld fixes happened yes, I don't know the details
<mikdusan>
macho stuff sounds promising
emekoi has quit [Ping timeout: 240 seconds]
emekoi has joined #zig
<emekoi>
does anyone if @tagName crashes when given an exhaustive enum?
<emekoi>
hmm, i think i found a bug
<emekoi>
is there a way to check if a non-exhaustive has a named field?
Spex_guy has quit [Remote host closed the connection]
emekoi has quit [Remote host closed the connection]
nycex has quit [Quit: Quit]
nycex has joined #zig
<tdeo>
hm, i'm trying out zig and rust for writing a pebble watch app, and it seems for a function that returns a 64-bit struct by value, zig gets the abi wrong
<tdeo>
in zig's llvm ir it's `%GRect (i8*)`, but in rust's output it's `void (%"sys::GRect"*, %"sys::Layer"*)`, where the signature in c is `GRect layer_get_bounds(const Layer *)`
<tdeo>
the rust one gives me the correct result, zig one doesn't
<tdeo>
flags -target arm-freestanding-eabi -mcpu cortex_m3 for zig, and target thumbv7m-none-eabi for rust
<shakesoda>
tdeo: struct returns by value do some funky stuff sometimes i've found
<shakesoda>
i ran into some issues that sound awfully similar to this when i was getting imgui working in my sandbox
<shakesoda>
some struct parameters by value are funky too
<daurnimator>
tdeo: which `callconv()` did you use?
cole-h has quit [Quit: Goodbye]
<tdeo>
callconv(.C)
r4pr0n has joined #zig
<r4pr0n>
andrewrk: a few days ago you told me how to enable the zig segfault handler in c programs. i tried that and it actually panics: `Panicked during a panic. Aborting.`
<r4pr0n>
and this is the command to compile I used: `zig build-lib sfhandler.zig && zig cc test.c -L . -lsfhandler`
<r4pr0n>
though for some reason I can't get it to compile with clang or gcc, just with zig cc
<r4pr0n>
or rather to link, I get the error `/usr/bin/ld: ./libsfhandler.a(./sfhandler.o): relocation R_X86_64_32S against `.bss' can not be used when making a PIE object; recompile with -fPIE`, maybe I'm doing something wrong after all
<r4pr0n>
I'd report an issue but I'm not sure if this is my fault
<TheLemonMan>
tdeo, the C ABI is only (badly) implemented for x86_64
<TheLemonMan>
don't expect anything but integer/pointers to work, and even then you cannot trust the values to cross the boundaries correctly
<daurnimator>
tdeo: then why do we have arm32 freestanding as tier 1 support?
<daurnimator>
uh *TheLemonMan
<TheLemonMan>
I don't know?
<daurnimator>
TheLemonMan: is there a relevant issue open for it? I'm not seeing one
<TheLemonMan>
no, there are a few issues about values getting corrupted
dermetfan has joined #zig
<pixelherodev>
Proposal: `zig fmt` should be able to run on C/C++ files
<pixelherodev>
Compiler shouldn't enforce it though
<pixelherodev>
Just as a useful touchup
dermetfan has quit [Ping timeout: 260 seconds]
_Vi has joined #zig
gazler__ has quit [Quit: Leaving]
gazler has joined #zig
neceve has joined #zig
<wilsonk>
r4pr0n: you still here?
<r4pr0n>
yeah
<wilsonk>
you can build the sfhandler.o file using zig with the --bundle-compiler-rt flag and -fPIC to solve your issues with using clang/gcc instead of zig cc
<wilsonk>
...still get the same 'panicked during a panic' but at least you can test with clang/gcc if needed
<TheLemonMan>
panicked during a panic? that's bad
<TheLemonMan>
do you have the source code for that binary?
<r4pr0n>
Okay -lc seems to make it work with zig cc, your compiler flags fix that issue, but now i get https://bpaste.net/7GOA
<wilsonk>
TheLemonMan: up above r4pr0n listed the three files at 1:35:28 AM
<TheLemonMan>
r4pr0n, -fno-stack-check
<r4pr0n>
thanks
<r4pr0n>
now it works
<r4pr0n>
though i guess i'm missing some debug symbols
<wilsonk>
r4pr0n: just to be clear, you only need the --bundle-compiler-rt flag if you are going to build the c binary with clang/gcc and not 'zig cc'.
<r4pr0n>
oh okay
<r4pr0n>
i just tested and "-g" kinda makes it work but also not a 100% https://bpaste.net/NXWQ
<TheLemonMan>
well that's the best you can get, unless you compile the libc with the frame pointer enabled
<r4pr0n>
so you mean i would have to recompile glibc?
<TheLemonMan>
there are no more interesting frames below the "main" one
<TheLemonMan>
you have __libc_start_main but as I said that as no frame pointers
neceve has quit [Ping timeout: 256 seconds]
<r4pr0n>
that's true, it's just that it doesn't really work for the "real project" i wanted to use it for, even though i added -g
<r4pr0n>
but i guess i'll look into why that's not working
<TheLemonMan>
can you show the non-working backtrace?
<wilsonk>
TheLemonMan: do you build LLVM very often?
<TheLemonMan>
no crash :(
<r4pr0n>
hm that's weird
<TheLemonMan>
wilsonk, I'm testing a patch
<TheLemonMan>
running the test suite is another huge time sink
<wilsonk>
not sure if you have tried building clang with LTO+PGO but I built it a couple nights ago and it dropped subsequent LLVM builds by about 23%...just so you know. So if you have to build LLVM a lot it might be worth the effort of LTO+PGO
nycex has quit [Remote host closed the connection]
nycex has joined #zig
<wilsonk>
LTO+PTO (and I would try facebooks bolt on top of that except my EPYC machine doesn't support pmu) takes about 2 hours on a 64 core machine, so it could take A VERY LONG TIME on a quad core or similar machine. Just so you are aware :)
<wilsonk>
*PGO
<TheLemonMan>
it's not much of a problem, incremental rebuilds are pretty fast
<r4pr0n>
TheLemonMan: oh actually i think it only crashes in neovim, maybe you can try that, i'm not exactly sure why
<TheLemonMan>
one more reason not to use neovim!
<r4pr0n>
xd
<r4pr0n>
what are other reasons though, overall i like it more than vim actually
<TheLemonMan>
still not crashing
<wilsonk>
TheLemonMan: the other problem was that the LTO+PGO clang binary went into an infinite loop when bulding zig0?!? And I mostly did all this just to test and see if I could get the zig build time improved...what a pain :(
<r4pr0n>
sometimes you need to try it 2-3 times or so
<TheLemonMan>
wilsonk, hard to tell where the problem is with such a convoluted pipeline heh
<wilsonk>
yep
<TheLemonMan>
r4pr0n, I've tried at least 20-30 times :\ what font are you using?
<r4pr0n>
hm...
<r4pr0n>
i'm using liberation mono for that currently
daex has quit [Ping timeout: 265 seconds]
daex has joined #zig
<TheLemonMan>
welp it's still not crashing
<r4pr0n>
i'll try to debug when exactly it's crashing, maybe it's some neovim config setting, but it's kinda indeterministic (it just didn't segfault after a bunch of tried with the same neovim config with which it did crash before?!), i'll write in here again when i found out what's the problem
<TheLemonMan>
the dwarf parser doesn't find any problem with the debug info so *shrug*
<r4pr0n>
hm okay
<r4pr0n>
well now i'm at the point where it doesn't even segfault with my nvim config and all even though i did it exactly like before 😕
<pixelherodev>
The number of times I've gone to ask a zag question here and then remembered it was extremely simple to parse and I could just check /usr/local just went into the double digits I think :)
<pixelherodev>
Things not to `comptime`, part three: SHA256 hashing :P
<r4pr0n>
why not :D
<pixelherodev>
Try it.
<pixelherodev>
You'll see why not.
<pixelherodev>
:P
<pixelherodev>
It works (probably, I didn't let it finish)
<pixelherodev>
But it burns CPU like mad
<pixelherodev>
It's inefficient and wasteful.
<pixelherodev>
Running it thousands of times at runtime would still be faster than running it once at comptime
<pixelherodev>
Source: in debug mode it finishes in milliseconds at runtime. I interrupted it after it ran for >1 minute
<pixelherodev>
in comptime that is
<pixelherodev>
If I'm mean and say it took 100 ms (pretty sure it was faster), that's still >360 times faster in debug mode. Plus, I didn't let it finish in comptime, and there's always release mode for real speed
<pixelherodev>
s/360/600 (sorry I'm tired)
<pixelherodev>
Anyway, I'm going to get back to test-casing my dynarec (the hashing is to ensure it's using the ROM it knows how to test)
dddddd has joined #zig
<r4pr0n>
well i guess that could be optimized in comptime, couldn't it?
<r4pr0n>
that speed difference is much more significant than it should be
<pixelherodev>
Oh of course
<pixelherodev>
comptime's implementation right now isn't focused on speed as I understand it
<pixelherodev>
Performance of self-hosted comptime is intended to match CPython is what Andrew's said a few times IIRC
<pixelherodev>
(That's slang for If IRC, which coerces to true)
<wilsonk>
I also build llvm-10.0.0 on Ubuntu-16.04, buster, MacOSX Catalina and win10. Each of those had clang-9 available because I had previously built 9 for zig development. And I haven't tried llvm git head at all...just the src download of 10.0.0
<wilsonk>
does 'sudo apt list |grep clang' show a newer clang available?
<Xavi92>
wilsonk: up to clang-9
<wilsonk>
yeah, see if you can upgrade to clang-9 perhaps. I have the LLVMDistributionSupport.cmake available so I assume that comes with a newer clang
<wilsonk>
Oh, actually it looks like you were trying to run cmake in the ..llvm-project/clang directory? You have to run an out of tree build at the top level for llvm/clang so you should make a 'build' dir under llvm-project (and clang should be uncompressed under llvm-project/tools...compiler-rt and lld under llvm-project/projects if you need them), and then do a 'cmake .. <options>...' in the 'build' dir
<wilsonk>
you can't build directly in the clang (or lld/compiler-rt or whatever) directories
<wilsonk>
I would definitely pick up the source release (ie. 10.0.0) if you are going to do much with zig. That is the 'release' that is supported and llvm/clang move so fast things might have already broken for building zig with git HEAD
<Xavi92>
The former includes preliminary support for MIPS I, which hasn't been included into upstream yet
<wilsonk>
oh, hmmm
<wilsonk>
one second
<Xavi92>
wilsonk: llvm has a release/10.x branch, though
<wilsonk>
actually, no I just looked at my llvm-project build on another server and it should work with 'cmake ../llvm'
<wilsonk>
that will still pick up clang, I believe
<wilsonk>
Oh, nope you will need to specify which subprojects with
<Xavi92>
wilsonk: what if I cherry-pick MIPS I support into release/10.x?
<wilsonk>
yeah, those instructions are only for the source tarballs, not for the git clones
<wilsonk>
right at the top of that page is the download links for the tarballs...git is a little different
<Xavi92>
But yesterday that worked for https://github.com/impiaaa/llvm-project , master branch. Could have got everything up and running if zig hadn't failed compiling
<wilsonk>
hmm, are you sure those exact instructions worked for impiaaa? Because the build instructions on that website are exactly what I am following for llvm git. See about mid way down where you have to choose the projects and 'cmake ../llvm'?
<wilsonk>
you also might want to pick a different generator (like Ninja if you have it installed) but otherwise things should work fine by following those instructions on impiaaa exactly
<Xavi92>
wilsonk: I swear they worked. I'll try again with release/10.x, for the sake of doing it
<wilsonk>
impiaaa is a few months old also, so I would merge the 10.0.0 RELEASE tagged llvm into it and then build that...just to be sure that zig will build afterwards
<Xavi92>
wilsonk: yeah, that's what I'm referring to. Let's see what happens :)
<Xavi92>
Right, cmake worked
<wilsonk>
hmm, that impiaaa repo is only one commit ahead of llvm (and then 11850 behind master). I would download the 10.0.0 src tarballs and then hand modify the four files in that commit by hand. Not much there really (unless I am missing a bunch of other commits or something)
<wilsonk>
oh, ok...well if cmake worked then hopefully the rest will
<Xavi92>
Let's hope so :)
<wilsonk>
I would just hate to have to wait an hour or two (depending on your machine) to build llvm only to watch it fail :( But if you got the 10.0.0 release then it should be ok
<wilsonk>
*fail on zig
<wilsonk>
ok, good luck. I am off to bed o/
<Xavi92>
Night!
<ifreund>
is there any fancy way to iterate over a slice in reverse? or do i just need to use a while loop?
marijnfs has joined #zig
dermetfan has joined #zig
dermetfan has quit [Ping timeout: 246 seconds]
CommunistWolf has quit [Quit: No Ping reply in 180 seconds.]
CommunistWolf has joined #zig
nmeum has joined #zig
<nmeum>
hey, I am currently experimenting with freestandig zig and I was just wondering: If I have a function returing a struct how is memory for it actually allocated? for example: https://tpaste.us/rePV
FireFox317 has joined #zig
<ikskuh>
nmeum, in zig functions there's a result location passed as a hidden parameter
<ikskuh>
there isn't documentation on that already
<ikskuh>
but in short:
<ikskuh>
your function does not "return" value but it just constructs the value where it will be located in the end
<ikskuh>
so if you do
<ikskuh>
var foo = rxctrl.init();
<ikskuh>
the return value is in "foo"
<nmeum>
ah!
<nmeum>
and if foo is part of a function body it is stored on the stack of that function, right?
<nmeum>
neat!
waleee-cl has joined #zig
gazler has quit [Read error: Connection reset by peer]
<Xavi92>
TheLemonMan: it still triggers the same errors, though
jessermeyer has joined #zig
<ifreund>
am I not allowed to have an anon list of anon structs like so? https://paste.rs/EmQ
<jessermeyer>
For the last few days on the Master Window's build I get the following linker error just building my program : lld: error: undefined symbol: _tls_index >>> referenced by C:\dev\Zig\lib\zig\std\debug.zig:258>>> .\win32_tbd.obj:(std.debug.panicExtra)>>> referenced by C:\dev\Zig\lib\zig\std\debug.zig:260>>>
<jessermeyer>
.\win32_tbd.obj:(std.debug.panicExtra)>>> referenced by C:\dev\Zig\lib\zig\std\debug.zig:289>>> .\win32_tbd.obj:(std.debug.panicExtra)
<jessermeyer>
I don't override the panic handler.
<jessermeyer>
Any suggestions how to help me narrow this down for a issue tracker?
<fengb>
ifreund: tuples aren’t iterable by for. You need to coerce it into an array or use inline for
<ifreund>
i get an unable to evaluate const expression error pointing to the line of the for stateme
<ifreund>
ah thank fengb
<TheLemonMan>
jessermeyer, how are you building that?
<TheLemonMan>
jessermeyer, I think that's the problem, you're somehow avoiding the inclusion of start_windows_tls.zig
<ifreund>
i feel like in an ideal world you should be able to :D
<fengb>
I don’t think Zig type inference will ever get there
<TheLemonMan>
Xavi92, that's all you needed to change? that doesn't really explain the error during the lowering phase
<fengb>
It’s hard to match anon structs with its parent without explicit types. Tuples work around it because they don’t require the same types, but that’s also why you can’t do a for loop
<jessermeyer>
If it helps, I can get the error on the tinier test programs just by switching main() to WinMain()
<ifreund>
that's fair, i can live with it
<jessermeyer>
And I don't need subsystem for the error to occur.
<jessermeyer>
I think I have a minimal repo, so I'll add a issue ticket.
<TheLemonMan>
yeah check out start.zig
<TheLemonMan>
you can fix by unconditionally including that damn file if the target os is windows
<jessermeyer>
Thanks!
FireFox317 has joined #zig
<Xavi92>
TheLemonMan: that's all I did. Took release/10.x branch from https://github.com/llvm/llvm-project and cherry-picked that commit into it
<Xavi92>
Well, there was a missing static member that I had to add so it compiled, but it's a very minor change
<ifreund>
nice, i can at least avoid giving the type a name https://paste.rs/nKw
<TheLemonMan>
Xavi92, I'll have a look
<Xavi92>
Thanks, TheLemonMan
<jessermeyer>
Haahaaa, Ok, so I @import("start_windows_tls.zig"); if the builtin os is windows, and now I get lld: error: duplicate symbol: _tls_index .... :/
<jessermeyer>
Which obviously implies it was already being exported.
<jessermeyer>
An alternative explanation is that the if condition was evaluated twice somehow?
<tdeo>
so it'd presumably need manual support in every other llvm frontend
<TheLemonMan>
yes
<TheLemonMan>
as I told you earlier today Zig does a bad job for x86_64 only
<nmeum>
I am using packed structs to represents memory mapped registers of a uart peripheral. It works so far, unfourtunatly, some register bits are reserved can I somehow mark the struct members representing them as unexported/hidden? https://tpaste.us/PMzy
<TheLemonMan>
no
<nmeum>
unfortunate
<tdeo>
TheLemonMan: could you point me to where that's determined in the zig stage1 compiler? i want to see if i can fix it reasonably without just adding a special case for this
<nmeum>
I guess I will just name them _ and __ then
<TheLemonMan>
tdeo, iter_function_params_c_abi
drp has joined #zig
<TheLemonMan>
the ARM ABI is reasonably simple, fixing the compiler is hard because the logic is all over the place
jessermeyer has quit [Remote host closed the connection]
<TheLemonMan>
Xavi92, can you try with -mcpu=mips1+soft_float ?
FireFox317 has quit [Ping timeout: 265 seconds]
darithorn has joined #zig
<shakesoda>
mips1... ps1?
cole-h has joined #zig
<shakesoda>
what happened to len on alignedarraylist
<BaroqueLarouche>
you need to do items.len now
<shakesoda>
ok
<shakesoda>
thanks
<nmeum>
I am trying to store a hashmap as a struct member, my initialization code looks as follows: https://tpaste.us/6Va8 when I try to put values into this map using self.map.put I get a `cast discards const qualifier` error, how do I fix that?
<shakesoda>
nmeum: s/const/var/
<nmeum>
for alloc or for the Plic type itself?
<shakesoda>
either alloc or where you're calling this
* shakesoda
just woke up, and isn't all here yet
<nmeum>
calling what?
<nmeum>
the hashmap put function?
<fengb>
That’s like me but all the time
<shakesoda>
nmeum: what is your buffer space declared as
<nmeum>
> var irq_handler_buffer: [@sizeOf(*u32) * INTERRUPT_SOURCES]u8 = undefined;
<shakesoda>
this can happen where you initialize the thing (if you assign to a const then put something into the map) or if your self parameter is *const
<shakesoda>
or you're doing something like putting in &foo
<shakesoda>
instead of foo, for the function arg
<shakesoda>
(which doesn't look like the case)
<nmeum>
ah
FireFox317 has joined #zig
SebastianM has joined #zig
<nmeum>
changed the self in the method using it from `self: Plic` to `self: *Plic` and changed the initializer accordingly, that seems to work
<nmeum>
thanks!
SebastianM has quit [Quit: leaving]
waleee-cl has quit [Quit: Connection closed for inactivity]
nycex has quit [Remote host closed the connection]
<Xavi92>
shakesoda: yup, trying to compile zig for the PS1 :)
<TheLemonMan>
Xavi92, ok so now open compiler_rt.zig and chop away the line with @include("atomics.zig")
<marijnfs>
frett27: your program builds fine for me
<frett27>
marijnfs, on master ?
<marijnfs>
juop
<frett27>
there is a regression, on april 2, it works
<Xavi92>
TheLemonMan: great! That made it compile
<frett27>
on my plateform
<marijnfs>
what are you running on
<Xavi92>
Which features have been stripped away with that line? Still don't know about how zig handles atomicity
<marijnfs>
maybe try different libc?
<frett27>
marijnfs, i use the standard one, but it was working, i'm on progress on the bisect
<TheLemonMan>
mips ISA < 3 are missing the necessary opcodes to implement the atomic ops iirc
decentpenguin has quit [Quit: decentpenguin]
<shakesoda>
Xavi92: exciting
<TheLemonMan>
and I doubt you care about smp when targeting mips1 heh
<Xavi92>
TheLemonMan: definitely :)
<TheLemonMan>
we need more compile-time logic to avoid pulling in those builtins on weak/old platforms
<Xavi92>
shakesoda: have done stuff with the PS1 in C for years and was looking for something else. There's a Rust-based SDK out there, but LLVM did not (and it still doesn't) compile to MIPS I, where this issue still applies zig, too
<TheLemonMan>
the mips1 backend should be pretty much functional
<Xavi92>
But I noticed there's a patch available for LLVM, so I wanted to write in zig so I have an excuse to learn it :)
<TheLemonMan>
I had a look and they've added some code to lower the conditional moves to something equivalent
<TheLemonMan>
the patch adds support for the load-delay slots
waleee-cl has joined #zig
<TheLemonMan>
I stand corrected, mips2 is the earliest isa with support for smp
<nmeum>
quick question regarding left shifts, the doc states that: `b must […] have a type with log2 number of bits as a` so if a is a u32 and b is a u5 that should work, right? because https://tpaste.us/zazW doesn't work for me
<nmeum>
fails to compile with `LHS of shift must be an integer type, or RHS must be compile-time known`
<Xavi92>
TheLemonMan: "we need more compile-time logic to avoid pulling in those builtins on weak/old platforms" -> that'd be really interesting. I think zig should focus into small microcontrollers, where C is still king with all of its well-known quirks
<TheLemonMan>
Xavi92, I'm refining the logic every time a new problem pops up, the huge combination of architectures/isa revisions/flags make that a non-trivial task
<Xavi92>
TheLemonMan: sure it does. I'm happy to know there's already such intention from the team
<TheLemonMan>
1 has type comptime_int and has an infinite number of bits
emekoi has joined #zig
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 250 seconds]
haliucinas has quit [Quit: leaving]
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
haliucinas has joined #zig
octetta has quit [Quit: My Mac Pro has gone to sleep. ZZZzzz…]
leth has joined #zig
<leth>
how do i properly print out a numerical value to stdout? I can't seem to get it right from reading the horribly manual.
foobles has joined #zig
<foobles>
hello
<darithorn>
leth are you trying to format the value or just print it?
<ifreund>
hey, is there a good way to run external commands in a build.zig other than using ChildProcess or something?
layneson has quit [Quit: WeeChat 2.8]
ave_ has quit [Quit: Ping timeout (120 seconds)]
ave_ has joined #zig
Akuli has quit [Quit: Leaving]
lunamn has quit [Quit: Ping timeout (120 seconds)]
ave_ has quit [Read error: Connection reset by peer]
lunamn has joined #zig
<ifreund>
ah nice, I found exec in std/build.zig
dermetfan has joined #zig
<wilsonk>
UGHHHHH, does a minimal SDL2 example work for anyone else with the newest zig? I keep getting 'reached unreachable code' when just trying to SDL_Init!!
<leth>
darithorn: Well I just want to print it, but I'm doing that by trying to format it first. I'd actually like to know how to do both now that you ask.
<andrewrk>
wilsonk, I'm about to revert a recent regression to translate-c
<afontain_>
wilsonk: I'm having a problem where SDL_Init can't init video backend, but that's not related
<wilsonk>
ah, ok...I just tried clashproto and it failed the same way so I was glad to see it apparently wasn't something I changed. Thanks andrewrk
darithorn_ has joined #zig
<darithorn_>
leth have you used std.debug.warn? that's the easiest way to print something out to the terminal, it uses stderr
<darithorn_>
std.debug.warn("{}\n", .{ 42 }); is the typical way to print something out in zig
<ifreund>
you can use the same format system with std.debug.warn() and others
<shakesoda>
some slice stuff changed and broke my code in a way that doesn't make sense
<shakesoda>
hmmmmmmmm
<shakesoda>
i was assigning a &[_]foo{...} to a []foo slice, which it was previously happy with, but now attempting to do that fails and if I try to re-slice the thing it's magically const and I can't do it, apparently
<andrewrk>
shakesoda, make it const
<andrewrk>
either make the thing that accepts the slice []const foo, or `var bar = [_]foo{...};` and then do &bar
<andrewrk>
if the memory is mutable, you have to choose where to put it
<leth>
darithorn: Yeah sure, that's great for testing stuff and debugging, but I need to output some stuff to stdout. And frankly the idea of writing stuff to stderr as being better is quite a strange viewpoint. stderr should only be use in case of failures.
<leth>
ifreund: yeah I read that but i couldn't get it to work. Perhaps i was misinterpreting it.
<leth>
print("{}", value) for instance seemed like it should work from my interpretion of that document. yet it doesn't. but perhaps the problem isn't with the foramting?
<emekoi>
andrewrk would you be open to adding a CI job for mingw?
<darithorn>
print is a function for streams, so you need to grab the stdout stream and print to it
<darithorn>
i don't think there's a shortcut function for printing to stdout like std.debug.warn. so you have to manually grab stdout so you can print to it
<darithorn>
something like std.io.getStdOut().outStream().print("{}\n", .{ 42 }); should work
<leth>
That's what i though and sor tof what i tried, I get expression value is ignored using your code, but perhaps the error is elsewhere.
<leth>
Yeap, only your exmple in a main function with std imported. either that or in all that simple code i have another bug.
<leth>
that's what i started with more or less, still doesn't compile.
<ifreund>
what's the error
<darithorn_>
you need to change main's return type
<darithorn_>
!void
<darithorn_>
! is used when the function can return an error, which it can now since you used `try`
<pixelherodev>
`!void` means it can return basically any error (or void), and the compiler will determine which ones are allowed.
<leth>
still no luck.
<ifreund>
what is the error you are getting
<leth>
error: expected token 'Symbol', found '{'
<leth>
.>{< 42
<ifreund>
are you on zig master or zig 0.5.0
<leth>
0.5.0
<mikdusan>
leth: try pasting your code at https://bpaste.net . it's very difficult to see what issue you have
<Xavi92>
Still working on MIPS I: https://pastebin.com/MEs5cdJM . 'mipsel-unknown-elf-objdump -S main.o' shows assembly code, but 'mipsel-unknown-elf-objdump -S main' shows nothing.
<ifreund>
yeah, there's the problem, the .{} syntax for format args is new
<shakesoda>
0.6 is coming out extremely soon, just use master
<pixelherodev>
For the old one, just remove the `.{}` part though
<mikdusan>
master or bust™
<pixelherodev>
e.g. `stream.print("");` instead of `stream.print("", .{});` if there's no args
<Xavi92>
'mipsel-unknown-elf-size main.o' shows 636 bytes on .text, but only 48 bytes for 'main'. I guess everything is being optimized away by the linker, but how can I avoid this?
<pixelherodev>
Disable optimizations?
<pixelherodev>
If you're building in debug mode, nothing should be optimized away
<pixelherodev>
... I completely forgot to submit the reduction to LLVM
<Xavi92>
pixelherodev: debug mode is selected by default, right? Also, even if _start should be provided, it still compiles and links even if I do not provide it
<leth>
Why is there no simple way to just output something to stdout?
<shakesoda>
std.debug.warn("foo\n");
<pixelherodev>
^
<Xavi92>
pixelherodev: does the entry point need to be indicated?
<pixelherodev>
Xavi92, I wouldn't think so
<pixelherodev>
The entry point isn't actually main
<pixelherodev>
It's start, which is in the standard library
<pixelherodev>
That calls main
<leth>
doesn't that write out to stderr?
<pixelherodev>
leth, yes
<pixelherodev>
99% of the time that's okay though
<leth>
I asked for stdout not stderr
<pixelherodev>
I do think there should be a std.debug.print though
<pixelherodev>
"warn but for stderr"
<mikdusan>
leth: if you upgraded zig to latest releas NEWER than 0.5.0, your pasted code works fine.
<pixelherodev>
s/err/out
<leth>
there is a significant difference between stderr and stdout
<fengb>
There’s an issue for standardized logging
<fengb>
And warn / print will move to that module
<shakesoda>
tossing things into stderr is the one that's easy at this particular moment, doesn't mean it absolutely should be that way
<shakesoda>
just status quo
<pixelherodev>
leth, keep in mind that Zig is in it's early stages
<shakesoda>
fwiw, i found this annoying too
<pixelherodev>
There's a lot of changes coming down the pipeline to make life easier (logging, as mentioned)
<pixelherodev>
stdout will be much simpler to use down the line (hopefully for 0.7)
<mikdusan>
imagine implementing `cat` with unchecked stdout writes
<mikdusan>
blank output would be: did it work? i dunno. maybe. maybe not. let's guess.
<pixelherodev>
True, but that would be a misuse of the API
<mikdusan>
or truncated output too :)
<pixelherodev>
std.debug.warn isn't meant for anything important
<pixelherodev>
Docs explicitly say "for when it doesn't matter all that much if writing fails"
<leth>
imagine implemeting cat only writing out to stderr.
<pixelherodev>
(paraphrasing from memory)
<shakesoda>
mikdusan: as a wise man once said
<shakesoda>
yolo
<pixelherodev>
leth, the code I gave you should work for stdout
<mikdusan>
pixelherodev: not referring to warn. referring to habitual C code that never checks stdout writes
<pixelherodev>
Ah yeah
<pixelherodev>
If you have `const stdout = try std.io.getStdOut().outStream();`, then `try stdout.print("{}\n", 42);` should work
<pixelherodev>
on 0.5.0
<shakesoda>
i certainly never check them, nor do i ever care if they actually worked
<shakesoda>
:D
<pixelherodev>
You'll have to tweak it a tad for 0.6 though
<Xavi92>
pixelherodev: since the target is mipsel-freestanding-gnueabi (is even gnueabi appropiate? don't know), I understand I need to provide _start myself (as in the pastebin above)
<pixelherodev>
Ahh
<pixelherodev>
For freestanding that's probably correct
<pixelherodev>
s/probably/definitely
<pixelherodev>
shakesoda, to me, if it doesn't actually matter if something is written, you shouldn't really be writing it in the first place
<pixelherodev>
That's just waste of system resources
<pixelherodev>
stdio isn't free (or even cheap)
<pixelherodev>
Relative to other things it can be
<pixelherodev>
But on multiple programs I've written recently stdio uses >50% CPU time
<mikdusan>
pixelherodev: just optimize with macros: fputc() /s
<pixelherodev>
To the point where I'm progressively cutting out debug info and replacing it with tests so that that info isn't ever needed
<pixelherodev>
mikdusan, this is Zig code
<pixelherodev>
There are no macros :)
<pixelherodev>
also
<shakesoda>
pixelherodev: for the love of god don't lecture me about stdio performance lmao
<pixelherodev>
It took me a second to get that :P
<shakesoda>
i understand deeply
<pixelherodev>
:)
<shakesoda>
my primary usage of it is dumb checkpointing that gets removed shortly after and a bit of initialization spam
<pixelherodev>
Proposal: there should be a `std.io.setBuffered(bool) void` that allows replacing the default stdio streams with buffered versions
darithorn_ is now known as darithorn
<pixelherodev>
Make it easier to do the right thing
<pixelherodev>
Hides the complexity of buffering from the user
<shakesoda>
heh, meanwhile, i usually have to go out of my way to unbuffer it elsewhere
Xavi92 has quit [Remote host closed the connection]
<mikdusan>
pixelherodev: i think when logging comes in, it will make use of globals specified in main.zig used as "configurators" or options. that same mechanism is probably a good idea for setting buffered standard streams
<pixelherodev>
If I'm transitioning a codebase from C/C++ to Zig, does it make sense to link individual Zig files on their own? Or should I have a root Zig file which is compiled into an object and linked with C/C++?
<pixelherodev>
This is a personal project so I can do whatever :)
<mikdusan>
root zig to allow for best optimization
<shakesoda>
i'd do the latter
<fengb>
Zig likes to be a single unit
* pixelherodev
shrugs
<pixelherodev>
Motion passes 3-0!
<mikdusan>
there's a unit joke in there somewhere
<fengb>
Yes but only mikdusan’s opinion has weight 🙃
<pixelherodev>
Want to take bets on whether @cImport(libgit) will work OOTB?
<pixelherodev>
I I can bet internet cookies :P
<pixelherodev>
There's definitely a unicode cookie
<pixelherodev>
🍪
<pixelherodev>
I was joking.
<pixelherodev>
But it's real.
squeek502 has joined #zig
<fengb>
🧮
<fengb>
Unicode is silly
<pixelherodev>
Stupid more like
<pixelherodev>
Need a revolution to overthrow whoever's in charge of it
<pixelherodev>
They're clearly incompetent
<leth>
how do you suggest we handle the almost countless amounts of scripts that are around?