<nikki93>
hope that was plaintext enough -- i'm on irccloud lol
<nikki93>
yeah i run it in WSL on windows too xD
<andrewrk>
I could use this as a nice shortcut when doing a live coding stream on trying to wire up hot code reloading into ELF compilations :D
<nikki93>
yup :D entr is awesome
<nikki93>
andrewrk: one thing to not is it just takes the name of a binary as its arg (plus rest args to send to it), so if you want to run multiple things you should do `/bin/bash -c "blah && blah && ..."`
<andrewrk>
ok I *just* realized that somebody made std.testing.expectEqualStrings with proper diff printing and it is super duper useful
<andrewrk>
using git blame to figure out who to praise
<andrewrk>
ahh Vexu!
cow-orker has quit [Ping timeout: 244 seconds]
<nikki93>
if i have a pure compute c lib, zig can compile that to wasm and link with it right?
<nikki93>
ugh the lib may use malloc and so on hmm
waleee-cl has quit [Quit: Connection closed for inactivity]
<andrewrk>
nikki93, yes
<andrewrk>
zig can also provide some libc functions for C programs for the wasm target
<andrewrk>
I don't think we have malloc implemented yet tho
<andrewrk>
maybe you would want to contribute that? you could try wiring it up to GeneralPurposeAllocator backed by std.heap.page_allocator (which does support wasm thanks to fengb)
<andrewrk>
FireFox317, windows tests passed locally for me :)
<FireFox317>
ah that would explain the weird randomness indeed
<FireFox317>
because sometimes it does work and sometimes it doesn't
<FireFox317>
andrewrk, nice! :)
<andrewrk>
I found one issue on macos, should be an easy fix
jjsullivan__ has joined #zig
jjsullivan has quit [Ping timeout: 240 seconds]
<nikki93>
andrewrk: sweet thanks for the tips. hmm i've kinda wanted to have control over the allocations of this physics engine too so i'll think about how this could be wired up
<nikki93>
like maybe i just wire some specific malloc/free that is eg. tied to scene duration in tbe game
cole-h has quit [Quit: Goodbye]
<andrewrk>
interesting, good to know that's a use case
cCCCCcccccCCc has left #zig ["Leaving"]
<nikki93>
yeah these thoughts are more nebulous but, in games it tends to be some entities that are static and stick around, while there are a few entities that tend to come and go more. and i've been wondering about having two diff allocators for the data of each kind
<nikki93>
it was already kinda meh to me that (i use this physics engine in c++) that it does dynamic allocs for me like that while i keep most of my own actual game logic data more pooled and compacted. it does let u allocate kinda but it maintains pointers between the objs internally so i can't eg. just move them. i wish libs just parameterized over an id->data function (essentially a dereference op) and then spoke in ids and just
<nikki93>
let you manage the data layout or sth (including moving objs around and compact)
earnestly has joined #zig
<andrewrk>
FireFox317, oof, I got the file name pattern wrong
<andrewrk>
it's libfoo.1.2.3.dylib, not libfoo.dylib.1.2.3
<FireFox317>
ah, yeah annoying version numbers :(
<FireFox317>
andrewrk, so you are running the tests locally on a mac now? :D
<andrewrk>
yeah. ran into another issue, about to find out if my fix worked
<andrewrk>
it did. tests are cruising along again now :)
<FireFox317>
nice! its really nice we have so much coverage tho
<andrewrk>
all tests passed locally :D
* FireFox317
really happy
<FireFox317>
Hypeee! Andrew's big branch has been merged!!
<FireFox317>
Congrats man! You deserve some beers and rest :P
<ikskuh>
> Merged #6250 into master.
* ikskuh
screams in excitement
<andrewrk>
woo hoo!
<andrewrk>
apologies in advance for the regressions that I didn't find before merging. at least fixing them will be in .zig code
<andrewrk>
there are some breaking changes btw
<ikskuh>
:D
<FireFox317>
andrewrk, did you ever had 60 PR's open on zig hahah?
<andrewrk>
no I think this is peak
<FireFox317>
with a good reason tho xd
<andrewrk>
ok now which issues do I get to close >:]
<alexnask[m]>
:D
<andrewrk>
oh yeah alexnask[m] so now with llvm-enabled builds, at the link flush() you will have .lib files available for all the DLLs that need to be linked
<andrewrk>
you could also choose to work on self-hosted codegen into .obj files, and rely on LLD as a linker
<andrewrk>
although I personally find it satisfying to go straight to executable :)
<alexnask[m]>
That is amazing :) I will start working on imports and exports for PE
<andrewrk>
probably a bunch of issues can get labels modified now too -stage1 +stage2
<andrewrk>
I have 45 github issues to file
<FireFox317>
its so nice to browse through the zig code now using zls + vscode 'Jump to definitions' <3
<ikskuh>
andrewrk: you're on a issue killing spree, very nice :D
<andrewrk>
I think that's it actually. and now I have to file 45 new issues
<ikskuh>
dang
<ikskuh>
this means i have to be careful now :D
<andrewrk>
it's ok, they're much easier than the ones that just got closed
<andrewrk>
not all issues are created equal
<ifreund>
\o/
<FireFox317>
andrewrk, #1344 can be closed?
<andrewrk>
that issue wasn't really valid anyway, it didn't actually articulate a problem
<andrewrk>
ifreund, oh that glibc issue is solved now
<FireFox317>
andrewrk, i'm just looking through issues seeing which one can be closed :P
<ifreund>
andrewrk: excellent, that will make sticking with 0.7.0 nicer :)
<ifreund>
though my WIP libwayland bindings now make heavy use of tdeo's opaque{} so I may be tempted to switch to master if that gets merged post 0.7.0
<andrewrk>
does that mean you're strongly in favor of opaque {} ?
<ifreund>
very
<ifreund>
it makes writing bindings far cleaner since you can namespace stuff without wrapping opaque pointers in a struct
<andrewrk>
alright well I need to take that vacation I promised myself but at this point I'm feeling pretty inclined to accept it
<ifreund>
the previous impl was basically const Foo = struct { const Impl = @Type(.Opaque); impl: *Impl, };
<ifreund>
and then you have to deal with having a wrapper struct everywhere
<ifreund>
yes definitely take that vacation! would appreciate you giving it a look when you get back :)
<andrewrk>
FireFox317, I remember for the last release you were really helpful getting various builds of zig-bootstrap to work
<andrewrk>
there's an issue right now in the upcoming release that I could definitely use your help with if you're interested
<FireFox317>
andrewrk, yes that's correct :) I would love it to help you with that again
<andrewrk>
actually it's an issue with master branch even. somewhere between 0.6.0 and now, we started tripping an llvm assert for ReleaseFast and ReleaseSmall with the std lib tests
<andrewrk>
the problem is that you can only detect it with a debug build of llvm so that it has asserts enabled which is reeeeeally slow. so that's why it doesn't get tested very often
<andrewrk>
but it means basically that we're hitting UB in llvm code in ReleaseFast and ReleaseSmall builds for whatever code is triggering this
<andrewrk>
and as sonic sez, That's No Good
<FireFox317>
I think i can test that on the arm server, if it is still alive
<andrewrk>
should be
<andrewrk>
it's possible that it might or might not trip the problem
<FireFox317>
so this is not specific to for example an arm/raspberry-pi zig-bootstrap build?
<FireFox317>
are you planning on releasing all these tarballs again for 0.7.0 btw?
<andrewrk>
yep hopefully we didn't regress any of them
<andrewrk>
I think llvm 11 is releasing in a couple days so we have about a month to figure it out
<ifreund>
nice, I can poke at it a bit to see if I can fix it
<ifreund>
should also make sure the -femit-bin=foo thing solves that other issue I had
<andrewrk>
yeah
cdrubin has joined #zig
<FireFox317>
ifreund, so did you check the `uname -a` output?
<andrewrk>
I'm kinda confused why that worked before. the code I linked above is unchanged in the branch I just merged
osa1 has joined #zig
<ifreund>
Linux trantor 5.8.12_1 #1 SMP Sat Sep 26 18:03:25 UTC 2020 x86_64 GNU/Linux
<ifreund>
doesn't show libc version :/
<andrewrk>
the libc version is determined by readlink() on the path you get if you `ldd /usr/bin/env` and choose the libc.so.6 one
<FireFox317>
oh sorry, i thought it was about the linux version my bad
<ifreund>
I think stepping through it in a debugger might be enlightening
<osa1>
I'm trying to build zig from source. I have LLVM 10 installed but not in a standard location. Anyone know how to point cmake to that location? Currently I'm getting these errors: https://gist.github.com/osa1/faf00d12d38137f5a1de342d2329c354
<FireFox317>
i guess andrewrk changed the logic a bit
<ikskuh>
yeah
<pixelherodev>
Whelp, that probably breaks Thor too
<ikskuh>
i'm tracking back the cause
<ikskuh>
only explanation right now is that somewhere the propagation of the lib type is set to .Dynamic
<FireFox317>
ikskuh, nah. It is just checking for an executable or a dynamic library. For a static library it just doesnt add the compiler_rt to the work queue
<ikskuh>
yes
<ikskuh>
but!
<ikskuh>
the compiler_rt should be linked only if it's a dynamic lib or an executable ;)
<FireFox317>
ahh, is that true tho?
<ikskuh>
i think i found the error
<FireFox317>
nice!
<ikskuh>
the link mode passed to the File is determined differently from the one passed to the compilation
<FireFox317>
which is maybe also causing #6469
<FireFox317>
because that also looks at link_mode
<FireFox317>
yeah so i guess when building zig, it uses the self-hosted code (which is incorrect) and thus it sets the builtin.link_mode to .Static (regarding #6469)
<ikskuh>
FireFox317: yeah, it's building my static lib as a dynamic file
<ikskuh>
i'll try debugging it later
waleee-cl has joined #zig
joey152 has joined #zig
ltr has joined #zig
omglasers2 has joined #zig
omglasers2 has quit [Client Quit]
omglasers2 has joined #zig
dbohdan has joined #zig
<mkchan>
why can't a struct depend on an optional of itself?
<ikskuh>
mkchan: the optional is "just" struct { value: T, is_null: bool }
<fengb>
Because memory layout doesn't make sense
<ifreund>
an optional pointer would be fine
<ikskuh>
so an optional is "sizeOf(T) + 1 bit"
<pixelherodev>
Root reason: ecause it'd be infinitely recursive
<pixelherodev>
because*
<fengb>
You need enough memory to store fields + optional + itself
<fengb>
And itself == fields + optional + itself
<pixelherodev>
`struct a { b: a }` <- it's impossible, fundamentally, for any object of type a to exist
<fengb>
In theory... it can store itself if itself is a zero sized type :P
<mkchan>
obviously it's a *const MorseTree and not a *MorseTree, do i really have to use an allocator during comptime processing?
<mkchan>
(ignore my lack of base case for recursion)
<pixelherodev>
Pointers can be comptime known if they're pointing to comptime objects, I think?
<fengb>
I think you can force it to be runtime by assigning a variable: `var tree = MorseTree{}; self.dot_suffix = &tree;`
<mkchan>
won't it go out of scope?
<fengb>
That's true regardless of you assigning a temp variable or not
<fengb>
But at comptime, there's a garbage collector
<fengb>
for stack variables
<mkchan>
so if i were doing this at runtime, the obvious choice is an allocator because i'll just never free that memory until the end of the program. at comptime, it's really unclear
<mkchan>
good news is that suggestion seemed to work, let me write some tests
<pixelherodev>
mkchan: if you're never freeing the memory for the entire duration, then... why not just stack in main()?
<pixelherodev>
Or, a global?
<mkchan>
it is a global
<mkchan>
line 43
<pixelherodev>
Why does it need to be allocated?
<mkchan>
no, you're misunderstanding what i'm saying
<mkchan>
if it's an optional pointer, and at runtime, if i do this: var tree = Tree{}; ptr = &tree; the ptr will contain an invalid value
<mkchan>
at runtime i'd have to allocate and use that in the ptr
<ifreund>
it would only be invalid if the `tree` variable went out of scope
<mkchan>
anyway, i updated the gist with working code, thanks fengb
<mkchan>
ifreund: if you read the code in the gist, it does go out of scope
<mkchan>
but at comptime apparently that doesn't matter
<ifreund>
indeed, comptime works differently
<mkchan>
so at comptime these things are effectively shared_ptrs
<ifreund>
they are effectively garbage collected
<ifreund>
they exact method isn't important
sawzall has joined #zig
<mkchan>
so coming back to my initial question, "why can't a type depend on an optional self", isn't this a way to implement that feature?
<mkchan>
oh but i suppose it's implicit allocation at runtime hmm nvm then
<tdeo>
yeah no it would be a very big change
<ifreund>
stucts must have a complie time known size
<mkchan>
yeah it fails the basic tenet of no implicit allocation anyway
<ifreund>
idk how it would be implicit allocation
<mkchan>
but this was interesting, comptime implementation stuff sure is interesting
<mkchan>
because the implementation i mentioned was basically implementing an optional as a ptr and assigning to the optional would be an allocation
Akuli has joined #zig
<ifreund>
oh you were saying the compiler would do that for you?
<ifreund>
yeah that violates a lot of what zig is about :D
<mkchan>
yeah exactly
<mkchan>
btw, do you guys maintain a "Zig by example" type thing? like a cookbook
<mkchan>
the docs do a lot of it for the basic features but a repo for common use cases would be nice
<alexnask[m]>
ziglearn.org is the closest thing to this
<alexnask[m]>
But this is more of a tutorial deal, not exactly the type of content you are talking about
<mkchan>
yeah, like i imagine an example way to implement a linked list would be useful for people to learn this concept i just stumbled upon
<ikskuh>
mkchan: then you're maybe searching for std
<ikskuh>
the zig stdlib implements a lot of common patterns in a quite well-readable manner
<ifreund>
lack of macros and overal simplicity make it the most redable std I've ever seen
<justin_smith>
nikki93: that stuff about alloc lifetime could likely be simplified via ECS. Have a minimal struct of identifiers for the "game objects", then eg. a room can have a mapping from game-object id to resources that can be disposed when that room is out of scope or that object leaves that room
<mkchan>
oh yeah, just a week or two back i was trying more comptime hackery and someone here mentioned the std.meta.fields function. i think it was fengb . cleanest, easiest to read metaprogramming i've ever seen
<justin_smith>
and if a game object is destroyed / removed from the game, you can walk each of the contexts and free things that index to it
<FireFox317>
andrewrk, i managed to hit the assert in llvm :) However weird thing is it only happends when i do `zig build test-std` but not when i do `for f in ../lib/std/*.zig; do if [ "$f" == "../lib/std/std.zig" ] ; then continue ; fi ; echo "$f" ; ./zig test -OReleaseFast "$f"; done`
a_chou has quit [Remote host closed the connection]
llimllib has quit [Quit: Connection closed for inactivity]
V is now known as v
v is now known as V
ltr has quit [Remote host closed the connection]
<FireFox317>
I think we weren't hitting this before just because the amount of tests increased, thus at some point this single test executable gets to big and llvm doesn't like that
<fengb>
Industry: write lots of tests! LLVM: but not too many 😭
sawzall has quit [Read error: Connection reset by peer]
sawzall has joined #zig
<FireFox317>
I guess they dont like it that we put them all into a single binary haha
<ikskuh>
FireFox317: i just know that zig wrongly assumes that my static lib is dynamic
<ikskuh>
and i have no idea where this is introduced
<FireFox317>
Do you have a small repro? Just `zig build-lib -static`?
<ikskuh>
not yet
<ikskuh>
will try next
<ikskuh>
debug printing is the best printing
<ikskuh>
just introduced some prints :D
<FireFox317>
ikskuh, i see you were building c files right?
<ikskuh>
yeah
<justin_smith>
is it expected that the compiler wouldn't be able to do a floating point multiply at comptime?
<justin_smith>
I want to populate a table for DSP when compiling, if possible
<justin_smith>
I guess I can use an inline literal array, but it would be more elegant to just put my formula for making the array in the code
<FireFox317>
justin_smith, floating point at comptime should be possible yes
<justin_smith>
OK then I need to narrow why this is failing, thanks
<justin_smith>
so breaking it up, the error doesn't happen on the floating point op, it happens in the array fill code
<justin_smith>
I have an array of f64 called fade_in (a volume curve): for (fade_in) |*item, i| {
<justin_smith>
using item.* to assign a value to an array index is failing
<FireFox317>
justin_smith, hmm okay. Can you post a small snippet of the code on a gist/postbin or something?
joey152 has quit [Read error: Connection reset by peer]
<justin_smith>
FireFox317: absolutely
osa1 has quit [Ping timeout: 240 seconds]
<justin_smith>
FireFox317: error happens on the item.* = scale line http://ix.io/2zii
<FireFox317>
justin_smith, i think there is some context missing. Where is fade_in defined?
<FireFox317>
and is this at global scope or function scope?
<justin_smith>
it's an array pub var fade_in: [curve_length]f64 = undefined;
<justin_smith>
global scope
<FireFox317>
okay
<justin_smith>
currently trying a while, instead of the fancy array pointer / index syntax to see if that helps
<FireFox317>
you might be able to see why this is going wrong. So fade_in is defined as a `var`, which means that it is runtime known. It has to be defined as a `const`. One moment while I type up an example
<FireFox317>
It basically comes down to defining it as const, and then using a block to initialize the list and break the value from the block
<justin_smith>
oh, it was const at first and I think I misunderstood the error I got
<justin_smith>
but using while instead of for gets rid of the if block, which I actually like...
<justin_smith>
FireFox317: "error: cannot assign to constant" on the same pointer assignment
<FireFox317>
justin_smith, you are welcome! The code inside the block has to be executed at comptime because it is a constant global.
<justin_smith>
great, that's exactly what I want (why use CPU cycles on startup filling in tables...)
<FireFox317>
yeah zig solves that really nice with the comptime feature :)
<nikki93>
justin_smith: i am literally using an ecs :) i was just talking about the physics engine in that case
<justin_smith>
nikki93: yeah, I think I was mostly learning out loud how well an ecs could align with ownership / lifecycle management
<nikki93>
the physics engine i'm use kinda mallocs and frees stuff on its own for its objects, but i just have a move-only handle on its stuff (in c++) so the lifetime is managed. but unlike the rest of the data in the ecs it's not compacted
<justin_smith>
I've used something like an ecs before, but in a garbage collected language, but I'm seeing now how a well designed ecs could really simplify lifecycle logic
<nikki93>
yeah for sure. it was more about the compaction than the lifecycle. bc. the physics engine internally uses ptrs vs some id system i can't move stuff around
<nikki93>
for the rest of the "components" when something is removed, the last element is moved down into its place and stuff remains compact
<nikki93>
which only works by only accessing things thru id and no pointers
<nikki93>
i agree tho: in games lifetime is actually part of the gameplay logic. and having allocation hang off of that makes a lot of sense vs. gc.
scientes has joined #zig
<nikki93>
zig's reflection and comptime features can lend itself to some nice stuff here that i'm excited to try :o
<justin_smith>
nikki93: now I'm thinking I can use some ECS concepts for properties of my synth DSP (instead of having to go add a pan to every object for a stereo version, I can have a panner table indexed to objects to make them stereo...)
<nikki93>
yeah i think it's a good architecture for a lot of realtime system kinda stuff haha
<FireFox317>
justin_smith, is your code available? DSP stuff is interesting :P
<nikki93>
i'm curious about applying it to xplat ui apis -- like having a layout component and hierarchy component, and specific components for each concrete platform and xplat components they read from
<justin_smith>
FireFox317: this is a very young project and my first time doing something other than example code, I do have a translation of the jack audio simple client though
<justin_smith>
first time in zig that is...
<FireFox317>
ah that was you too. Yeah i remember that example :)
<nikki93>
but yeah it does that thing where data lifetime automatic stuff just "works." eg. the physics body is automatically removed from the physics scene when a component is dropped
<FireFox317>
justin_smith, ah i see. So you can just create your audio at that point indeed
<FireFox317>
cool stuff
<justin_smith>
yeah, the hard part is making a signal that is not objectively offensive to the ear (with jack you can plug into a filter / limiter in another program instead of the speakers directly at least - or even just plug into a spectrum analyzer instead of the speaker)
<justin_smith>
it's much more civilized than using the sound card directly
<justin_smith>
especially when debugging (plug into my daw to see a trace of the waveform, spectrum analyze etc. etc. and it's all timestamped)
<justin_smith>
if I have suspicion about an internal signal, I can put it into a debug outlet and analyze that in parallel, why not!
<justin_smith>
nikki93: looking at that c++ code now...
<nikki93>
i have a video of the game itself somewhere to give an idea. but one of the nice things is how the Walk component is enabled/disabled on the Player to have them walk around
<FireFox317>
ikskuh, pixelherodev, ah nevermind. I confused system_libraries with libc. Ofcourse you should be able to statically link system libraries
ur5us has joined #zig
<ikskuh>
<FireFox317> xq ah nice find! But can we build a static library and link libc together when using -gnu? Only with -musl right?
<ikskuh>
you can also create static libraries that require to be dynamically linked against libc later
<ikskuh>
what the heck does --enable-websql?!
<ikskuh>
seems to work…
<ikskuh>
my workbench builds again
<pixelherodev>
Nice
<pixelherodev>
... fudge it
<pixelherodev>
Using a static build for now
<pixelherodev>
I mostly do stage2 work anyways
<FireFox317>
ikskuh, Nice! PR incoming? :P
<ikskuh>
yeah :D
<ikskuh>
i test it a bit more though
<pixelherodev>
Wow stage2 is bigggg now
<pixelherodev>
I wish stage1 could break down files within the cache
<pixelherodev>
Cache by function instead of by file
<andrewrk>
one final thing before I go on vacation for a few days
<pixelherodev>
They here to be pinged with congratulations?
<pixelherodev>
andrewrk: enjoy your vacation!
<pixelherodev>
I can't speak for the rest of us, but I'll certainly try to push that PR count higher for when you return ;)
<ifreund>
hmm, -femit-bin=foo stops --enable-cache from causing the cache path to be written to stdout
<Snektron>
yea enjoy your time off
<ifreund>
this explains why my attempt to add -femit-bin=foo support to the bulid system earlier today failed
<pixelherodev>
andrewrk: does the mailing list accept patches as an alternative to GitHub PRs? Or is it purely for discussions?
<andrewrk>
Vexu, Alex, and Jakub are perfectly capable of merging PRs, especially bug fixes. I'm confident I can leave in peace and not block everyone from getting things done :)
<andrewrk>
toodles
* pixelherodev
waves
<pixelherodev>
Enjoy your break!
<alexnask[m]>
ciao : )
<ifreund>
o7
<pixelherodev>
o7
<pixelherodev>
Uh oh
<pixelherodev>
Now there's a double oh seven loose! *screams in terror*
<ikskuh>
andrewrk, have fun!
<fengb>
Have fun!
<pixelherodev>
Hmm
<pixelherodev>
Probably safest to stick to PRs for now, at least until I can confirm that anyone else uses the list enough to merge in patches from it
<pixelherodev>
oh right, I wanted to ping you about something last night... uh
<pixelherodev>
uhhh
<pixelherodev>
what was it...
<tdeo>
i mean it builds and runs, but i haven't measured memory usage
<pixelherodev>
A PR!
<tdeo>
pixelherodev: i saw you were talking about the varargs pr but forgot if you actually asked anything
<nikki93>
pixelherodev: o yeah i'm familiar with libgc, was jw if it makes sense to actually use as an std.Allocator. like impl an allocator that uses it
<pixelherodev>
Ahh, I remember now!
<pixelherodev>
tdeo: does the va_list PR work?
<nikki93>
i guess you were asking abt using it for zig's internal allocations too tho
<pixelherodev>
nikki93: *specifically* for internal allocations, yeah
<tdeo>
it works, the remaining issue is just how to use it portably
<pixelherodev>
tdeo: work in the sense that it's usable on x64 POSIX systems
<pixelherodev>
Ahh cool
<tdeo>
yes it is
<nikki93>
got it
<pixelherodev>
tdeo: is it rebased onto master yet? :P
<tdeo>
don't think so yet
<tdeo>
what are you using it for?
<tdeo>
it's rebased now, probably works
<pixelherodev>
tdeo: I'm not anymore, actually :P
<pixelherodev>
I redesigned the C API for my project instead lol
<tdeo>
yeah that's probably better
<pixelherodev>
Now it just does e.g. `thor_load_argument_int(thor, index, value)`
FireFox317 has joined #zig
ur5us has quit [Ping timeout: 240 seconds]
donniewest has quit [Quit: WeeChat 2.9]
ur5us has joined #zig
<Piraty>
is zig supposed to work on archs other than x86?
<Piraty>
will look at it in a few days again, gotta go
<Piraty>
good work @zig people
<pixelherodev>
I believe the official term is "ziguanas" :)
<ifreund>
take off every zig!
<jjsullivan__>
Piraty, that PR was my doing if you wanted to know anything
<jjsullivan__>
I also submitted the bootstrap patch upstream, just a little change to the cmake so you can use the llvm dynlibs on the target
<jjsullivan__>
**sorry, not just me, ericonr pulled through for testing armv6
<nikki93>
wondering if to try sth like indirect dispatch for opcode vm things using tail calls haha
qeeg_ has joined #zig
<qeeg_>
hey, i've installed all the packages necessary to build zig from the arch linux repos (clang, lld, llvm, and llvm-libs), but cmake still can't find clang's libraries
<qeeg_>
what exactly am i doing wrong?
omglasers2 has quit [Quit: Leaving]
<ifreund>
qeeg_: on arch you need a special cmake flag due to how they package llvm: -DZIG_PREFER_CLANG_CPP_DYLIB=ON
<ifreund>
see the PKGBUILD for the zig package in the arch repos
<qeeg_>
ah, okay, thanks
<ifreund>
no problem! I don't even use arch, this just comes up fairly often :P
<qeeg_>
okay, now when trying to build stage2 i get this "error: linking against dynamic libraries not yet supported"
<qeeg_>
which... seems a bit odd
<ifreund>
this is with master zig?
<ifreund>
a very large branch porting linking among other things from c++ to zig was merged in the past 24 hours
<ifreund>
stage2 seems to have built fine for me though
<qeeg_>
yeah this is with master zig
<ifreund>
so you built stage1 with cmake successfully and then ran zig build using it?
<qeeg_>
yep
<qeeg_>
should i have run zig build from the stage1 build dir or another directory?
<ifreund>
from the root of the repository
<ifreund>
though idk maybe it doesn't matter
<pixelherodev>
I do it in build usually
<qeeg_>
tried that too
<pixelherodev>
Shouldn't matter
<qeeg_>
same thing :/
<pixelherodev>
What arch?
<qeeg_>
x86-64 arch linux
<qeeg_>
weird, removing the -Denable-llvm fixes it
<pixelherodev>
LLVM is needed for stage1...
<pixelherodev>
ah wait
<qeeg_>
yeah this is stage2 i'm compiling :/
<qeeg_>
*:p
<pixelherodev>
Nah, I meant
<pixelherodev>
there's three stages now
<qeeg_>
i know
<pixelherodev>
stage0, which is built as part of the stage1 process
<qeeg_>
ah okay
<pixelherodev>
stage1, which contains a lot of stage2 code
<pixelherodev>
that's built by stage0, and links against LLVM I believe
<pixelherodev>
then stage2 is built by stage1?
<pixelherodev>
Unless... I think 6250 may have changed it
<qeeg_>
for some reason stage2 can't compile itself though, gives me this error build_runner.zig:1:1: error: no entry point found
<qeeg_>
attempt to use null value
<pixelherodev>
so stage0 doesn't exist
<pixelherodev>
Ah yeah, no, stage2 can't nearly compile itself
<pixelherodev>
It's not close to ready for that
<pixelherodev>
stage1 is needed for a reason
<qeeg_>
ah
<pixelherodev>
Stage2 has only been undergoing serious work since 0.6
<qeeg_>
where can i start helping with getting it to compile itself?
<pixelherodev>
it's intended to be released for 0.8
<pixelherodev>
The first step is to get involved, which you already have :)
<pixelherodev>
Maybe look for "contributor friendly" "stage2" issues on GitHub
<qeeg_>
no, i mean like, where's the code i can hack on?
<qeeg_>
ah okay
<pixelherodev>
Might be a good idea to mention intent to work on it in here
<pixelherodev>
I'm working on CBE stuff, and I know some others are working on the various linker backends
<pixelherodev>
So it's a good idea to avoid stepping on each other's toes :)
salotz has joined #zig
<qeeg_>
cbe stuff?
<pixelherodev>
C backend
<pixelherodev>
Want me to give you a quick rundown of how the compiler works?
<pixelherodev>
I have... enough time for that
<pixelherodev>
Probably.
<ifreund>
do we have something in the std that will tell me if a string is a valid zig identifier or not?
<ifreund>
or should I just wrap all the identifiers I generate in @"" :P
<pixelherodev>
ifreund: why *not* just use @"" for everything?
<tdeo>
ah right predefined stuff won't matter since it won't let you shadow it
<qeeg_>
ah
<ifreund>
pixelherodev: it's ugly to read, and people will want to read the generated code
<qeeg_>
well, maybe i'll just start fixing tests that fail on stage2?
<pixelherodev>
qeeg_: that's a lot harder than it sounds
<qeeg_>
oh?
<ifreund>
what part of the compiler are you interested in? Higher level AST stuff? x86_64 codegen?
<pixelherodev>
You can't fix something if you don't understand why it's broken
<pixelherodev>
ifreund's question is on point, too
<pixelherodev>
ifreund: fair
<qeeg_>
i'm not sure, i've never worked on a compiler before o.o
<qeeg_>
i've tried to get into it, but i've never really understood any of it
<pixelherodev>
qeeg_: want me to give that rundown? That might help you decide what you're interested in
<ifreund>
me neither. My way to get started on stage2 was to start implementing a backend for wasm
<qeeg_>
sure
<tdeo>
i've been reading through stage2 and trying to understand
<pixelherodev>
Do you know the basic terms? Actually, better idea: if you don't understand something, just ask
<ifreund>
this involved reading and understanding a lot of the wasm spec, and then reading and understanding lots of the stage2 code before I could actually write any code of my own
<qeeg_>
i uh, have NO idea how compilers work
<qeeg_>
i know how emulators work!
<pixelherodev>
Ah, okay
<qeeg_>
but not compilers
<pixelherodev>
Do you know what an AST is?
bartwe_ has joined #zig
<qeeg_>
abstract syntax tree, but i have no idea what that actually means
<qeeg_>
or how to make one
<pixelherodev>
Basically, the *parser* reads in the Zig code and then produces an in-memory tree which maps to the source code 1:1
<qeeg_>
or what to do with one once you've made it
<qeeg_>
i'm a HUGE noob at this
<pixelherodev>
We all were once
<bartwe_>
o hi
<pixelherodev>
AST is basically just a data structure which exactly represents source code
<qeeg_>
okay
<pixelherodev>
It's possible to take the AST and derive the original source - and this is basically how `zig fmt` works. It reads in the code into an AST, looks it over, adjusts it, and writes it back out
<qeeg_>
but what do you do with it?
<pixelherodev>
`astgen.zig` takes in the AST and produces "IR"
<ifreund>
well, your end goal is machine code for a target cpu
<pixelherodev>
IR, or intermediate representation, can be thought of (inaccurately) as abstract assembly
<pixelherodev>
The IR undergoes semantic analysis - type checking, for instance - and is then passed on to codegen
<pixelherodev>
codegen takes IR and produces machine code for a specific target
<pixelherodev>
AMD64, aarch64, wasm, etc
<pixelherodev>
(or, in the case of the C Backend [CBE], C code)
<pixelherodev>
The machine code is sent through the *linker*, which produces a binary (ELF on Linux, .exe on Windows, etc)
<pixelherodev>
I can direct you to a much simpler (and worse) compiler for a totally different language, if that helps get some idea - it's much smaller, and it's in C, if that helps
<qeeg_>
the "it's in C" part doesn't really help much, plain C is often quite confusing for me :p
<qeeg_>
honestly, i kinda wanna get into code optimization work
<qeeg_>
since that can probably translate well into my emulator work
<pixelherodev>
Optimization isn't really a priority right now :P