<andrewrk>
I'm starting to think there might be some nondetermisistic behavior here
stripedpajamas has joined #zig
<Snektron>
I still do a double take every time i see robin-hood-hashinh
<andrewrk>
josh pointed out to me that it might be better to put the max_distance_from_start in the indexes array
<Snektron>
(cause its my name)
<andrewrk>
oh haha
knebulae has quit [Read error: Connection reset by peer]
stripedpajamas has quit [Quit: sleeping...]
<shakesoda>
oh is hashmap being optimized
<shakesoda>
we switched to robin hood hashing in soundself a while back (slightly before release), fixed various performance problems
<shakesoda>
no idea what the state of the art for a good hashmap is but i was very happy with that move
stripedpajamas has joined #zig
knebulae has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
<fengb>
andrewrk: should I switch my donation to ZSF instead?
<andrewrk>
hmm I guess the cat is out of the bag
<andrewrk>
doesn't hurt anything, but maybe wait until the 11th ;)
aerona has quit [Quit: Leaving]
lunamn has quit [Ping timeout: 256 seconds]
linuxgemini has quit [Ping timeout: 260 seconds]
ur5us has quit [Ping timeout: 256 seconds]
stripedpajamas has quit [Quit: sleeping...]
marnix has joined #zig
B4s1l3 has quit [Quit: Konversation terminated!]
_Vi has joined #zig
r0bby has joined #zig
<marnix>
Did anyone try to do Python-style generators in Zig? Seems perfectly possible using suspend and resume, but a working implementation with a simple API eludes me at the moment... (Can perhaps post a gist of an attempt later, not today probably.)
<daurnimator>
yes
<daurnimator>
there's a few around
<daurnimator>
they're... imperfect
dermetfan has joined #zig
_Vi has quit [Ping timeout: 240 seconds]
<lemmi>
ifreund: just watched the swiss map video. i'm wondering if this might still be fast even without simd
dermetfan has quit [Ping timeout: 256 seconds]
<marnix>
@daurnimator Any links, perhaps?
antaoiseach has joined #zig
dddddd has joined #zig
<antaoiseach>
Hello good folks, I know that there is no official dependency manager for Zig yet, but suppose I wanted to include another zig project in a new project, aside from building a library and linking against it, is there a way to include the project directly? Or is there a preferred way of going about including dependencies? Is there a plan for a central repository of libraries like crates.io?
<ikskuh>
antaoiseach: right now, there's no package manager and the usual way is to either include repositories as source or as a submodule in your code base
<ifreund>
an official centralized package repo isn't planed, but it's very likely that several unofficial ones will arise after the advent of the package manager
<antaoiseach>
ikskuh: Hmmm... sort of what I expected. Thank you! Just curious - including the project directly will still use the same licensing terms etc., right? I mean, that aspect shouldn't be any different from using a binary of the project?
<antaoiseach>
Hmmmm
<ikskuh>
it depends
<ikskuh>
but you cannot include zig libraries as binaries
<ikskuh>
zig is always compiled from source
<antaoiseach>
I mean support project "calculator" is compiled as libcalc.a and then I link to it, that is fine, right? It's only zig itself which should be built from source if it were to be used in another project? Or did I get that wrong"?
<antaoiseach>
suppose*
<ikskuh>
if it's a zig library/package, you won't have a "libcalc.a", only "libcalc.zig"
<ifreund>
you can compile zig code to a dynamic library with C ABI and link dynamically against
<ikskuh>
for native dependencies like C projects you wil have a libcalc.a
<ifreund>
this is not the standard way to do things though
<antaoiseach>
ifreund: yes, that's what I meant ... as a native lib
<daurnimator>
antaoiseach: use a git submodule
<antaoiseach>
daurnimator: Okay, I could try that out and see ...
<antaoiseach>
Again, not too familiar with licensing restrictions ... suppose the linked project is failing, and I use an updated version of it (as source) in my project ... would that be a potential breach of licensing?
<antaoiseach>
(Maybe not)
<ikskuh>
it really depends on the licence
<antaoiseach>
ikskuh: that makes sense...
<antaoiseach>
Okay, thanks, ikskuh ifreund daurnimator - I'll try out some experiments and also check the licences of the dependencies I have in mind! Thank you for the help! :-)
antaoiseach has quit [Quit: leaving]
<ifreund>
lemmi: yeah I watched it too and they look quite promising. I think I'm going to go ahead with a zig implementation and try to copy some benchmarks
<lemmi>
ifreund: i also tempted to just naively write one for shits and giggles
<ifreund>
do it, we can have a hashtable-benchmark-off
<ifreund>
I haven't had a chance to use zig's simd stuff for real yet, so I'm curious how that will work out
<lemmi>
if time permits, yep
<alexnask>
ifreund, Caved in and implemented utf16 offsets for zls :P kak should still be fine though, I support the clangd extension for utf-8 offsets as well
<ifreund>
suppose that's necessary for vscode?
<alexnask>
Yeah I wanted muh pretty semantic tokens
<ifreund>
thanks for implementing the extension <3
<alexnask>
And also correct completions on lines with non ascii chars
nikita_ is now known as nikita
nikita is now known as Guest25669
dermetfan has joined #zig
<alexnask>
I think you have to add offset_encoding = "utf-8" to language.zig and offsetEncoding = ["utf-8"] to language.zig.initialization_options though
<alexnask>
Not sure, I will investigate soon (should work out of the box with utf16 offsets anyway but utf8 offsets are jsut more efficient)
discipulus has joined #zig
<alexnask>
andrewrk, Fixed the formatting btw (it was inconsistent because I was sending the result then immediately a null result because of a missed return >.>)
<ikskuh>
heya
<alexnask>
o/
<ikskuh>
is there a way to read "available" data from stdin?
<alexnask>
Can you seek stdin?
<ikskuh>
no
<ikskuh>
it's usually a pipe
craigo has joined #zig
<ifreund>
I think you can open the file with O_NONBLOCK and read until you get EAGAIN
<ifreund>
this is assuming you're on linux
<ikskuh>
not sure, afaik the "file" is already open
ur5us has joined #zig
<ifreund>
well, you could probably use fcntl then
Mulugruntz has joined #zig
<ifreund>
looks like you should use SETFL not SETFD though as stdin/stdout/stderr usually share the same fd
doublex has quit [Read error: Connection reset by peer]
doublex has joined #zig
VojtechStep has joined #zig
alexnask has quit [Quit: Leaving]
shcv has quit [Remote host closed the connection]
samtebbs has quit [Ping timeout: 246 seconds]
josias has joined #zig
<josias>
When compiling from master, I get "undefined reference to `getPollyPluginInfo()'". I am using g++ and the error occurs at "Linking CXX executable zig0".
<scientes>
Debian 10 in chroot in Termux in Android 5.1 on an ARM tablet.
<scientes>
can you try on a more recent android?
<scientes>
cause IIRC they changed a bunch of C stuff at some point
<josias>
I don't have access to such a device at the moment unfortunately.
<scientes>
what kernel version?
<josias>
uname -r says 3.18.19
<scientes>
josias, also can you you use follow-child-mode
<scientes>
strace -f
layneson has quit [Ping timeout: 256 seconds]
<josias>
That doesn't change the output.
<scientes>
anyways you should put android in the topic
<scientes>
and ancient kernel
<scientes>
*old
<ifreund>
thanks for opening the issue
<josias>
Updated the issue.
<scientes>
it could be that android only supports PIE executables
<scientes>
but that might just be bionic
<scientes>
anyways, no idea
samtebbs has quit [Ping timeout: 246 seconds]
<josias>
A quick search says that PIEs have been supported from Android 4.1.
<scientes>
bionic ONLY executes PIEs
<scientes>
but you are running a chroot so that changes a bunch of stuff
<scientes>
you are running glibc
<josias>
Yes.
<ifreund>
oats: by the way, std.cstr is a thing
<scientes>
anyways I had been fine running statically-linked non-PIE zig executables on android
<scientes>
in order to test stuff
blinghound has joined #zig
<blinghound>
is there a clean way of adding a signed int that could be positive or negative to an unsigned int if I know the unsigned int won't underflow/overflow?
<fengb>
@bitCast one to the other
<scientes>
you have to sext the signed number
<scientes>
with @as()
<scientes>
and then @intCast() it back
<scientes>
after the add
<blinghound>
hmm, I want to be able to do something like 'var unum: u64 = 69; var snum: i8 = -10; unum += snum;'
<blinghound>
so can I just bitCast the signed int?
<ikskuh>
nah, that won't work
<scientes>
so you add a sign bit to unum
<ikskuh>
you need to sign-extend first
<scientes>
@as(i65, unum)
<ikskuh>
@bitCast(u64, @as(i64, snum))
<scientes>
no, i65
<scientes>
@intCast(u64, @as(i65, unum) + snum)
<ikskuh>
oh, right
<blinghound>
ohh I seee
<ikskuh>
forgot that unsigned overflow is undefined :D
<blinghound>
I think I'll wrap that into an inline generic function
blinghound has quit [Remote host closed the connection]
wootehfoot has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
dddddd has quit [Ping timeout: 256 seconds]
josias has quit [Quit: Quit]
josias has joined #zig
<ifreund>
scientes: vectors are starting to make sense to me, holy shit this is so much better than C
<scientes>
ifreund, I said that at my talk and people really didn't want to believe me....
<scientes>
I was like "this is impossible in C"
<scientes>
and "C cannot be fixed"
<ifreund>
I think I will have to do a blog post or talk or something when I get this swiss tables impl working
<ifreund>
do some comparisons of the unreadable C++ code and the much shorter, more clear zig code
layneson has joined #zig
josias has quit [Remote host closed the connection]
josias has joined #zig
cole-h has joined #zig
riba has joined #zig
_Vi has quit [Ping timeout: 244 seconds]
a_chou has joined #zig
a_chou has quit [Remote host closed the connection]
a_chou has joined #zig
a_chou has quit [Client Quit]
dingenskirchen has quit [Quit: dingenskirchen]
layneson has quit [Ping timeout: 264 seconds]
decentpenguin has quit [Quit: decentpenguin]
dermetfan has quit [Ping timeout: 256 seconds]
dingenskirchen has joined #zig
<companion_cube>
grrr I forgot the name of the chan with a bunch of language designers
dddddd has joined #zig
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
dingenskirchen has quit [Client Quit]
dingenskirchen has joined #zig
dingenskirchen has quit [Client Quit]
dingenskirchen has joined #zig
cole-h has quit [Quit: Goodbye]
marnix has quit [Ping timeout: 264 seconds]
dingenskirchen has quit [Client Quit]
dermetfan has joined #zig
<ikskuh>
i have the strong feeling that @enumToInt is borked for exhaustive enums
<leeward>
"How do I use this" is not the kind of thing that should go out of date super fast. I'm not talking about comments in code.
<leeward>
I just want to know what argument to pass it, and I have to look at the source code? Not well documented.
<scientes>
the tests are usually the best documentation of that stuff
dermetfan has quit [Ping timeout: 244 seconds]
<leeward>
Yes, source code. I just want a freaking man page.
waleee-cl has joined #zig
dermetfan has joined #zig
<leeward>
man gcc gives me a complete list of options available for my target platform, along with all the valid target specification options.
wootehfoot has quit [Read error: Connection reset by peer]
dermetfan has quit [Quit: WeeChat 2.7.1]
dermetfan has joined #zig
swills has quit [Ping timeout: 246 seconds]
<pmwhite>
I have a value `t` of type `[*]const u8`. If `t[0] & 0x80 != 0`, then I want to interpret the first 8 bytes as a u64. I was testing with the array `[8]u8{0x80,0,0,...,0}`, and tried to use `var x = @ptrCast(*align(1) const u64, t)` to do the reinterpretation, but the value `x.*` is printing out as just 128, which means it is just using the first byte as the whole u64 value.
<fengb>
std.mem.readIntLittle
<fengb>
Or should it be big endian?
<pmwhite>
Oh, cool.
<pmwhite>
Big endian is the backward one, right
<pmwhite>
?
<leeward>
no, little endian is backwards
<pmwhite>
Do you know what @ptrCast is wrong? What's going on?
<leeward>
big endian is the one you probably don't have, unless you're on a weird architecture
ur5us has joined #zig
<pmwhite>
readIntBig was what worked.
<leeward>
Oh, the *data* was big endian.
a_chou has joined #zig
* leeward
is easily confused by liliputians.
ilmu has joined #zig
<pmwhite>
honestly, i'm lost with regards to endianness. I've heard all the facts at one time or another, but I think I need to get a refresher at some point.
a_chou has quit [Client Quit]
<leeward>
There are 2 common ways to interpret a value that's more than 1 byte long: The first byte can be the most significant, or the least significant. Networks (mostly) interpret the first byte as the most significant. Most computer architectures choose the opposite representation. There is much strife, and warring among the Lilliputians.
<leeward>
The only times it matters exactly how the bytes are swapped around are when you're debugging or writing ntoh[X].
<fengb>
Little endian has nice pointer semantics. Big endian matches human number conventions
<fengb>
And thanks to Intel, modern processors are mostly little endian
<leeward>
Big endian also has advantages when bytes are received one at a time (hence its use in networks)
r4pr0n has joined #zig
<fengb>
It used to be more varied but pure big endian kinda died off
<leeward>
Ugh, the way LLVM "supports" AVR is by calling GCC's linker.
<leeward>
I don't think this is a viable target for Zig. Even if I do get it working, it will require having GCC's ld installed.
<scientes>
it is very limited
<leeward>
Next week I'll have an msp430 dev kit here. We'll see if that works better. Looks like the LLVM backend uses gcc's assembler.
ur5us has quit [Quit: Leaving]
tariq has joined #zig
<tariq>
are there any guidelines on directory structure for a zig project? i have a src/ and test/ dir but I'm getting an error when I @import("../src/some
<tariq>
error: import of file outside package path: '../src/some_file.zig'
<andrewrk>
set `--main-pkg-path` to the parent that they share