ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
JinShil has joined #zig
sherjilozair has joined #zig
sherjilozair has quit [Quit: Leaving...]
<donpdonp> andrewrk: nod.
<donpdonp> im having a different, more basic zig prob
<donpdonp> do("string")
<donpdonp> fn do(word: []u8) I figured would cover any string
<donpdonp> but im getting cant cast [6]u8 to []u8
<donpdonp> which I understand "string" is a fixed sized string and not a slice
<donpdonp> but do I have to really "string"[0..] or somethiing?
<andrewrk> donpdonp, you either need to make it a []const u8 or figure out where the memory will go
<andrewrk> because you can't mutate string literals - they end up in the read-only .data section of the ELF
<donpdonp> oh thats all it needed, the const. ok thx
<andrewrk> this has come up a few times before. I'll make a mental note to improve the error message
<donpdonp> error: expected type '[]u8', found '[7]u8'
<donpdonp> its just not obvious that the fix for that is []const u8
<donpdonp> yeah.
<andrewrk> there's a lot more we can do to report why exactly types do not match
<andrewrk> in fact the internal functions return a recursive struct that has a complete explanation - we just don't convert this data into human readable error messages yet
<donpdonp> o^O
<GitHub33> [zig] andrewrk pushed 1 new commit to master: https://git.io/vhkZ0
<GitHub33> zig/master b132a17 Andrew Kelley: std.zig.parse ignores comments...
darithorn has quit [Quit: Leaving]
<GitHub167> [zig] andrewrk pushed 1 new commit to master: https://git.io/vhknd
<GitHub167> zig/master 54e887e Andrew Kelley: std.zig.tokenizer: fix tokenization of hex floats
<donpdonp> ug. turns out gobject (which gtk uses) is its own kind of pointer-hell.
<donpdonp> also found an enum BEHAVIOR = {a=1, b=2}, then they call func((BEHAVIOR)0);
<donpdonp> which works in C, but the zig enum doesnt have an entry for 0 cause... it follows the rules.
<donpdonp> okay so dipped my toes into Qt. so much header magic I cant even get starter.
<donpdonp> with gtk i could at least open a window
<donpdonp> sigh.
davr0s has joined #zig
tiehuis has joined #zig
<tiehuis> so i had a quick look at implementing a python extension in zig last night
<tiehuis> that proved a bit annoying at this stage due to the way a PyObject is defined with way too many macros
<tiehuis> i then had a look at embedding lua in a zig program and that fairly easily working around a few macro parsing deficiences
<tiehuis> pushed the example here: https://github.com/tiehuis/zig-lua
<tiehuis> when we improve translate-c then it would work really easily which is nice
<tiehuis> i'm also slightly interested in getting a libc implementation far enough long so that we could embed it directly with no libc required
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<tiehuis> a quick scan of the source indicates that it is fairly light in its usage so there isn't that much work required here
<tiehuis> would be cool to be able to cross-compile a program with a robust dynamic scripting language as a use case
<tiehuis> also small note but i'll probably make a pr for the bigint module into std next week
<tiehuis> only need to fix up one branch in multi-limb division
tiehuis has quit [Quit: WeeChat 2.1]
davr0s has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
dpk has quit [Ping timeout: 250 seconds]
m6w6 has quit [Ping timeout: 265 seconds]
JinShil has quit [Quit: Leaving]
dpk has joined #zig
m6w6 has joined #zig
Hejsil has joined #zig
<Hejsil> Interfaces in userland without @creattype/@reify?! What is this dark magic! https://github.com/Hejsil/fun-with-zig/blob/master/fun/interface.zig
_whitelogger has joined #zig
Hejsil has quit [Ping timeout: 260 seconds]
Hejsil has joined #zig
Hejsil has quit [Quit: Page closed]
quc has joined #zig
noonien has joined #zig
davr0s has joined #zig
<andrewrk> tiehuis - wow, all exciting stuff
<andrewrk> Hejsil, I think this will be enhanced by the addition of tuples (and removal of var args)
Hejsil has joined #zig
<Hejsil> andrewrk, true. Especially if we can "explode" the tuple into the remaining args of a function.
<andrewrk> I'm thinking that will look like @call(function, tuple)
darithorn_ has quit [Ping timeout: 252 seconds]
<Hejsil> Could it do, @call(func, arg1, arg2, tuple) ?
<Hejsil> You know, provide some args, and then give a tuple for the rest
<andrewrk> @call(func, [arg1] ++ [arg2] ++ tuple)
<Hejsil> Aah
<andrewrk> where [foo] is a tuple of size 1
<Hejsil> Powerful
<Hejsil> The more I hear of tuples, the more I want them!
<andrewrk> btw last night I got zig fmt to the point where it handles all same line comments correctly
<Hejsil> Nice
<andrewrk> the parser ignores all comments and skips over the tokens. the renderer looks "nearby" tokens for line comments to findthem
<andrewrk> so now I'm going to use this to change all &T to *T and move one with pointer reform
<andrewrk> *move on
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<Hejsil> Would love to try out zig fmt with the new pointer syntax, but I have a branch I wonna finish up before I get to that :)
<andrewrk> fixing the inability to have a pointer to a type at comptime should fix a lot of comptime bugs
<andrewrk> this interface example is really neat
<Hejsil> One thing that would be nice, is to have methods on the interfaces
<Hejsil> Which is not really possible without @reify
<andrewrk> I see
Hejsil has quit [Quit: Page closed]
t5c has joined #zig
davr0s has joined #zig
bheads has quit [Ping timeout: 245 seconds]
bheads has joined #zig
darithorn_ has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
SimonNa has left #zig ["Leaving"]
davr0s has joined #zig
bheads_ has joined #zig
bheads has quit [Ping timeout: 248 seconds]
MajorLag2 has quit [Ping timeout: 245 seconds]
MajorLag1 has joined #zig
steveno_ has joined #zig
<t5c> hi, I'm adding OpenBSD syscalls and errnos to zig right now. I'm wondering why the values like pub const O_CREAT = 0o100; are in octal notation, does that have any particular reason? for simplicity I would just use the hex values from OpenBSD.
<t5c> the 0u100 example is from os/linux/x86_64.zig
<t5c> oh I see that the darwin modes are also in hex or decimal, so it shouldn't be a problem
<MajorLag1> probably because they're in octal in the C source and documentation.
<t5c> yeah, my question was more about style. but since there are hex and decimal already in...
<andrewrk> hi t5c
<andrewrk> hex decimal is preferable I think. the ones that are in octal are from code that was ported
<t5c> hi andrewrk
<t5c> I guess its fine to use the exact values from the header of the os
<t5c> makes porting easier not having to calculate everything
<t5c> so many syscalls, signals and stuff :/
<t5c> man its a lot
bheads has joined #zig
bheads_ has quit [Ping timeout: 260 seconds]
steveno_ has quit [Quit: Leaving]
Ichorio has joined #zig
<andrewrk> t5c, are you aware of zig's lazy top level declaration evaluation?
<andrewrk> my strong suggestion to you is to follow this process: 1. port nothing to OpenBSD and try to run the zig std lib tests
<andrewrk> 2. see what compile errors you get. port over the OpenBSD functionality that is necessary to fix them
<andrewrk> repeat step 2 until all std lib tests passing
<andrewrk> it will be a small manageable subset of OpenBSD that we can merge and iterate on
<andrewrk> even the linux support right now is not complete
<andrewrk> we have only added syscalls that we needed
bheads_ has joined #zig
bheads has quit [Ping timeout: 256 seconds]
<t5c> andrewrk: yes that is a good plan.
<andrewrk> oh, and before all std lib tests - you can start with something simple such as hello world
<andrewrk> that should only require read/write and some constants
<andrewrk> this is related: https://github.com/ziglang/zig/pull/941
<andrewrk> if you make significant progress, I'll try to figure out how to get CI going for OpenBSD and then we can add official support for it
<t5c> that sounds good.
<t5c> ah yes, there where issues with finding the stdlib on openbsd.
<t5c> maybe thats the first thing to fix
<t5c> btw, thanks for putting the openbsd integer sizes in pullreq was by me
<andrewrk> err, actually the one below it, selfExeDirPath
noonien has quit [Quit: Connection closed for inactivity]
<t5c> yes, patched that couple hours ago. testing in a bit
bheads_ has quit [Ping timeout: 260 seconds]
bheads has joined #zig
l1x has quit []
l1x has joined #zig
l1x has quit [Client Quit]
minus is now known as Guest48533
Guest48533 is now known as minus
l1x has joined #zig
darithorn_ has quit [Ping timeout: 276 seconds]
darithorn_ has joined #zig
quc has quit [Read error: Connection reset by peer]
quc has joined #zig
Ichorio has quit [Ping timeout: 245 seconds]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
<t5c> andrewrk: https://pastebin.com/CsXCDAKH these are the last error messages I get
<t5c> dunno if there is something missing in openbsd right now
<t5c> probably the lld or gcc stuff
<t5c> hm.
<andrewrk> t5c, this is problems with link.cpp not linking against libc correctly on openbsd
<andrewrk> I suggest working on the non-libc tests first
<andrewrk> actually let me ask a question first - is the syscall ABI stable?
<andrewrk> on linux it is, on macos it is not
<andrewrk> it's better for zig if it is
<t5c> no, I don't tink so
<andrewrk> ok so we need to use libc as the syscall interface
<andrewrk> so we need to solve this problem
<t5c> thats what I'm doing
<t5c> using libc
<andrewrk> you may need to edit link.cpp and edit the ELF code that gives linker arguments to LLD
<andrewrk> the first thing to do is try using ld to link the .o file that zig generates
<andrewrk> it's probably in zig-cache/test.o
<andrewrk> see if you can link that with the system linker
<andrewrk> then try with LLD from the LLVM project
<andrewrk> one trick I used is to run gcc or clang and use strace to see what arguments it passes to the linker
<andrewrk> you can also read the clang code that constructs the linker args
<andrewrk> it's pretty readable
<andrewrk> once you know what args to use to link with the linker directly, you can edit link.cpp in zig to do that
<t5c> there seems to be a problem with the llvm ld and openbsds stack protector. __guard_local is an undefined symbol
<t5c> i'd like to change the linker to use the llvm linker and not the default one. should be possible with cmake, shouldn't it?
<t5c> nah, that wouldn't help
darithorn_ has quit [Ping timeout: 265 seconds]
darithorn has joined #zig
<t5c> no crt1.o - can be replaced with crt0.o, but also no Scrt1.o ...
<andrewrk> t5c, we can add __guard_local to std/special/builtin.zig
<andrewrk> you can see there are other guard functions there depending on the os / archc
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<andrewrk> t5c, did you get it to work just by invoking the system ld using a zig-generated .o file?
<t5c> thats with the standard linker on build.o
<andrewrk> t5c, we can create an implementation of __guard_local and put it in std/special/builtin.zig, and then we'll link with builtin.o
<andrewrk> we can look at the implementation in openbsd libc
<andrewrk> where is openbsd libc? I haven't found the source repository yet
<andrewrk> ah found it. here's a mirror: https://github.com/openbsd/src/tree/master/lib/libc
<andrewrk> I don't see this symbol defined anywhere. it seems like it's pointing at random data
<andrewrk> let's try implementing it like this: export fn __guard_local() c_long { return 0;}