<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?
<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>
https://github.com/ziglang/zig/issues/513 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>
http://ix.io/3lEr 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>
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>
http://ix.io/3lEw 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
<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?
<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: https://0x0.st/-axy.zig
<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>
foo.bar == 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.bar.bar.bar.bar.bar == foo
<noam>
^
<noam>
since foo.bar == foo, foo.bar.bar == foo.bar == 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 foo.bar.bar == foo.bar, 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
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? (https://llvm.org/docs/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
<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)
<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 `-lz.so.5.0` ? 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
<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.