<yrashk>
I managed to compile this thing :) Now, my only remaining question for now is the use of absolute paths in .a -- whether there's some reason behind this or not :)
marijnfs_ has joined #zig
marijnfs1 has quit [Ping timeout: 260 seconds]
ur5us has quit [Ping timeout: 240 seconds]
<diltsman>
Does anyone know of an example of how to use an ArrayList with an OutStream? I am going crazy trying to figure this out.
<andrewrk>
yrashk, it could quite possibly be a bug, I'm not sure without further investigation
<andrewrk>
diltsman, let me merge daurnimator's pull request and then you can do array_list.outStream()
ur5us has joined #zig
marijnfs1 has joined #zig
marijnfs_ has quit [Ping timeout: 258 seconds]
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 265 seconds]
diltsman has quit [Remote host closed the connection]
<daurnimator>
andrewrk: are you referring to #4665 ? I just left a few replies to your comments
<daurnimator>
I won't have time to rebase/fix for a few hous myself
<daurnimator>
*hours
nephele_ has joined #zig
<andrewrk>
want a handoff? I can take it from here
nephele has quit [Ping timeout: 240 seconds]
<andrewrk>
success! ziglang/bootstrap is now capable of producing arm-linux-musleabhf zig tarballs\
<andrewrk>
that's 32-bit arm that works on raspberry pis
darithorn has joined #zig
<fengb>
🥳
marijnfs has joined #zig
marijnfs1 has quit [Ping timeout: 260 seconds]
<yrashk>
andrewrk: I will try to get to the bottom of it
dermetfan has quit [Ping timeout: 252 seconds]
waleee-cl has quit [Quit: Connection closed for inactivity]
mahmudov has quit [Remote host closed the connection]
<daurnimator>
andrewrk: go for it; let me know if you don't get to it today though
<andrewrk>
ok
<daurnimator>
andrewrk: I'll also rebase 4602 tonight unless there were other issues?
<andrewrk>
I don't think I reviewed that one yet
<andrewrk>
it should be fine if it doesn't break anything
<andrewrk>
hmm I'm a bit behind on issues quota :-/ need to get down to 42 today
<daurnimator>
4602 is one you closed due to "failing tests"; but that was only the freebsd ci test failing back when it was a problem. but now there is a merge conflict.
<daurnimator>
it will need a fast merge after rebasing as its likely to break as other PRs are sent
<andrewrk>
I see; thanks for the heads up
<andrewrk>
sorry I'm a bit overwhelmed with pull requests. it's pretty difficult to keep up
darithorn has quit [Quit: Leaving]
daex has quit [Ping timeout: 256 seconds]
daex has joined #zig
ur5us has quit [Ping timeout: 252 seconds]
<andrewrk>
daurnimator, I'm heading to bed, didn't get around to the PR
marijnfs1 has joined #zig
marijnfs has quit [Ping timeout: 264 seconds]
_whitelogger has joined #zig
<pixelherodev>
`sorry I'm a bit overwhelmed with pull requests. it's pretty difficult to keep up` On the bright side: a lot of people are interested in helping out!
_whitelogger has joined #zig
cole-h has quit [Ping timeout: 260 seconds]
ur5us has joined #zig
boothby has quit [Ping timeout: 240 seconds]
_Vi has joined #zig
marijnfs has joined #zig
marijnfs2 has joined #zig
FireFox317 has joined #zig
<FireFox317>
wow nice andrewrk!
marijnfs1 has quit [Ping timeout: 240 seconds]
frett27 has joined #zig
frett27_ has joined #zig
frett27 has quit [Ping timeout: 256 seconds]
junon_ has quit [Quit: Leaving...]
rappet has quit [Ping timeout: 256 seconds]
rappet has joined #zig
mahmudov has joined #zig
daurnimator has quit [Remote host closed the connection]
_Vi has quit [Ping timeout: 246 seconds]
frett27 has joined #zig
frett27_ has quit [Ping timeout: 260 seconds]
halbeno has quit [Remote host closed the connection]
<Kingsquee>
would there be any issues with dependencies, with this solution?
<Kingsquee>
like if a dependency defines it as u16 while you define it as a u8
<ikskuh>
Kingsquee: as zig is not designed with an ABI in mind, it should not be a problem
Deknos has joined #zig
marijnfs has quit [Ping timeout: 256 seconds]
<Kingsquee>
good to know
<Kingsquee>
but what would the behaviour be, exactly?
<Kingsquee>
a compile error that you need at least a u16?
<Kingsquee>
the opposite way around (you defining u8, dependency defining u16) would be interesting as well, since one wonders whose errors start from zero
<Kingsquee>
would be weird to include a new dep and the ABI breaks
<ikskuh>
as said: there's no ABI so you cannot break it
<ikskuh>
compiled zig modules expose C ABI, no error handling
dermetfan has joined #zig
<ikskuh>
the idea is that you can reduce your memory requirements, if you have less errors
<Kingsquee>
oh, I missed the 'not' :I
<Kingsquee>
now I'm a little confused as to how it's not a problem
<ikskuh>
huh, why?
<Kingsquee>
well, errors are just an int value underneath the hood
<Kingsquee>
so this means what errors are assigned which values depends on what errors there are
<ikskuh>
yes
<ikskuh>
this error set is defined at compiletime
<ikskuh>
and may differ between each compilation (i think)
<Kingsquee>
right, the differ-ing is what's spooking me
<ikskuh>
why? you are not supposed to store or transfer error codes on disk/network :D
<Kingsquee>
JUST WATCH MEno
<Kingsquee>
if A includes B as a dynamic library and A manages one of B's errors
<ikskuh>
as soon as you do dynamic libraries, you are bound to C ABI
<ikskuh>
which does not support Zig error codes ;)
<Kingsquee>
then B gets upgraded to a new version, which drops a dependency, dropping some values from its error table and therefore making its errors different
<Kingsquee>
we then start up A and it tries to handle one of B's errors
<ikskuh>
yeah and it doesn't matter ;)
<Kingsquee>
but the error it's handling is now a different error D8
<ikskuh>
because you cannot pass error codes across C boundaries
<Kingsquee>
and WHO WILL BUILD THE ROADS
<Kingsquee>
wait what
* Kingsquee
squints
<Kingsquee>
so usually one would compile libraries to static or dynamic libraries and then use their functions from your own code
<Kingsquee>
you're saying the moment I do that (or at least with dynamic libraries), I can't handle error codes?
<ikskuh>
yes
<ikskuh>
as soon as you do that, you are bound to C ABI
<ikskuh>
and have the same interface as any other C librariy
<Kingsquee>
but I thought the whole appeal of making errors as easy to write as possible was to mitigate the problems with error handling, especially from external libraries
<Kingsquee>
I mean, removing error handling for external libraries entirely certainly is a very... final solution
<ikskuh>
i think you miss the point ;)
<ikskuh>
zig interacts with other libraries in source form ;)
<ikskuh>
not in compiled form
<ikskuh>
as there is no ABI, you cannot use any zig feature from a compiled library (static or dynamic)
<Kingsquee>
so it's kind of like the gpl but enforced by practicality instead of legality
<Kingsquee>
"give me your source code, or I'll check C-types at you"
<Kingsquee>
*chuck
<ikskuh>
*grin* yeah, kinda
<Kingsquee>
not sure if brilliant or stupid
* Kingsquee
keeps reading documentation
<ikskuh>
it's brilliant ;)
<ikskuh>
as it makes software maintainable
<Kingsquee>
that said, someone could just make a middle-layer mapping zig errors with bourgeoisie hard-coded error consts
<ikskuh>
yeah
<Kingsquee>
so I suppose it at least makes closed-source-life miserable
<ikskuh>
that's what i do for example ;)
<Kingsquee>
DUN DUN DUHH
<ikskuh>
what?
<ikskuh>
because i want to write libraries one can not only use with zig, but also with C
<Kingsquee>
ikskuh was the bourgeoisie all along!
<Kingsquee>
what a twist
<ikskuh>
so i write a Zig package and a library based on that package that just exports the functions with a shim that maps error handling from "convenient" to "C style"
<ikskuh>
→ you can use the library with any language, but it's most comfortable with Zig
<Kingsquee>
wait, so the library you write is in zig?
<Kingsquee>
and you map zig error codes to constants?
<ikskuh>
yes
<Kingsquee>
...so basically a lookup table mapping the possibly-varying zig errors to constant values
<Kingsquee>
HAH smart
<ikskuh>
that's just the way to do it ;)
<ikskuh>
you can even auto-generate such mappings
daurnimator has joined #zig
<Kingsquee>
using zig comptime fns I assume
<ikskuh>
yep
<ikskuh>
and an error enum :)
<Kingsquee>
beauty
<ikskuh>
const E = extern enum(u32) { OutOfMemory, … };
<ikskuh>
and then comptime-map error.OutOfMemory to E.OutOfMemory
<ikskuh>
Zig == Awesome
<Kingsquee>
at that point though, does it really make sense to have the quick-and-implicit error defining?
<Kingsquee>
I can see how it's useful for internal errors, but external errors need to be mapped properly
<ikskuh>
yes
<Kingsquee>
and you could run into typo issues with OutOfMemory != OutOfMammay
<ikskuh>
but only those
<ikskuh>
the typo thing is easily found
<ikskuh>
as soon as you don't do implicit error sets everywhere
<Kingsquee>
easily found, how?
<ikskuh>
because they yield compile errors
<ikskuh>
if you don't catch them
<Kingsquee>
oh?
<ikskuh>
if you just bubble them up to main, sure
<ikskuh>
you'll miss them
<Kingsquee>
hm
<ikskuh>
but as soon as you don't infer error sets everywhere, you cannot just return OutOfMemorry
<ikskuh>
because the function does not allow that error to be returned
frett27_ has joined #zig
frett27 has quit [Ping timeout: 264 seconds]
<Kingsquee>
"Since Zig understands error types, it can pre-weight branches in favor of errors not occurring. Just a small optimization benefit that is not available in other languages."
<Kingsquee>
"can" as in "it's possible", or "can" as in "it does this"
<ikskuh>
can as in "it's possible, but the corrent compiler doesn't do this"
<Kingsquee>
kk
<ikskuh>
all the fancypants stuff will come to self-hosted version
<Kingsquee>
weeeee
Kingsquee has quit [Quit: Konversation terminated!]
daex has quit [Ping timeout: 256 seconds]
r4pr0n has joined #zig
daex has joined #zig
<r4pr0n>
hey. i tried the https://github.com/ziglang/bootstrap to compile zig, but even though i ran the ./build script, it still used the system's llvm and i got
<r4pr0n>
CMake Error at cmake/Findllvm.cmake:33 (message):
<r4pr0n>
expected LLVM 10.x but found 9.0.1
Deknos has quit [Quit: Deknos]
Patrice_ has joined #zig
frett27_ has quit [Ping timeout: 256 seconds]
r4pr0n has quit [Remote host closed the connection]
r4pr0n has joined #zig
tzekid has joined #zig
return0e has quit [Remote host closed the connection]
FireFox317 has quit [Quit: Leaving]
TheLemonMan has joined #zig
<TheLemonMan>
yo, is any Windows user willing to fetch a backtrace for me?
<squeek502>
TheLemonMan, i can try
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
marijnfs has joined #zig
ifreund has joined #zig
_Vi has joined #zig
<squeek502>
nvm, i need to sleep
riba has joined #zig
haliucinas has joined #zig
r4pr0n has quit [Quit: r4pr0n]
marijnfs1 has joined #zig
D3zmodos has joined #zig
frett27 has joined #zig
marijnfs has quit [Ping timeout: 256 seconds]
Patrice_ has quit [Ping timeout: 260 seconds]
riba has quit [Read error: Connection reset by peer]
<andrewrk>
r4pr0n, the first thing that script does is build a native zig compiler, and that is what is used for cross compiling
marmotini_ has quit [Read error: Connection reset by peer]
frett27_ has joined #zig
frett27 has quit [Ping timeout: 256 seconds]
tzekid has quit [Ping timeout: 252 seconds]
r4pr0n has joined #zig
ifreund has joined #zig
<r4pr0n>
andrewrk: oh, thanks, i can just remove that part
<andrewrk>
r4pr0n, ah I see, yes perhaps the script can be split into two, and so you could run the second half if you already have a zig compiler handy
<r4pr0n>
yeah, i guess so
<andrewrk>
hmm I think I will keep it how it is. the "supported" way to do it is to use exactly the sources in that repo
<r4pr0n>
well I could just remove the upper part of the script, it's no big deal, so that'll work
<andrewrk>
TheLemonMan, want me to add freebsd, netbsd to line 31 of compiler_rt.zig when merging #4874?
<andrewrk>
sorry I know that I kinda made a mess there with duplicated logic
<TheLemonMan>
oh sure, I forgot to add that
<TheLemonMan>
yeah the version detection logic gets hairy pretty quick
nephele_ is now known as nephele
<daurnimator>
should the OS check be removed entirely?
<daurnimator>
e.g. darwin should be there too right?
<andrewrk>
the point is that it should be missing rather than a compile error when there is not support
<andrewrk>
let me finish merging and then you can submit a refactor PR if you want
<andrewrk>
it should be fine to use std os bits too but make sure not to accidentally drag in any exports such as __clone
<andrewrk>
daurnimator, I'll look at #4665 as soon as those tests finish
mahmudov has quit [Ping timeout: 260 seconds]
<TheLemonMan>
perhaps it's cleaner to split the clear_cache in many small functions and export only the correct one, the exportIt is really ugly IMO
<TheLemonMan>
daurnimator, if you have any Q about @export feel free to ask here
<TheLemonMan>
it's much easier to discuss here than in a GH ticket
<daurnimator>
TheLemonMan: how does exportIt work? from your comment in that other issue it seems it wouldn't
<daurnimator>
would my example work if I used `inline`?
<TheLemonMan>
it's changing the symbol linkage, it's not exporting a literal
<TheLemonMan>
andrewrk, the problem with `zig cc` & RISCV64 is because clang has different defaults than Zig, what's the long term solution? Adopt whatever clang defaults to?
<andrewrk>
TheLemonMan, nah, we coerce clang into doing what we want-
<daurnimator>
TheLemonMan: our baseline cpu needs to take the OS into consideration
<TheLemonMan>
it's not a bad idea as Clang defaults are often also GCC defaults and so we get some degree of compatibility across different toolchains
<andrewrk>
well we can change zig defaults to match, if those defaults are a good idea
<andrewrk>
but also it needs to be fixed that zig is failing to correctly inform clang about the target
<andrewrk>
keep in mind that it's also planned to have a non-llvm backend
<TheLemonMan>
well speaking of riscv we're already using the same feature set when targeting linux
<TheLemonMan>
it makes sense to default to the same ABI
<andrewrk>
I agree
<andrewrk>
I think I misunderstood your original proposal and I agree with you
<andrewrk>
I'm just clarifying on the implementation details
<andrewrk>
it looks like perhaps "floating point ABI" is something we don't adequately take into account into the concept of the "target"
<andrewrk>
or is it? should we be using riscv64-linux-musleabihf instead of riscv64-linux-musl?
<TheLemonMan>
well the only supported arch where that matters is ARM, and we got around that by using the eabihf/eabi distinction
<andrewrk>
what exactly is clang and zig differing on in the riscv case? that's something I'm not clear on yet
<TheLemonMan>
zig is defaulting to soft-float while clang defaults to lp64d that's hard-float
<andrewrk>
I definitely think we should default to hard float
gazler has joined #zig
<andrewrk>
once that's done I wouldn't have an answer to "how do you select soft float for riscv64?". maybe we could add -hf variants to the ABI enum for where eabihf is not appropriate
<andrewrk>
err maybe add sf variants
mahmudov has joined #zig
<andrewrk>
but we already have an "ABI" section of the target, and I'm convinced that's where soft/hard should be chosen
<TheLemonMan>
maybe it makes sense to add the ilp32f, ilp32d, lp64f, lp64d ABIs too
marmotini_ has joined #zig
<andrewrk>
that would make sense to me
<TheLemonMan>
I mean, trying to abstract all this madness in a cross-ISA, cross-OS, cross-version, cross-whatever way is not really worth the headache
<andrewrk>
even if some of them can't be supported, it can be a very clear error message
marijnfs2 has quit [Ping timeout: 240 seconds]
marijnfs has joined #zig
<andrewrk>
what are you suggesting to not do?
marmotini_ has quit [Read error: Connection reset by peer]
<TheLemonMan>
I'm suggesting not to overload the eabihf/eabi ABIs and add some new ones as needed
<andrewrk>
ah! ok yes I agree with you
<andrewrk>
damn I hit that unable to inline function bug
<TheLemonMan>
oh I think I know why that happens
<TheLemonMan>
last time I checked in compiler-rt that error showed up only for generic functions marked as inline
<andrewrk>
hmm I just hit it in a non generic function marked inline
<andrewrk>
I think it's probably something going on with llvm mangling function names and we check the wrong name or something
<andrewrk>
it's pretty hacky- it checks the post-processed ir file and makes sure the function got deleted
<andrewrk>
I wonder how close we are to being able to have riscv-64 tarballs
<andrewrk>
that would be a pretty sexy announcement if it was part of the 0.6.0 release
<shakesoda>
armv6/raspbian coming is pretty nice already
marijnfs has quit [Ping timeout: 260 seconds]
<shakesoda>
that's one i wanted available at least
marmotini_ has joined #zig
<fengb>
Sorta. People kinda expect it to work already >_>
marmotini_ has quit [Read error: Connection reset by peer]
FireFox317 has joined #zig
<andrewrk>
already 2 new tarballs planned for this release: zig-bootstrap-0.6.0.tar.xz zig-armv7a-linux-museabihf.tar.xz
<andrewrk>
already 2 new tarballs planned for this release: zig-bootstrap-0.6.0.tar.xz zig-0.6.0-armv7a-linux-museabihf.tar.xz
<FireFox317>
andrewrk, do you have the zig-arm binary somewhere? i tried to built it but ran out of disk space :(
<andrewrk>
ah bummer. yeah I can upload a tarball for ya
<andrewrk>
shakesoda, it's v7a not v6
<shakesoda>
is that v7a instead of v6/1176jzf-s
<shakesoda>
I see
<andrewrk>
pretty sure raspbian is the same
<FireFox317>
want to check if it really works on a raspberry
<shakesoda>
raspbian supports lower as it applies to the old model pis and pi zero
<FireFox317>
andrewrk, what cpu features did you built it with? i guess baseline arm? which is armv7a?
marmotini_ has joined #zig
marmotini_ has quit [Remote host closed the connection]
<shakesoda>
they weren't armv7 until the pi 2
<andrewrk>
ah
<shakesoda>
(later models of that are aarch64, the early ones were v7)
<fengb>
Yeah, Pi Zero (WH) are still v6
<andrewrk>
well we can try to build one for armv6 too. v7a is still a good target to have tho
<shakesoda>
yes, absolutely
<shakesoda>
I'd just like a zig build on hand to run on my small pi zero army
<shakesoda>
:D
<fengb>
Silly idea: we need a standard network protocol for the Zig compiler
<fengb>
Then we can pool together compilation over wire
<shakesoda>
maybe before that we could have concurrent build support for builder ;)
<FireFox317>
andrewrk, did you build on some server or using your own hardware? i throught i had a pretty fast laptop, but it still takes ages xd
<andrewrk>
FireFox317, yeah I built on my laptop. it's pretty swanky hardware. you are using an appropriate -j arg right?
<andrewrk>
I got this laptop with the understanding that I would be building LLVM over and over again
* shakesoda
has a variety of potato computers fitting only just within the last decade
<FireFox317>
yup (-j8), i think cross-compiling llvm took like 1,5/2 hours or something. is that similar to yours?
<andrewrk>
pretty similar
<TheLemonMan>
you can also use the aarch64 beast to build LLVM
<FireFox317>
okay, it just takes so freaking long XD
<pixelherodev>
Maybe rewrite parts of LLVM in Zig so it builds faster :P
<TheLemonMan>
that monster compiled LLVM and Clang in no time
<shakesoda>
pixelherodev: yeah, I'm done with waiting for C++ too for anything of my own, but I still need it for work.
<shakesoda>
someday I will be free, but not today.
<TheLemonMan>
andrewrk, I was thinking of your idea for a @extern builtin, it may also be helpful to change the linked symbol name for the NetBSD versioned symbols
r4pr0n has quit [Quit: r4pr0n]
<andrewrk>
makes sense
<TheLemonMan>
rust has something slightly different, the link_name attribute that works a bit like our @export
<fengb>
We will never be consistently lower than 1000 issues :(
<TheLemonMan>
I'm not sure if that's better than having some usingnamespace + comptime switch to select what to include in c.zig
<pixelherodev>
Issue quantity doesn't really mean much...
* pixelherodev
says without any project with an issue count above 20
<andrewrk>
TheLemonMan, on NetBSD you can #include <stat.h> and call C functions like normal right? I think c.zig should enable this same thing
mps has joined #zig
<TheLemonMan>
that'd work either way, I'm thinking of what's the cleanest way to do so
<andrewrk>
I see
<mps>
I've built zig on alpine linux aarch64 and tested with some small C programs
<TheLemonMan>
we should also consider #4426 for the other platforms, are we trying to cover the whole libc or the pieces we need in the stdlib?
<mps>
and, hello.zig
<mps>
looks good
<mps>
andrewrk: what is your opinion about enable it on aarch64 on alpine linux
marijnfs has joined #zig
<andrewrk>
mps, aarch64 alpine linux is well tested, it's the environment Drone CI uses
<pixelherodev>
I think he dislikes async even more though (and I honestly completely see his point on this one, though I haven't yet decided how I feel on the matter): `completely overhauls the runtime characteristics of your program with little to no changes [to your code]`
<pixelherodev>
That is, just changing a boolean in the root source file can change runtime behavior in significant ways, making debugging harder and the program less predictable
<pixelherodev>
Though that's more of an issue with the standard library than the language, as I understand it (since it's zag that checks the root source file for evented/blocking mode)
<fengb>
I can agree with that
<fengb>
But I'm also tired of async bifurcating every userland
<fengb>
I don't think there's a good solution for both problems
<pixelherodev>
Right - it's a matter of priorities
<pixelherodev>
Every programming language has these kinds of tradeoffs
<pixelherodev>
The job of a responsible language is to make them explicit ahead of time so you know what you're getting into
FireFox317 has quit [Quit: Leaving]
<pixelherodev>
That's another area where I think Zig excels
<companion_cube>
oh my, drew makes a language.
<companion_cube>
at least he got the type notation right.
<fengb>
It seems like most languages are generally all the same page now :P
<andrewrk>
he's going to go through the exact same process I did, and then end up with an earlier version of zig from 3 years ago, or something that is designed incorrectly
<ikskuh>
yeah, good language design is hard
<companion_cube>
andrewrk: who knows, he might pick basic macros over comptime?
<andrewrk>
even rust, which already has powerful AST macros, is converging on zig's comptime features
<andrewrk>
and C++ even
<ifreund>
what was the argument against comptime? I think it's a far more elegant solution than macros of any kind
<companion_cube>
I think rust did the macros first because they were easier
<andrewrk>
the comptime stuff is just objectively the correct way to design a language. not necessarily even having the keyword like zig does - zig takes it to a new level with inline loops and stuff - but just basic stuff like array lengths being able to call functions
<fengb>
Really? But AST macros have more powa!
<companion_cube>
(also, they allow to duplicate code in a more syntactic way)
<andrewrk>
it's just so clearly a design flaw if you can't make a global constant initialized by a function call
<Snektron>
I think Rust would have a hard time implementing comptime types into their typesystem
<Snektron>
What with specifying contracts and all that
<companion_cube>
you mean traits?
<pixelherodev>
The anti-comptime argument: `it means you cannot predict the runtime behavior of some code just by reading it, you need context - there's no syntactical difference between comptime and runtime code`
<companion_cube>
I mean they're working on const, it's just a lot of engineering effort
<pixelherodev>
He was arguing that it's not predictable enough?
<andrewrk>
pixelherodev, that argument falls apart in the examples I just gave
<companion_cube>
pixelherodev: you can do like D and have foo!bar to clearly indicate templates… 🤷
<pixelherodev>
Take it up with Drew, not me; I try to avoid engineering holy wars :P
<companion_cube>
what are you interning on?
<andrewrk>
nah I'll just keep working on the release
<ikskuh>
<andrewrk> it's just so clearly a design flaw if you can't make a global constant initialized by a function call
<ikskuh>
This is so true
daex has joined #zig
<ikskuh>
as soon as this idea is sparked, the rest naturally follows
<andrewrk>
that's how I see it
<andrewrk>
TheLemonMan, what do you think? v4.2.0 or v5.0.0-rc0?
<andrewrk>
the other tags have gone through 4-5 release candidates on average before the final tag
<TheLemonMan>
420 of course
<andrewrk>
lol good point
<ikskuh>
i'd go the full route though (full type generation and code execution at comptime), but can understand the reasons not to do so as well
cole-h has joined #zig
jjido has joined #zig
<TheLemonMan>
speaking of AST macros, Nim macros are so cool that the whole async machinery is implemented as a macro (with a little help from the compiler)
<andrewrk>
that is neat and scary
<andrewrk>
I think nim async await has some fundamentally different semantics as zig
FireFox317 has joined #zig
<FireFox317>
andrewrk, hmm getting an sigill with the zig binary on raspbian. it's an udf instruction
<andrewrk>
in what function?
<FireFox317>
i'm running this on an rpi3b+ which is armv8, but armv8 is backwards compatible with armv7
mps has left #zig [#zig]
return0e has joined #zig
<FireFox317>
andrewrk, os_init
<andrewrk>
hmm
<TheLemonMan>
get a backtrace with gdb
<andrewrk>
FireFox317, I can also make a build with debug symbols
<TheLemonMan>
udf is an undefined opcode, udf is used for trapping the execution
<FireFox317>
yeah bt is os_init, main. andrewrk if you don't have time I can do it myself too
<TheLemonMan>
run `disassemble` and upload the result
riba has joined #zig
<andrewrk>
I might need to make this qemu in an alpine docker image
<FireFox317>
uname -a: Linux raspberrypi 4.19.97-v7+ #1294 SMP Thu Jan 30 13:15:58 GMT 2020 armv7l GNU/Linux
<TheLemonMan>
getauxval is returning a null pointer
<TheLemonMan>
try running zig with `LD_SHOW_AUXV=1 <failing command>`
<andrewrk>
it's statically linked
<FireFox317>
lol when i run `LD_SHOW_AUXV=1 ./zig` it runs fine
<andrewrk>
hmm where is the LD_SHOW_AUXV logic? I don't see it in musl sources
marijnfs1 has quit [Ping timeout: 258 seconds]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<TheLemonMan>
FireFox317, does it print any line starting with AT_ ?
<FireFox317>
TheLemonMan, nope
<TheLemonMan>
oh it's statically linked, right
<FireFox317>
jup, but it does run when i put LD_SHOW_AUXV=1 before the command
<TheLemonMan>
ok so let's see why it's fucking up
<TheLemonMan>
put a breakpoint on os_init (b os_init)
<FireFox317>
i have some basic gdb knowledge :)
<TheLemonMan>
then run the program until it hits the bp and step with `ni` 'till you reach the tst below getauxval
<TheLemonMan>
if you hit the first it's just AT_RANDOM being misaligned
<TheLemonMan>
if you hit the second branch the returned pointer is null
<TheLemonMan>
but I believe it's the former
<FireFox317>
jup its the first tst
<FireFox317>
first branch i mean
<TheLemonMan>
it's an easy fix then, write some logic to memcpy from the getauxval pointer to a temporary int-sized variable and pass that to srand
<FireFox317>
0x01cb0124 is the instruction that jumps to the end of the function
<FireFox317>
TheLemonMan, thanks for the quick help :)
<TheLemonMan>
np, I love debugging stuff
<TheLemonMan>
and fuck x86 for allowing unaligned reads
riba has quit [Read error: Connection reset by peer]
riba has joined #zig
<FireFox317>
TheLemonMan, but getauxval returns a value right? not a pointer
<TheLemonMan>
a pointer is a value :)
<TheLemonMan>
for AT_RANDOM that's a (unaligned) pointer to a 16-byte buffer full of (hopefully) random data
<FireFox317>
oh yeah, i see its casted to a pointer actually
<FireFox317>
TheLemonMan, #4881 looks correct?
<FireFox317>
andrewrk, could you rebuild the arm binary with #4881 or should i do it myself? :D
<andrewrk>
I thought you didn't have enough disk space?
<FireFox317>
I can do it on the beefy aarch64
<fengb>
Oof, that's something Zig would just catch for us >_>
<andrewrk>
FireFox317, any work you can take off my hands is a blessing
return0e has quit [Remote host closed the connection]
<TheLemonMan>
FireFox317, I've left two comments
<jaredmm>
I haven't been able to compile LLVM10 on Win10 because of an `The ASM compiler identification is unknown` error.
<jaredmm>
Are there different instructions now or should the Wiki page still be good?
<andrewrk>
is there an open issue for this? I personally tested compiling llvm10 on windows 10, and updated the wiki accordingly
<FireFox317>
TheLemonMan, damn that's some nice knowledge you have there xd
<FireFox317>
TheLemonMan, updated, should be better now :)
riba has quit [Read error: Connection reset by peer]
Patrice_ has joined #zig
riba has joined #zig
frett27_ has quit [Ping timeout: 256 seconds]
<TheLemonMan>
lgtm o/ time to test it on the rpi
<ikskuh>
good luck!
<pmwhite>
I'm hitting stuff with recursive async functions, and I'm a little confused...
<TheLemonMan>
jk, I have no idea where my rpi is, this room is a mess
<fengb>
Oh shoot, my pi's gameboy shell should be arriving today
<pmwhite>
A is the main function, and B is the helper. A allocates a frame to call B with. B calls A. I get an error about A that says "recursive function cannot be async"
<fengb>
You'll need to be explicit when using recursive functions
<pmwhite>
I have been doing this without error with just A, but now I was wanting to use B twice inside of A.
<fengb>
e.g. manually allocate the recursion frame
<fengb>
Can you post a snippet?
<pmwhite>
But A is allocating a frame to call B. Do I need to allocate a frame from B to call A?
<jaredmm>
andrewrk: Since it is an issue with me compiling LLVM, I did not create an issue yet. I'll create something if I determine there is something that needs to be changed to make it work in a specific environment.
<pmwhite>
You can ignore the switch at the end I guess, because the error happens even without it.jk;w
<pmwhite>
jk;w = quit insert mode and save file, lol. vim is leaking into my entire life.
TheLemonMan has quit [Ping timeout: 250 seconds]
riba has quit [Ping timeout: 256 seconds]
marijnfs1 has joined #zig
<pixelherodev>
I was testing one last configuration on the compiler, and it unexpectedly made it hundreds of milliseconds worse - or so I thought. I restored the good compiler flags, and the results were about the same! Then I realized I'd increased the complexity of the test program and I just wasted nearly fifteen minutes on this :P
marijnfs2 has quit [Ping timeout: 256 seconds]
<pmwhite>
fengb: All I'm really trying to do is mutually recursive async functions. I know they won't technically be recursive, since the stack frame will be manually allocated, but that's the idea. I think if I saw a small example, I could apply it to my use-case.
return0e_ has quit [Remote host closed the connection]
return0e has joined #zig
<mikdusan1>
in stage1, is_comptime() returns true for both globals or `comptime { var a... }` locals; any hints on how I can differentiate?
<fengb>
`e.handleEvent(event);` is e a different type? Maybe that has recursion?
<pmwhite>
yeah...that might be where that is. I just thought of that myself.
<mikdusan1>
ah I think maybe ConstPtrMutRuntimeVar
<pmwhite>
fengb: I'm allocating that frame now, but no change.
mikdusan1 is now known as mikdusan
<andrewrk>
mikdusan, yeah the pointer that points at a global is technically comptime known (even though it may have to get resolved by the linker)
<andrewrk>
however the memory the pointer points to, may not be comptime memory
<andrewrk>
as you can imagine there are a few bugs around this edge case
<mikdusan>
yeah I think #2622
return0e has quit [Remote host closed the connection]
return0e has joined #zig
<FireFox317>
jaredmm, on linux we also get a warning for that, but cmake just continues after all
<FireFox317>
wait nvm, this only happends when we build llvm with `zig cc` -- Warning: Did not find file Compiler/-ASM
<andrewrk>
oh jaredmm are you trying to use zig cc on windows? that's interesting, I haven't tried to do that yet
riba has joined #zig
<andrewrk>
hm we should be able to additionally set ASM="zig cc"
<fengb>
Philip White: allocating frame only breaks an immediate chain. If handleEvent is internally recursive then it is still a problem
<fengb>
async calls require the size to be known at comptime. Unbounded recursion means it's unknowable
<pmwhite>
there are two functions called handleEvent. One of them is associated with Elements, which weren't in the snippet I gave you. That one is not recursive, but it is async. If I remove that call to that, in the snippet, then the whole thing compiles.
<pmwhite>
That unbounded recursion issue also usually raises a different error, right?
<fengb>
Hrm it’s possible the recursion detection is having trouble
<pmwhite>
Actually nevermind that last statement.
riba has quit [Read error: Connection reset by peer]
riba has joined #zig
ifreund has quit [Quit: WeeChat 2.7.1]
<pmwhite>
possible. Copy-paste is always an option...but now that is giving me the dreaded "instruction does not dominate all uses"
<fengb>
andrewrk's favorite error! 🙃
<andrewrk>
damn it
<andrewrk>
well at least you know it's the compiler's fault rather than yours
<pmwhite>
yeah, i guess...do you want me to make an issue for this?
<pmwhite>
not sure if i can yet...i need to figure out what the essence of the issue is.
riba has quit [Ping timeout: 256 seconds]
<andrewrk>
if you can reduce it to a small test case then I'm definitely interested
return0e has quit [Remote host closed the connection]
return0e has joined #zig
jjido has joined #zig
marijnfs2 has joined #zig
Patrice_ has quit [Ping timeout: 256 seconds]
marijnfs1 has quit [Ping timeout: 250 seconds]
FireFox317 has quit [Remote host closed the connection]
<pixelherodev>
`%bar = and %foo, 0` then doing a conditional branch on whether that's equal to zero
<pixelherodev>
Ahhh, because the integer might not match ptr size!
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jjido has joined #zig
ifreund has quit [Quit: WeeChat 2.7.1]
<pixelherodev>
Good news is, my compiler backend works! Bad news is, that depends on how you define *works*
<BaroqueLarouche>
pixelherodev: What's working so far ?
<pixelherodev>
it produces a valid binary, but the binary BusErrors in the *middle* of an instruction, is completely inefficient, and the calling convention is a monstrosity
<pixelherodev>
So, uh, it's great?
<pixelherodev>
This is actually completely intended though
<pixelherodev>
Part of the incremental design is the terrible backend that only barely works
<pixelherodev>
Then I can use that to finish up the tree generation, and then rewrite a much saner backend
<BaroqueLarouche>
you are parsing LLVM IR right ?
<pixelherodev>
Yeah
<pixelherodev>
It also is giving me a lot more information on how to properly design the backend
<BaroqueLarouche>
is the code public yet or you are waiting for something more presentable ?
<Cadey>
is `zig c++` released yet?
<redj>
andrewrk: I'm guessing zig cc won't deal well with linux style paths on windows? -L../ecere/obj/bootstrap.linux
<andrewrk>
Cadey, `zig c++` works and master branch tarballs have it. the next official zig release to have this feature is 0.6.0
<andrewrk>
april 13
<Cadey>
cool
<redj>
andrewrk: sorry, nvm that, I'm on linux! lol
<Cadey>
i'm doing something horriffic to a discord bot written in rust and zig c++ is gonna save me :D
<redj>
lld: error: unable to find library -lecereBootstrap
<redj>
lld: error: unable to find library -lecBootstrap
<Cadey>
someone decompiled the turnip price logic in animal crossing on the switch and released a C++ fragment to calculate it
<Cadey>
i'm putting that C++ into a discord bot
<FireFox317>
andrewrk, in `ir_analyze_call_extra` i think pass1_options is a nullptr, any clue why this could be the case?
<jaredmm>
andrewrk: Yeah. Part of the problem is my lack of CMake knowledge. By creating Windows shortcuts (zigcc and zigc++) I was able to get a Ninja project to generate and build.
<oats>
is there a place I can read about the in-progress changes for 0.6.0?
drvirgilio has quit [Remote host closed the connection]
<jayschwa>
Hi, I create snap packages (Ubuntu's new-ish package manager) for Zig. I plan to start publishing arm64/aarch64 builds to the Ubuntu store (in addition to the current amd64/x86_64 builds), but I don't have access to an arm64 machine to validate that the packaged snap actually works. If anyone here has an arm64 Ubuntu machine with `snap` installed
<jayschwa>
and is willing to test a build, please email me at jay@jayschwa.net. Thank you.
jayschwa has left #zig [#zig]
drvirgilio has joined #zig
<Cadey>
well crap, i'm getting a segfault instantly now
<Cadey>
gonna try and trace it down
<Cadey>
to compile a C++ library for a .so it's `clang++ -g -c -Wall -Werror -fpic stonks.cpp` and then `clang++ -shared -o libstonks.so stonks.o` right?
FireFox317 has quit [Ping timeout: 256 seconds]
gazler_ has joined #zig
gazler has quit [Read error: Connection reset by peer]
<andrewrk>
Cadey, you're building native stuff right? you probably want to dynamically link against glibc
<andrewrk>
are you using nix clang, built-from-source clang, or zig c++ ?
<Cadey>
nix clang to try and find out why the heck this is segfaulting
<Cadey>
(i get the same segfault with zig c++)
<Cadey>
it seems to be segfaulting inside clock_gettime
<andrewrk>
that sounds vdso related, but not sure if that's a clue. first I want to understand why it's statically linked because on nixos it should be dynamic linking glibc
<andrewrk>
you might need -fPIC on the compile command
<andrewrk>
if you're planning to build with zig anyway you could use zig's CLI rather than zig c++
<yrashk>
I am trying to use zig-bootstrap, early on in the build process (x86_64-linux-[gnu|musl]) I get Error running link command: No such file or directory
<andrewrk>
cmake dumps logs that show the command it tried to run
<andrewrk>
and the corresponding stderr
<yrashk>
looking at those
<Cadey>
same segfault :D
<yrashk>
there's actually a bunch of errors in the stderr
<yrashk>
let me compile
frmdstryr has joined #zig
<andrewrk>
Cadey, want to try something fun? include a zig file that exports initDebug() and call it from your c++ main(). initDebug() will just call std.debug.attachSegFaultHandler()
<frmdstryr>
Unreachable at /deps/zig/src/analyze.cpp:869 in get_slice_type. This is a bug in the Zig compiler?
<Cadey>
C++ isn't the main :D
<Cadey>
rust is
<yrashk>
way too many, including linking issues. I suspect zig-bootstrap might be having difficulties with NixOS
<andrewrk>
Cadey, well you get the idea - you can look at the segfault in a debugger or you could try to instrument the binary to do it for you
<Cadey>
yrashk: i have a stupidly powerful nixos machine in front of me, want me to take a look at zig-bootstrap?
<frmdstryr>
Anyone see that error, any suggestions on where to look?
<andrewrk>
yrashk, I ran the x86_64-linux-musl with ziglang/bootstrap just fine, on nixos. I wonder what is different with your box
<yrashk>
Cadey: sure; mine is also stupidly powerful (for a laptop :) but I maybe I am missing something...
<yrashk>
andrewrk: hmmm
<yrashk>
I am on 19.09.2345.6d445f8398d
<andrewrk>
yrashk, can you show the link command that resulted in no such file or directory?
<Cadey>
i'm on 20.03 beta, let's see if that matters
<yrashk>
this is interesting, now it seems to be going through, after numerous attempts
FireFox317 has quit [Ping timeout: 256 seconds]
<fengb>
It got scared of andrewrk
<yrashk>
(but I did update some packages recently using home-manager)
<yrashk>
yeah, I suppose
<yrashk>
andrewrk: btw do you happen to have your own default.nix / shell.nix for zig?
<Cadey>
andrewrk: is it okay if i contribute a `shell.nix` file to the bootstrap repo?
<yrashk>
I am currently building zig's master using a PR for llvm10 plus my patch to zig's derivation
<yrashk>
but I'd rather have a solid shared `shell.nix ` for the main repo to build it regardless of the state of things in nixpkgs
<andrewrk>
Cadey, i'd like to keep that repo clean from any environment-specific hacks
<andrewrk>
I would welcome you to paste your env into a wiki article on that repo
<Cadey>
:+1:
<andrewrk>
wow thanks yrashk
<andrewrk>
yrashk, hmm did you hack up the build script from the bootstrap repo? I think it would be better to not do that
<yrashk>
andrewrk: no, I am still using the original build script, but it started working somehow (I don't like mysteries, but hey, at least it works)
<andrewrk>
that must have been someone else who deleted half of it because they already had zig installed
<yrashk>
what I am more interested in right now is shell.nix for zig-lang/zig to have a comfortable development environment to contribute
<andrewrk>
personally I use llvm, clang, lld built from source though
<yrashk>
current llvm in nixpkgs in rc5
<yrashk>
that's why I thought maybe having a zig-lang/zig-specific shell.nix could be a good place to start to ensure there's always a correct build of clang/llvm/lld with it