ifreund has quit [Read error: Connection reset by peer]
ifreund has joined #zig
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
_whitelogger has joined #zig
ur5us_ has quit [Ping timeout: 260 seconds]
swills has quit [Ping timeout: 246 seconds]
swills has joined #zig
ur5us_ has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
shachaf has quit [*.net *.split]
signop has quit [*.net *.split]
[RMS] has quit [*.net *.split]
allan0 has quit [*.net *.split]
nore has quit [*.net *.split]
companion_cube has quit [*.net *.split]
bbrittain has quit [*.net *.split]
nore has joined #zig
allan0 has joined #zig
companion_cube has joined #zig
bbrittain has joined #zig
shachaf has joined #zig
[RMS] has joined #zig
signop has joined #zig
casaca has quit [Ping timeout: 264 seconds]
klltkr has quit [Ping timeout: 265 seconds]
craigo has quit [Ping timeout: 265 seconds]
_whitelogger has joined #zig
ur5us_ has quit [Ping timeout: 260 seconds]
_whitelogger has joined #zig
neptunepink has quit [Remote host closed the connection]
Nilium has quit [Quit: <kristin> Cower is like... I dunno. sometimes he seems senile and other times he seems like a middle schooler.]
Nilium has joined #zig
redj has quit [Remote host closed the connection]
dongcarl has quit [Read error: Connection reset by peer]
neptunepink has joined #zig
redj has joined #zig
dongcarl has joined #zig
zippoh has quit [Ping timeout: 240 seconds]
marnix has joined #zig
marnix has quit [Read error: Connection reset by peer]
bgiannan has joined #zig
<bgiannan>
Updated zig and got `lld: error: Unable to find library for -lSystem` when building my project. Since i'm on macOS Big Sur I suppose it's related to that ?
<Nypsie[m]>
Yeah, but I believe a PR was merged to fix that for macOS Big Sur
<bgiannan>
that commit is one month old, and i just downloaded the last master version of zig
<Nypsie[m]>
Hmmm
<Nypsie[m]>
I'll ask one of the Big Sur users on Discord
<Nypsie[m]>
Using Catalina myself so can't really help :s
philtor has quit [Ping timeout: 260 seconds]
st4ll1 has quit [Quit: WeeChat 2.9]
craigo has joined #zig
dddddd_ is now known as dddddd
waleee-cl has joined #zig
cren has joined #zig
<cren>
how do you/can you/should you make program constants in Zig? Like things you would do in C with #DEFINE
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
rzezeski has joined #zig
<ifreund>
just a variable really
<ifreund>
cren: do you have a particular use case in mind?
dimenus has joined #zig
<cren>
ifreund, it's MAX_MESSAGE_SIZE: u8
<cren>
it's just that I found I couldn't declare a constant in the global scope
kevsmith has quit [Remote host closed the connection]
<ifreund>
how so?
<ifreund>
oh you mean that it has to be inside a namespace? Yeah that's a feature
<ifreund>
you could have e.g. a `defs` struct that has all your things in its namespace and then import that everywhere
xackus_ has joined #zig
_whitelogger has joined #zig
<Nypsie[m]>
bgiannan: Seems like the other Big Sur user is also running into trouble since beta 3. Beta 2 was working fine, but 3 and 4 both don't seem to work, fwiw.
<bgiannan>
Nypsie[m], ok. The last update put my mac in a boot loop, i had to reinstall the system so i'm won't update for a while
gpanders has quit [Read error: Connection reset by peer]
gpanders has joined #zig
gpanders has quit [Read error: Connection reset by peer]
gpanders has joined #zig
dingenskirchen1 has joined #zig
dingenskirchen1 has quit [Client Quit]
Akuli has joined #zig
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
dingenskirchen has quit [Client Quit]
dingenskirchen has joined #zig
<danyspin97>
I was reading the source code and I saw an abstraction over os.listen, os.accept
<danyspin97>
is it usable?
<danyspin97>
std.net.StreamServer
<Nypsie[m]>
Very usable for non-windows platforms
<Nypsie[m]>
If you require Windows support, zig-network is a great option
<danyspin97>
Nypsie[m]: my program is unix-only, so that's perfect!
mikdusan has joined #zig
<danyspin97>
StreamServer did work, now I'll wait for StreamClient Implementation
<danyspin97>
btw, I think the code is too condensed in few files :/
<Nypsie[m]>
Not sure what you mean with StreamClient. You can already implement a tcp client using std
<pixelherodev>
There isn't one *in* std though
<pixelherodev>
I think that's their point
<Nypsie[m]>
Ah I see
<pixelherodev>
danyspin97: whatcha working on, if you don't mind me asking?
<pixelherodev>
You've piqued my curiousity :)
<danyspin97>
Nypsie[m], pixelherodev: yup, I use os.socket and the other functions
<danyspin97>
but since there is a StreamServer, I think it makes sense to provide an abstraction for other side
<danyspin97>
which is my first project using zig :)
<danyspin97>
agreed about that, I also wanted to write a unsetEnv method
<Nypsie[m]>
Btw, zig-network will be merged in std at one point, which will provide an abstraction over the OS's
<Nypsie[m]>
Then you will just be able to write to a socket os-independent.
<danyspin97>
I don't personally mind about that but I see it would be very useful for someone
mikdusan has quit [Read error: Connection reset by peer]
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
CodeSpelunker has joined #zig
mikdusan has joined #zig
rzezeski has quit [Quit: Connection closed for inactivity]
cole-h has joined #zig
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
stripedpajamas has joined #zig
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
<danyspin97>
os.linux.syscall* returns a usize
<danyspin97>
though some syscall return negative values
<danyspin97>
okay, casting it to i32 does the trick
<andrewrk>
@bitCast
<danyspin97>
andrewrk: @intCast is correct too, isn't it?
<andrewrk>
only if the value is mathematically in the range of an i32. if you want to reinterpret the usize as twos complement you need bitcast
<danyspin97>
wdym by twos complement?
<andrewrk>
if the syscall returned the mathematical number -1, it does it in a register, which is a usize. that would be the value 0xffffffffffffffff (18446744073709551615). If you try to @intCast that to an i32, zig will panic and say it doesn't fit
<danyspin97>
it worked though
<andrewrk>
however if you @bitCast(isize, rc) you will get -1, and you could then @intCast that to an i32 if you want to make it smaller
<andrewrk>
when you say, "it worked" are you saying that you tested a case when the syscall returned a negative number?
<danyspin97>
yea
<danyspin97>
I am trying it right now
<danyspin97>
and @intCast does not panic
<andrewrk>
and you get a negative value?
<danyspin97>
I get -1
<danyspin97>
which is the expected value for me
<danyspin97>
now the only thing not working is errno
<danyspin97>
(i update zig-master today, that may be it)
<pixelherodev>
danyspin97: are you using release mode?
<pixelherodev>
a release mode*
<danyspin97>
default mode, running zig build
<andrewrk>
well paint me red and call me a fire truck. how long has this been broken? https://clbin.com/p1I7T
<andrewrk>
goodness
<andrewrk>
I wonder what bugs lurk in everyone's code that have not been caught by this
<pixelherodev>
... there's not already a behavior test for it?
<andrewrk>
there is about to be
<danyspin97>
also, errno is not working for me anymore
<danyspin97>
std.c._errno().* is it the correct way?
<andrewrk>
what abstraction level are you targeting? posix? libc? linux only?
<danyspin97>
I am using std.os.linux.syscall for now
<danyspin97>
so linux-only target for now
<andrewrk>
std.os.linux.getErrno
<danyspin97>
Ah, I see
<danyspin97>
but I am sure it worked some days ago
<andrewrk>
I don't know what you did days ago, but the proper way to get the errno from a raw linux syscall is that function
<andrewrk>
note that you are operating under an abnormally low abstraction level. typically one would target a more portable abstraction layer
<danyspin97>
yup, I was using std.c._errno() and with a someday older version of zig I got the errno
<danyspin97>
you mean I should use std.os instead of std.os.linux?
<andrewrk>
I don't recommend using libc errno except under very specific circumstances. use the function appropriate to the abstraction layer you are using
<danyspin97>
I agree, I was just reporting the different behaviour
<andrewrk>
anyway thanks for reporting the -1 thing. I'm looking into that now
<shachaf>
The classic thing for Linux system calls is that errors are in the range (UINTPTR_MAX-4096,UINTPTR_MAX], right?
<danyspin97>
thanks for the really good explanation :)
<andrewrk>
if you're using the std.os (to be renamed std.posix) layer, it has an errno function
<shachaf>
Oh, I guess this is going through libc or something with errno.
<andrewrk>
yes shachaf - but zig std lib abstracts over the fact that sometimes it's obtained directly from the syscall rc value and differently when using libc
<pixelherodev>
I still say pozix makes more sense, since it's Zig-flavored posix ;)
<danyspin97>
I see, however I am using Linux specific syscalls so I need std.os.linux.getErrno
<shachaf>
Right.
<andrewrk>
danyspin97, out of curiosity, what linux syscalls are you using that are not covered by std.os?
<danyspin97>
ioprio_set
<andrewrk>
gotcha
<danyspin97>
and sched_setscheduler
<pixelherodev>
It's very nice ;)
<danyspin97>
it's nice in all sense
<danyspin97>
since I am also using nice(2)
<danyspin97>
;)
<andrewrk>
danyspin97, you'll probably want to have a look at std.os.linux source code for inspiration, to get an idea for how to properly convert your args to usizes for the purpose of calling the syscall1, syscall2, etc functions
<danyspin97>
andrewrk: thanks, I did some testing and finally I was able to got them working
<danyspin97>
the only thing still not really clear to me is the conversion between []u8 to [c*]u8 and literals
<andrewrk>
just remember: @intCast is for preserving the mathematical number. @bitCast is for preserving the bit pattern
<ifreund>
well, I have now got wasm to the point of actually being able to run and debug it :D
<andrewrk>
ifreund, wow!!
<pixelherodev>
nice
<ifreund>
of course it doesn't work yet though :D
<pixelherodev>
I'm inspired to work on the HEX backend now ;)
<Nypsie[m]>
ifreund: Nice work!
<andrewrk>
ifreund, I briefly took a look at the wasm spec just now and pleased to see that the way zig's loop IR works will be straightforward with wasm
<andrewrk>
in fact it looks identical
<ifreund>
I think I may have been unclear, I'm running and debugging the wasm backend for the compiler not wasm code yet
<ifreund>
still cool though
<ifreund>
and yeah, wasm seems like it will map fairly well to the ir
<andrewrk>
ah gotcha
<pixelherodev>
andrewrk: I submitted a minor cleanup PR, when you get a chance to look at it
<pixelherodev>
Trying to stick to the one-pr-at-a-time thing :P
<ifreund>
so it seems like updateDeclExports() is being called before updateDecl(), I thought that wasn't supposed to happen?
<pixelherodev>
ifreund: thanks for 2fc18b52788f789ceba7b4f60e850de3ce67495c ;)
<pixelherodev>
(stage2: make link data in Decl into unions)
<ifreund>
np
<ifreund>
theres some more Elf-specific stuff in Module.Export that I found today, but that can be another PR
<pixelherodev>
Also, you're right
<pixelherodev>
updateDeclExports is only supposed to happen after updateDecl
<ifreund>
my printfs say that's not what's happening, perhap I'm doing something wrong though
<ifreund>
running zig build-obj -ofmt=wasm
<andrewrk>
don't you need to do -target wasm32-freestanding ?
<andrewrk>
which should select wasm object format by default
<andrewrk>
(and error out on any other ofmt override)
<ifreund>
doesn't seem to make a difference what combination of -ofmt and -target I use
<pixelherodev>
ifreund: updateDeclExport has to run after a call to updateDecl *with the same decl*, I *think* it can run between other updateDecl calls
<pixelherodev>
Heck, updateDeclExports is called *by* updateDecl for ELF
<ifreund>
what I'm currently seeing is updateDeclExports being called before *any* call to updateDecl
CodeSpelunker2 has joined #zig
<pixelherodev>
but I think you're right
<pixelherodev>
yeah
<pixelherodev>
Module.zig is calling updateDeclExports on the link.File
<pixelherodev>
I think that's wrong
<pixelherodev>
Module.zig:1878
<andrewrk>
it's allowed to do the export before updateDecl
<pixelherodev>
Ah, so the comment is wrong then?
<andrewrk>
for ELF this works fine
<andrewrk>
allocateDeclIndexes makes it so that you can do the exports as well as function calls on a Decl that hasn't been machine code generated yet
<pixelherodev>
The comment is wrong then, yeah
<andrewrk>
what comment
<pixelherodev>
andrewrk: link.zig:2313
cren has quit [Ping timeout: 260 seconds]
<andrewrk>
I see
<ifreund>
ok, I can work around that
CodeSpelunker has quit [Ping timeout: 256 seconds]
<andrewrk>
hmm no, it reads the decl's vaddr which does depend on updateDecl
<andrewrk>
ifreund, thanks for letting me know, I'm looking into this
<pixelherodev>
Code disagreeing with comments is always fun :P
<pixelherodev>
still better than e.g. `// This is a buffer` on a `char*` :P
<ifreund>
andrewrk: no problem, I will find a workaround for now
<pixelherodev>
You know what would be a really neat feature for ZLS?
<andrewrk>
ifreund, I also noticed that the x86 code for your test case has a bogus jmp
<andrewrk>
I'm looking into that as well
<pixelherodev>
If you could, say, add a tag to an enum, and it'd instantly insert @panic("TODO") on anything that switches on it :P
<ifreund>
if it wasn't clear already, it's getting called by astGenAndAnalyzeDecl()
<ifreund>
(through analyzeExport())
<pixelherodev>
Toldja!
<pixelherodev>
(That's the only call to updateDeclExports outside link.zig ;)
<pixelherodev>
git grep FTW
<ifreund>
well, I got it actually writing a (slightly mangled) wasm file
<pixelherodev>
"A malicious file is detected" - how's this done? Simply because it doesn't map to the input?
<pixelherodev>
There's got to be a better wayt o do these abstractions
<pixelherodev>
to do *
<pixelherodev>
e.g. link.File.updateDecl
<pixelherodev>
Hmm, maybe there is
stripedpajamas has quit [Quit: sleeping...]
<pixelherodev>
Good thing about ihex: it doesn't encode debug / symbol info the way ELF does, so I don't need e.g. allocateDeclIndexes :)
<andrewrk>
ability to do allocateDeclIndexes is a feature, it allows more parallel compilation
<andrewrk>
we'll be able to codegen two functions that call each other on different threads at the same time
<pixelherodev>
I'm not saying I won't add it eventually, just that it's not *necessary* now :)
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
klltkr has joined #zig
<ifreund>
I have no idea how parallelism is going to work out for wasm incremental compilation
<ifreund>
the format reall doesn't lend itself to that
zippoh has joined #zig
<andrewrk>
that's ok. it's not required really
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
Akuli has quit [Quit: Leaving]
cole-h has quit [Quit: Goodbye]
klltkr has quit [Ping timeout: 246 seconds]
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
CodeSpelunker2 has quit [Quit: CodeSpelunker2]
dimenus has quit [Read error: Connection reset by peer]
dimenus has joined #zig
klltkr has joined #zig
xackus_ has quit [Ping timeout: 260 seconds]
mikdusan has quit [Quit: WeeChat 2.5]
zippoh has quit [Ping timeout: 256 seconds]
mikdusan has joined #zig
<ifreund>
aah spent an hour finding to find a really dumb bug
<ifreund>
I have now genereated my first functioning wasm file though!
<andrewrk>
woohoo!
<andrewrk>
is it the return 42 one?
<ifreund>
yeah, though I actually cheated on the codegen part
<ifreund>
(just have the return hardcoded for now)
<ifreund>
all the infrastructure for the container format seems to work though
<andrewrk>
we can talk about modifying the IR for returning to be friendlier to wasm if you want
<andrewrk>
that's great, I'm well aware of how much work that is for the container format stuff
<ifreund>
yeah, returning is a little awkward with wasm
<andrewrk>
one idea as part of defer (https://github.com/ziglang/zig/issues/283#issuecomment-666762863) is that we will no longer have "return" IR instructions. returning will be implied at the end of a function, and early returns will be astgen as breaks from blocks
<ifreund>
that would fit very nicely with wasm
<andrewrk>
"The return instruction is a shortcut for an unconditional branch to the outermost block, which implicitly is the body of the current function." heh yep
frmdstryr has joined #zig
craigo has quit [Ping timeout: 265 seconds]
zipp has joined #zig
<andrewrk>
ifreund, woohoo! I'll get you a review asap
<ifreund>
thanks! will be nice to have some eyes on it
<ifreund>
still a ton to do, but its a decent start
<andrewrk>
I'm always happy to merge stuff that is an improvement over status quo
<andrewrk>
as long as footguns are covered with safety protections :)