<juturnas>
daurnimator: do you have any of your http thoughts written down somewhere? I'd be interested in keeping them in mind while I work on this proxy
<daurnimator>
juturnas: FWIW I'm the author of https://github.com/daurnimator/lua-http/ many of my ideas are from there. other ones are lessons learned that I haven't written down...
<daurnimator>
juturnas: do you have particular questions I could try to answer?
<daurnimator>
first I guess I'll say that there are two main interfaces: "connection" and "stream". a connection may have many streams. in http2 they are parallel. in http1 they are pipelined. a stream is made up of "header" and "data" packets/chunks.
<daurnimator>
let me know if you want to know more about those concepts
<daurnimator>
second I'll mention that you want to optimise the socket abstractions to take advantage of all the modern features available including TCP fast-open, TLS early data and in-kernel TLS. Note that this means that the traditional berkerley sockets API is not a good model or starting point
<juturnas>
I'm familiar with the concepts of http2 but I haven't implemented it before. I'll have a look over lua-http tonight and if I'll make note of any questions I have regarding how you think concepts should translate to zig
<juturnas>
Not familiar with TLS early data either - is that separate from session resumption?
<daurnimator>
juturnas: yep. TLS early data lets you send encrypted data in the first packet; and then in the 2nd packet after key negoiation you provide the key to decrypt the early data
<daurnimator>
juturnas: essentially it removes 1RTT from making requests
<daurnimator>
and you can send that early data in the TCP fast-open too. Which means that you actually want to have e.g. your GET request ready before you even call connect()
laaron has quit [Remote host closed the connection]
<juturnas>
Does http-lua implement most of these? Wondering what the interface between the http lib and the tls implementation looks like
laaron has joined #zig
<daurnimator>
juturnas: not right now; but the interface is designed so be able to add it transparently behind the scenes
<Tetralux>
Does that turn out to be a good for the PI?
<Tetralux>
API*
<Tetralux>
(.. of cqueues)
<daurnimator>
juturnas: for zig I want to do something that is both simpler and more complex. the abstraction I'm working on is based on the new linux kernel uring API ( http://kernel.dk/io_uring.pdf ) which I think I can make work on windows really well too
<daurnimator>
Tetralux: yes.... though that wasn't a very precise question
<daurnimator>
juturnas: oh. and the other thing to keep in mind for setup of http connections is happy eyeballs. https://tools.ietf.org/html/rfc6555
<Tetralux>
daurnimator: I was fishing for an example of how it makes it better xD
<Tetralux>
And how you bound it.
<Tetralux>
I'm guessing it eventually blocks if there's a certain amount of stuff queued.
<daurnimator>
Tetralux: yep. you get to pick the size of your buffers. if you try and write more than you get a synthesized EAGAIN
<Tetralux>
EAGAIN, presumably meaning, "You should try that again."
* Tetralux
smiles.
<daurnimator>
Tetralux: EAGAIN usually means "select/poll/wait" and try again once there's room
<Tetralux>
You can poll writing to a socket?
<daurnimator>
of course
<Tetralux>
Oh wait
<Tetralux>
I guess you give it flag for "Tell me when there's room"
<daurnimator>
thats what POLLOUT is
<Tetralux>
Ah-ha.
<daurnimator>
(see `man poll`)
<Tetralux>
.. convieniently, POLLOUT is the only one in `man poll` without a description xD
<daurnimator>
really? what OS/set of man pages
<daurnimator>
try googling for it instead :P
<Tetralux>
FreeBSD
<Tetralux>
I wouldn't know how to determine the set of man pages.
<daurnimator>
Tetralux: oh, POLLWRNORM I think is an alias for it on freebsd. i.e. the description is for both of them
<bgiannan>
what's the difference between []u8 and []const u8 exactly?
<mikdusan>
andrewrk: ah ok i finally get it: `var p: [*]u32 = undefined; var slice = p[n..n];` is always allowed because [*] is always unknown size. (i was incorrectly fixating on `undefined`)
juturnas has quit [Remote host closed the connection]
<mikdusan>
bgiannan: a slice is "pointer + length". pointers can be eg. `*u32` or `*const u32` and the pointer of a slice is marked as const with syntax `[]const u32` and prevents writes to elements therein. `slice[3] = 10` would fail
<bgiannan>
mikdusan, i just figuered it out yes: i had a slice and i didn't understand why my data was messed up with until i put const
LargeEpsilon_ has quit [Ping timeout: 245 seconds]
<bgiannan>
daurnimator, Tetralux found a way to test the type of instances in my OOP pointers solution but it crashes zig: https://0x0.st/z4mJ.zig
Ichorio has joined #zig
<samtebbs>
bgiannan: Why do the structs have to be packed?
<daurnimator>
samtebbs: so that layout is defined; which means that you can cast it to other similar structs
<samtebbs>
daurnimator: I see. I removed the packed keyword and it doesn't crash zig
<samtebbs>
Packed structs are a bit touchy right now
<daurnimator>
samtebbs: layout of members in structs is undefined unless they are extern or packed.
<daurnimator>
==> in future they could be packed for effcient use of memory; or for large structs, putting frequency used members together so they share a cache line
<daurnimator>
but at the moment I think it's just the order that you write them in source
<bgiannan>
so i'm stuck, the union solution is far too verbose and will result of a bunch of function calls just to access simple struct members
<daurnimator>
bgiannan: link to latest?
<daurnimator>
bgiannan: I think I've said it before, but I think the "best" solution is the @fieldParentPtr one
<bgiannan>
most likely i'll add Units to an array without knowing how to get the unit field
<bgiannan>
samtebbs, i already got that working
<bgiannan>
it's the `instanceOf` bit that's crashing zig
<samtebbs>
bgiannan: Ok, but how do you make an array of structs implementing Unit since they're of different types?
<samtebbs>
bgiannan: Oh ok
<bgiannan>
samtebbs, that's why i need packed struct
<bgiannan>
Agent's first field is a Unit
<bgiannan>
so @ptrCast an Agent to a Unit will work
knebulae has joined #zig
<samtebbs>
So you'll do the ptrCast before putting it in the array, rather than afterwords
<samtebbs>
I read your messages as though you were going to make an array of structs that implement Unit, then ptrCast them when reading them from the array
<bgiannan>
right ptrCast first
<samtebbs>
Makes sense
<bgiannan>
so i need a way given a Unit to know if it's actually an Agent or a Terrain
<bgiannan>
the instanceOf methods seemed to be the solution but i think a function member with a comptime T in it must be a little to weird for zig
<bgiannan>
in a packed struct i mean
<daurnimator>
bgiannan: have a member 'unit type' that is an enum?
<bgiannan>
daurnimator, i need to be able to tell that it's an instanceOf A>B>C, not just C
<samtebbs>
Removing packed gives this "error: parameter of type '*const Agent' must be declared comptime"
<bgiannan>
i can pass types as strings for now and replace them with actual types when zig is fixed
<daurnimator>
bgiannan: could C have a "parent" field that says B? and B have a parent field that says A?
<daurnimator>
bgiannan: switch over an enum?
<bgiannan>
hum why not
<bgiannan>
wouldn't it grow slower and slower as i create more types?
<samtebbs>
bgiannan: instanceOf wouldn't work at runtime because the type has to be known at comptime
<bgiannan>
that would be comptime
<daurnimator>
I really think we need tschultz on this question :P
<bgiannan>
i would write things like: `if (a.instanceOf(Agent)) {...}`
<daurnimator>
bgiannan: so there's a weird hack around to add functions into a struct that they used in a demo
<samtebbs>
bgiannan: Oh of course ignore that
<bgiannan>
daurnimator, samtebbs, using strings instead of actual types -> https://0x0.st/z4mU.zig Can be a solution until a fix
<samtebbs>
bgiannan: It would be worth reporting this. Check if there are issues similar first though as packed structs have been causing problems.
<bgiannan>
yes
<bgiannan>
daurnimator, does zig internize short string like lua would do?
<daurnimator>
bgiannan: no
<daurnimator>
bgiannan: hence why use an enum instead :P
<bgiannan>
now that i think about it i should know how to get the unit instance when adding something to my collection so i can do without the packed struct
<samtebbs>
bgiannan: Yeah that was my thought :)
SimonN has quit [Ping timeout: 244 seconds]
SimonN has joined #zig
SimonNaa has joined #zig
SimonN has quit [Ping timeout: 268 seconds]
Ichorio has quit [Ping timeout: 264 seconds]
ntgg has joined #zig
alexander92 has joined #zig
ntgg has quit [Ping timeout: 245 seconds]
laaron has quit [Remote host closed the connection]
<Tetralux>
bgiannan: `typ: UnitType` <- Can be Agent, Terrian, etc.
<Tetralux>
@fieldParentPtr to this field
<Tetralux>
You now know what kind of thing it is.
<Tetralux>
Also, make the zero value UNINITIALIZED or something
<Tetralux>
typ: UnitType = .Unitialized,
<alexander92>
hey
<Tetralux>
That way, if you forget to set it in a new type, it'll realise immediately.
<Tetralux>
alex: Hiya!
<bgiannan>
a type field would not be useful Tetralux
<bgiannan>
Tetralux, yes but i'm not a fan of having to follow a trail of pointers to find out the type of my instance instead of just calling a `instanceOf` method that will just tell me
<daurnimator>
^ something liek that would be the internals of a .read function
<daurnimator>
we haven't got that written yet though
<fengb>
If your code uses a blocking fs call, it should automatically run as async when io_mode is switched
<Tetralux>
bgiannan: I'm not sure there's a better way.
<alexander92>
daurnimator thanks: i am playing with nim's multisync and trying to see if there are parallels, i was surprised to see zig supporting this
<alexander92>
is there a way to forcefully "await" an async call in blocking context then?
<alexander92>
that's the other thing that i usually use there in similar context
<daurnimator>
alexander92: yes. `await` :)
<alexander92>
i see, we call it waitFor
<alexander92>
ok, will play with it later
<daurnimator>
alexander92: one way to think about things is that a *normal* function call `x = foo()` is sort of the same as writing: `x = await async foo()`
<daurnimator>
i.e. all function can be called "asyncly".
<alexander92>
yeah, the way it's done in nim is that you can write something like an "async-generic" function which specializes two instantiations : one async, and one sync which mostly accepts await as no op
<alexander92>
so it's kinda similar, but i wonder if this dependency on io_mode is cleaner
<daurnimator>
alexander92: so the key thing in 1778 is that async is.... "inherited". like, if *you* call an async function `foo()`, then *you* implicitly become async
<daurnimator>
however if you *don't* want to become async, then use `async foo()` : which means foo() is allowed to finish "later"
<alexander92>
but is it like "you become async *when* io_mode is Evented, and when it's not : this inferrence doesnt happen", or is it like "async is just implemented blockingly when io_mode is Blocking"
<Tetralux>
The second one.
<daurnimator>
alexander92: so to delve in one layer deeper: you become async if you hit a `suspend` statement
<daurnimator>
alexander92: however the point of the global `io_mode`, is that you can switch (at compile time) if you want to hit suspend statements or not
<alexander92>
i see: so, in this case this means, that if you want your lib to be "generic" for async-ness(suspend-hitting), you need to write it with async annotations
<alexander92>
and that's all you need to do
<daurnimator>
alexander92: huh? no...
<alexander92>
hm
<daurnimator>
alexander92: in practice it means almost nothing needs to care about async vs non-async
<daurnimator>
the internals of (e.g.) the .read() function are the only ones that decide
<daurnimator>
and then it gets "inherited" up the call chain
<alexander92>
yeah, what i meant was that
<alexander92>
if i write a lib with similar "primitives"
<alexander92>
ah, i see: i need to do it explicitly
<Tetralux>
If you write a lib using `async f()`, suspend, resume, await, etc, then it can be used in a blocking and a non-blocking fashion.
<Tetralux>
Otherwise, it's blocking.
<alexander92>
yes, that's something like what i wondered
<alexander92>
we've had some discussions about this approach, as some people dont see any value in supporting blocking IO (as you can always "await asyncLibCall()" in your blocking app)
<alexander92>
but i also like it
<daurnimator>
alexander92: you can always turn a sync function into async. but not always the other way
<daurnimator>
alexander92: which means: that async should essentially be the default.
<Tetralux>
SeeThe whole problem I have with async anything is that I now have to understand stuff about how async is implemented.
<Tetralux>
I do if I want to understand both what my program is doing, and performance implications.
<alexander92>
oh, i read it
<alexander92>
i've seen this link like 5 times
<alexander92>
the last two days :D :D
<alexander92>
everybody always pastes it in those discussions
<daurnimator>
its a good introductory article :p
<alexander92>
i know that: but the problem some people see is that this really doesnt solve the color problem
<alexander92>
it merely helps with implementing a bit more "generic" abstractions
<alexander92>
as you still have io_mode .. Blocking, and also functions-working-only-in-blocking-fashio and still cant really call blocking functions from async code (right .. ?)
<daurnimator>
alexander92: sure you can....
<daurnimator>
alexander92: the big thing though is: it doesn't matter if you "become" async
<alexander92>
hm?
<alexander92>
but it does?
<daurnimator>
alexander92: why?
<alexander92>
if you call a blocking e.g. file read
<alexander92>
your whole event loop can hang
<daurnimator>
that would be a flaw in your file read function for not respecting the io mode (or you not reading the docs of the read function and seeing that it blocks)
<alexander92>
i can't see how changing the default fixes that
<alexander92>
but that's what i am saying:
<alexander92>
you can't call functions that block from async functions
<daurnimator>
you *can*. you *shouldn't*
<alexander92>
ok, that's what i meant, sorry
<alexander92>
let's say a better type system can catch this
<alexander92>
and make it "can't"
<daurnimator>
?
darithorn has joined #zig
<daurnimator>
I don't think that's possible
<alexander92>
there shouldn't be a difference between "can't" and "shouldn't" if possible in lang design imho
<fengb>
I don’t see how that solves anything
<fengb>
That’s basically saying this execution context can’t run anything computationally expensive
<daurnimator>
you can always have functions that "block" e.g. if they call out to some C function; or if they even just do a long math operation. either way your main loop doesn't get to tick for a while
<alexander92>
it's inevitable, but if it's possible for X to be checked instead of expecting a human to read its docs, it should be checked
<daurnimator>
solving that is really what preemptive multi threading is about
Snektron has joined #zig
<daurnimator>
which is an OS concern; not a language one
<alexander92>
daurnimator: but that *is* a real problem
<fengb>
But preventing a call doesn’t solve it
<alexander92>
and one can easily imagine "blocking" annotations/type qualifiers
<fengb>
It just bifrocates the userland more
<alexander92>
which are checked by the compiler in a similar way like async
<fengb>
And technically every function is blocking. So we’ll need things like async pow()?
<alexander92>
but i *want* the compiler to tell me if i try to call a heavy math function inside some of my async code
<fengb>
Define heavy math
<mq32>
daurnimator, in the case of async-await it gets a language problem as the event loop is actually a cooperative task scheduler
<alexander92>
obviously there is more nuance
<Tetralux>
.. And when you don't actually want that xD
<alexander92>
and this is something that the language can give options for
<Tetralux>
My point was, how?
<Tetralux>
By having the human mark functions blocking?
<alexander92>
e.g. 1) you might manually mark your heavy cpu functions 2) you can run some kind of "cost" inferrence
<fengb>
mq32: we’re building in a threadpool worker so it’s not just cooperative
<alexander92>
3) you can have primitives that the stdlib marks
<alexander92>
and inferrence can figure out that your function calls them
<mq32>
fengb: as long as our threadpool is large enough ;)
<mq32>
and also only for I/O-heavy stuff, not for computanional heavy stuff
<Tetralux>
I think a better counter question is this:
<Tetralux>
In a complicated system
<alexander92>
4) it might be possible for the compiler to autoinstrument such heavy code with "cooperative" yields in async mode
<Tetralux>
How do you determine if you are calling a blocking function in an async function which is taking too long and is grinding your event loop to a halt?
<Snektron>
Hello, im trying to improve arm (32-bit) support for the zig std, however the linux headers got me confused. I'm starting with the constants, equivalent to std/os/bits/linux/arm64.zig and x86_64.zig, which i'm just taking from the headers on my old raspberry pi. While looking around though, i found that some constants are defined multiple times, for example F_GETLK is defined to 5 in /usr/include/asm-generic/fcntl.h and to 12
<Snektron>
in /usr/include/bits/fcntl.h. How do i know which one is correct?
<daurnimator>
Snektron: IIRC asm-generic is base definitions; those are used if an arch-specific definition isn't available
<Tetralux>
alex: A good idea in theory
<Tetralux>
But
<alexander92>
Tetralux: if [1) + 3)](which use the same mechanism) and 4) is implemented, it seems easy to me
<Tetralux>
What if you need a certain instruction to occur before suspending?
<Tetralux>
Like: you can't suspend here-to-here, but you might here.
<alexander92>
well, i guess that the compiler can work with a bit higher level code , not really instruction level
<alexander92>
and try to separate it into non-blocking/fast-enough pieces: if this is not possible: it can just refuse to typecheck that
<Tetralux>
I suspect that this is too complicated.
<Tetralux>
That's my gut reaction.
<alexander92>
and let the user either enforce it with a manual annotation, or rewrite it in more async way himself
<alexander92>
the another option is of course smarter auto .. threading?
<daurnimator>
alexander92: one cornerstone of zig is *no hidden control flow*. what you're suggesting sounds like hidden control flow.
<alexander92>
but i admit i have no idea if this is efficient enough
<alexander92>
well, in this case, you can just detect those possibly-blocking calls and always refusing them
<fengb>
Vague thought: a library function that asyncifies by creating its own thread pool
<alexander92>
and let the user async-ify / "run-in-threadpool-and-return"
<alexander92>
them
<Snektron>
whats the point of having a fallback definition if it's not correct anyway
<alexander92>
fengb: exactly
<fengb>
Er, execution thread, not pool
<mq32>
alexander92, what you are trying to do is solving the halting problem. not possible for the compiler to determine "code heaviness"
<daurnimator>
fengb: I'm sort of getting to that point in some of the uring fallback code
<alexander92>
mq32: this was optional: the most important thing is to infer internal "blocking calls" and add the ability for the user to mark his own "heavy" code
<mq32>
yeah but what's the real advantage of that? i have two options: either execute "heavy" code because i have to or not execute heavy code (but then i don't have to mark it as "heavy")
<alexander92>
fengb: i mentioned this asyncify-in-threadpool idea as it's something that i need in nim as well
<fengb>
snektron: I'd guess it's based on the generic spec, which doesn't necessarily match the specific subarch
<alexander92>
mq32: it can help with detecting stuff that can block your event loop
<daurnimator>
Snektron: often there is 20 architectures; but only 2 of them have different definitions
<alexander92>
i admit: it would be better to have some kind of number with which this is measured
<fengb>
alexander92: but it's not async vs sync. Because you can write an async function that still blocks badly
<alexander92>
that's true, but it's one possible issue imo
<alexander92>
with async
<fengb>
I think it's more of a execution cost problem
<alexander92>
e.g. i run an async server and i want low latency
<alexander92>
and ugh: this call can hypothetically take 2s
<mq32>
i think that's not a problem a language should solve
<mq32>
but good software architecture
<alexander92>
but this heavy code thing is more an edge case
<alexander92>
the main case imho are stuff like blocking io
<fengb>
At some point, some idiot will write while (i < 10) : (while i += 0)
<fengb>
And hang the server >_>
<alexander92>
but this can be fine i guess, if one has async alternatives for all of its io primitives
<alexander92>
fengb: except, if you auto-cooperativify the loop :P
<mq32>
alexander92, tell me a generic-purpose way how to "auto-cooperativy" any control structure?
<mq32>
whould this happen every loop? at the beginnning, at the end?
<alexander92>
this was tongue in cheek in this case
<mq32>
and as andrew said: "if you suspend, you should have a plan to resume it"
<alexander92>
i haven't really thought about that deeply
<mq32>
auto-generated code has no plan to resume
<fengb>
There should be a built-in for "resume whenever you come back to me"
<Tetralux>
mq32: You don't know that. xD
<alexander92>
andrewk: does this apply to compiler-assisted cooperativeness
<fengb>
I do that all the time in JS
LargeEpsilon_ has joined #zig
<Tetralux>
fengb: Doesn't that just mean "resume when you resume me?" xD
<mq32>
fengb: i think zigs async is much more lowlevel than the one in js
<mq32>
as we have to actually store the suspend frame position somewhere
<fengb>
It's implicit at the callsite if there isn't one
<fengb>
Ruby isn't a good benchmark for performance :P
<kristoff_it>
the TLDR is near the bottom in a table
LargeEpsilon_ has quit [Ping timeout: 245 seconds]
<kristoff_it>
in C# using async/await has great chances of deadlocking an application depending on the ecosystem and load
<kristoff_it>
it's bonkers that people put up with this design
<Tetralux>
Personally, I only used Async/Await in DotNet because it made making my UI not lock up easier.
<fengb>
I think this is why people hopped on the node bandwagon. Cannot block actually works decently for the architecture
<fengb>
Just don't do math and you're okay!
<Tetralux>
One word: Verbose.
<fengb>
Or expect debugging help
waleee-cl has joined #zig
<kristoff_it>
Yes, and I think it's similarly why some moved from Node to Go: you get a concurrency model that you can reason about (I find the C# one inscrutable) and you get multithreading compared to Node
<Tetralux>
Personally, I'd like to be able to very easily say "Hey, I don't want to wait for this, but I need it later. Do this on another thread", and maybe specify the thread pool, or something
<fengb>
Yeah I like Go's model really well
<alexander92>
mq32: but i agree with you: my question was more open
<alexander92>
it was : why then nobody adopts pure green threads/goroutines instead
<Tetralux>
Stackful?
<mq32>
because working with blocking is easier to *everything* except performance
<fengb>
Because writing a scheduler is hard and coordinating it with the OS scheduler is super hard
<Tetralux>
Though, I should note that you can get almost all the way there synchronously.
<Tetralux>
The only thing you can't do, _is_ more than one thing at once.
<Tetralux>
How much that matters, depends on a few things.
<fengb>
mq32: goroutines are basically blocking green threads. It's really nice
<fengb>
For Zig: green threads require stackful context and is semantically unsound with the rest of the language
<fengb>
It required cascading an allocator everywhere and failed for a lot of usecases
<daurnimator>
fengb: except... it doesn't :)
<daurnimator>
biggest trouble right now is that you can't pass comptime arguments when making a @Frame()
<kristoff_it>
It's from the commenter that a few weeks ago helped explain comptime in Zig on HN when my blog post rose to the front page
<daurnimator>
fengb: with zig we can pretty much emulate green threads with stackless resumption
<fengb>
daurnimator: I mean actual preemptive green threads, which is what I assume alexander92 was describing
<fengb>
We can fake it with a threadpool + async, but it's not quite the same
<daurnimator>
fengb: preemptive green threads are...... super rare. I don't think I've seen them this millenium
<fengb>
goroutines are preemptive
<daurnimator>
are they?
<fengb>
yes
<daurnimator>
isn't it only at certain boundaries?
<kristoff_it>
IIRC you don't yield from Goroutines, but the compiler adds yields statements for you when it thinks it's appropriate
<mq32>
how do you even do preemptive green threads?
<daurnimator>
otherwise I can't imagine anyone writing safe container management code in Go......
<mq32>
signals?
<daurnimator>
mq32: signals were the old way.
<mq32>
can't image how that should work with either instrumentation or some kind of interrupts
<fengb>
Oh... maybe I'm wrong
<daurnimator>
mq32: you can do it with a 2nd OS thread that interrupts your "first" one. if you're in something like Go you use the garbage collection check-times to do it I think
<fengb>
The userland feels preemptive but architecturally it's not
<daurnimator>
for VM languages you could IR instructions
<fengb>
lol... I've actually wondered if I could make "real" multithreaded JS by making every function async
<fengb>
Go is way ahead of me
lunamn has quit [Ping timeout: 248 seconds]
<daurnimator>
fengb: there was a project for ES6 in ES3 that made that possible
<daurnimator>
Continuum
<mikdusan>
andrewrk: re: hoisting bounds-checking to IR, is there value to create a new IR instruction-type to represent a single bounds check, or just generate IR using existing instruction-types?
<fengb>
Note to self: if I think I have a smart idea, it's probably been tried half a dozen times
halosghost has joined #zig
<andrewrk>
Sahnvour, tiehuis: nice work on the auto hash stuff
<kristoff_it>
fengb: but maybe it takes 13 tries to execute correctly, and you have the advantage of being able to observe 12 of them :)
<daurnimator>
fengb: but also; the DOM is full of weird corner cases of things that cannot be async
<andrewrk>
mikdusan, I'm not sure. One thing I would want to try doing (which is difficult / big project) would be to emit the safety checks as existing instructions, and then do some kind of control flow analysis / value tracking, and try to eliminate the checks if it can be proven that a branch is never taken
<fengb>
Yeah I like to pretend the DOM doesn't exist when doing heavy JS stuff :P
<daurnimator>
fengb: e.g. IIRC, you can only make a popup in direct response to a user click. not asyncly after a onClick handler returns
<fengb>
Yeah that bit me quite a few times. My coworkers disabled that check on their browsers and it drove me bananas
<fengb>
"It works for me" -_-
<daurnimator>
there's enough little things like that around that you can't "async all the things"
<fengb>
But I meant more JS-JS. I'm one of those weirdos that uses JS for non-DOM stuff too
<daurnimator>
it's also why we couldn't use IndexedDB for a project where it would have been a perfect fit: all IndexedDB operations are async... but we needed to fetch something in response to a click that had to be done instantly
<fengb>
Ohhhh Ron Pressler == pron
<fengb>
That is not a googlable username
<Tetralux>
You should see some of the usernames of original Bell Labs people.
<Tetralux>
It's things like
<Tetralux>
"qr"
<mq32>
Tetralux: I'm actually using "xq" as my nickname nowadays, but there's someone on freenode who uses that already :D
<Tetralux>
Maybe I should be Tl or something. :3
LargeEpsilon has joined #zig
<mq32>
but: xq is actually "x q" which is a substring of my real name... :D
<mq32>
x_q just looked to much emoji-like to be used for a nickname *grin*
<Tetralux>
You have a surname that starts with Q? O.O
<mq32>
and first name that ends with x, correct :D
<Tetralux>
Well then.
<Tetralux>
Clearly, I've now met one of the Chosen Ones.
<fengb>
I'm assuming your first name is Tetralux
<mq32>
*rofl*
<kristoff_it>
haha
<Tetralux>
Naturally. ;)
<kristoff_it>
then, according to my IRC client, his surname starts with `:`
<Tetralux>
But my name does have a W in it, so. :)
<Tetralux>
And a U too.
<Tetralux>
So. Pretty even I think. :p
BigEpsilon has quit [Ping timeout: 245 seconds]
<samtebbs>
Does anyone get tagged when anyone writes "nickname"?
<Tetralux>
You mean like if I mention samtebbs like this?
<Tetralux>
Yeah, that works for me too.
<samtebbs>
Tetralux: indeed
alexander92 has quit [Ping timeout: 244 seconds]
<samtebbs>
Is there a page with the zig fmt style guide?
LargeEpsilon_ has joined #zig
<andrewrk>
samtebbs, no
<kristoff_it>
`gq` in Vim is amazing, is there a way to make it work with doc comments?
<samtebbs>
andrewrk: Ok, since I would like to use it in my project and providing documentation for a style is a good idea
<Tetralux>
kristoff_it: gq?
<kristoff_it>
Tetralux: re-flows comments to a fixed length. This way you don't have to manually adjust each line.
LargeEpsilon has quit [Ping timeout: 268 seconds]
<Tetralux>
Ah. Curious
<kristoff_it>
but it doesn't recognize properly `///` comments
<kristoff_it>
It's great, with it, if you have a big comment, you don't have to manually groom it to make it look nice
<kristoff_it>
to be precise: you don't need to write a single line, you can also use `gq` to reflow an existing multiline comment
LargeEpsilon_ has quit [Ping timeout: 272 seconds]
<euantor>
Interesting looking project there kristoff_it! I started a RESP3 library a while back but ran into some issues when dealing with maps and sets and I've not tried since
<kristoff_it>
euantor: thanks, I think I got that part mostly figured out. I just need to finish implementing all types, but what you can read in the README is there already.
<kristoff_it>
euantor: one thing that I really wanted to achieve with comptime is being able to resolve simple replies with no allocations, if you know what to expect from redis
<andrewrk>
haha I am so good at predicting when llvm will release
<euantor>
Yeah, I was taking a slightly different approach where I has a `Resp3Value` union
<euantor>
But zero allocation is very cool
<kristoff_it>
euantor: Yes I called that DynamicReply, it's at the bottom of the readme. It was a union until yesterday, now it's a struct because it also captures attributes
<andrewrk>
6 months ago I chose sept 30 as a guess of 1 week after llvm 9. they had planned for months to release 1 month earlier than that, but there's an email just now saying it's late, new release date for llvm 9 is in 2 weeks... leaving exactly 1 week until sept 30
<euantor>
kristoff_it: I should probably dig into comptime more...
<kristoff_it>
I love this type of metaprogramming :)
<euantor>
kristoff_it: Yep, I've added that to my list of things to read eventually :)
<daurnimator>
kristoff_it: I always found the redis protocol a bit weird. especially the different "modes"
<daurnimator>
there was always really poorly documented corners where the actual behaviour was difficult to model correctly, e.g. if you subscribe as part of a transaction, then the subscription only takes effect when you commit
<daurnimator>
==> so you have to know *which* commands start different modes, which commands start/finish transactions, and then match them all up at the relevant times
<kristoff_it>
daurnimator: yes, you're right the push type of communication was bolted on top of the old protocol. RESP3 removes all of that stuff
<kristoff_it>
no more modes, and the replies are more structured now, so you don't need to reason about the command to know how to shape the reply
<daurnimator>
mm k. I recall seeing a design doc for it but didn't really look too closely
<kristoff_it>
you might be interested in just reading the first part, where the rationale behind RESP3, and the breaking differences from RESP2 are explained
alexander92 has joined #zig
<shritesh>
donpdonp: I stumbled into your Zootdeck project looking for Zig LMDB bindings and it looks REALLY COOL!
<andrewrk>
yeah I'm impressed too. my jaw dropped when donpdonp came in here and learned about heap allocation stuff. I was thinking, "how did you do this amazing thing without even knowing that??"
<donpdonp>
hey thx guys.
<donpdonp>
i wouldnt say im proud of the zig in zootdeck (especially those 50line methods), but its been a fun/educational journey.
<donpdonp>
the heap stuff was more hey how does this work in zig, but i can come across as "whats a heap?" :)
<donpdonp>
shritesh: lmdb is incredible. what are you using it for?
laaron has quit [Remote host closed the connection]
<fengb>
Anyone else think that that it's weird the memory heap isn't really a heap data structure?
<andrewrk>
wow. I learned about "the heap" before I learned about heap data structures, and I never made that connection
<andrewrk>
are you sure it's not though? maybe in the kernel it is?
<fengb>
I think it was originally but most modern implementations aren't heaps
<fengb>
At least not solely heaps
laaron has joined #zig
marler8997_1 has quit [Read error: Connection reset by peer]
shritesh_ has joined #zig
kristoff_it has quit [Ping timeout: 272 seconds]
<shritesh_>
donpdonp: I'm not using it yet but we are looking to build a fast disk persistence solution for Erlang at NashFP. RocksDB has been suggested and I'm not a fan.
<Snektron>
I've ran into a problem while improving arm32 support: The kernel on my raspberry pi doesnt expose mmap, but rather mmap2. The man pages of mmap2 state that this variant can be used when off_t is 32 bits, yet off_t is 64 bits on my raspberry pi?
tgschultz has quit [Read error: Connection reset by peer]
<samtebbs>
Snektron: Which raspi do you have?
tgschultz has joined #zig
<Snektron>
B+, the old one, so its proper 32-bit arm if thats what you're wondering
<Snektron>
(armv6)
avoidr has joined #zig
samtebbs has quit [Quit: leaving]
<andrewrk>
Snektron, there is a pattern you can follow in the std lib to solve this
<andrewrk>
Snektron, look for @hasDecl in std/os/linux.zig, for example in the pipe function
<Snektron>
andrewrk: since the old mmap requires the offset to be i on a page boundary anyway (and mmap2 takes the offset in number of pages), i think mmap can safely be implemented in terms of mmap2
<Snektron>
yet im confused of which type of parameter i actually should pass, considering the documentation
<Snektron>
im fairly convices that it should be a u32/usize, yet does that mean off_t is incorrectly defined to be a long long, or is the documentation simply wrong?
<andrewrk>
Snektron, on linux, long long corresponds to u64
<andrewrk>
sorry, i64
shritesh_ has quit [Quit: Leaving...]
<andrewrk>
I'd need to double check the calling conventions, but I believe for 32 bit linux, i64 is passed in 2 registers
<andrewrk>
we probably need to check the linux kernel source of the syscall, to find out the type it's expecting. we need to know the ABI
<Snektron>
andewrk: The problem is that i doubt mmap2 actually takes a 64 bit int on 32 bit linux, considering the implied usage of mmap2 and the fact that there arent enough registers to pass an i64
<andrewrk>
one thing to consider is that the man page is for libc, not necessarily the raw syscall
<andrewrk>
oh, have you looked at musl source code for this target?
<andrewrk>
I'm looking now, and I think it answers your questions
<andrewrk>
src/mman/mmap.c
<andrewrk>
I believe the reason that offset is 64 bits even on 32 bit linux is because mmap can be used for file descriptors. you can e.g. have a 6 GiB file on a 32 bit system
<Snektron>
looks like i was indeed confusing libc and syscall prototypes
<alexander92>
this seems as a common gotcha with 32bit api-s
<Snektron>
yes, the whole syscall convention is a fiasco too
<alexander92>
i've seen it with int32 stream indicies
<Snektron>
what with the aligning of 64-it parameters to pairs of registers
<alexander92>
no, i mean the "something must be 64 bits sometimes even on 32bit sys"
<alexander92>
are there any zig TUI libs btw
<andrewrk>
not that I'm aware of
<andrewrk>
other than C libraries
<alexander92>
i wondered about a simple zig project to get a feel for the lang
<alexander92>
my other ideas were a simple gc or a copy of stuff like `ls`
<Tetralux>
I use 'which' for that.
<andrewrk>
a .tar.gz extractor would be very welcome
<alexander92>
something that reuses zlib?
<fengb>
No, we'll need something written in zig
<andrewrk>
I'll probably make all the C compatibility stuff an "optional extension" in the zig language specification
<andrewrk>
I could see there being a third-party fully self hosted compiler that didn't use llvm and didn't have translate-c or c compilation capabilities
<alexander92>
i'll think about it, i maybe prefer something i can port to rust/nim to be able to compare those (my goal is to get a better grip of rust/zig/ocaml this year)
<fengb>
Which one of those is not like the other? :P
<andrewrk>
marler8997, unless you're in the middle of it, I'll merge your PR #3119 into a local branch and fix the issues
<gonz_>
alexander92: What made you choose this lineup of languages? (Just curious, I have no agenda.)
<alexander92>
well, rust and zig are lower level system languages which i am mostly interested in currently
<alexander92>
(and i already have a bit more xp with c/c++/nim)
<gonz_>
OCaml is a very well put together language and learning it is not a lot of work because of the size of it.
<alexander92>
and ocaml : i want to use a strong FP language for some lang experiments, but haskell seems .. too much over there, ocaml seems very pragmatic, but still powerful (and very popular in those circles )
<gonz_>
The pragmatism bit I don't quite agree with; Haskell is much better off for industry in many ways, but OCaml is still a very good language.
<Tetralux>
I'm guessing an error that doesn't tell me where in my source code the problem is...
<Tetralux>
The new auto hash stuff.
<Tetralux>
"autoHash does not allow slices"
<gonz_>
alexander92: I would suggest looking at / learning OCaml regardless of which other language you choose to learn as well. It's not a very meaty task, as I said, because it's so small. In many ways it's what I imagine zig could be, but for lower level things.
<alexander92>
well, that's my impression at least: that ocaml is simpler and mixes up paradigms/impure code in a simpler way, haskell libs out there .. it seems to me they just use 10 lang extensions(and ocaml also seems used in the industry)
<gonz_>
Haskell is more popular in industry. When I make the rounds I usually note that OCaml will reliably have one tenth as many positions up on boards.
<andrewrk>
Tetralux, the new compile error note tracing should show you
<alexander92>
also, not sure if laziness by default is great
<gonz_>
by the sounds of it I think maybe you should learn Haskell :D
<Tetralux>
andrewrk: It traces up to hash_map.zig:540, and nothing above that.
<Tetralux>
It shows L540 -> L542 -> auto_hash.zig:169.
<alexander92>
gonz_, this might be true, but still some big companies use it: jane street, facebook (reason) etc: but in any way i am mostly interested in the lang, not so much in jobs with it rn
laaron has quit [Remote host closed the connection]
<Tetralux>
But none of my source code.
<Tetralux>
(It's used from a test{} block)
wilsonk_ has quit [Read error: Connection reset by peer]
<Tetralux>
It's also not entirely clear to me what transform I have to do to make it work again.
wilsonk has joined #zig
<gonz_>
alexander92: In any case, I think you can probably fit learning both zig and OCaml in into the same time block you'd spend learning one more complicated language.
* Tetralux
resigns himself to the fact that he's gonna have to bring up hash_map.zig...
<andrewrk>
Tetralux, whats your code? I'm surprised about the lack of compile error note trace
laaron has joined #zig
<andrewrk>
std.AutoHashMap([]const u8, T) ?
<Tetralux>
Yup.
<Tetralux>
In this case, T = i32.
<alexander92>
gonz_: that's true (i guess there is no #zig-offtopic ? :P i am sorry), in any way, i think i'll start with reinventing simple bash commands in zig
<andrewrk>
Tetralux, I see it, give me a sec to look into this trace thing
<andrewrk>
I reproduced it
<Tetralux>
Excellent.
<companion_cube>
alexander92: OCaml is neat, but the tooling/ecosystem might seem a bit rough at first. I can answer questions if need be :)
<andrewrk>
that's a nice error message. I think it can be further improved by mentioning StringHashMap
<companion_cube>
(we use it in our startup)
<fengb>
You should use zig!
<alexander92>
companion_cube: thanks. i'll keep it in mind: i'd probably mostly write stuff that ocaml has good ecosystem for
<companion_cube>
tbh the sweet spot is compilers and other AST manipulating stuff
<companion_cube>
(and for that it's brilliant)
<Sahnvour>
Tetralux: the error message gives pointer on what to do when this error occurs, ie. use `std.auto_hash.hash` or a custom function
<Tetralux>
Sahnvour: It tells me to use std.auto_hash.hash, but I have no idea what that is... I'm guessing that it's the function to pass to HashMap as the hasher function, in which case, knowing the order of args to HashMap would be nice, and knowing that it's a compatible function would be nice.
jzck has joined #zig
<alexander92>
companion_cube: exactly, thats what i want to use it for
<Tetralux>
I'm also not gonna wanna do that if it's no obvious to me how to get an equality function for most stuff.
<Tetralux>
Like i32, for example.
<Tetralux>
The point is, I want to get my stuff working. If I have to dig through docs to figure out how to use the thing, _it_ failed.
<Tetralux>
I might expect to have to do that for a major version change, but even then - I'd look down on a language that doesn't give you simple guidance like that.
<Sahnvour>
well you're certainly aware zig is not release-quality yet
* Tetralux
smiles.
<Tetralux>
Bit of a cop-out, but I know what you mean. :xD
<Tetralux>
Hence only a "bit."
<Sahnvour>
I'll use your suggestion on the error message nonetheless, it's true it can be improved
<Tetralux>
Thank you.
<alexander92>
Tetralux: *sometimes* this is not good: e.g. if one uses a completely unknown to him paradigm for the first time
<Sahnvour>
note that the API for hashing and hashmaps may not be final, so it's maybe not worth having a really extensive guidance about this kind of error for now, I don't know
<alexander92>
you can't just teach it to him with error msg-s (e.g. async or multithreading)
<alexander92>
but otherwise i agree, error messages should educate
<Tetralux>
Even in those cases, you'd be surprised.
<Tetralux>
But yeah - there's only so far you can go.
meheleventyone has joined #zig
<Sahnvour>
anyways, yeah just use StringHashMap instead and you're good to go
<Tetralux>
Sahnvour: Maybe THAT's what the error should say... ;)
<Tetralux>
.. since you know that the user is doing AutoHashMap([]const u8, T)
<Sahnvour>
I'm considering it right now, that's common enough to justify it
<Tetralux>
I certainly would.
<Snektron>
Thread-local storage on arm in the musl implementation is some dark magic if i've ever seen some
<andrewrk>
Snektron, yep. thread local variables are not free
<Sahnvour>
andrewrk: mind if I change your snippet a bit and propose a PR ?
<Sahnvour>
no actually it's ok I have nothing to add
<andrewrk>
go for it
<Sahnvour>
except maybe the advice about StringHashMap should be in AutoHashMap directly ?
<andrewrk>
whatever you think is best, go for it. I'm trying to solve the error trace not showing up
THFKA4 has joined #zig
alexander92 has quit [Ping timeout: 245 seconds]
<Sahnvour>
okay
<andrewrk>
nice, LLD merged LemonBoy's PR to fix the problem with macos
<andrewrk>
this means we can drop the only patch on top of LLD that we have
<Snektron>
andrewrk: i'd rather say this is a punishment than 'not free'
<Snektron>
also, i was wondering if the prototype for clone is correct, since on the x86 version flags is an usize but on aarch64 (and in musl) its a int
<andrewrk>
int and usize have the same ABI - it's just a register
ofelas has joined #zig
<mikdusan>
andrewrk: i have op1, building op2 with `ir_build_struct_field_ptr()` and then ir_build_bin_op; op2 (i think) causes zig_unreachable in codegen `ir_render_instruction()`; any hints?
<mikdusan>
also happens if op1 or op2 is instruction from `ir_build_const_usize()`
<mikdusan>
i think i'm doing something really dumb. like building an unrenderable insn in wrong context. hmm... maybe i have to put it into a stack var? something like that.
<andrewrk>
mikdusan, ohhh, ok some of these instructions are meant only for zig ir, meant never to get to codegen
<andrewrk>
mikdusan, have a look at the comments in all_types.hpp:2286, above enum IrInstructionId
<mikdusan>
thanks i think i can make progress again
<andrewrk>
try using ir_const() instead of ir_build_const_usize
<andrewrk>
and then set the type and the x_bigint
<andrewrk>
there are a bunch of places that would benefit from ir_const_usize()
Akuli has joined #zig
<andrewrk>
well maybe. I actually don't see any right now
<mikdusan>
i initially had a scalar for comptime slice bounds checking. then i tried to build IR for the const value. then my brain started working and told me I *already* had the IrInstruction, that's how I got the scalar in the first place. I need more practice with this stuff :)
<andrewrk>
it's admittedly a bit convoluted. zig's analysis started off as directly emitting code from an AST
<andrewrk>
the assumptions of the code have been yanked out from underneath it countless times
<andrewrk>
the meaning of various IrInstructions have changed in subtle ways... it's all part of the path to figuring out how things will eventually work
GiovaniAbel has joined #zig
<GiovaniAbel>
Hello ziggers!
<Tetralux>
Greetings, Human.
<fengb>
... that looks terrible
<andrewrk>
GiovaniAbel, we're Ziguanas
<andrewrk>
true fact
<GiovaniAbel>
I must agree
<fengb>
Can I be a ziggy?
<andrewrk>
can the ziguana's name be ziggy?
<Tetralux>
Only if their name isn't Ziguana.
SimonNaa has quit [Remote host closed the connection]
<andrewrk>
ok I only have to crush 6 more people's dreams today by postponing issues until 0.6.0 and then I can work on more async/await proof of concept stuff
<gonz_>
I imagine you saying this with glee
<Tetralux>
I am... Unsettled.
<GiovaniAbel>
I wasn't expecting so much moviment over here, just found about this language... Really loved the concept of it!
<andrewrk>
give it a shot! report bugs & feel free to contribute to the std lib
<GiovaniAbel>
I've been working with java for 2 years now, I really want to move to something closer to C. But I don't think I have the knowledge to contribute, yet...
<Snektron>
I've compared implementations of setting the tls thread pointer of musl and glibc
<GiovaniAbel>
I've tried to compile your tetris project, something is wrong when linking with glfw.
<andrewrk>
Snektron, the #musl chat room is friendly and helpful, if you wanted to get some more insight there
<Snektron>
So for now i'll just leave it at just the syscall, unless i can somehow find documentation of the dark magic
<Snektron>
andrewrk: sure, good idea
<andrewrk>
GiovaniAbel, what operating system are you on?
<GiovaniAbel>
Debian 10
<andrewrk>
can I see the output?
SimonNa has joined #zig
kristoff_it has joined #zig
porky11 has joined #zig
<GiovaniAbel>
Guess it was something with my path, now I have a different error about epoxy.
<GiovaniAbel>
Will try to fix the problems with the dependencies, if I get another erro I'll send here.
<GiovaniAbel>
Just a sec
<GiovaniAbel>
lld: error: unable to find library -lglfw
<GiovaniAbel>
lld: error: unable to find library -lepoxy
<GiovaniAbel>
Is there a better way to send big text over here?
<Tetralux>
We usually use our pastebin-like of choice.
<GiovaniAbel>
Oh right, will find somethig, guess gist will do it.
<Tetralux>
That'll do fine.
<andrewrk>
GiovaniAbel, it looks like you need to install libglfw-dev and libepoxy-dev debian packages
<andrewrk>
we don't have the zig package manager yet, so these are system dependencies
laaron has quit [Remote host closed the connection]
<GiovaniAbel>
It works!
<GiovaniAbel>
Thx
<andrewrk>
things are going to be very different from java, but I think it's quite fun to be in (more) direct control of the hardware :)
laaron has joined #zig
<GiovaniAbel>
Yeah, I've been playing with a lot of new technologies theses days.
<GiovaniAbel>
I've learned a little about Rust and Go.
<GiovaniAbel>
Rust have so many simbols doing magic tricks in my code
<GiovaniAbel>
That confuses me a lot
<GiovaniAbel>
Go I really love the syntax, but I want to learn game dev, it's an amazing language to do the server side, but the client... not gonna work so good.
<GiovaniAbel>
Sorry for my bad english, I'm from Brazil :P
<Tetralux>
I don't like Rust's symbols either.
<gonz_>
You're doing fine, don't worry about it. :)
<companion_cube>
what symbols? :-°
DutchGh0st has joined #zig
BigEpsilon has quit [Ping timeout: 245 seconds]
<fengb>
<>!#*&@
<fengb>
Looks like I got angry with the terminal :P
<GiovaniAbel>
Yeah hahahaha
<companion_cube>
I mean, only & is really indispensable? and :: for namespacing, which seems pretty reasonable
<DutchGh0st>
Im not sure if I can help fix it somehow? Im not familiar with how its compiled and where this safety check lives
<Tetralux>
I don't like Rust's symbols either.
<Tetralux>
Whoops - wrong window XD
<DutchGh0st>
you mean the ::<>{} things Tetralux? ;p
<Tetralux>
YES I DO
* Tetralux
grins
<DutchGh0st>
I love em
<Tetralux>
I did that thing again where I tab to my console to run a command, pressed UP+Enter, and of it goes to this window randomly instead xD
<Snektron>
andrewrk: seems musl defines an arm v7a and v7r architecture, yet i cant find those in Zig's architectures. Do you know how those relate to the Zig ones?
<andrewrk>
Snektron, I'm not sure, but it's the same question as how they relate to clang, or rust, or LLVM
<companion_cube>
::<> is not something you need everyday, come on ^^
<DutchGh0st>
I dont know. `Something::new` vs `Something.init`, the `::` keeps it all nice aligned together
<DutchGh0st>
while with the `.` its like...its high, its high, its low (the dot), and the we go high again
<andrewrk>
Snektron, oh I think I know what it means. the 'a' or 'r' is describing what target features are available. in this case atomic instructions
<Snektron>
Right, so i guess we can't do that right now
Ichorio has joined #zig
marler8997_1 has joined #zig
<marler8997_1>
andrewrk: hey when will you get a chance to look at https://github.com/ziglang/zig/pull/3119 ? It looks like recent changes have caused the issue to spread into other places into the code. I just don't want to keep re-working the change. If you can let me know when a good time is to work on it I'll re-work it to work with the code then
nairou has quit [Remote host closed the connection]
DutchGh0st has quit [Remote host closed the connection]
FireFox317 has joined #zig
<FireFox317>
marler8997: This is what andrew said today, maybe you didnt see it: > unless you're in the middle of it, I'll merge your PR #3119 into a local branch and fix the issues
<marler8997_1>
I didn't see it
<marler8997_1>
yes please feel free to merge it with another branch and fix the issues...I just want the issue fixed :)
shritesh has quit [Quit: shritesh]
Akuli has quit [Quit: Leaving]
<FireFox317>
Should bitshifting only work with integers on the right side i.e. const x = 1 << (some_int) or should it be possible to pass in different types on the right side of '<<'?
<Tetralux>
What other types would make sense?
<FireFox317>
I dunno, but I don't think any other type makes sense. Right now the compiler crashes when you for example use a pointer as the shift amount.
<Tetralux>
Oh yeah. Bug alright xD
<torque>
shouldn't it actually specifically be an unsigned integer
<Tetralux>
Depends on if you want people to have to write an if it could shift either way.
<Tetralux>
s/an if/and if, if it could
<torque>
actually I never considered how c interprets a negative right hand side shift parameter
<Tetralux>
Does that matter?
<Tetralux>
Oh nvm
<Tetralux>
Ignore me x)
<torque>
well, yes, because you have distinct right and left shift operators
<FireFox317>
Yeah there is already a issue that tracks this: #2933
<Tetralux>
I don't see why that makes a difference.
<Tetralux>
It's obvious what negative shift should do, no?
<FireFox317>
Jup torque, you are right, its not allowed to shift using a negative number
<FireFox317>
so it can be signed, but just not negative
<FireFox317>
That check is already in the compiler
<torque>
yeah, that makes sense to me
<Tetralux>
Yeah, that works.
<Tetralux>
Q: What's the best way to debug a stack overflow in Zig?
<Tetralux>
Printf debugging?
<torque>
I agree that it could be valid to have negative shift semantics but it would probably very unituitive. typically you don't want to shift signed numbers anyway since you'll shift the sign bit off
<fengb>
C spec preserves sign
<torque>
interesting
<fengb>
I believe zig does too
<torque>
that makes sense
<fengb>
I remember expecting it to shift in a 0 but it didn't
<Tetralux>
I'm not sure why it would be unintuitive. I kinda think that not shifting out the sign bit is more so xD
<torque>
well, I apparently should read up more on how C handles weird shifting edge cases before I continue flapping my gums
<halosghost>
right-shift on a signed integer is implementation-defined behavior for preservation of the sign bit iirc
<GiovaniAbel>
I shouldn't have a problems using Plugged right?
<FireFox317>
Sorry, I don't know what Plugged is
<GiovaniAbel>
I mean, vim-plug
<GiovaniAbel>
plugged is the name of the dir
<halosghost>
torque, fengb: ISO/IEC 9899:2011, §6.5.7 ¶5, “If [the left operand of >>] has a signed type and a negative value, the resulting value is implementation-defined”
<andrewrk>
std.math.shl supports negative shift
<halosghost>
s/“/“… /
<Tetralux>
Is positive shift the fast path?
<andrewrk>
Tetralux, a debugger makes debugging a stack overflow pretty trivial
<andrewrk>
you can see all the frames
* Tetralux
grins
<Tetralux>
Beat you to it ;p
<Tetralux>
I really shouldn't bother trying to use gdb on windows
<Tetralux>
It does nothing.
<Sahnvour>
on non-windows, can you build zig in debug but link it to llvm built in release mode ?
<andrewrk>
Sahnvour, I was unable to figure out how to do that. if you figure it out please tell me how
<Sahnvour>
Tetralux: use winDBG preview or VS
<Sahnvour>
it's on my list but the use of msvc's stdlib (iterator debugging thingy) makes it hard, just curious if it's easier on linux or whatever
<Tetralux>
I think I do that. I have a release copy of LLVM binaries which I use when I build Zig.
<Sahnvour>
so painfully slow to link against debug llvm
<Tetralux>
I've not built LLVM once for Zig.
<andrewrk>
Sahnvour, oh! sorry I misunderstood your question. Yeah on non-windows every combination works
<FireFox317>
andrewrk: I'm adding a compile error and i would like to point to the shift amount. However that also generates a note with referenced here. I can also just point the error at the '<<' symbol, which doesn't generates the 'referenced here'
<Sahnvour>
I should probably rebuild my whole stack with clang-cl :)
<Tetralux>
I'm not sure what the "referenced here" part actually shows you.
<Tetralux>
Looks redundant to me.
ntgg has joined #zig
<FireFox317>
It's missing the arrow (^), but is points to '<<' in the 'referenced here' note
<Tetralux>
I'd only print the line that points at 'x', but the next best thing is the second one since the 'referenced here' doesn't point to anything.
<FireFox317>
Well the problem is that the 'referenced here' note is automatiicaly added since the lazy value PR thing
<Tetralux>
I guess you'd better do the first one then, since the expression on the RHS could be arbitrary...
<Tetralux>
Ugh.
<FireFox317>
But there's not really a point in discussing i think, i'm just going for the simpler one
<FireFox317>
Jup true
<Tetralux>
I suggest you mark it with a TODO as to what the better thing is.
<andrewrk>
FireFox317, I think the "referenced here" can be addressed separately. I'd make it point at the shift amount
<Tetralux>
s/TODO as to what/TODO that says what
<FireFox317>
andrewrk: Okay!
<GiovaniAbel>
When I include clibs, do I need to pass additional parameters to zig compiler?
<andrewrk>
marler8997, yeah, I'll take it from here. Thanks for the patch and the nice regression test case
<Tetralux>
You can then build the project with `zig build`
<Tetralux>
In that example, you can do `zig build play` to have it run the game after compilation.
<ciarand>
hey friends! I want to parse an IDL string (think protobuf schema or AIDL file or even regexp pattern) into a zig struct at comptime, but I can't figure out how to vary a struct's fields in a dynamic way. Is there a fancy builtin or some other usage pattern that I'm missing?
<ciarand>
Thanks Andrew! A little bit of a bummer, nice to see it's planned though
<ciarand>
is there an easy way to add the dependency / generation rules to a build.zig file?
<andrewrk>
ciarand, note that it's not planned - just being considered. there is an "accepted" label for proposals that are planned
<ciarand>
oh got it
<andrewrk>
ciarand, let me see if I can find an example for you. Assuming your code is in zig and you're producing .zig code, you'll use foo = addExecutable() and then foo.run(). and then declare a dependency on the generated file, for the build artifact that will import it
<ciarand>
ok cool, that's probably enough for me to go off
<andrewrk>
note that this whole thing is declarative
<ciarand>
nice, that's easy enough
<andrewrk>
so your users will be able to do `zig build --help` to see options and what build steps are available
<andrewrk>
and eventually other kinds of introspection / combination with other build systems
porky11 has quit [Quit: Leaving]
<Snektron>
Great, my "hello world" works on my rpi
<Snektron>
with --single-threaded, that is
<Snektron>
andrewrk: why is tls initialization needed with a single threaded build?
<Tetralux>
threadlocal globals are non-threadlocal in single-threaded
<Tetralux>
And creating a thread is illegal with single-threaded.
<Tetralux>
And so TLS is disabled.
<Tetralux>
I believe that's how that works.
<Snektron>
apparently not, since i had to fix a function related to TLS when compiling single threaded
<Snektron>
std/special/start.zig does not appear to have a special case to deal with it (in posixCallMainAndExit)
<Snektron>
Im not sure how that should be handled anyway, tbh i have no idea how TLS actually works
<Tetralux>
TLS basically stores an array, one element for each thread, and when you deref a pointer to it, the pointer is patched with an offset to the appropriate slot in the array.
<Tetralux>
I believe that's loosely how it works on *nix anyway.
<Tetralux>
You have to ask the kernel about it on startup if you use it.
<Snektron>
The kernel does the patching i guess?
<Snektron>
i see the difference in godbolt yes, i think the TLS initialization might just be skipped but im not entirely sure about that
<Snektron>
might be skipped if the program is single threaded, that is
<andrewrk>
Snektron, I believe that errno on some libcs requires TLS and it's the same libc regardless of --single-threaded
<andrewrk>
just that one stupid errno holding everything back
laaron has quit [Remote host closed the connection]
<andrewrk>
uhh maybe glibc was what I was thinking of
<andrewrk>
now I'm struggling to remember, because when we link libc, that startup code is not executed
<andrewrk>
maybe it's worth it to disable TLS for --single-threaded and see what breaks, and then if it has to get reverted, it can get a helpful comment this time