ChanServ changed the topic of #zig to: zig programming language | | be excellent to each other | channel logs:
<cr1901_modern> >error: parameter of type 'type' must be declared comptime
<cr1901_modern> Oh, would ya look at that
<g-w1> :)
<cr1901_modern> ziglearn has a Matrix example I'm stealing for my own use. But seeing as I'm not good at Zig yet, my initial impl looked nothing like the example
<cr1901_modern> g-w1: >no, you can have runtime consts Do you have an example of the difference between a "runtime const" and "comptime const"? Does the latter use the "const" reserved word at all?
<g-w1> comptime const: `const i: u32 = 1;` runtime const `const i: u32 = some_runtime_thing;`
<cr1901_modern> ahhh
<cr1901_modern> What is the correct syntax for "add an extra byte if cols * rows isn't divisble by 8"?
<cr1901_modern> ./src/gf2mat.zig:6:76: error: invalid token: '!='
<cr1901_modern> var num_bytes: comptime_int = (cols * rows)/8 + if ((cols * rows) % 8) != 0) 1 else 0;
<cr1901_modern> Uhh, why is it invalid?
<g-w1> bool != int
<g-w1> @boolToInt
<cr1901_modern> an if statement should take a bool, correct?
<g-w1> correct
<cr1901_modern> So why do I need boolToInt?
<g-w1> ah i misread, i think you have weird parens
<cr1901_modern> yes... yes I do.
<cr1901_modern> Oh right, is there an equivalent of Rust's unimplemented!()? I guess unreachable works
<andrewrk> @panic("unimplemented")
<g-w1> unreachable is probably not a good idea as it can cause ub in some release modes
<cr1901_modern> Hmm, I would've liked this, to test that trying to multiply two matrices which don't have equal row/col fails
pretty_dumm_guy has quit [Quit: WeeChat 3.2-dev]
meinside has joined #zig
<cr1901_modern> Okay, this code also fails, but with error: expected type 'Gf2Mat(7,4)', found 'type'. Why?
<cr1901_modern> b has type "anytype", so why is Zig complaining when it infers?
<g-w1> because foo is of wrong type
<g-w1> it is of type struct { ... }
<g-w1> you must instantiate the struct
<g-w1> using Gf2Mat(7, 4) { .data = whatever }
<cr1901_modern> Uhhh, why aren't they compatible types even when I don't initialize them?
<g-w1> multiply takes Self
<cr1901_modern> Why is Self() not equal to the struct I returned from Gf2Mat() function?
<cr1901_modern> not the same type*
<g-w1> @This() means an instantiated version of the struct
<cr1901_modern> Why are @This() and struct {...} without instantiation two different types when they are structurally equivalent?
<cr1901_modern> :)
<cr1901_modern> err wrong term
<g-w1> they are not
<g-w1> @This() just allows you to refer to the struct type within itself
<cr1901_modern> some langs, two structs are the same if they have the same fields w/ the same types and same names and same order are the same type
<g-w1> this is not the case in zig nor the source of your issue
<noam> structural equivalence is not the same as equivalence in zig
<noam> just as two slices containing the same data doesn't matter if their pointers are different
<noam> one instance of the struct keyword is one type
<g-w1> cr1901_modern: what languages do you have background in?
<cr1901_modern> A bit of OCaml, Rust, C
<g-w1> thats what i thought :)
<cr1901_modern> Structural equality "kinda-sorta" works in OCaml, but under the hood it's a nice convenience that OCaml doesn't actually understand
<cr1901_modern> I don't remember the other one... nominal equality?
<cr1901_modern> Anyways, for my purposes: In this case, struct { .. } and @This() don't even have the same layout, and thus surely can't be the same type?
<noam> two different structs are never the same tyype.
<noam> type*
<g-w1> > one instance of the struct keyword is one type
<g-w1> you must remember that comptime functions are memoized
<noam> that still counts
<g-w1> so when you call a function that returns type with the same args, the struct keyword is only used once
<g-w1> noam: telling cr1901_modern
<noam> :)
<cr1901_modern> So hows does zig know that you're passing in a struct that takes @This() with some, but not all, fields initialized?
<g-w1> initialized was the wrong word sorry, it needs an instance of the struct
<cr1901_modern> is an instantiated struct { .. } also a struct from the compiler's POV (that's is not the same type as the type it was instantiated from, as what noam said)
<noam> const foo = struct{...};const bar = foo{...};
<g-w1> no an instantiated struct is SomeStructType { .field = filled_in }
<noam> foo is of type 'type'
<noam> bar is of type 'foo'
<g-w1> ^
<cr1901_modern> Just as a stupid hypothetical, if I wanted to return, say, an i32 from a fn that returns type, how do I do that?
<cr1901_modern> >(7:54:34 PM) g-w1: const T: type = u32;
<cr1901_modern> >(7:54:41 PM) g-w1: const T: type = type; ;)
<g-w1> fn F() type { return i32; }
<g-w1> ??
<cr1901_modern> Why didn't I think that worked?...
<cr1901_modern> Anyways these questions came up b/c I got very uncomfortable with "function in return type position":
<cr1901_modern> But I can't avoid this I don't think, b/c I don't want to return a type. But I don't know the return type until the function needs to be compiled
<g-w1> then embrace it!
<cr1901_modern> But it's looks scary :(
<cr1901_modern> (And is this in fact the "recommended Zig way" to solve the "Idk the return type until compile time" problem?)
<g-w1> probably
<cr1901_modern> Last thing for now. Not that I woul have any idea, but... does returning "type" fall under "Higher Kinded Types" (the type of types?)
<cr1901_modern> Ty noam, g-w1, and andrewrk for the help tonight
<noam> np
ncon has quit [Remote host closed the connection]
<siraben> cr1901_modern: returning a type would be most naturally expressed with dependent types
<siraben> HKTs usually mean you can abstract over type constructors rather than fully saturated types
ncon has joined #zig
<cr1901_modern> This code got me the compiler error I want
<daurnimator> cr1901_modern: `@TypeOf(self)` and `Self` are interchangable in there.
<cr1901_modern> Ahhh neat
<daurnimator> cr1901_modern: btw, an init() method that doesn't do anything aside from initialisation to a constant is considered an antipattern
<cr1901_modern> init() feels nicer than doing .data = [_]u8{0} ** Gf2Mat(r, c).num_bytes,
<cr1901_modern> But ack
<cr1901_modern> ./src/main.zig:2:16: error: unable to find 'gf2mat'
<cr1901_modern> const gf2mat = @import("gf2mat");
<cr1901_modern> const gf2mat = @import("gf2mat.zig") works
<cr1901_modern> is that supposed to be how I do it (gf2mat in same src dir)
<daurnimator> cr1901_modern: you can use `--pkg-begin gf2mat gf2mat.zig --pkg-end` on the zig command line
jeang3nie has quit [Quit: Quit]
<kiedtl> Is there any equivalent in Zig of `from foo import *` (Python) or `use mod::submod::*;` (Rust)?
<daurnimator> kiedtl: `usingnamespace @import("foo")`
<kiedtl> Ah, thanks
<daurnimator> that said, I think it makes hard to read code: it's better to give it a name so you know where symbols come from
<kiedtl> I think the extra namespacing is unnecessary in this case, I'm just putting a bunch of types that are used throughout the project into a single 'types.zig'
<daurnimator> it also opens you up to potential breakage if the module you use adds additional exports that may conflict with your own function names or locals (zig doesn't allow shadowing)
<cr1901_modern> How do I compare arrays in testing?
<daurnimator> cr1901_modern: `std.testing.expectEqualSlices(ElementType, expected, actual)`
<daurnimator> cr1901_modern: assuming you meant to say slices. I think actual arrays you can just use expectEqual?
<cr1901_modern> I meant arrays
<daurnimator> also note that pointer-to-array coerces to slice
<cr1901_modern> Why does equal slices need the elementtype?
bitmapper has quit [Quit: Connection closed for inactivity]
<daurnimator> good question. I don't know.
<g-w1> its for increased type safety
<g-w1> it makes sure that it has a slice instead of some random type
<g-w1> that way it doesn't have to do any assertions to make sure thing[i] doesn't give weird compile errors
<noam> I've found from attempting to find counterexamples that a [:0]u8 coercing to [*:0]u8 is fine in 99.99% of cases
<noam> If anything, I think that the length disagreeing should be treated as a bug
<noam> I don't think we should allow [:0]u8 where there's zeroes before the end.
<noam> (at least, in safety-instrumented modes)
<daurnimator> noam: you may want to revisit the original issue where I proposed that
<cr1901_modern> Okay, so I didn't actually make much forward progress this weekend, but I sure as hell am happier w/ how the code is organized now:
<cr1901_modern> I think it might be worth rolling my own matrix lib for the limited functionality and special requirements I need
recalloc has joined #zig
recalloc has left #zig [#zig]
recalloc has joined #zig
<daurnimator> cr1901_modern: you only increment `curr_byte` on the first iteration?
<daurnimator> oh wait no
<cr1901_modern> No, only when I'm sure the byte has been filled, relying on wrapping arith to go straight to next bit
<recalloc> Hi, I tried different ways to wrap around C bitmask flags and it looks like using structs are probably the most idiomatic. Is this a good idea, or are there other ways I should wrap around it? Here's what I toyed around with so far:
<recalloc> Specifically a struct of bools like io.File.{Open,Create}Flags that transforms into the u32 bitmask argument the C API wants.
<cr1901_modern> g-w1: You mentioned that "each struct { .. }" is memoized. Does that include the comptime parameters inside the struct? So only if comptime parameters match is it considered a "cache hit"?
<daurnimator> recalloc: there's std.EnumSet now. I haven't looked at what actually got merged, but I think you'll find something in there
<recalloc> aight, I'll look at that
<andrewrk> recalloc, I like your example that does it with a struct method
<recalloc> Awesome, sounds like we're thinking on the same page!
<g-w1> cr1901_modern: comptime fns are memoized, structs are *not*
<daurnimator> recalloc: have a quick play with: `std.EnumSet(InitFlagsEnum)`
<cr1901_modern> >(9:08:49 PM) g-w1: so when you call a function that returns type with the same args, the struct keyword is only used once
<cr1901_modern> Ahhh, this explains how two structs _can_ have the same type
<cr1901_modern> whoops
<noam> More like can *be* the same type :)
<noam> Structures *are* types
<noam> All structures have the same type - 'type'!
<noam> @TypeOf(some_struct) is always 'type'
<cr1901_modern> >(9:07:44 PM) noam: two different structs are never the same tyype.
<noam> and in the case where you call a memoized func, it's not two structs being the same type
<cr1901_modern> Lol
<noam> the memoized func *is* a *single type*
<noam> e.g. const foo = ArrayList(u8)
<noam> const bar = ArrayList(u8)
<daurnimator> cr1901_modern: the struct *is* the type. vs the type *of* the struct type -> which is always `type`
<noam> That's the same as if you did const baz = struct{...} ; const foo = baz; const bar = baz;
<noam> In this case, foo and bar are both *aliases* for the *same structure*
<noam> It's important to be able to separate the *identifier* from the *value*
<noam> It's *one structure* with *multiple identifiers*
<noam> or multiple *names*, if that's an easier way to cognize it
<cr1901_modern> >the memoized func *is* a *single type*
<cr1901_modern> But you're not assigning foo to have a value of "type of ArrayList(u8) (err, type)"
<cr1901_modern> In const foo = ArrayList(u8)
<cr1901_modern> You're assigning it its return value which is a "type" type (struct)
<recalloc> DarkUranium: I'm looking at the tests and source code for that -- it looks like the value of the enums's int values are expected to be an index to an underlying BitSet, but not a bitmask itself.
<cr1901_modern> So how can't the struct have been memoized if you're calling the same function w/ the same parameters?
<cr1901_modern> Anyways, it's fine I don't have to understand this all tonight... and my energy's fading quickly :(
<noam> cr1901_modern: because it's not really a *call* per se
<noam> Think of ArrayList(foo) *as the type*
<noam> just as e.g. struct{...}
<recalloc> I *could* make a different InitFlags enum independing from C SDL's init flags, but I feel manually translating EnumSet's flags to SDL2's would probably roughly put me where the struct strategy is right now.
<noam> when you do `const foo = struct{...}`, you're naming the structure foo
<cr1901_modern> hmmm
<noam> when you do const bar = foo, you're giving a second name to the same structure
<recalloc> ahh, meant to ping daru
<noam> ArrayList(u8) *is a name*
<noam> It's not the structure itself, just an identifier
<noam> (an identifier whose value is the result of the actual call)
<noam> Honestly, I think that's a really confusing concept that could do with some clarification.
<g-w1> not actually an identifier, but it works fine if you think of it like that
<recalloc> daurnimator: ^^^
<noam> the memoization is important, but it breaks some cognitive assumptions about how function calls work
<noam> g-w1: semantically, it is
<noam> semantically, assigning foo = ArrayList(u8) is the same as assigning foo = bar
<cr1901_modern> const foo = struct{...} gives you a binding "foo" to create structs.
<noam> and *not* the same as foo = baz() (for a runtime fn baz)
<noam> cr1901_modern: yeah, it binds the name to the value
<noam> With comptime functions which return types, the call is bound to the value in the same way
<cr1901_modern> And unless you use @This() somewhere inside your struct body, so does ArrayList(u8)?
<daurnimator> recalloc: as long as the flags are dense you don't need to manually translate anything
<daurnimator> cr1901_modern: I don't think `bind`-ing is the right thought model.
<noam> cr1901_modern: huh, what? What does using @This have to do with it?
<cr1901_modern> (@This() can be used to get multiple "instances" of a particular struct, not just a name binding to the struct type)
<noam> @This doesn't give you an instance
<noam> @This is another "binding"
<daurnimator> cr1901_modern: I treat `=` universally as a (shallow) copy in my mind.
<noam> const foo = struct {}; const bar = foo;
<cr1901_modern> Oooooh
<noam> const foo = struct { const bar = @This(); }; const bar = foo;
<noam> == bar
<noam> == foo
<g-w1> you can do very weird stuff with this :)
<cr1901_modern> Well, that... uh, makes things quite a bit clearer
<cr1901_modern> well, for me anyway
<noam> :)
<g-w1> == foo
<noam> ^
<noam> since == foo, == == foo, and so on
<g-w1> and it gets weirder with multiple structs!
<noam> But frankly, I think that such indirection should be prohibited
<noam> Self-recursive indirectoin*
<noam> indirection*
<cr1901_modern> Well, it's not like I'm going to do something like that
<cr1901_modern> But seeing a contrived example like that does help
<noam> I don't mean for you, I mean that there's no real valid use case for it
<daurnimator> I'm sure I could come up with one
<noam> definitionally, since ==, continuing to self-recurse has no effect
<noam> daurnimator: *definitionally* it has no effect
<noam> it's like `const a = b + 0;`
<noam> If you hardcode that zero, there's no case in which it has an effect
<noam> That's *definitionally* equal to `const a = b;`
<cr1901_modern> daurnimator: The "shallow copy" analogy doesn't really help me, but I'm definitely tired after several hours of working on a language I'm new to :P
<noam> s/equal/equivalent/
<g-w1> or as someone though of on discord `const a, b, c = thing;`
<cr1901_modern> So maybe it'll make sense after some sleep
<noam> "shallow copy" really isn't accurate, because it doesn't make a copy at all
<noam> Even with a shallow copy, the results aren't 100% the same
<noam> but with assignments like this, they're more like aliases
<recalloc> daurnimator: What makes flags dense? Looking at the tests, I'm assuming it means each enumeration has assigned a value, is that right?
<daurnimator> noam: well for starters, that's an assert that `b` supports addition
<cr1901_modern> >Even with a shallow copy, the results aren't 100% the same
<cr1901_modern> What do you mean?
<noam> ..."for some integer type n"
<noam> (where b is of n)
klltkr has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
klltkr has joined #zig
klltkr has quit [Client Quit]
adsr has joined #zig
hiljusti has joined #zig
earnestly has quit [Ping timeout: 252 seconds]
waleee-cl has quit [Quit: Connection closed for inactivity]
tdeo has quit [Read error: Connection reset by peer]
tdeo has joined #zig
tdeo has quit [Ping timeout: 276 seconds]
tdeo has joined #zig
tdeo has quit [Excess Flood]
tdeo has joined #zig
cole-h has quit [Ping timeout: 240 seconds]
daex_ has quit [Ping timeout: 268 seconds]
daex has joined #zig
leon-p has quit [Quit: leaving]
Bernstein has quit [Ping timeout: 265 seconds]
earnestly has joined #zig
Bernstein has joined #zig
Bernstein has quit [Remote host closed the connection]
hiljusti has quit [Ping timeout: 252 seconds]
Bernstein has joined #zig
dyeplexer has joined #zig
xackus__ has joined #zig
AtomToast has joined #zig
klltkr has joined #zig
TheLemonMan has joined #zig
[wtf] has joined #zig
aigoo has quit [Quit: Peace!]
antaoiseach has joined #zig
<antaoiseach> hello folks, would it be possible to use Zig for working through the llvm kaleidoscope tutorial? ( ... I know Zig works seamlessly with C, but I'm new to both Zig and llvm... was just thinking of doing it for learning.
<antaoiseach> Also, I know that Zig works nicely with C so the llvm c api could be used, but the llvm c api is not maintained (?)
<TheLemonMan> the C api is a bit behing the C++ one
pretty_dumm_guy has joined #zig
<antaoiseach> TheLemonMan: Yeah, that's what I found out while researching too
<antaoiseach> TheLemonMan: If I wanted to use the c++ api, then there's no straightforward way then, right? I mean, use with Zig
[wtf] has quit [Quit: [wtf]]
<TheLemonMan> you can write small wrappers around the C++ methods like we do in zig_llvm.cpp
<antaoiseach> TheLemonMan: Oh, I didn't know about that. I suspect the work might be be a bit too much for me right now, but I'll take a look at zig_llvm.cpp. That should come in handy in the future as well. Thank you!
<antaoiseach> TheLemonMan: I see what you mean - ZIG_EXTERN_C in the header, right?
<TheLemonMan> it's the same trick you'd use to expose C++ symbols to C, use an extern "C" block and write some functions to encapsulate all the C++-specific logic
<antaoiseach> TheLemonMan: Yup. That makes sense to me.
<antaoiseach> Actually, reading that file might also give a lot of info about the actual API used, so that looks great!
<antaoiseach> Thanks for the help... will get back once I get going and run into issuess.... cheers! :-)
antaoiseach has quit [Quit: leaving]
<mikdusan> it seems our ELF criteria to enable "link_in_crt" is `output_mode == .Exe and link_libc`; don't we also need this stuff when building .so ?
jmercan has joined #zig
waleee-cl has joined #zig
<TheLemonMan> nope
<mikdusan> on openbsd zig creating a .so with `build-lib` results in __guard_local missing symbol; it's available in crtbegin.o and crtbeginS.o
<mikdusan> tests are getting pretty far on openbsd now. just trying to fix a few standalone tests
<mikdusan> (this is with lld patched to make finding system .so work)
<semarie> mikdusan: i have a diff for libs (on OpenBSD)
<mikdusan> semarie: I just ape'd it from /usr/ports
<semarie> my diff isn't in ports :)
<mikdusan> one sec.
<semarie> i have the following in my wip directory:
<semarie> to use different crt files depending if output_mode is .Exe or .Lib
zenkuro has quit [Ping timeout: 252 seconds]
zenkuro has joined #zig
<TheLemonMan> ah, the various crtbegin/crtend objects
<mikdusan> semarie: here is lld patch to find (for example) `/usr/lib/`:
<mikdusan> that presumably is what openbsd system clang/lld is doing
<semarie> if you are trying running tests on OpenBSD machine (with the patched llvm12), it will fail on crosscompilation to linux due to -pie . the llvm12 patch is crude and it passes -pie to all targets (so linux too)
<semarie> mikdusan: yes, it is the code from base
jmercan has quit [Ping timeout: 252 seconds]
<mikdusan> semarie: I've progressed to `zig build test -Dskip-non-native -Dskip-release -Dskip-stage2-tests` but haven't tried cross stuff yet
<mikdusan> semarie: ah yes your Elf.zig patch hoists openbsd crt logic out of `if link_in_crt` block
<mikdusan> this is what I was trying to determine. why don't we kick in crt logic other elf when building .so like linux?
<TheLemonMan> long story short, the crt usually kickstarts the execution of a binary
<mikdusan> and they have ___S.o for the shared objects
<mikdusan> but we don't seem to ever do that
<mikdusan> gcc on archlinux (glibc) does this for .so: crti.o crtbeginS.o crtendS.o crtn.o
Akuli has joined #zig
<mikdusan> for exe: Scrt1.o crti.o crtbeginS.o crtendS.o crtn.o
<mikdusan> openbsd for .so: crtbeginS.o crtendS.o
<mikdusan> openbsd for .exe: crt0.o crtbegin.o crtend.o
<mikdusan> openbsd for STATIC .exe: rcrt0.o crtbegin.o crtend.o
<mikdusan> archlinux for STATIC .exe: crt1.o crti.o crtbeginT.o crtend.o crtn.o
<earnestly> There is some contention about who should supply the crtbegin/end
<earnestly> Some say libc should, others say compiler
<TheLemonMan> they are not essential as 99% of what they do is legacy stuff
<earnestly> musl doesn't provide them iirc
<mikdusan> just looking at a .zig file and musl I think does
<earnestly> May have changed in the years since I looked
<semarie> mikdusan: oh, and async should fail too as std expects EVFILT_USER for openbsd, and it isn't implemented (for now, I have wip)
<TheLemonMan> musl has no crtbegin nor crtend
<TheLemonMan> and it's libgcc (crtstuff.c) that provides them
pretty_dumm_guy has quit [Ping timeout: 252 seconds]
<mikdusan> find lib/libc/musl | grep -i crt
cole-h has joined #zig
<TheLemonMan> there's no crtbegin nor crtend ?
<mikdusan> seems not
<TheLemonMan> that's what I said heh
<mikdusan> sure but somehow I don't think we're going to get away with just crtbegin/crtend logic without it being kludgy. Probably going to have to look at the whole picture
<mikdusan> ie: for a patch
<mikdusan> our "drop in replacement for cc" `zig cc` doesn't, for example, do any crtbegin/end when creating shared lib on either openbsd or linux
klltkr has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<TheLemonMan> well if we want to be as drop-in as possible then we may want to add a small crtbegin/end implementation too
<TheLemonMan> I believe that .init/.fini are long dead, but you never know what kind of weird stuff people are trying to compile
<mikdusan> semarie: btw did you run into a weirdness when building zig and llvm-config says to link `` ? I did an ugly hack to workaround
xackus has joined #zig
B767B has joined #zig
xackus_ has joined #zig
xackus__ has quit [Ping timeout: 260 seconds]
xackus has quit [Ping timeout: 240 seconds]
<kiedtl> has the {u} format specifier not been implemented yet? When I use it with std.debug.print and a non-const u21 I get the "Unknown format string: 'u'" error.
leon-p has joined #zig
<ifreund> kiedtl: are you sure that you are passing your u21 by value and not a pointer to it or something?
<ifreund> from skimming the code it looks like it should work on master
<Nypsie> kiedtl, you need zig master
<Nypsie> 0.7.1 Doesn't support it
<kiedtl> Nypsie: oopie, I see
<mikdusan> perfect
v0idify has joined #zig
v0idify has left #zig [#zig]
Biolunar has quit [Ping timeout: 250 seconds]
Biolunar has joined #zig
<semarie> mikdusan: if you are building directly openbsd, I would recommand building llvm12 with CXXFLAGS="-fno-ret-protector -mno-retpoline" (assuming amd64)
<semarie> it will help the build time *a lot*
<mikdusan> I see also that cmake no longer prunes -O3 flags for optimized builds in 6.9
<semarie> if I recall correctly, there were cmake changes to do that only when building ports stuff (and not always)
<mikdusan> it certainly kicked-in on 6.8 (and maybe 6.6?) because I had to manually override cmake command line building llvm to get -O3
<mikdusan> and that also inflated bins because no DCE
<semarie> in openbsd, -O3 is avoided (too much unwanted optimizations if I recall correctly)
<mikdusan> I think we've been getting away with not adding crtbegin.o/crtend.o pairs on linux because there is little c++ going on and those are related to constructor/destructors
<mikdusan> but openbsd places (in libc I think) a reference to __guard_local which is defined in crtbegin.o forcing us to need to link it
<mikdusan> (I should qualify both lines above; for cases of building .so)
<TheLemonMan> linux/musl is fine, on linux/gcc we're skipping the destructors/atexit hooks
<andrewrk> good riddance
<andrewrk> all global static destructors and atexit hooks are bugs
<semarie> maybe, but without atexit it means linking with libc is not properly supported
<semarie> (as libc might rely on atexit)
<andrewrk> *sigh* that's true
<TheLemonMan> mikdusan, was copyFile the only problem with the newer qemu version?
<mikdusan> TheLemonMan: I never tried to continue beyond that point
<semarie> mikdusan: I am able to pass the tests with only the following disabled: docgen (linkage failure: can't create dynamic relocation R_X86_64_64 against local symbol in readonly segment) and dumpCurrentStackTrace (signal 6)
<semarie> but else, it seems fine (on openbsd, for the context)
<mikdusan> nice; aside from the llvm/lld patches, I don't recall openbsd getting this far before
<semarie> ( zig build test -Dskip-compile-errors -Dskip-non-native -Dskip-release )
<mikdusan> hmmm I had to -Dskip-stage2-tests (haven't looked into what is causing it)
<TheLemonMan> semarie, does the linker error go away if you use system's ld?
notzmv has quit [Ping timeout: 252 seconds]
<mikdusan> on a side note I got dragonfly bsd building zig.exe but sidelined before I got dig into a child_process failure. It has to do with polling file descriptors
dyeplexer has quit [Remote host closed the connection]
cole-h has quit [Quit: Goodbye]
cole-h has joined #zig
<TheLemonMan> it'd be nice to have at least {open,net}bsd hooked up to the CI
recalloc has quit [Ping timeout: 265 seconds]
recalloc has joined #zig
<andrewrk> TheLemonMan, we have some systems readily available, as soon as any subset of tests are passing and we do some initial setup work, that can be a reality
<karchnu> TheLemonMan: I wonder if the OpenBSD kernel will accept Zig async stuff. I don't know that well the implemented mitigations.
<semarie> karchnu: "Zig async stuff" ? you mean EVFILT_USER or something else ?
<karchnu> semarie: I don't quite grasp the concept of async functions, from what I understand they are functions inside stack memory.
<TheLemonMan> andrewrk, provisioning the CI machine and installing the test fixtures is the hardest part heh
<TheLemonMan> karchnu, there's no stack involved
<andrewrk> zig async functions are just a way to organize control flow, they don't interact with the OS at all
<andrewrk> there is however a standard library event loop implementation, which very much does need to interact with the OS :)
<karchnu> TheLemonMan: my bad, so async functions are in the heap memory. Isn't W^X security feature of the OpenBSD kernel a problem in this case?
<karchnu> andrewrk: true, but the only interaction is the use of kqueue, right?
<andrewrk> karchnu, yes and threads
<andrewrk> the machine code of async functions is the same as the machine code of normal functions
<TheLemonMan> to be fair one could say that the stack is also part of the heap heh
<andrewrk> the only difference is where local variables are. they could be in the heap, or the stack, or even in global memory
<TheLemonMan> functions are placed in a executable area, we're not writing (nor reading) anything from there
<andrewrk> essentially async functions are just functions which accept a secret struct pointer as the first paramater, which is used for all the locals instead of the stack
<companion_cube> (in other words, a closure :))
<andrewrk> yes
<shachaf> Well, "closure" usually suggests something is closing over external variables. Here it's more like internal variables, which is a bit different.
<companion_cube> you can have a closure that is the sole owner of what it closes on
<companion_cube> it's pretty common
<companion_cube> some might even call that "objects"
<companion_cube> (heh, that's pushing it, but you can do that kind of things)
<karchnu> andrewrk: thanks, your last sentence actually made me understand async functions :D
<karchnu> that pretty simple
<andrewrk> nice. it's a different sentence for different people :)
<karchnu> yep, as a 4-year PhD teacher I saw that a few times ^^
<andrewrk> haha
pretty_dumm_guy has joined #zig
<noam> andrewrk: ahhhh, and that means that you can run multiple of them in parallel since they aren't touching the stack, right?
<noam> That explanation is a lot better than the others I've heard :)
<earnestly> Funny how the unsugared explanation always seems to make the most sense
<andrewrk> noam, right
<g-w1> wow, this makes sense
<ifreund> yep, all the memory is in the @Frame() :D
<TheLemonMan> fucking captchas are getting crazier and crazier
<rxF> captcha arms race
<TheLemonMan> and it's now stuck in a redirect loop lol
<TheLemonMan> the internet was a mistake
<andrewrk> captchas were a mistake
<andrewrk> discrimination against robots
<andrewrk> robots are people, too
<plumm> define person
<fengb> LemonBot
<plumm> fengb do you know how to use hzzp to read response bodies
<plumm> I am trying to adapt your replybot thingy
<karchnu> so, async functions can (will?) be used by event loops to perform network operations while the event loop itself will only be running for event notification (ex: socket X has something to read, socket Y can be written, then sleep until next event), right?
<fengb> According to the zCord code, the first event received after the request is .status, and it has an attached code
<andrewrk> karchnu, yes
<andrewrk> karchnu, you can see some proof of concept code for this in std.event.Loop
<karchnu> and mutexes shouldn't be used since they will block an entire thread while async functions could be used on a single one, "simulating" multiple threads
<andrewrk> there is a kqueue implementation there
<andrewrk> it's also possible to have a multi-threaded event loop :)
<andrewrk> in such case you have to beware that when you use `async` that function may be running in a different thread at the same time as the code until `await`
<andrewrk> this is identical to how concurrency in go works, with `go` keyword
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
<karchnu> andrewrk: it seems to be what 80's developpers named "coroutines"
<andrewrk> yes you might call zig async functions "stackless coroutines"
<karchnu> OSs weren't all pre-emptive back then, so they had to do hacky stuff like that
<mikdusan> TheLemonMan: netbsd 9.1 is in "decent" shape; it's currently failing on socket missing from std.c, and os.getFdPath() needs impl. that kind of thing. but we're getting there!
<mikdusan> order of zigness: freebsd > openbsd > netbsd > dragonfly
<mikdusan> andrewrk: given an OS like openbsd which differs enough that we'd need to apply small patches to llvm/lld, and those patches are cherry-picked from openbsd's llvm patches, and those patches are not in a state to be upstreamed, how would you suggest we document/support openbsd in our matrix?
cole-h has quit [Quit: Goodbye]
cole-h has joined #zig
xackus_ has quit [*.net *.split]
earnestly has quit [*.net *.split]
deb303 has quit [*.net *.split]
xentec has quit [*.net *.split]
isolier has quit [*.net *.split]
tlam has quit [*.net *.split]
andrewrk has quit [*.net *.split]
deb303 has joined #zig
tlam has joined #zig
isolier has joined #zig
andrewrk has joined #zig
xentec has joined #zig
xackus_ has joined #zig
earnestly has joined #zig
ifreund has quit [Ping timeout: 240 seconds]
ifreund has joined #zig
zenkuro has quit [Ping timeout: 260 seconds]
xackus has joined #zig
xackus__ has joined #zig
xackus_ has quit [Ping timeout: 252 seconds]
Guest50015 has joined #zig
xackus has quit [Ping timeout: 240 seconds]
deb303 has quit [Quit: WeeChat 2.3]
B767B has quit [Remote host closed the connection]
pretty_dumm_guy has quit [Ping timeout: 260 seconds]
wootehfoot has quit [Read error: Connection reset by peer]
Akuli has quit [Quit: Leaving]
* mikdusan cries in black-and-white. openbsd's lldb has no color!
Guest50015 is now known as notzmv
klltkr has joined #zig
Bernstein has quit [Remote host closed the connection]
<karchnu> mikdusan: color is a security issue.
halbeno has quit [Quit: Leaving.]
halbeno has joined #zig
<betawaffle> andrewrk: the GitHub wiki says you want help moderating this irc channel. Can I throw my hat in the running? References available on request.
<noam> ...I've definitely seen your name somewhere...
<betawaffle> Yep, a lot of places. I’m everywhere.