<andrewrk>
Clang/LLVM 9 has emscripten as an OS target
<daurnimator>
andrewrk: oh I meant to ask you: how do I target wasm with zig cc?
<andrewrk>
don't use zig cc, use the higher level API
<daurnimator>
e.g. I make wasm.c containing: `int foo() { return 42; }` -> how do I call that function in my browser?
<andrewrk>
gotta go
<daurnimator>
Trying to run `zig cc -target wasm32 wasm.c` results in: `wasm-ld: error: unknown file type: /lib/crt1.o` `wasm-ld: error: cannot open /usr/lib/clang/8.0.0/lib/libclang_rt.builtins-wasm32.a: No such file or directory`
fengb has joined #zig
kristoff_it has joined #zig
<fengb>
daurnimator: I think you're supposed to use something like `zig build-lib --library c --c-source wasm.c -target wasm32-freestanding`
kristoff_it has quit [Ping timeout: 258 seconds]
<daurnimator>
fengb: okay, that outputs a libwasm.a file.... what should I do with that?
<fengb>
build-lib -target wasm32-freestanding should build a .wasm file...
<fengb>
Do you have wabt? We can try inspecting lib file to see if it's correct
<daurnimator>
fengb: it seems to have put a wasm file inside of a .a archive
<daurnimator>
inside of the archive is a single file: `zig-cache/o/VQ1oIrWBLiUiB6v98Pd2ehg8lXnt6uXaJWr9h2XxP4n0Jhy03F36eN3ZucxgGiXm/wasm.o` which *does* seem to be a wasm file
<fengb>
That's really weird
<fengb>
Lemme pull latest
<fengb>
I'm also distracted cause I finally got Mario working lol
<daurnimator>
so trying to load that wasm.o file into node gives: LinkError: WebAssembly Instantiation: Import #0 module="env" function="__linear_memory" error: memory import must be a WebAssembly.Memory object
<fengb>
Yeah that's just an object file. It's not fully linked
<fengb>
Latest with build-lib gives me a "wasm.wasm" output file
<fengb>
Hmm, how old is your zig? Maybe you still need build-exe ?
dimenus has quit [Ping timeout: 245 seconds]
<ntgg>
is there a way to call a shell command in zig and capture the output?
<lunamn>
maybe with std.ChildProcess?
marijnfs has quit [Ping timeout: 276 seconds]
<ntgg>
looks promising
marijnfs has joined #zig
<fengb>
error: integer value 16384 cannot be implicitly casted to type 'u8' — u32(BANK_SIZE)
<fengb>
Am I going crazy?
kristoff_it has joined #zig
<fengb>
Oh... the field type was accidentally u8
<darithorn>
how do i pass a union(enum) as an argument to a function? I get "runtime cast to union 'Key' which has non-void fields"
kristoff_it has quit [Ping timeout: 248 seconds]
<darithorn>
the error isn't very helpful
<ntgg>
like have a function that takes in a type that is union(enum)?
<ntgg>
just the same as any other type i think
<darithorn>
yeah, if const Key = union(enum){}; and fn foo(key: Key){}
<darithorn>
that's what I thought but i'm getting an error
<darithorn>
hm, it had something to do with the fact I didn't explicitly specify the type on my variable
<darithorn>
I had var myKey = Key.None; I changed it to var myKey: Key = Key.None; and it fixed the error.
<darithorn>
maybe someone who understands how the compiler infers types would know why
<ntgg>
there are a fair amount of errors with tagged unions and type inference it seems.
fengb has quit [Ping timeout: 260 seconds]
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 272 seconds]
belgin has joined #zig
<belgin>
hello
fengb has joined #zig
<darithorn>
hello belgin
ntgg has quit [Ping timeout: 246 seconds]
<belgin>
what's the deal with the line endings in zig?
<belgin>
my baudot teletype expects a carriage return after a line feed
<belgin>
can't zig copy the source in to ram and then run fmt on that buffer?
<belgin>
before starting to parse/compile etc
<belgin>
on the other hand, i do appreciate the sentiment to have all zig code look the same
<belgin>
but if fmt can fix the problems, just have fmt fix them?
<hryx>
whitespace discussion is considered off-topic here; you should refer to the links in that FAQ. (sorry to have engaged earlier)
<darithorn>
belgin if you have the zig vim plugin it runs zig fmt everytime you save
<darithorn>
and i think the idea is to have zig fmt separate from the actual zig compiler because it's not really a pleasant idea to have the compiler itself mutating your source code
<emekankurumeh[m]>
what about instead of `usingnamespace` we changed it to `using`? using identifier length to enforce a style of code seems strange imo. that sort of thing belongs in the style guide.
<hryx>
hey emekankurumeh[m], I was thinking of making a proposal to remove `usingnamespace` entirely, but I know that some consider it important and I want to make sure I consider real use cases. Would you mind explaining or linking me to the most compelling use case (in your opinion)?
Pwipwi has quit [Remote host closed the connection]
fubd has joined #zig
<fubd>
are there known alignment/codegen segfaults? I'm seeing a weird one where if I add or remove a warn() call, my program is crashing, and the value of a field in my struct is getting zeroed out
<mikdusan>
i can see segfault on windows. fyi doesn't happen on macos or linux.
<Pwipwi>
When I make a function that returns a new struct instance and assign it to some memory that was allocated, is a copy made or does the compiler "know" how to directly assign to it ?
<Pwipwi>
var mystruct = allocator.alloc(Struct, 1); mystruct[0] = mkstruct();
<Pwipwi>
is there a copy step when I do that ?
<mq32>
afaik there is right now, but there's been work put into copy elision
<fubd>
mikdusan: hmm, strange. i wonder how else i can narrow this one...seems very dependent on alignment, because adding or removing certain statements makes it not happen
<mikdusan>
omglasers2: 3-4 weeks ago there were some posix/os API renames. `std.os.Thread` -> `std.Thread`
<omglasers2>
thanks, had to change at l260 but now I have "src/main.zig:237:9: assertion failed. This is a bug in the Zig compiler."
<omglasers2>
at l260 too*
fubd has joined #zig
<fubd>
mikdusan: ah, I see. i was assuming that since the things they were pointing to were in the heap I was okay--I wonder if returning a slice of a stack object should be disallowed
<daurnimator>
fubd: it should. but it's hard to do. currently an open issue I think
<mikdusan>
fubd: i believe that is in the plan for compiler to do things like more thorough escape analysis
<scientes>
when do ConstExprValue get populated?
<scientes>
and what do i have to call to populate it
<scientes>
// populated if special == ConstValSpecialStatic
<scientes>
but it is
<scientes>
figured it out
fubd has quit [Ping timeout: 260 seconds]
<scientes>
if i use the child then i don't have a ConstExprValue, but if i use the non-child then i don't have a type.... :/
<mikdusan>
is there something in .cpp source code (Visual Studio compiler) similar to @compileLog()? I'd just like to emit a sizeof(thing)
<scientes>
printf
<scientes>
or the debugger
<scientes>
zig is generally developed on Linux
<mikdusan>
yeah the issue is i can't get as far as passing asserts. no matter, i have a workaround.
<scientes>
are you sure that code is being run?
<scientes>
and are you compiling in debug mode?
<scientes>
cause I'm working on ir.cpp right now
<mikdusan>
it's a .cpp assert that fails comparing sizeof() on windows; zig_lang.cpp stuff. i suspect hardcoding some padding is not very robust and my compiler is producing something different
<scientes>
oh then fix the bug
<scientes>
that assert saved a much more difficult to fix bug
<mikdusan>
i dunno, started off by asking something about .cpp compiler and how you got here is beyond my understanding.
dimenus has joined #zig
<scientes>
its not my problem. if you want answers you have to provide enough information
<mikdusan>
@compileLog() in zig runs before runtime. the question was seeking an analogue for C++ if that even makes sense. printf/debugger/linux is not helpful. telling me to fix the bug is not helpful. i'm saying this with all due respect. and this is no longer productive, i have a workaround as stated.
<scientes>
yeah you can step through in the debugger
<scientes>
that is compile-time
lunamn has quit [Ping timeout: 248 seconds]
<scientes>
gdb or lldb
<scientes>
or some windows thing perhaps
<scientes>
oh i see
<scientes>
yeah I don't think C has that
<scientes>
I'm sorry
<scientes>
the problem is I don't think C CAN have that, because of the preprocess
<scientes>
you can look at the .i file from using --save-temps
<mikdusan>
yeah i agree. it makes no sense. which is why the question probably threw u off.
<scientes>
that is about all you can do
<scientes>
that will tell you what the real type is
<mq32>
<mikdusan> is there something in .cpp source code (Visual Studio compiler) similar to @compileLog()? I'd just like to emit a sizeof(thing)
<scientes>
you can do that with introspection features
<scientes>
...probably
<Pwipwi>
I'll wait for it to be implemented :)
<scientes>
or should be able to
<scientes>
hmm, yeah I can't figure out how to get ir_render_foo to run
<fengb>
Pwipwi: you can also embed that as a method `fn stringify(self: &This()) []const u8`
<mikdusan>
Pwipwi: "is it possible to use strings in enums" - just to confirm, you're not talking about union(enum) right?
<Pwipwi>
enum ([]u8) {
<fengb>
That's a slice. I wouldn't expect that to ever work
ofelas has quit [Quit: shutdown -h now]
<Pwipwi>
even with enum([]const u8) ?
<fengb>
Maybe [*]u8 since that doesn't have an embedded length
<Pwipwi>
since literals can auto cast in them
<mq32>
Pwipwi, that doesn't really make sense
<fengb>
[]const u8 maybe... it gets tricky because slices always have length
<mq32>
what do you want to switch on?
<mq32>
literals? runtime-values?
<mq32>
but i think the real question should be: what do you want to achieve with that construct?
<fengb>
Right now, enums are always exhaustive so none of that could be done. There's a proposal for non-exhaustive enums, which may be able to support pointers: https://github.com/ziglang/zig/issues/2524
<fengb>
But even then... I'm not sure I'd want an enum to operate on pointers, since there's no guarantee those are stable
halosghost has joined #zig
<gonz_>
Non-exhaustive enums
<gonz_>
that seems super low value
<fengb>
OS interop
<fengb>
Rust and Swift both added it
<mq32>
gonz_, that's relevat everywhere you cast integers into enumeration values where you don't know the whole enumeration set
<gonz_>
fengb: I'm not sure that's a good argument for anything
<fgenesis>
enums may be extended with lib/OS/... updates too so at least having an explicit fallback case is nice
<mq32>
just imagine you interface *something* that says "enumeration values may be extended in the future"
<halosghost>
what is a non-exhuastive enum?
<fengb>
It means it's clearly desired by similar languages. You can ignore all of their research if you want...
<halosghost>
I don't believe I've heard that phrase before
<mq32>
halosghost, enumeration that allows non-listed values as possible options
<halosghost>
ah
<halosghost>
à la C
<halosghost>
meh
<fgenesis>
halosghost: enums you know that won't be extended where you can guarantee at compile-time that all values are checked
<gonz_>
fengb: zig *should* ignore most of rust's wants and needs, IMO
<fgenesis>
= exhaustive
<halosghost>
fgenesis: right
<halosghost>
rust, zig, and swift all have quite different goals and needs, that's for sure
<halosghost>
good to know about ideas from other languages, but “because they did” isn't a great reason to do something imo
<mq32>
gonz_, doesn't mean we shouldn't consider features with practical use that may prevent either bugs or huge workarounds
<fengb>
But dismissing it because "rust" is also not very helpful
<gonz_>
A language that is trying to replace C++ is necessarily different than one that tries to be simple and have less extras
<fengb>
I'm just saying there's a bunch of proposals about low level interop that's been done at a low level by other languages
<gonz_>
Enough small things of practical use and you just end up with a language that has tons and tons of extras that can be added everywhere
<fengb>
At least maybe read their reasoning before saying "no, rust"
<halosghost>
I have a question
<halosghost>
isn't @bitCast to an int already enough to solve this problem?
<gonz_>
at that point the stated goal of debugging your own language knowledge not being a thing is definitely shot to hell
<mq32>
halosghost, no, because if you want the enumeration values to be switched on you need @intToEnum
<mq32>
and that panics/UBs when you pass non-valid values to it
<fengb>
halosghost: but you can't actually use an enum to represent the "enumerated value" if it's not captured in the enum. You'll need to pass around `u8` or equivalent
<halosghost>
mq32: but, if we're talking about values which have been added to the interface since you wrote your program, unless you have a default case, wouldn't that happen anyway?
<fengb>
Distinct types are another solution, but it doesn't capture the known values very well
<gonz_>
fengb: I think you're intentionally being dismissive as well, to be honest. I said citing rust as a reason for having it isn't really enough, not that zig shouldn't have it because rust does.
<fengb>
halosghost: it's more about things you can't control, like OS status codes
<gonz_>
fengb: Those two aren't the same
<fengb>
e.g. Linux has a bunch of codes that are listed but extended at any point. We don't want Zig to just crash if the OS gets upgraded
<halosghost>
fengb: I'm not sure I understand why that would matter; aren't OS status codes mostly documented and enumerable?
<gonz_>
But in general, I stand by what I said; a language trying to replace C++ shouldn't end up looking like one that tries to replace C. One of them has gone badly wrong at that point.
<halosghost>
mm
<halosghost>
I see
<mq32>
halosghost, but i cannot have a default case if i cover all *defined* values in my code, so i get the optimzation that the default case is never met
<halosghost>
mq32: hmm
<fgenesis>
semi-never
<mq32>
i also have beautiful example for this
<mq32>
wait a sec
<fengb>
They're documented to be extended so it'd be nice if Zig could represent this case
<halosghost>
mq32: wouldn't, then, the solution be to allow for default cases when switching on an enum even if all known cases have an explicit case?
<halosghost>
because that is a change I would support
<halosghost>
that seems very measured and reasonable
<fengb>
halosghost: current enums cannot support unknown values
<fgenesis>
+1
<mq32>
halosghost, that's what we're talking about ;)
<fengb>
It's undefined and panics in safe mode
<halosghost>
heh
<mq32>
quoting the LPC 178x manual:
<mq32>
Interrupt identification. IER[3:1] identifies an interrupt corresponding to the UART1 Rx or TX FIFO. All other combinations of IER[3:1] not listed below are reserved (100,101,111).
<halosghost>
I see
<mq32>
if i now query the interrupt source and cast it to an enum (because we are semantic programmers, we do such things) and now my new *hardware* returns values i was noit allowed to use before
<mq32>
i need a default case
<halosghost>
right
* halosghost
double-checks some things about zig enums
<halosghost>
been too long
<fengb>
Also kinda helps with C enums since they're all non-exhaustive... but that's not necessarily a good motivator
<fgenesis>
or like my new hardware suddenly returns a random number instead of -1
* fgenesis
eyes AMD
<halosghost>
since zig enums cannot carry a payload, it would really need to be a different kind of enum
<halosghost>
since, I assume, we aren't really thinking that it'd be a good idea to make all zig enums non-exhaustive
<fengb>
Not a payload. We can do enum(u8)
knebulae has quit [Remote host closed the connection]
<fengb>
But yeah, definitely should be opt-in
<halosghost>
wait
<halosghost>
don't `extern enums` cover this case?
<halosghost>
if you switch on an extern enum, does it still require exhaustiveness?
<mq32>
yes
<halosghost>
hmm
<halosghost>
that seems odd
<mq32>
(at least that's what my compiler tells me here)
<Pwipwi>
ok, I'm trying to get the error set from instream
<Pwipwi>
this is the best I could get :
<Pwipwi>
error: no member named 'Error' in struct 'std.io.InStream(error{OperationAborted,BrokenPipe,Unexpected,InputOutput,SystemResources,IsDir,})' pub fn read(a_: A) (ValueError || in.Error)!Value {
<Pwipwi>
I tried os.InStream.Error, but not much better
<Pwipwi>
Ha, found it
<Pwipwi>
sorry, asking too fast
<scientes>
yeah I have difficulty with that too
<scientes>
its hard to balance other people's time with estimating how long it will take to do it yourself
ntgg has quit [Ping timeout: 248 seconds]
fengb has quit [Ping timeout: 260 seconds]
brakmic_ has joined #zig
brakmic_ has quit [Client Quit]
brakmic_ has joined #zig
brakmic has quit [Read error: Connection reset by peer]
avoidr has joined #zig
avoidr has quit [Quit: leaving]
<andrewrk>
scientes, do you have an aarch64 laptop?
<andrewrk>
what is it?
<fgenesis>
just for reference, rpi4 is aarch64 too, right? i mean once they update the OS to actually run 64 bits
<andrewrk>
yes
<andrewrk>
I'm looking to get a new main dev machine
<andrewrk>
I'm tired of running out of disk space and ram
<mq32>
hm.
<mq32>
i have an olimex teres 1, but that's not a good "main dev" machine
<dimenus>
andrewrk: I'm not having any issues linking glfw statically on Windows
<dimenus>
with up to date master
<dimenus>
there's something else going on here
<andrewrk>
dimenus, thanks, that's good to know. I still think 95e04e3874d is a good idea, do you disagree?
<gonz_>
Anything that allows 16GB+ DDR4, a nice quad core and 512GB+ SSD is a good dev box if it also comes with a nice-ish display, IMO
<dimenus>
andrewrk: no, I would agree that msvc by default is probably good
<gonz_>
But that's pretty much any laptop nowadays
<gonz_>
I have a Dell Inspiron 15 7000 Gaming with 32GB RAM, 1TB SSD and otherwise the defaults. It's probably not very expensive now (if sold still) and does very well.
brakmic_ has quit []
<gonz_>
All in all it's been a very decent experience. I used to run arch on it without any major issues (beyond the usual "Shit, I don't remember what to do about nvidia drivers").
ibutra has joined #zig
<gonz_>
I run Windows now but that's because voice recognition and control still sucks on Linux.
<companion_cube>
1TB SSD :o
<mq32>
companion_cube, isn't that expensive anymore
<ibutra>
andrewrk can you elaborate on #2883 what -target doesn't cover which would be covered by -mcpu?
<mq32>
flash prices are all down right now
<companion_cube>
damn, and I still only have 128GB
<gonz_>
companion_cube: It was actually very obtainable, so I decided to buy a Samsung 860 EVO M.2. This was purely on the recommendation of the shop, though, because I'm not particularly "with it" when it comes to peripherals/accessories.
<mq32>
i have a *bunch* of M-SATA SSDs on my table. 20€ each, 120 GB
<andrewrk>
ibutra, I'll comment on the issue
<ibutra>
I know currently the code just uses the native features in code (See linked pull request) but that could be adjusted to use the target doesn't it?
<ibutra>
sure, thx
very-mediocre has joined #zig
<andrewrk>
ibutra, I also added " Add the list of possible options to zig targets so that they are discoverable" as a checkbox on that issue
<ibutra>
andrewrk I am not sure about (all) the features for a cpu but things like fpu etc. are set by the tripple afaik.
<andrewrk>
the fpu can be communicated by the C ABI, have a look at the list of `zig targets`
darithorn has quit [Quit: Leaving]
<ibutra>
OK, I read in the documentation of clang, that even with -target it is often required to specify -mcpu, -mfpu, -mfloat-abi (and -mattr as well then I guess even though it isn't explicitly mentioned)
lunamn has quit [Ping timeout: 246 seconds]
very-mediocre has quit [Read error: Connection reset by peer]
lunamn has joined #zig
very-mediocre has joined #zig
ltr- has joined #zig
<andrewrk>
as a first step, we need these options enumerated in target.hpp/target.cpp
ibutra has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ibutra has joined #zig
<ibutra>
sry, didn't mean to leave. You mean enumerate all possible options for -mcpu, -mfpu, -mfloat-abi and -mattr?
fgenesis has quit [Quit: leaving]
<andrewrk>
yes
<andrewrk>
this list must exist somewhere in llvm, and we need to expose it
<andrewrk>
and bring it into become a zig concept rather than an llvm concept
<ibutra>
as far as I know it only exists in source code and is dependent on compile options but I can try to look into that
ibutra has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<andrewrk>
these will be exposed in @import("builtin") for comptime use in zig code
<scientes>
andrewrk, i did, the pinebook, but now i'm waiting for the pinebook pro, which you can preorder in a week
ibutra has joined #zig
<scientes>
<andrewrk> I'm tired of running out of disk space and ram
<scientes>
yeah not the machine for you then
<scientes>
only 4GB of ram
<andrewrk>
hmm this is still quite an interesting system for me though, it would be good to have an aarch64 computer
<scientes>
New York should have a great used thinkpad trade on craigslist
<scientes>
SF certainly does
<andrewrk>
ok definitely going to get one of these pinebook pros when it comes out
<andrewrk>
gotta test that aarch64
<gonz_>
Seems a bit underpowered for a main dev machine
<andrewrk>
yeah that would not be a main dev machine
<scientes>
its about the same as my current laptop
<scientes>
4GB is fine, except that zig is a bit ram hungry
<gonz_>
8 is bare minimum and I don't think I could reasonably go lower than 16 at the moment
<scientes>
but yeah it isn't ok for LLVM
<scientes>
meh 4gb is fine for LLVM, but you want more CPU
<gonz_>
4 is definitely not fine for Haskell, 8 is mostly fine but would get cramped
<bheads>
Actually the darter pro looks like a good dev laptop
Akuli has joined #zig
<scientes>
well not everyone can get by with 4GB like me
<scientes>
i would like more cpu, but I can just do llvm stuff on a VPS
<andrewrk>
I've had trouble with the system76 power cables before, the way they plug into the laptop
<scientes>
I wouldn't get anything except a thinkpad
<scientes>
that's just me
<gonz_>
System76 always seemed a bit overpriced to me
<gonz_>
Beyond that I've also noticed that what people recommended usually was worse than what they would actively suggest not to buy. My Dell laptop works great and I've upgraded it to the point where it's better than most people's desktops.
<gonz_>
We've had two thinkpads that've had odd issues with their hard drives in Windows and shoddy hibernation support for Linux
<scientes>
lots of ram is just an excuse for lazy programming
<scientes>
like ubuntu starts up the thunderbolt daemon on computers without thunderbolt
<scientes>
its just stupid
<gonz_>
My HP ProBook that I bought for more portable stuff also works great
<companion_cube>
sadly if you're in a position where you're expected to use slack… :s
<gonz_>
I dunno, consumers having lots of RAM aren't exactly causing the issues themselves.
omglasers2 has quit [Killed (kornbluth.freenode.net (Nickname regained by services))]
<andrewrk>
zig stage1 is paying the cost of using more ram than strictly necessary so that we can iterate faster
omglasers2 has joined #zig
<scientes>
which is fine
<andrewrk>
once the requirements stop changing so fast we can settle in and improve things
<gonz_>
scientes: One of the reasons that I started looking around for a lower level language again a while ago was actually that I felt like we've lost sight of making software that isn't so resource hungry.
<gonz_>
And sure, one justification that can be heard is that we have "so much RAM", but I think it's a bit deeper than that.
<companion_cube>
what were you using then, gonz_?
<scientes>
I agree, performance is part of correctness IMHO
<gonz_>
Haskell, Elixir, PureScript, Racket, etc.
<scientes>
at least once you have the requirements straight
* companion_cube
is updating his raspi 1, talk about feeling what's slow
<scientes>
(premature optimization is still the root of all evil)
<gonz_>
I used to do only C++ way back, but then I found python and since I was so tired of programming after 7 years of C++ I just fell in love with that stuff.
<companion_cube>
feels like haskell wouldn't be that slow compared to python
<gonz_>
And then I found functional programming with Racket and all the rest of the languages in time.
<gonz_>
Haskell is pretty fast and not super unreasonable to optimize, but I wanted something that made it easy to reason about lower-level ideas.
<scientes>
well yeah, hardware is not functional
<gonz_>
It's not that I dislike everything higher-level now but I'm looking to "build my mountain" (if anyone's seen Eskil Stenberg's C talk)
<scientes>
its procedural
<gonz_>
I want to build that mountain on something that I can talk to about lower level things and the spirit of zig makes that stuff fun (again).
<companion_cube>
scientes: it's kind of neither, really, with modern cache consistency issues and whatnot
<companion_cube>
gonz_: what about rust? too complicated?
<gonz_>
I've learned some rust and I really like that they've cross-pollinated a lot, but I've just never had fun with it. Even the small things I've written in zig have been fun.
<gonz_>
Also, rust is just trying to do a lot, I feel like
avoidr has joined #zig
<gonz_>
zig is one of those joyful languages that I just really like writing whenever I get the time
<Sahnvour>
andrewrk: you showed builtin stack traces for zig1 before, is this intended to ship, or just for development ? Does/should the current release build have it ?
<nrdmn>
building zig with "make" (not: "make install") writes into the user's home directory (~/.local/share/zig/...), is this intended?
<andrewrk>
Sahnvour, good question. it's just for development, probably should be disabled on the builds that we ship on the download page, since they don't have debug info
very-mediocre has quit [Read error: Connection reset by peer]
<andrewrk>
nrdmn, yes there's a global cache for compiler_rt, builtin.zig, and zig's libc
very-mediocre has joined #zig
<Sahnvour>
does the windows package ship with the pdb then ? also, we should advise to build it locally in RelWithDbgInfo
<Sahnvour>
I had some crashes caught by that mechanism but it was unable to load debug info, I didn't look at it yet but I suspect that's it
<andrewrk>
I don't think we're going to ship with debug info on the download page, so for those builds it should be disabled. I agree for source builds we should recommend RelWithDebInfo
<Sahnvour>
I'll do that one day or another and update the wiki
<andrewrk>
dimenus, plz don't recommend to people to delete zig-cache
<andrewrk>
unless there are any known bugs in it
<andrewrk>
which is currently not true
<dimenus>
apologies, i was just trying to recommend a clean slate for debugging the linking issue
<dimenus>
but yeah, .def/.libs are generated in the base dir anyway
<dimenus>
so it wouldn't be a cache problem
<dimenus>
point taken
<andrewrk>
yeah, it makes sense you're just trying to eliminate variables
<andrewrk>
I'm just worried about people getting an incorrect understanding of how zig-cache works
<dimenus>
agreed, you don't want word to spread
<dimenus>
that deleting the cache is a recommended part of the process :P
<andrewrk>
right
<dimenus>
should I redact/edit that response?
<andrewrk>
nah it's fine
<andrewrk>
note that the first thing in all the cache-hashes is the zig compiler id (which you can see with `zig id`)
<andrewrk>
so not only are all the input parameters in there, if you make any changes to the zig binary, or even any of its dynamic dependencies such as LLVM or even libc, it will produce a different hash value
<andrewrk>
which means that the caching system works perfectly no matter how many versions of zig you're using simultaneously
kristoff_it has joined #zig
<ltr->
can i rely on the json parser on the std not chaning much in the future?
kristoff_it has quit [Ping timeout: 268 seconds]
ntgg has joined #zig
dimenus has quit [Read error: Connection reset by peer]
dimenus has joined #zig
dimenus has quit [Read error: Connection reset by peer]
<nrdmn>
andrewrk: target zig_build_libuserland, which is a dependency of the default target, seems to install stuff to CMAKE_INSTALL_PREFIX. Is this intended?
fengb has joined #zig
<nrdmn>
and while doing so, it doesn't prepend DESTDIR to CMAKE_INSTALL_PREFIX
dimenus has joined #zig
Akuli has quit [Quit: Leaving]
<andrewrk>
ltr-, I wouldn't consider anything in the std lib stable
<andrewrk>
nrdmn, yes it's intended. what's the use case for DESTDIR when CMAKE_INSTALL_PREFIX specifies the install prefix?
marijnfs has quit [Quit: WeeChat 2.4]
<fengb>
andrewrk: random question — is Zig as big of a project now as you had anticipated when you first started?
<andrewrk>
it's been the plan to actually take over the space for real, not just a hobby project, since the beginning
<halosghost>
:)
very-mediocre has quit [Read error: Connection reset by peer]
<andrewrk>
in terms of scope? yeah I'd say that there were areas of the scope that I didn't anticipate
<andrewrk>
for example, the idea that we'll probably need other backends besides LLVM
<omglasers2>
are there other backends on the roadmap ?
<andrewrk>
I don't think I expected to have to become an expert in so many different operating systems. I'm fine with it though
fengb has quit [Remote host closed the connection]
<andrewrk>
omglasers2, not yet, it's a far-away goal that is not officially planned yet
<andrewrk>
but it's becoming more and more apparent that this will be an ingredient to taking mind share, as well as accomplishing some of the technical goals, such as compilation speed for debug builds
very-mediocre has joined #zig
<scientes>
yeah a gcc backend is very sensible thing
<dimenus>
scientes: transpiling?
<scientes>
dimenus, no, an actual backend like gccgo
fengb has joined #zig
<scientes>
but gcc doesn't have as good of a cross-compilation story
<scientes>
(which is something gcc developers are very aware of)
<companion_cube>
but it's still very fast in some situations
<scientes>
gcc has really great optimizations that llvm doesn't have
<fengb>
andrewrk: I'm glad you stuck through all of it. I feel like learning Zig has made me a better programmer
kristoff_it has joined #zig
<andrewrk>
fengb, I'm happy to hear that!
<andrewrk>
btw can I demo FunDude on the stream tomorrow?
<fengb>
Uhhh sure
<fengb>
It's pretty raw still and I don't really like things half done... but I don't foresee it being as good as I want any time soon :P
kristoff_it has quit [Ping timeout: 246 seconds]
<scientes>
I've got a comptime int here, and yet data.x_bigint isn't populated
<scientes>
what am i doing wrong
<scientes>
neither in the child nor parent
<scientes>
oh wait, the number is zero haha
<scientes>
ahh I think i have to cast it to a type from comptime int
<scientes>
before passing to llvm
<scientes>
andrewrk, do you try to work 40 hours a week on zig?
<andrewrk>
I think I average somewhere closer to 65
<scientes>
I need a more ergonomic setup
<scientes>
I just started swimming again, which is great
<scientes>
but the posture of using a laptop is killing me
<andrewrk>
how much I'm "trying" to work is a balance between my physical health, mental health, and relationships (friendships & significant other)
<andrewrk>
I recommend a keyboard & monitor, it makes a huge difference
<andrewrk>
a couple hundred dollars to significantly improve your physical health, easy decision
<scientes>
i'm just traveling
<andrewrk>
oh
<scientes>
so i hate to have to give it away when i move
<scientes>
but I can hang out in one place for a while
marijnfs has joined #zig
<very-mediocre>
invest in a good chair imho, you spend at least 40% of your life in a chair or a bed
kristoff_it has joined #zig
<andrewrk>
if this project sounds fun to anyone, it would be beneficial to the wider open source community: work on emscripten's ability to self-host (build llvm)
<andrewrk>
once this works, it will be a small straightforward process to make a zig sandbox in the browser that works client-side
<andrewrk>
hryx, I'm creating the llvm9 branch in zig right now and doing the "deal with breakage to zig_clang.cpp" process for the first time. I'll let you know how it goes if you're curious
<hryx>
oh awesome, sounds good andrewrk
<mikdusan>
hryx: have a moment?
<hryx>
mikdusan: I'm at work but can read/respond here and there. what's up?
<mikdusan>
it's not activating for me because `WIN32` is not defined for me. I don't understand why it fails for me, but CI builds did not fail. changing it back to use `_WIN32` and stage1 builds for me again.
<andrewrk>
I'm pretty sure it should be _WIN32
<andrewrk>
emekankurumeh[m], was removing the underscore intentional there?
<andrewrk>
gonz_, feel free to add a comment something like "adding search keywords: comptime allocation"
kristoff_it has quit [Remote host closed the connection]
kristoff_it has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Sahnvour>
andrewrk: is zig actively doing something wrt inlining of functions, excepted @[no]inlineCall ? It's been a few times I find it not inlining very much, so I'm wondering
<andrewrk>
Sahnvour, zig adds the `alwaysinline` llvm attribute, and then adds an "always inline pass" when calling LLVM
fengb has quit [Ping timeout: 260 seconds]
<andrewrk>
I thought you were asking about the inline keyword, but are you asking about release-fast builds, and inlining functions which do not have any annotations?
<Sahnvour>
yeah
<Sahnvour>
so every function is marked `alwaysinline` ?
<andrewrk>
no, only `inline` functions are marked `alwaysinline`
<Sahnvour>
ok, what about using `inlinehint` for functions that are neither `inline` nor `noinline`
<Sahnvour>
I'm curious if it would help, and not increase codesize much, because as we know in c++, in the end the compiler does what it pleases
<mq32>
i don't think its good to have an "maybe inline" flag. it just adds confusion about *when* the compiler will inline things and when not
<mq32>
the @Cold and @Hot model is imho better to notify that something is timing critical
<Sahnvour>
note I'm talking about the compiler's internal, not something visible from zig code
<Sahnvour>
I don't really like inline hints either, but for now it looks like zig is under-inlining
<andrewrk>
Sahnvour, if this is a problem with zig then it should be a problem with clang too
<andrewrk>
what are we doing differently?
<emekankurumeh[m]>
is there a way to test github linguist syntax locally?
halosghost has quit [Quit: WeeChat 2.5]
<Sahnvour>
andrewrk: actually looking at clang code to see how they use it
<Sahnvour>
seems like they're using `inlinehint` only for functions that were hinted by the programmer
omglasers2 has quit [Read error: Connection reset by peer]
<andrewrk>
that makes sense to me
<Sahnvour>
yeah, so now I'm wondering if that's actually a good thing to not have inlining hints
<Sahnvour>
in my case (hashing simple integers), forcing inlining causes the optimizer to see that since it knows the size of the object, the hash function can be simplified a lot
<Sahnvour>
but I don't want to force this function to be inlined _everywhere_, for example when the size of the object (a slice) is not comptime known
<Sahnvour>
I just wish the analysis would work across the function call, and inlining is kinf of a workaround
<andrewrk>
yeah I've been thinking, there must be a better way to annotate the code other than "inline hint"
ntgg has quit [Ping timeout: 248 seconds]
<andrewrk>
what is the actual information that the optimizer is missing? maybe we can supply that
<Sahnvour>
I *think* it's missing that the slice passed to the function (`std.mem.asBytes(&anInt)` really) has a known length, and then it can't see the fastpath based on this length inside the function
<Sahnvour>
do you think that's a tough change ? I might be interested in doing that
<andrewrk>
yes I think it will be challenging because it will cause breakage that won't be caught by compile errors
ntgg has quit [Ping timeout: 268 seconds]
<andrewrk>
not to discourage you though
<andrewrk>
there are also some frequently used functions which will now have incorrect assumptions, e.g. handle_is_ptr for a slice currently returns true
<andrewrk>
that should probably change to false but that will probably break other stuff
<Sahnvour>
okay, well @inlineCall might do the trick in the mean time