<jwmerrill>
That seems to work out pretty well, but I think it means that the union will always take up enough space for the largest kind of Obj. I think the "Struct Inheritance" way lets different kinds of objects take up different amounts of space.
<fengb>
There’s a trick to do it without using up the space
<fengb>
By passing around just the pointer, it doesn’t take up any additional space
<fengb>
And it’s “safe” if you only access the active field
<jwmerrill>
That makes sense to me, but it means there's one more level of pointer indirection than there is in the C implementation
<fengb>
There’s a few C structs that do this natively. Sockets I think
<fengb>
The other way is to clone the fields
<fengb>
And make sure the fields corresponds to the “base” one-to-one
jwmerril1 has joined #zig
<fengb>
Oh I think you can do it this recommended way too
<fengb>
Just have to be defined as extern. Normal structs in Zig don’t have well defined memory
<jwmerril1>
That makes sense. So far I've used the same representation as in the zox project I linked above, but I might try switching to a structure that's more like the book using extern and see how it goes.
darithorn has quit [Remote host closed the connection]
<mikdusan>
companion_cube: what part is of interest, just the x86 code generator part?
<companion_cube>
yeah I think so
<GreaseMonkey>
alright, *finally* managed to convince it to use BufferedInStream without breaking, and it's now about the speed i was getting before i started hooking up the builtin bitstream stuff
<GreaseMonkey>
went from 907 lines down to 848 lines, so i've had some really productive commits there
xackus has joined #zig
xackus_ has quit [Ping timeout: 258 seconds]
dddddd has quit [Ping timeout: 250 seconds]
<GreaseMonkey>
...OK, how does a deflate decompressor written in Zig manage to use less RAM than GNU's implementation of "yes"?
<oats>
well, `yes` is yeeting bytes like a tree chipper
<mikdusan>
foobles: here's what I came up with for #1332 ; zig build test passes on local macos,linux:
darithorn has quit [Remote host closed the connection]
<daurnimator>
GreaseMonkey: I saw your deflate_ring.zig I think you reimplemented part of std.LinearFifo
<daurnimator>
mikdusan: no output
foobles has quit [Remote host closed the connection]
foobles has joined #zig
<mikdusan>
works for me. maybe you missed the `--` ? anyway only 2 files in entire repo with `eol=crlf` are: deps/SoftFloat-3e/COPYING.txt, deps/SoftFloat-3e/README.txt . are those same ones giving you issue?
<daurnimator>
mikdusan: oh whoops, I ran it from inside of my build/ dir
<daurnimator>
and yes; those are the two files giving me issues
<GreaseMonkey>
daurnimator: perhaps, but i do need a 32,768-entry sliding window for LZSS
<daurnimator>
GreaseMonkey: to me that sounds like a non-sequitur. could you elaborate?
<GreaseMonkey>
perhaps "ring" was the wrong word, its primary purpose is not to give a FIFO, but to allow one to either add bytes on the end, or copy a byte a certain number of steps from the end repeatedly
<daurnimator>
GreaseMonkey: isn't a sliding window a ring?
<foobles>
mikdusan why dont you use `ir_analyze_optional_payload_value` when they are runtime?
<GreaseMonkey>
in this case it is
<daurnimator>
well not really
<daurnimator>
GreaseMonkey: anyway; use std.LinearFifo :0
<daurnimator>
GreaseMonkey: I'm cloning your repo now. How do I test it?
<GreaseMonkey>
daurnimator: feed in a .gz file (a .tar.gz file will be fine) and see if it manages to get to the end without crashing or failing
<GreaseMonkey>
i know it'll need unit tests, i'll get around to that at some point
<GreaseMonkey>
...it'll also need some decent error codes instead of just spitting out error.Failed whenever it's unhappy
<mikdusan>
foobles: I ran into a strange bug that manifests with tests 2,4 here:
<GreaseMonkey>
zig build run path/to/your/whatever.gz
<mikdusan>
daurnimator: don't know why you're hitting that crlf issue. it's almost like when you do something, some special .txt overrides come in and that's creating a difference
<GreaseMonkey>
...taking a look at LinearFifo, my use case requires reading stuff from behind the read index
<GreaseMonkey>
i can create a LinearFifo just fine, but... yeah
<GreaseMonkey>
so, thanks for your suggestion, but it's not the right thing to use
<GreaseMonkey>
i technically *could* use it while messing with .rewind(), but that would mean taking a distance relative to the write index by basing it on the read index, and it needs a lot of kludging to get it into place
klltkr has quit [Ping timeout: 264 seconds]
<mikdusan>
daurnimator: fwiw, the i=crlf w=crlw mean what your index/workdir has for the files and that paste looks the same as my output
<daurnimator>
GreaseMonkey: PR sent with what I meant
<GreaseMonkey>
alright
<GreaseMonkey>
is there a standard on how to name things in Zig?
<GreaseMonkey>
from what i can see, variables are lower_snake_case, functions are lowerCamelCase, and types tend to be UpperCamelCase
<GreaseMonkey>
i've got some camels i need to attack with a snake
xackus has quit [Ping timeout: 256 seconds]
waleee-cl has quit [Quit: Connection closed for inactivity]
<daurnimator>
GreaseMonkey: I think you have a weird set of terminology here
<daurnimator>
GreaseMonkey: "in" the fifo here is "in" the window
<GreaseMonkey>
daurnimator: the way that i have it set up, the read index moves along as you grab bytes from the buffer. i only ever add bytes to the buffer once the read index has reached the write index. however, i refer to stuff which typically tends to be *earlier than* the read index.
<GreaseMonkey>
so basically: 00 * 01 02 03 |readindexgoeshere| 04 05 06 |writeindexgoeshere| <-- i can still read the byte marked by * and onwards
<GreaseMonkey>
or actually any byte in there as long as it's not more than 32KB ago
<daurnimator>
GreaseMonkey: ah okay; I confused what `*` and the read index is. Either way LinearFifo is the right choice :)
<daurnimator>
I'll fix the PR
<GreaseMonkey>
have you attempted to run the program
<daurnimator>
yeah. but only on a small archive.
<daurnimator>
so I probably never went over either limit
<GreaseMonkey>
it'd have to be preeeeetty small to not be able to screw up there
<GreaseMonkey>
to be blunt, i'd wager that every single call to copyPastBytes is going to read behind the read index
<foobles>
mikdusan are you going to submit your PR?
<StateOff>
Does anyone have a good sample for fmt usage?
<StateOff>
never mind. bufPrint is what I needed.
<pixelherodev>
andrewrk, would you prefer if I didn't tag my backported repo with e.g. 0.6.1 to avoid giving the impression of official releases?
<daurnimator>
pixelherodev: my first question is: when/why do you tag?
<daurnimator>
time based?
<pixelherodev>
Yeah
<pixelherodev>
And mostly because it makes it easier to maintain
<pixelherodev>
If I version it weekly, and then I make a mistake, I can reset to the latest tag and then have less than a week's worth of commits to deal with
_whitelogger has joined #zig
guan has quit [*.net *.split]
backwhack has quit [*.net *.split]
alva has quit [*.net *.split]
afontain_ has quit [*.net *.split]
APic has quit [*.net *.split]
lqd has quit [*.net *.split]
torque has quit [*.net *.split]
backwhack has joined #zig
guan has joined #zig
alva has joined #zig
afontain_ has joined #zig
APic has joined #zig
lqd has joined #zig
torque has joined #zig
drp has quit [Read error: Connection reset by peer]
drp has joined #zig
dingenskirchen has quit [Read error: Connection reset by peer]
dingenskirchen1 has joined #zig
dingenskirchen1 is now known as dingenskirchen
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
cole-h has quit [Quit: Goodbye]
dermetfan has joined #zig
dermetfan has quit [Client Quit]
dermetfan has joined #zig
frett27 has joined #zig
foobles has quit [Ping timeout: 240 seconds]
<daurnimator>
I see https://github.com/ziglang/zig/issues/5077 was already accepted and closed. TBH I think that was too quick of a turn around for such a significant change
<andrewrk>
it is an upstream issue with known workarounds
<andrewrk>
pixelherodev, sure basically. the devil is in the details
<sanaris>
okay, basically my fault to not use my source-based distro
<pixelherodev>
Right, but a thought occurred
<pixelherodev>
If that's the case, why is CPython performance the goal?
<pixelherodev>
Shouldn't it be possible to vastly outmatch it?
<pixelherodev>
I think it's obvious where I'm going with this
<pixelherodev>
JIT!
<pixelherodev>
As long as the translator is aware of the target's quirks, it should be able to work without issue and with great performance
<andrewrk>
sanaris, I am sorry, unfortunately llvm upstream has made it impossible for zig to have a configuration that works on all systems
<pixelherodev>
Can confirm that
<pixelherodev>
I can't build zig on my laptop anymore
<pixelherodev>
LLD is installing weirdly
<pixelherodev>
Your best bet is likely building a static Zig compiler within a chroot and then extracting it to the base system
<andrewrk>
pixelherodev, I think you're right about JIT and performance. I think that would require more personell than zig has available
<pixelherodev>
For most platforms sure
<pixelherodev>
But this is about performance, not features or compatibility
<pixelherodev>
Which means it's fine if some platforms support it, as long as there's also an interpreter and the behavior of both can be proven to be identical
<andrewrk>
I think CPython perf is a reasonable goal and performance baseline for users, which we should aim for. JIT would be possible, but more complicated and too ambitious, and not enough benefit for the cost
<pixelherodev>
What would be the cost? Maintenance?
<andrewrk>
of course, if it can be shown that it would be reasonable to integrate, in a way that did not introduce bugs or instability, then it would be welcome
<andrewrk>
yes
<pixelherodev>
Yeah, that's what I thought
<sanaris>
Does Zig has functinal features like REPL in Scheme?
<pixelherodev>
I'd be willing to maintain it at least for x64
<pixelherodev>
I'm finishing up a GNU Lightning-esque library for Zig anyways
<andrewrk>
it might be more complicated than you are considering. consider for example inline while loops
<andrewrk>
there is comptime code mixed with emitting runtime instructions here
<andrewrk>
or maybe I am lacking imagination
<pixelherodev>
I'm fairly certain it can be done
<andrewrk>
which I will fully admit as a possibility
<pixelherodev>
The only real problem there is it cannot be done without a defined ABI for all functions the generated code needs to invoke
<pixelherodev>
But these are all solvable problems
frett27 has quit [Ping timeout: 260 seconds]
<pixelherodev>
I'm equally certain that I'm underestimating difficulty and that you are overestimating it :)
frett27 has joined #zig
v64 has joined #zig
gazler_ is now known as gazler
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
dddddd has joined #zig
marijnfs has joined #zig
<marijnfs>
hmm having trouble debugging a segfault. The crash is in a c-library and is called from a thread, but the stacktrace doesn't show the call from zig
<marijnfs>
actually I guess its because the library itself has threads and doesn't crash at the callpoint directly, annoying
Xavi92 has joined #zig
<pixelherodev>
IMO threading is never worth it.
<pixelherodev>
and before anyone says I should try Rust: it's not a language thing.
<ikskuh>
pixelherodev, threading depends on the job you do :D
<pixelherodev>
(though I do plan on looking into Rust at some point)
<pixelherodev>
ikskuh, for sure, but in most cases the benefit isn't worth the cost
<pixelherodev>
I prefer applications to not scale
<ifreund>
in many cases yes, but there definitely valid use cases
<pixelherodev>
because when multiple applications try stealing all available resources, it just makes me uninstall all of them
<pixelherodev>
ifreund, I don't disagree
<pixelherodev>
I just think that most cases where they're used they shouldn't be
<pixelherodev>
and there a number of places where they should that they aren't
<ikskuh>
hm
<ikskuh>
can you elaborate this?
<ikskuh>
i usually use threading to speed stuff up when there is no other possibility left
<ikskuh>
or to make stuff that is inherently concurrent, concurrent
<pixelherodev>
For starters, I disagree with that premise
<pixelherodev>
There is no case where threading is the only option for performance
<pixelherodev>
which leads to my next point
<pixelherodev>
When people use threading to improve performance, they do it at the expense of proper profiling and optimization
<pixelherodev>
(speaking in the general case of course)
<pixelherodev>
One place I've used threading in the past was for a plugin-driven application framework
<pixelherodev>
For performance reasons, I had each plugin run in a thread
<pixelherodev>
I ended up making it faster by removing threading, simplifying the framework, and spending a few hours digging through profiling info
<ikskuh>
<pixelherodev> There is no case where threading is the only option for performance
<ikskuh>
what if i told you that i utilize my cpu in some projects with 120%?
<ikskuh>
a single cpu core
<pixelherodev>
I would say "How much time have you spent in profilers?"
<ikskuh>
(so having an average of 1.2 instructions per cycle)
<pixelherodev>
Have you tried shifting algorithms?
<pixelherodev>
Adjusting data structures?
<ikskuh>
yes ;)
<marijnfs>
i'm doing networking stuff, so threading is quite needed there
<ikskuh>
there was just no place anymore on a single core to speed stuff up
<ikskuh>
marijnfs: not really
<ikskuh>
networking isn't really a thing for threading, using poll() makes your code way more robust
<ikskuh>
i once used one thread per client as well
<ikskuh>
but in the end, this just does not scale
v64 has quit [Quit: WeeChat 1.9.1]
<pixelherodev>
I don't think threading is never a good idea
<pixelherodev>
I think in the vast majority of cases it isn't
<pixelherodev>
Multiprocess > multithread
<pixelherodev>
e.g. compilation
<ikskuh>
depends on if you need shared memory
<pixelherodev>
I'd rather run four copies of a compiler than to have a single compiler use four threads
<ikskuh>
depends
<ikskuh>
for C/C++ that really hurts performance
<ifreund>
pixelherodev: did you happen to do AoC this year? you woulda hated my solution to one of the problems (it was spinning up 50 threads)
<ikskuh>
because compilers could cache the headers and precompiled headers could be a thing of the past
<pixelherodev>
Sure but
<pixelherodev>
performance of the one process isn't my concern
<pixelherodev>
my concern as a user is that no one process is consuming all my resources
<pixelherodev>
whether that's cores, RAM, bandwidth, or anything else
<ikskuh>
it depends
<ikskuh>
it's really a matter of "i want throughput" or "i want good latency" on my system
<ikskuh>
i would happily spend 30 seconds of "blocking system" when i could use "3 minutes of non-blocking system"
<shakesoda>
there certainly are cases where threading is pretty much all you can do anymore
<shakesoda>
I end up in tons of situations where you'd be a fool not to thread it in games + graphics
<ikskuh>
oh yeah
<ikskuh>
good example is Doom Eternal i heard
<ikskuh>
they have such good thread/cpu utilization
<marijnfs>
so would you put everything in one large event loop?
<marijnfs>
sounds quite unwieldy
<ikskuh>
marijnfs: if you write a networking library, it's the saner way anyways
<ikskuh>
to have your caller do the dispatching calls
<ikskuh>
you lose a bit of latency, but for most cases, it's way more convenient
<marijnfs>
can lld do something like find the point where a variable originated across threads?
<marijnfs>
i guess i need valgrind for that
sanaris has quit [Remote host closed the connection]
<ikskuh>
what do you mean?
<ikskuh>
you have to use c allocator for valgrind to work
<marijnfs>
I see
<marijnfs>
Its probably better to just review my code, must be doing something stupid
<Snektron>
<ifreund "pixelherodev: did you happen to "> Which day?
<Snektron>
So by the looks of it, both clang and gcc cannot generate code with dsp instructions for arm v7e-m, but LLVM and Zig can
<ifreund>
probably a good idea, i've been kindof assuming a few public package registries will spring up once we have a package manager
wootehfoot has quit [Ping timeout: 260 seconds]
<ikskuh>
yeah
<ikskuh>
afaik there's the GitHub API which we could utilize for this
<ikskuh>
so using git+github api for package search and similar
moo has quit [Quit: Leaving]
<ifreund>
we definitely would need a way to support packages hosted elsewhere as well too
<ikskuh>
yeah true
<ikskuh>
but it would be a way to search packages in *one* registry
<ikskuh>
nothing about the others :D
<ifreund>
definitely a good first step
<ikskuh>
i just added my two packages in the path
thmzlt has joined #zig
<ikskuh>
also going to add another one later :)
<ikskuh>
zig-serial will help with serial port support :)
<ifreund>
i don't have any packages yet :/
thmzlt has quit [Client Quit]
factormystic has joined #zig
darithorn has joined #zig
layneson has joined #zig
StateOff has joined #zig
antaoiseach has joined #zig
<ikskuh>
ifreund: then write some!
<ifreund>
spending all my time on my compositor right now, I do plan on writing a zig-wayland package at some point though
<ifreund>
probably just wrap libwayland at first, only going to reimplement in zig if i have a lot of time on my hands
waleee-cl has joined #zig
antaoiseach has left #zig [#zig]
Xavi92 has joined #zig
<pmwhite>
I have a zig windowing module that I've been using. Until the package manager comes along, and perhaps after, I'm keeping all my programs that use it in the same repository, called "wayland-stuff". The idea is also to develop ui widgets for each program, so I'm especially appreciating the low friction of the monorepo approach.
<ifreund>
pmwhite: link? i'm always interested in wayland stuff
<pmwhite>
window.zig is the window setup code. I bought the Wayland book when I started working on that, so that's where my understanding of the protocol primarily comes from.
decentpenguin has quit [Quit: decentpenguin]
<ifreund>
cool, i haven't written a client in zig yet, but almost certainly will soon
<ifreund>
kinda waiting on #1717 functions in zig so i can make a nice wrapper for libwayland-client first
<ifreund>
may try to wrap wlroots someday, but i'd rather wait for it to get more stable first
<pmwhite>
Ah, that's right, you're working on a compiler. I guess you have the opposite side of the problem than I do.
<ifreund>
it's almost to the point where i'm willing to use it as a daily driver
<pmwhite>
I'm the early adopter type, so I may be willing to give it a try.
<pmwhite>
You were the one that uses kakoune, right? I decided to give it another try, and this time it might stick.
<ifreund>
yep that's me, glad you're enjoying it
<pmwhite>
Rather off-topic to this channel, but I stumbled upon this issue - https://github.com/mawww/kakoune/issues/1735 - which makes me think that kakoune supports interleaved syntax highlighting. Wasn't able to get it to work though.
jjido has quit [Quit: Vision[0.10.3]: i've been blurred!]
<ifreund>
pmwhite: i haven't dug into how it works too much, but I can confirm it works in markdown
<pmwhite>
I read that file actually. How do I specify the language to highlight - I was trying ```c but all I get is a file that has no syntax highlighting.
<Sphax>
in my use case I'm communicating with cassandra where all sorts of thing can go wrong (invalid CQL query, network problems, unavailable replicas, etc), in these cases having some context would be nice.
<gonz_>
Sphax: I think the idea of having an error structure with possible null fields that are populated in case of certain errors is your best bet atm
<gonz_>
It requires more work on your part, but it's better in the general case than having your errors not be first class errors since we interact with errors as a special construct in zig.
<ifreund>
anyone have any ideas?
<Sphax>
gonz_: hm do you maybe have an example ?
<gonz_>
Have a structure with fields that are either some data or null, take the structure as an out parameter, have your error union as usual and decorate the structure with values corresponding to whichever error you're returning.
<gonz_>
An example could be parsing errors that really need to be decorated to be useful; `ParseError` could contain `sourceSpan: ?SpanData` & `expected: ?TokenType` that will be set accordingly when an `error.ExpectingToken` is returned, but not on success.
<jwmerrill>
I was asking yesterday about how to implement "Struct Inheritance" as described at https://craftinginterpreters.com/strings.html#struct-inheritance fengb gave me a couple nice suggestions, inlcuding using extern structs to fix the memory layout. I tried that, but abandoned it when I discovered that you can't store a string as a slice in an extern struct. I landed on a slightly different solution that seems to be working out really well: store the shared