<pixelherodev>
keegans, As of the end of that, I believe it's *possible* with some caveats
<pixelherodev>
You'd probably have to write the allocator yourself though at present
<pixelherodev>
Actually, the one up top might work
<pixelherodev>
Not sure
<keegans>
well the ComptimeAllocator is referenced, but it doesn't exist, what do you mean but one up top?
<keegans>
*by
<pixelherodev>
It's shown in that issue
<pixelherodev>
An example of one is, at least
<fengb>
Assigning undefined at comptime is still a problem
<pixelherodev>
Literally in the first post
<pixelherodev>
Not saying it's not
<pixelherodev>
Like I said, *possible*
<pixelherodev>
Doesn't mean it's a good idea just yet
<pixelherodev>
I will say, I far prefer the idea of finding workarounds to those problems that don't require adding in a builtin
<keegans>
i will play around with it, thanks
<andrewrk>
this use case one of the constraints of the possible "interface" feature to add to the language. it has to solve this problem
<pixelherodev>
Minimizing builtin count where possible (within reason; no removing subtraction and replacing with inversion + addition for instance, that'd just be stupid) is probably a good idea
<keegans>
error: cannot store runtime value in type '*ComptimeAllocator', in: const self = @fieldParentPtr(ComptimeAllocator, "allocator", allocator); -- I guess this worked previously, but not sure how I can solve this since I cannot really mark the `allocator` object as comptime, right?
<andrewrk>
I need sys::getHostCPUName() and sys::getHostCPUFeatures() ported to zig
<pixelherodev>
Alrighty, I was planning on redesigning my LLVM parser and then implementing to match the design, but that can wait; I'll port those shortly
<andrewrk>
yeah that one
<andrewrk>
unfortunately difficult to test, and catastrophic consequences for bugs in the implementation
<pixelherodev>
Yeah, but there's a simple way to work around that
<pixelherodev>
Just check the produced LLVM IR via `diff`
<pixelherodev>
... oh wait
<andrewrk>
...for every CPU
<pixelherodev>
It uses the preprocessor :(
<pixelherodev>
Okay, so is there a way to fake running Zig on a different host?
<pixelherodev>
Could check the produced asm that way...
<andrewrk>
to truly test this you would need to run it on N cpus * N operating systems
<andrewrk>
maybe qemu knows how to pretend to be certain CPUs
<pixelherodev>
... ah right!
<pixelherodev>
QEMU should work
<andrewrk>
that's a good idea mikdusan
<andrewrk>
I'm going to make this depend on LLVM's implementation of these functions for now, so that #3927 can get merged. but a zig implementation would be (1) cleaner (2) progress toward non-llvm backend (3) more complete! llvm's implementation only supports x86 and arm
<pixelherodev>
... uh... I was *literally* just going to port it
<pixelherodev>
Like, line-for-line port
<pixelherodev>
Then clean that up
<andrewrk>
that would be fine
<pixelherodev>
Lacks 3) for now
<pixelherodev>
x86 is most definitely where I'm strongest, though I do plan on ordering a PineBook shortly
<andrewrk>
yeah (3) is not a blocking problem
<pixelherodev>
Got it
<pixelherodev>
No promises, but I'll attempt to have it done tonight
<andrewrk>
nice! if you get it done within a day or two I'll incorporate it into the merge
<andrewrk>
I also have a pine book I can run it on
<pixelherodev>
Also, holy craps - the PineBook Pro has 10k mAh battery?!
<pixelherodev>
That's - that's still at 12V, right?
<andrewrk>
is that a lot?
<pixelherodev>
My Dell laptop's battery lasts ~7 hours, and it's 2700 mAh
<andrewrk>
oh wow
<pixelherodev>
With an *Intel* chip
<andrewrk>
and arm is-- yeah
<pixelherodev>
So, yeah, I'd say so
<pixelherodev>
Just how long does the battery typically last on there?
<andrewrk>
hmmm, pixelherodev, you'll probably need the std.Target structs & definitions for this implementation, and I'm completely changing the structure and namespacing from the PR
<andrewrk>
I've never had it die on me, but I haven't tested it either
<companion_cube>
wait, it's a consumer laptop based on ARM?
<andrewrk>
yeah, cheap too
<pixelherodev>
$200
<companion_cube>
wtf?! is this the notebook era again? :D
<andrewrk>
the build is sturdy, I like it
<companion_cube>
what OS do you use on it? debian?
<andrewrk>
it comes with a fork of debian, and it's not clear to me that it is compatible with upstream debian
<andrewrk>
for some confusing reason
<pixelherodev>
Whoa, this is interesting
<pixelherodev>
``The keyboard has a special firmware that lives on, and operates separately of, the operating system. In a nutshell, it detects if F1, F2 and F3 keys are pressed for 10s. Once one of the keys get pressed for the set duration, the keyboard firmware cuts power to the chosen aforementioned peripheral``
<pixelherodev>
This has to be the *only* benign (that is, existing for the *user*) OS-independent firmware I've *ever* seen
return0e_ has quit [Read error: Connection reset by peer]
<pixelherodev>
andrewrk, to my knowledge the Debian fork is to improve ARM support / performance
<andrewrk>
ah
<pixelherodev>
AFAIK it includes patched kernel / software
<andrewrk>
pixelherodev, re: get native cpu - I'll push to a branch in ~30 minutes here so you can get a sense of the std.Target structs and stuff. It'll be an in-progress commit because I have to manually go through and refactor ~18,000 lines of things
return0e has joined #zig
<pixelherodev>
So should I branch from that branch for this?
<andrewrk>
it would be reeeeeally nice to have an IDE rename feature right about now
<pixelherodev>
Hmm
<andrewrk>
yeah
<karrick>
I built my first non trivial and useful program with Zig 0.5 today, but using the debug allocator and need to use an arena. I tried to initialize the arena using `std.heap.page_allocator` but I get a compile error about `std.heap` having no `page_allocator` even though I see it right in the source code for std.
<pixelherodev>
What's higher priority, a CLI Zig refactoring tool or this port?
<companion_cube>
is the pine book entirely free? even for the bios (or whatever equivalent)?
<andrewrk>
karrick, you can check out the 0.5.0 tag
<pixelherodev>
companion_cube, AFAIK
<companion_cube>
:o that's incredible
<andrewrk>
if you're looking at a local git repo, `git checkout 0.5.0`. github.com has a way to browse tags as well with the UI
<andrewrk>
pixelherodev, the port
<pixelherodev>
Gotcha
<karrick>
Even if `zig version` already shows 0.5.0? Sorry for the hassle.
<andrewrk>
companion_cube, they have a phone too. I should be getting one within a week or two
<pixelherodev>
karrick,
<pixelherodev>
Whoops sorry, hit enter early
<companion_cube>
yeah I knew that because of ddevrault's review
<karrick>
Thanks for the help
<pixelherodev>
karrick, yes
<companion_cube>
I'm having a hard time imagining they can be profitable though
<pixelherodev>
The version is usually shown as major.minor.patch + revision
<pixelherodev>
The pre-0.6 revision changes renamed the alocator IIRC
<andrewrk>
karrick, yeah, `zig version` shows what version of zig you are using, but if you're looking at the git repo, the main branch has changed since 0.5.0. so you want to look at the std lib version that matches the zig version you have
<pixelherodev>
companion_cube, AFAIK they don't try to be
<pixelherodev>
They sell at literally zero profit
<companion_cube>
nice
<pixelherodev>
Yeah, found it
<pixelherodev>
`When fulfilling the purchase, please bear in mind that we are offering the Pinebook Pro at this price as a community service to PINE64, Linux and BSD communities. We make no profit from selling these units. If you think that a minor dissatisfaction, such as a dead pixel, will prompt you to file a PayPal dispute then please do not purchase the Pinebook Pro. Thank you.`
<karrick>
Okay thanks. So I’ll check out the 0.5.0 source and make sure I can find the proper allocator. Thanks
<pixelherodev>
I somehow managed to forget that existed
<pixelherodev>
Despite having read it at least half a dozen times previously
<pixelherodev>
Sorry to waste your time, thanks for the link!
<andrewrk>
no problem! I'm glad I invested in writing that short guide
<pixelherodev>
Hmm... I should probably consider a refactoring tool a *library*, with the CLI as the default implementation
<pixelherodev>
That would allow incorporating it more easily with future projects / IDEs / whateveer
<pixelherodev>
s/eer/er
<pixelherodev>
Oh hey wait, when you get a chance, is programming in Zig on the PineBook fast enough that it could be used as a daily driver if Zig is your primary concern?
<pixelherodev>
Just realized I've been wondering that and you said you had one :)
<keegans>
i keep running into this: error: expected type '[][]const u8', found '[4][]const u8', but in general how do I specify in types that there is no fixed slice size in a return value?
<keegans>
because omitting it doesn't seem to cut it
<keegans>
alright so i just ended up crashing the compiler
<keegans>
not what i was going for
<pixelherodev>
Heh yeah
<pixelherodev>
The most important thing I've had to remember about compiler bugs is to mark them down as to-fix after the compiler bug is fixed
<pixelherodev>
I don't doubt I have some workarounds in some projects for which I forgot to do so and the workarounds will just always be there
<keegans>
ah, good point
<keegans>
also it seems that i was causing out-of-bounds array access at compile time accidentally
<keegans>
and that crashes the zig ir processor
<pixelherodev>
Hmm, what's a good API sig for a library refactoring function? Currently, I'm thinking of taking in the source as a slice and returning a refactored slice
<pixelherodev>
For some reason, I always have more trouble arguing with myself on function sigs than actually implementing them :P
<pixelherodev>
It could modify-in-place the existing slice and use an adjusted offset, but if the caller wants to e.g. diff the refactor against the original and print that, it's better to not require duplicating the original
<pixelherodev>
Or, it could take in two *streams*! I was thinking, "I don't think I've ever needed to stream... out... a string oh wait that was obvious" :)
<pixelherodev>
That also allows for some nice performance increases in cases of slow I/O and for refactoring not-in-memory source
adamkowalski has joined #zig
___ has joined #zig
marijnfs has quit [Ping timeout: 265 seconds]
metaleap has quit [Ping timeout: 272 seconds]
marijnfs has joined #zig
marijnfs has quit [Remote host closed the connection]
<karrick>
For the record I did read that Choosing an Allocator doc before I asked the question. :)
<pixelherodev>
:)
<pixelherodev>
Anyone here who has used the std.zig API? The Doc comments are a bit... lacking, for some functions, and reading the entire source seems a bit excessive
<pixelherodev>
Looking at the .render function RN
<andrewrk>
pixelherodev, zig fmt is implemented using that
<andrewrk>
it might clear things up a bit to look at std.zig.ast
<andrewrk>
that has the AST node data structure that is central to std.zig.parse and std.zig.render
<pixelherodev>
Yeah, I was mostly misreading how render worked - the comment said "checks for changes," I assumed by parsing the stream and comparing the trees, but a glance and thinking about the name indicates that it's by rendering the tree into a stream and comparing *that* (unless I'm even more off base now)
___ has quit [Quit: Leaving]
metaleap has joined #zig
<pixelherodev>
Hmm, if I plan on providing this to Zig officially I probably shouldn't include some very annoyed anti-Windows comments in panic messages, even *if* those errors can *only ever happen on windows dammit why* argh
<metaleap>
pixelherodev: if your refactorings core logics go into a lib instead of a proggie, i could quite smoothly integrate them into my upcoming zig-lsp endeavour (with big fat credits of course=) --- otoh a separate prog has also benefits as people can update the external tool for future bug-fixes faster than I might react for a lib upgrade and republish..
<pixelherodev>
I'm doing both
<pixelherodev>
lib with a tiny arg processing + file reading main that passes the needed info to refactor.refactor
<metaleap>
if lib, might be good if they take in already-parsed ASTs and dont do the same redundant parsing work that the "lib consumer" might also do on its own for other purposes
<pixelherodev>
... ah right, that's a good point
<pixelherodev>
Thanks!
<metaleap>
symbol-renames can be a pervasive topic. for non-`pub`s aka file-only thats the easier case to attack initially. for `pub`s, cross-file renames involves figuring out importers, possibly in pre-scoped sets-of-proj-dirs potentially determined by the caller (or on your own), and then the cherry-on-top would be detecting nameclashes in both pub and local, with the transaction being rejected. but thats maybe going too wild. then one might actually kick off the
<metaleap>
rename of a symbol not at the point of definition but any arbitrary point of reference .. have fun =)
<pixelherodev>
Yeah, starting simple for now
<pixelherodev>
But basically everything you said is in scope
<metaleap>
way to go for sure
<pixelherodev>
The last point is one of the simplest actually
<pixelherodev>
At least, in terms of interface
<pixelherodev>
`findPointOfDefinition`
<pixelherodev>
I think the key is to require the root file
<metaleap>
oooh if thats also exposed, thatd be neat too
<pixelherodev>
From there, a full project tree can be built
<pixelherodev>
Everything except refactor's going to start out private and then be exposed on demand, whether that demand is from me or someone else
<pixelherodev>
And unless I have an overwhelming reason *not* to, basically any useful function can be exposed for outside use
traviss has quit [Quit: Leaving]
<pixelherodev>
(even if it ceases to be used internally, it can be deprecated and removed later on after the dependent project replaces it)
<pixelherodev>
Out of curiosity, anyone have a use case for errdefer they can link? I don't think I've found a single use for it yet
traviss has joined #zig
<metaleap>
i have 1, a sec
<metaleap>
btw looking forward to your project. kicks me into high gear to get started on the LSP part at my end, too. aiming for everything from symbols listings, autocomplete, hover intel, list-references, jump-to-def, diagnostics-from-build-on-save, and so on
<pixelherodev>
Hmm, well, I'd consider more than refactoring, but I'm not willing to go out of scope on this one
<pixelherodev>
It's a simple enough project that I should be able to get done *very* quickly at least for basic support
<pixelherodev>
Especially now that I thought of the root source file idea
<pixelherodev>
A lot of work that's a pain for other languages is freaking *trivial* for Zig thanks to that, even for libraries
<pixelherodev>
e.g. for stdlib, could use std.zig as the starting point
<metaleap>
i will for sure
<metaleap>
what would be EXTRA cool it just occurs to me: if the lib can gather all the "list of edits (file and position ranges and replacements)" as a return value , with another handler able to "interpret" (perform) such structure. because in LSP you can send "edits to do" to the editor back: this way, it can do them atomically (all or none) and the user has them in their undo
<pixelherodev>
... that's within scope enough that I'm willing to accept it, though only because I've only done the basic AST testing so far and that doesn't require a massive rewrite or anything :)
<metaleap>
so you compute a list-of-todos and separate the doing from the what-to-do
<pixelherodev>
Can easily just make a plan_refactor function that returns a changelist
<pixelherodev>
I think I'm going to end up having to build this from the top down and not the bottom up as I have been
<pixelherodev>
e.g. need to *start* with project level support
<pixelherodev>
The best worst part is now I just realized a lot of my code would be better if I'd used it :)
<pixelherodev>
Zig is really nice, but it definitely requires a shift in thinking from other languages
<metaleap>
whats happening is that usually the arraylist gets returned-and-freed via toOwnedSlice but in the error case it must still be cleaned
<pixelherodev>
Right, I got that
<metaleap>
hehe ok. people here seem to be real fast and scanning and grok'ing other folks' code. hope i can absorb this over time :P
<metaleap>
s/and/at
epmills has joined #zig
<fengb>
Only when it comes to identifying existing foot guns :P
<pixelherodev>
Largely due to experience; I've spent a lot of time on OSS projects by now (even if it's split up among enough projects that it's very little per project, unfortunately)
<pixelherodev>
I've been working on that last point; I've cut back on a lot of projects I've wanted to work on so I have more time-per-project
<pixelherodev>
Hence me having time to work on Zig tonight instead of random idea #39120214
<pixelherodev>
Also, while reading code is a very *very* important skill, *writing* code is even more so
<pixelherodev>
s/reading/reading good && s/writing*/writing* good/
<fengb>
Reading bad code is even more important 🙃
<metaleap>
truth, nothing raised my standards for myself more than reading other peoples code
<metaleap>
even tho i rarely *apply* those high standards =/
<metaleap>
well except when idle and in "gardening and tending" mood..
<andrewrk>
I'd like to think that zig is relatively easy to read compared to other languages :)
<fengb>
We’re lucky to attract people who care about craft atm
<fengb>
That might change once the language gets more popular >_>
nickster4 has joined #zig
<metaleap>
like attracts like as long as unlike-repels-unlike and isnt bashful about it :D
<metaleap>
or falsely ashamed
<fengb>
It’s more that Zig is so niche and new that the only people that actually try it are people who care enough to try
<metaleap>
andrewrk: no real complaints about readability overall from me. many idioms are exceptionally smooth indeed. such as capture vars, if/switch/block exprs and other such innovations. feels less noisy/verbose to me than c, c++, c#, java for sure. or the manner in which some JS codebases are concocted. some more sigils than go but to be expected as one can/must also express more details in zig (the whole ptr/slice/arr complex is more exposed in zig, as part of
<metaleap>
its objectives naturally)
<pixelherodev>
Anyways, metaleap, thanks for the help nailing down how this should work
<fengb>
I’m ratio happy at the keyword to symbol ratio
<fengb>
That first ratio should be really lol
<metaleap>
might there be a way to detect in your lib api that takes allocators whether its the allocator of an arena? other than a comptime bool. in order to `if` all the `free`s/`destroy`s/`deinit`s. or do they already turn into no-ops? but still call "overhead" is there
<pixelherodev>
I considered having a separate function to parse a full project into trees, but then I figured that'd be better as an extension to std.zig
<pixelherodev>
Probably going to build an arena internally
<pixelherodev>
But yeah, I think it's detectable
<pixelherodev>
Using @TypeOf comparison, no?
<andrewrk>
pixelherodev, this branch push is delayed again because I decided to fundamentally change the data layout even more; so that cpu features are bit sets. this way std.Target can avoid having to own memory and manage resources
<pixelherodev>
It's totally fine, just let me know when it's done
<pixelherodev>
"Enjoying" working on this anyways :)
<pixelherodev>
e.g. `if (@TypeOf(allocator) == *std.mem.ArenaAllocator)` should work, no?
<metaleap>
pixelherodev: no @TypeOf wont help because a lib func takes any *Allocator but the caller might provide their &myarena.allocator --- now all the cleanups would be pointless extra work, hence the question
<andrewrk>
here's hoping that no cpu has more than 64 features :)
<pixelherodev>
metaleap, Ah right
<daurnimator>
Ha
<daurnimator>
ha
<andrewrk>
(will find out at comptime if the assumption does not hold)
<andrewrk>
I'm pleased with how namespacing and importing turned out in zig
<pixelherodev>
Seconded
<pixelherodev>
fengb, argh
<pixelherodev>
Guess I'm adding another `TODO: see upstream #NNNN`
<pixelherodev>
Actually
<andrewrk>
pixelherodev, you don't need that to do what you said; it'll just lower waste once it's done
<pixelherodev>
andrewrk, what's the status on that?
<pixelherodev>
It says blocking on #2377
<pixelherodev>
Which is solved
<andrewrk>
yeah apparently it's done in a branch, just needs to be updated to latest zig and tested
<pixelherodev>
Alrighty, I'll do that rn
<pixelherodev>
Oh... oh wow, yeah it needs to be updated
<pixelherodev>
I did a git checkout and my wd became invalid :P
<pixelherodev>
panicked for a sec; last time that happened, it was because my HDD failed :(
<fengb>
Was that before the lib directory move?
<pixelherodev>
yeah
<pixelherodev>
I should really see about hooking up the RAID controller in my not-quite-functional server (MB isn't properly connected to case stuff - e.g. power button - among other issues) into my PC so I don't have that panic again :P
<andrewrk>
it wouldn't be too much work to start over probably
<pixelherodev>
This seems to be just a single commit anyways
<pixelherodev>
Yeah
<pixelherodev>
~60 insertions / 80 deletions
<pixelherodev>
So I'mma just do that
<fengb>
Can it just be rebased / cherry picked?
<andrewrk>
I think the way I did the std lib rename is friendly to rebasing
<fengb>
I’ll stop butting in since I have no context
<pixelherodev>
`warning: inexact rename detection was skipped due to too many files.` *but* with a notification that I can change a setting to increase that limit and it might work
<pixelherodev>
Okay, worked for mem.zig, but not heap.zig - still an improvement
<pixelherodev>
Alright, updated; just needs testing now
<pixelherodev>
Thought you meant a basic instruction
<pixelherodev>
That would be even odder
dddddd has quit [Remote host closed the connection]
adamkowalski has quit [Remote host closed the connection]
epmills has quit [Remote host closed the connection]
Ekho- is now known as Ekho
rageoholic has joined #zig
<rageoholic>
Alright I keep coming in here for dumb questions but I was wondering
<rageoholic>
Is it possible to have more than one output directory for executables per build?
<rageoholic>
that way you can build a monorepo style thing
<rageoholic>
But have dirs you zip up for distribution
<rageoholic>
Or should I just use submodules
<andrewrk>
are you aware of the "install" step of `zig build` ?
<andrewrk>
this will create a distribution dir
<rageoholic>
Yeah but I want more than one distribution in a project
<pixelherodev>
That - can I ask *why*?
<rageoholic>
I wanna build a raytracer and a game out of the same repository
<rageoholic>
They share a bunch of math code and shit
<rageoholic>
It's a monorepo
<rageoholic>
They're pretty normal
<rageoholic>
You know what, I'll just do a submodule thing
<rageoholic>
It feels fragile but it'll work
<pixelherodev>
... if they share a bunch of code, maybe make that a library linked into both?
<rageoholic>
Essentially you are
<pixelherodev>
Okay, but why do you need to install to multiple places?
<rageoholic>
Never mind
* pixelherodev
shrugs
<pixelherodev>
Well okay then
knebulae has quit [Read error: Connection reset by peer]
<rageoholic>
Basically for a game I want to have a resource compiler and a game executable
<rageoholic>
i don't want to distribute the resource compiler with the game
<pixelherodev>
So don't install the RC?
<pixelherodev>
That is, don't add it to the `install` step?
<rageoholic>
Oh you can do that?
<rageoholic>
Huh
<rageoholic>
OK
<rageoholic>
So it stays in zig-cache then?
<rageoholic>
And you can run it from build.zig?
* pixelherodev
shrugs again
<pixelherodev>
I haven't actually used build.zig
<pixelherodev>
I usually use Makefiles, because I'm honestly a bit lazy
<pixelherodev>
And I already know anything I need to write basically any makefile, whereas switching to build.zig will require looking up some APIs here and there
<pixelherodev>
Even if it admittedly will probably pay for itself pretty quickly
<pixelherodev>
Righty, was kinda hoping CI would handle e.g. QEMU, but for now I guess I'll just write a quick shell script to grep the package list, remove the version, and install all Alpine packages with qemu-system in the name
<andrewrk>
pixelherodev, you are welcome to rely on the CI. it does do qemu
<rageoholic>
Haha
<rageoholic>
Nice
<pixelherodev>
andrewrk, perfect, thanks! That definitely makes life easier!
<andrewrk>
yeah it's just slower turnaround time
<pixelherodev>
PR against master, not the upstream null-refactor?
<pixelherodev>
Yeah that would be weird
<andrewrk>
master plz
<pixelherodev>
Alrighty, 4235 CI running
<andrewrk>
nice!
<pixelherodev>
Once 2727 is fixed, I'll improve the CLI for the refactoring tool (and LLVM parser now that I think about it), but for now it's just a stupid "check which needed strings are null, fill the first, if any are still null panic, if more than expected are received panic"
<andrewrk>
I see you are a fellow yak shaver
<pixelherodev>
Heh, yeah
<pixelherodev>
Still, this at least proves the other solution wasn't too nested
<pixelherodev>
*because this is*
<pixelherodev>
It's just four nested if-unwrap-elses
<pixelherodev>
Inside an iterator loop
<pixelherodev>
And for the sake of not annoying anyone *too* much, the Windows panic message has been changed to "Windows has a borked API, sorry" instead of - well, instead of what I had before :P
<pixelherodev>
I considered unreachable, but this seemed more satisfying
<pixelherodev>
I mean, to *me*
<pixelherodev>
Not to Microsoft, and probably not to anyone who sees this
<andrewrk>
should we allow null terminated strings to type coerce to slices?
<andrewrk>
it's quite possible, and safe
<pixelherodev>
From what type? `[*:0]u8`?
<andrewrk>
[*:X]T to []T
<pixelherodev>
Without explicit slicing?
<pixelherodev>
Or with `[0..]`?
<andrewrk>
without explicit mem.toSlice()
<andrewrk>
it would basically amount to a hidden strlen
<pixelherodev>
So just `const a: [*:X]T = ... ; const b: []T = a`?
<andrewrk>
yes
<pixelherodev>
I mean, that violates no hidden control flow, doesn't it?
<pixelherodev>
If there's a behind-the-scenes strlen
<andrewrk>
debatable. var a = b; where b is an array is a hidden memcpy
<andrewrk>
both strlen and memcpy are O(N)
<pixelherodev>
Well yeah, but I don't think performance factors into whether it's a problem that it's hidden
<pixelherodev>
I don't think it's a problem personally, but others might disagree
<pixelherodev>
Though I do prefer status quo
<andrewrk>
also, `a / b` can possibly emit a libcall into compiler_rt depending on what instructions are available in the CPU, and the algorithm can be quite involved
<pixelherodev>
True, but that qualifies as part of the language - it's not really hidden in the same way because ohhhh wait yeah that's fair
Snetry has quit [Ping timeout: 272 seconds]
<pixelherodev>
It's still inherently part of the language
<andrewrk>
something to think about. it deserves a proposal at least, I think
<pixelherodev>
I was going to say that `If you give a value of type `[*:X]T` to toSlice and it's not actually X-terminated it's on you but if the language strlens behind your back it's a problem`, but on further reflection I have to agree
<andrewrk>
it would allow c libraries to work even more seamlessly with zig libraries
<pixelherodev>
Right
<pixelherodev>
Yeah, now that I'm thinking about it that'd be nice
<pixelherodev>
Literally wrote a `cstr` method that just called std.mem.toSlice to clarify intent for one of my projects, so, yeah
Snetry has joined #zig
<andrewrk>
and then here's the weird part: we can even do out of bounds safety checking for null terminated strings
<pixelherodev>
That reminds me, I still need to swap the strings in a C project from a home-grown string type to either `const char *` or rapidstring or something
return0e has quit [Read error: Connection reset by peer]
<andrewrk>
the safety would have some hard coded number it would give up after. like if the array index is less than 100 then make sure no null byte before that
<pixelherodev>
There's something oddly satisfying about grabbing a piece of paper, a clipboard, and the nearest writing implement in order to design a library instead of just, well, writing the code and making it up as you go
<pixelherodev>
The LLVM parser - well, I honestly didn't expect it to even *work*
<pixelherodev>
and then it *did*
<pixelherodev>
So the interface is utter garbage
<andrewrk>
:)
<pixelherodev>
I don't want that happening with the refactorer
<rageoholic>
I dunno, my experience is that preplanning means everything will go to shit
<rageoholic>
Wait, swearing, I should not do that here
<pixelherodev>
Eh, I doubt anyone overly cares; we're *engineers*. If anyone has a reason to curse, it's *us*. :P
<rageoholic>
hahaha fair enough. Also finally, people who admit software devs are engineers and not glorified mathematicians
<pixelherodev>
Well, *some* of us are
<pixelherodev>
But I've read code that - well, to say it was written by glorified mathematicians is an insult to the mathemeticians I know
<rageoholic>
Anyways time to get started on that dependency free raytracer. No libc here! Just good ol (and by that I mean bad) bmp files
<pixelherodev>
... bmps?
<pixelherodev>
... why not, say, framebuffers?
<rageoholic>
Cause then I'd need a way to display the framebuffer
<pixelherodev>
Why does the file format matter?
<pixelherodev>
If you work on the framebuffer internally, you can use any arbitrary library to do the actual work
<pixelherodev>
of saving / loading!
<rageoholic>
Yeah true
<pixelherodev>
Not the raytracing :P
<pixelherodev>
That came out wrong
<rageoholic>
I mean the work is going to be on internal framebuffers
<rageoholic>
It's just that eventually you wanna see it
<pixelherodev>
hmm
<pixelherodev>
Shameless plug here but
<pixelherodev>
I have a simple (pun intended) library that allows for easily displaying framebuffers
<rageoholic>
Oh neat
<pixelherodev>
It's called SIMPLE (SIMPLE Idiot Manufactured Platform for ... I don't even remember what stupid acronym it is)
<rageoholic>
Linksys plz. I am in the market
<pixelherodev>
Well, I say library, but it's more accurate to say libgit + C-based ImGui library + simple windowing output + plugin loader, but I have some simple examples lying around still, and it works perfectly with @cImport
<pixelherodev>
Give me ~two minutes to push an actually working version
<rageoholic>
Oh I'm trying to avoid cImport
<rageoholic>
I want it to be pure zig
<pixelherodev>
It used to be a z80 emulator with distinct components because I kept rewriting pieces :P
<pixelherodev>
Ah
<rageoholic>
Actually maybe I can write my own dumb framebuffer library :p
<pixelherodev>
Hmm, not sure there's any UIs in pure zig yet
<pixelherodev>
Yeah, it shouldn't be too difficult if you just need to display one texture
<pixelherodev>
Maybe just do raw OpenGL?
<pixelherodev>
If it's something that simple, you probably don't need anything more?
<rageoholic>
I was thinking win32 and X
<rageoholic>
And again, factor into a lib and maybe someone decides to port to macOS
<pixelherodev>
Whatever works for you
<pixelherodev>
Hey, maybe you could just port sokol-app
<pixelherodev>
s/app/gfx
<rageoholic>
Someday. RN I'm just learning graphics stuff
<pixelherodev>
It's a single header C library supporting Linux, macOS, and win32
<pixelherodev>
So it should be relatively straightforward to port to Zig
<pixelherodev>
Hence me suggesting it and not, say, SDL/SFML/GDX :P
<rageoholic>
The problem is the obj-c bits. I'm pretty sure on mac y ou need to use obj-c to output graphics
return0e has joined #zig
<rageoholic>
Although maybe I'm wrong, I never used macOS before
<pixelherodev>
Apparently not anymore
<pixelherodev>
There's *apparently* a Metal API in C?
<pixelherodev>
Ah, the *window* requires ObjC I think
<pixelherodev>
Which *is* from Sokol-app
<rageoholic>
That's right. Ugh. That is so annnnnooooooyyyyyiiiiinnnnggg
<rageoholic>
She says as a giant nuisance to everyone who can't even come out as trans to a mom who she knows will be accepting
<pixelherodev>
Can still probably port the Windows and Linux backends and give macOS the finger
<pixelherodev>
If you don't need it, it's probably better not to port it yourself anyways
<pixelherodev>
I find that people who create projects with the hope others will use them tend to a worse job than those doing it for themselves
<rageoholic>
Giving MacOS the finger does sound fun. Someone else can figure out zig on MacOS and calling Cocoa APIs. I'm sure you can do some ASM nightmare
<rageoholic>
However Rust does it. How does Rust do it?
<pixelherodev>
I don't even think I want to know
<pixelherodev>
Can I just say how happy I am Zig doesn't support shadowing?
<pixelherodev>
This refactor design is going a lot smoother than I expected :)
<rageoholic>
Oh they use obj-c
<rageoholic>
OK
<rageoholic>
I guess Zig will need an obj-c compiler *someday*. God knows I'll never use it
<pixelherodev>
Eh, can just not bother supporting it
<pixelherodev>
LLVM probably has a frontend anyways
<pixelherodev>
Can just use that
<pixelherodev>
Once it's turned into IR, langauge no longer matters anyways
<rageoholic>
LLVM definitely has a front end, apple loves clang
return0e has quit [Ping timeout: 268 seconds]
<andrewrk>
pixelherodev, the same reason you are happy there is no shadowing right now - because you're writing a tool that wants to make assumptions - is the same reason it is also beneficial for humans reading the code
<pixelherodev>
I know, but that doesn't make it any less awesome
return0e has joined #zig
<pixelherodev>
Coming up with a syntax for referencing variables is still mildly annoying though
<pixelherodev>
Not nearly as bad though, only one shared syntax for function parameter and fn-local var
<pixelherodev>
A couple tricky bits, but most can be resolved by rejection
<pixelherodev>
e.g. if an attempt is made to refactor `std.ArrayList(u8).items` into something else, it can just be denied
<pixelherodev>
At least until I figure out a better way to deal with it :P
<rageoholic>
It's amazing how many problems can be solved by just throwing your hands up in the air and defining it out of the problem you're trying to actually solve
<pixelherodev>
I mean, finding all calls to ArrayList() to build references might work...
<pixelherodev>
rageoholic, true, but I try to avoid that
<pixelherodev>
Better to be correct later than to be somewhat correct now
return0e_ has joined #zig
<pixelherodev>
I think that requiring a specification of e.g `std.ArrayList:ret` might work
<pixelherodev>
Explicitly modifying the source type
<rageoholic>
I mean yes but knowing what's a constraint and what's extraneous to the actual problem is a really important skill to have as an engineer
<pixelherodev>
Definitely
<pixelherodev>
A good example of that here is that I'm explicitly rejecting attempts to refactor C
return0e has quit [Ping timeout: 272 seconds]
<pixelherodev>
e.g. if `const a = @cImport`, and an attempt is made to modify `a.blob`, it's just a giant `@panic("Wow. Just, wow.");`
<pixelherodev>
At least for now; might be worth implementing later
<pixelherodev>
A better example of a rejected refactor would be an attempt to rename `std.ArrayList:ret.items` into `std.items`, since that's an attempt to move a field into a different structure
<pixelherodev>
Whereas refactoring std.ArrayList:ret.init into `std.alinit` might be accepted if no usage of `init` as a member function is found, which makes it a tad trickier
<pixelherodev>
Though, generally, the assumption is that the user knows what they're doing
<pixelherodev>
So if no problem is *found*, it's assumed that if there is one we don't have to care :)
<pixelherodev>
Have a good enough high-level overview to actually get to work now :)
<rageoholic>
Alright now to fuck with win32
<rageoholic>
The fun part of any project
<pixelherodev>
Eh, I no longer, uh, "enjoy" that; I wiped the last bit of Windows infecting my computers a few months back
<rageoholic>
That is fair
<rageoholic>
I am actually back after a long time off of windows
<pixelherodev>
Though, admittedly, I forgot to delete the *fucking partition wasting 50GB of my 240GB SSD for three fucking months!* Gah
<pixelherodev>
That's... that's probably the first time I've been annoyed enough to curse in this channel :P
<pixelherodev>
And naturally, it's with myself
<pixelherodev>
CI failed :(
<pixelherodev>
failing_allocator and logging_allocator apparently call shrinkFn directly
<andrewrk>
they should go through the std.mem.Allocator interface instead
<pixelherodev>
Will submit regression fix after I finish typing up my initial step1 refactor design
<rageoholic>
I just submitted a PR to put constants for kibibyte, mibibyte, and gibibyte into the stdlib
<rageoholic>
Because 3 LINES
<pixelherodev>
`KiB/MiB/GiB`?
<rageoholic>
Yup
<pixelherodev>
The problem with that is that e.g. `16 * std.KiB` is awkward
<pixelherodev>
Worse than just `0x4000`
<rageoholic>
Then import the symbols
<pixelherodev>
Right, but that's a bit... overkill
<rageoholic>
I prefer the former to the latter
<pixelherodev>
I think that a namespace like `std.constants` would be useful
<rageoholic>
Yeah that's true
<pixelherodev>
'cause then you can do `usingnamespace std.constants` and get those and anything else useful without having to manually use them, and without them interfering if unwanted
<rageoholic>
Fair but until we have that std.mem is the best place for them to live
<rageoholic>
And I just realized I did it off master.... fuck me
<rageoholic>
Should have forked
<pixelherodev>
s/forked/branched/ ;)
<pixelherodev>
Not that it matters, since it's in a soft fork anyways (a GitHub fork)
<rageoholic>
branched yes. Oh well.
<rageoholic>
Yeah but now I'll have to overwrite history and crap and I'll be annoyed
<pixelherodev>
While I definitely think those constants help clarify intent, it's probably not that helpful unless the stdlib is also patched to use the constants, which should probably be a proposal before any work is done
traviss has quit [Remote host closed the connection]
<pixelherodev>
(basically, just open an issue titled something along the lines of `Proposal: add std.constants and update stdlib to use them` and wait for approval before continuing)
<pixelherodev>
No reason to go to that kind of effort if it won't be merged
<rageoholic>
fair enough. How can I strip my last commit from github.
<rageoholic>
I pushed too quick
<pixelherodev>
Get the local history where you want it
<pixelherodev>
then `git push -f` (-f == `--force`, which should only ever be used if a) the history is *wrong*, and b) nobody depends on the remote)
<pixelherodev>
(design for step one of the refactor: building a complete project tree)
<pixelherodev>
For clarification: refactoring imported packages is not actually supported, and importing packages at all is only done to validate that the import is valid
<pixelherodev>
Which is really only needed to ensure that types used are valid
<rageoholic>
I'll be honest my reading comp is starting to go
<rageoholic>
I need tea to stay up
<pixelherodev>
Same :P
<pixelherodev>
Nice thing about tea is that it has other stimulants and chemicals which counteract the negative effects of caffeine while boosting the staying-alive aspects :)
_whitelogger has joined #zig
<andrewrk>
pixelherodev, I pushed the layneson-cpus_and_features branch. it doesn't build, due to needing to update all the rest of lib/std/target/* files to follow the pattern set by lib/std/target/aarch64.zig
<andrewrk>
I plan to spend basically all of tomorrow doing vim macro hackery to update the rest of the 17,000 lines
return0e_ has quit [Read error: Connection reset by peer]
return0e has joined #zig
<pixelherodev>
All the more time to work on the refactorer :)
<pixelherodev>
Also... I may have accidentally swapped the alignment and the size in that regression fix :( https://xkcd.com/1739/
return0e has quit [Read error: Connection reset by peer]
return0e_ has joined #zig
<pixelherodev>
Okay, and I wish I was joking, but I can't commit the fix because... *reasons*
<pixelherodev>
GPG: unknown system error
<pixelherodev>
gah
<pixelherodev>
...and now it spontaneously started working again... okay then...
<rageoholic>
Welp, night
rageoholic has left #zig ["ERC (IRC client for Emacs 26.2)"]
<pixelherodev>
night
knebulae has joined #zig
<pixelherodev>
What's the idiomatic way to read a full file regardless of size? readAllAlloc with max_size of @max(u64)?
<andrewrk>
the max_size parameter is there to remind you to set a limit, but yeah you can give std.math.maxInt(usize)
<pixelherodev>
The idea is that if it should attempt to read it all regardless of size
<pixelherodev>
If it can't - well, that's what the OOM killer is for
<pixelherodev>
If the user wants to load in a giant file, that's on them
<pixelherodev>
Might do e.g. check size and if above X ask for confirmation first
<pixelherodev>
e.g. `if size > 50% of $[`grep MemAvailable /proc/meminfo | sed -e 's/MemAvailable: //' -e 's/ kB//'`*1024]` then warn
<pixelherodev>
And yes that's a combo of pseudocode and POSIX sh. That's not the point :P
<pixelherodev>
and also Linux dependency
<pixelherodev>
ohh
<pixelherodev>
andrewrk, the reason they weren't using the interface is that new_align in shrinkFn isn't comptime
<pixelherodev>
Whereas the interface requires it to be comptime for reflection
<metaleap>
yeah the last line isnt hard to parse once its own of the tiny editor panel
<betawaffle>
when i use addAssemblyFile in build.zig, what assembler is used? (i want to read the documentation)
<mq32>
betawaffle: probably the clang/llvm assembler
<betawaffle>
ok, next question... is it possible to build some zig code as 32-bit, and some as 64-bit and link them together into a single elf binary? (think a kernel that starts in 32-bit mode and switches to 64-bit)
<betawaffle>
also... is it possible to compile and link llvm-ir assembly files into a zig program?
mahmudov has quit [Ping timeout: 268 seconds]
mahmudov has joined #zig
return0e has quit [Remote host closed the connection]
mahmudov has quit [Ping timeout: 240 seconds]
dddddd has joined #zig
lanodan has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<metaleap>
in which case "correct" (actually divisible) nats produce correct results (10 / 2 = 5) but others "bogus" such as 10/3 = 2863311534 ?
<metaleap>
or does zigs divExact have a different meaning
<mq32>
metaleap, yeah, divExact only works when the divisor is a integer divisor
<mq32>
it also asserts this in safe mode
<metaleap>
but both args to @divExact are always ints i thought.
<mq32>
yes
<mq32>
but 5/2 is not a integer division but has a remainder
<metaleap>
gotcha, "divisor" through me off because both operands need to be "ints" but yeah got it, thx
<metaleap>
so basically like described in the gmp-divexact.php above
<mq32>
yeah, seems so
epmills has joined #zig
return0e has quit [Ping timeout: 265 seconds]
<metaleap>
funny find while searching for zig-related stuff: "zen-lang.org" with `comptime` syntax too https://zen-lang.org/ja-JP/docs/ch12-comptime/ --- thought it's a Zig-docs-in-Japanese tho only 4 mentions as per searching `"zig" site:zen-lang.org` ... also "The Zen Programming Language are trademarks of connectFree corporation in Japan and other countries." :D :D :D
<metaleap>
so i'd say.. another "achievement unlocked": the first eastasian clones appear
metaleap has quit [Quit: Leaving]
metaleap has joined #zig
<Snektron>
zen was a fork of Zig by a pretty active contributor
<metaleap>
oh i see that explains it =)
GrooveStomp has joined #zig
<karrick>
Wait why would someone fork it?
<GrooveStomp>
What's the format string to print out a 4 character hexadecimal value? I know {x} or {X} works for hex, but not satisfying the width constraint.
<mikdusan>
{x:4}
<mq32>
GrooveStomp: {X:0>4} will right-align a 4-digit-hex value and fill with 0
<GrooveStomp>
Thank you mq32!
<karrick>
Those are both good to know.
epmills has quit [Remote host closed the connection]
mahmudov has joined #zig
epmills has joined #zig
<GrooveStomp>
If I want to assign the string "XX" to a variable, I can use the type '*const [2:0]u8', but what type would I use if the length of the string is not constant?
<GrooveStomp>
ie., now I want to assign "XXX" to the same variable.
<mq32>
var str : []const u8 = "hello";
<mq32>
str = "world!";
<GrooveStomp>
Oh geeze. Thanks again! You can tell I was just fixing compiler error and naively fixed the exact error. :-)
<GrooveStomp>
I've been padding the string with empty spaces until now...
<mq32>
:D
<mq32>
slices are quite handy :)
<GrooveStomp>
I tried to do something with a slice... but it was an awkward contortion. I don't remember what it was, but it didn't work quite like your suggestion! :-)
<karrick>
When learning Go for some reason slice syntax befuddled me quite a bit. Now I’m a fan, but still need to learn Zig syntax.
<mq32>
GrooveStomp, i remember that you tried storing string literals in mutable slices (which doesn't work)
<GrooveStomp>
Yup, definitely tried that.
<keegans>
is it possible to use comptime as a block expression? so I can return a value from it? it doesn't seem like it
<keegans>
i guess i can use a comptime var and set it from inside the comptime block
<mq32>
keegans:
<mq32>
const foo = comptime blk: { var x = 10; break :blk x; };
lunamn_ has quit [Quit: leaving]
<mq32>
should wrk
<keegans>
oh i got the blk and comptime in the wrong order pfft
<keegans>
somewhat unexpectedly the break :blk <val> needs to be a variable and not an expression
<keegans>
otherwise I get a error: expected token ';', found ':'
<mikdusan>
wut
<keegans>
oh i just needed parenthesis
<keegans>
oops
treeshateorcs has joined #zig
<treeshateorcs>
hey guys, is there anything like rust's include_str!("file") in zig?
<keegans>
@embedFile
<treeshateorcs>
nice! thank you
<keegans>
why is '\0' not a valid character? I want to (at compiletime) append a null terminator to a string so I may use it as a sentinel-terminated slice
<mq32>
keegans: appending a 0-terminator is foo ++ "\n", not foo ++ '\n'
<mq32>
oh, i see
<mq32>
why not just append 0?
<keegans>
i did: `break :b (date_format ++ [_]u8{0})[0..date_format.len:0];`
<keegans>
it works but just doesn't seem like the nicest way
<mq32>
but note that the string literal is already zero-terminated
<keegans>
yeah, unfortunately these are not string literals though
<keegans>
I parse an ini configuration file at compile time to load the configuration
<keegans>
but for certain usages they need to be terminated slices
GrooveStomp has quit [Ping timeout: 268 seconds]
<MaiDouH>
Hi everyone. I just got saved from a big programmer mistake thank to `shr`enforcing the rhs to be comptime known Log2T. And I think that's beautiful
<keegans>
stripping my zig executable causes it to SIGABRT ... ???
<metaleap>
sobeston: better comment right in there so folks get notified, this place here is eerily quiet on sundays it seems =)
<metaleap>
question to zig compiler initiates / in(ti)mates: when `switch (true)` with the cases being rather involved runtime bool conditions, the compiler wouldn't ever re-order them right? (motivation? when multiple-`if-elseif` blocks chained together with fat logic inside them grow too large, going for `switch` with its `=>` markers clearly delineating the major cases is a real readability/scannability boon)
<fengb>
Zig doesn’t but I’m not sure what LLVM does
traviss has joined #zig
<metaleap>
fengb: so that kind of `switch(bool) { someIntricateRuntimeCond => ..., someOtherIntricateRuntimeCondOnlyCheckAfterwards => ... }` has a direct LLVM-IR equivalent? would have thought all that exists in there would be JMPs .. never studied their IR in as much detail as i've been meaning to
<metaleap>
s/LLVM-IR/LLVM-IL
<fengb>
Although... I’d expect switched to be pre evaluated because I’m not sure how else a jump table would work
<sobeston>
thanks, have commented @metaleap
BaroqueLarouche has quit [Quit: Connection closed for inactivity]
<fengb>
I think I’m misunderstanding. I thought every switch branch must be comptime known
<metaleap>
ooh could be, hope not but gonna find out in a sec :D (had sth else to fiddle while I asked away)
<metaleap>
yeah, so it appears
<metaleap>
too bad because support for this could be mere sugar to transform into `if`s. but switches with their => are nicer readable for big-blocks on any of a substantial (>=3) number of conditions
<metaleap>
well not so critical either, tho :D fluff stuff
BaroqueLarouche has joined #zig
epmills has quit [Remote host closed the connection]
epmills has joined #zig
rageoholic has joined #zig
<rageoholic>
Mooooorrrrrnnnnniiiiinnngg
<mikdusan>
metaleap: if I grok zig IR for switch, first ranges are hoisted to if/branches. then regular items (non-ranges) make up the switch table which has a branch for each item. this is then codegen to LLVM-IR similar. range if/branches first. items inside a switch with branches for each. there is no re-ordering of items that I noticed.
* rageoholic
stretches tiredly
<metaleap>
mikdusan: what ya mean by "ranges" wrt `switch`?
<pixelherodev>
I don't think using switch as if/else like that is a good idea...
<pixelherodev>
Maybe set an enum based on a bool and switch on that?
<metaleap>
pixelherodev: yeah i have just proposed what you suggest, for that to be ergonomic/productive/hi-leverage some of the existing inference powers should/could be marginally magnified I currently believe, as outlined here: https://github.com/ziglang/zig/issues/4241
<pixelherodev>
Eh, I'd honestly say if/else chains properly formatted seem easier to read
<fengb>
Sounds like “cond” from Lisps
<metaleap>
lisp conds, how so ?! i just want anonymous enums , like the anonymous structs we can pass to std.fmt / debug.warn :D
<mikdusan>
metaleap: `5 => {}` is item. and `5,9,10 => {}` is sugar for 3 items, and here is a range `100...200 => {}` and some sugar is allowed to `100...200,95,90,500..900 => {}` so 2 ranges, 2 itmes
<metaleap>
mikdusan: aaah thx i should have figured *slaps-self*
<metaleap>
the only lisp cond i know is what others call the ternary and zig has already as if-exprs
<metaleap>
well if theres already selective-desugaring-of-*some*-switches-into-ifs .. there's no real "need" for comptime-known-cases or what am I missing =)
<fengb>
Because Lisp cond is just a macro for nested if statements
<metaleap>
oh neat to see zig IR (or lets name it zigIL =)
<fengb>
zIRg
<metaleap>
the bunch of locals in bulk on top are wild... and indeed they all DO contribute to %12 in the end!
<metaleap>
chic
epmills has quit [Remote host closed the connection]
<fengb>
mikdusan: you know that Gists were created for sharing code like this 🙃
adamkowalski has joined #zig
<adamkowalski>
I'm running zig master branch and I'm getting an error when building
<adamkowalski>
reference to unknown field is_exhaustive
<adamkowalski>
even with a fresh project that only has a single line which just warns hello world
<traviss>
anyone know approximately which recent commit broke inline while / for loops?
epmills has joined #zig
Akuli has joined #zig
<metaleap>
adamkowalski: if happens with any old minimal helloworld, sounds like a regression to report .. then revert to prior-day master ..
<Snetry>
Whats the prefered way of gathering the source code for packaging? the git tags or tarball on the homepage
adamkowalski has quit [Remote host closed the connection]
<cota>
Is there a way to assign ~0 to a variable at compile time? i.e. 'const v = ~0;' -> Semantic Analysis [685/964] ./sim.zig:177:15: error: unable to perform binary not operation on type 'comptime_int'
<mq32>
treeshateorcs, use aa slice instead of an array
<mq32>
fn calculate_words(words: []u8)
MaiDouH has joined #zig
<treeshateorcs>
ah, right! thank you mq32
<treeshateorcs>
hm, now this: error: expected type '[]u8', found '[796674]u8'
<mikdusan>
fengb: yeah i keep forgetting if if i _waste_ the first part of gist, the replies can do syntax formatting.
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<metaleap>
treeshateorcs: if you change your arg from []u8 to []const u8 your string lit should coerce. you can also at the call site slice your known-length arr via: `arr[0..]`
<metaleap>
as you pass it. might have to do both possibly
<treeshateorcs>
thank you metaleap ! const did it
<treeshateorcs>
but i dont understand why
<metaleap>
what you passed is not mutable
<metaleap>
but []u8 is mutable
<metaleap>
whereas []const u8 is also not mutable (inside)
<mq32>
keegans, btw, improvement for your printNamed: you can omit the type and use var instead, this will allow the use of anonymous struct literals as well
<treeshateorcs>
so i need to declare everything that is not mutable const?
<treeshateorcs>
i must*
<metaleap>
it depends what the func needs to do and what you want to pass it.
<Snetry>
Hey, I'm trying to package up Zig for Fedora but I'm having some troubles with an uninit error I can not track down
<metaleap>
if the func strictly requires a mutable slice to write into it --- and you only have an immutable arg, then a copy must be made & passed
<mq32>
treeshateorcs, that is a good pattern, ye
<mq32>
*yes
<mq32>
everything you don't want to change, make it const
ur5us has quit [Ping timeout: 258 seconds]
<treeshateorcs>
thanks
<fengb>
The optimizer can do more stuff with const. In Zig it means we don’t have to store it on the stack
epmills has quit [Remote host closed the connection]
<metaleap>
with the caveat that const only applies to ptr args (incl. slice types) and is invalid syntax on other types for args: the value being passed is "immutable anyway"
<metaleap>
whereas for locals this whole thing is indicated by using `var` or `const`
<fengb>
Oh you mean function args? Ignore what I just said :P
<fengb>
I should stop responding without context
<metaleap>
yeah its about the args type qualifier in treeshateorcs case
<fengb>
For function args, const protects the caller from making bad assumptions, protects the function from accidentally mutating, and allows more general usages. So you should always do it if it’s possible
<fengb>
Gets more apparent with strings since most of those are const and functions that only take `[]u8` are really hard to use
<metaleap>
"so you should always do it" is generally true but it depends also on what you pass it to. to alloc you'll need a *Allocator so cannot take a *const Allocator etc. but its easy to get used to i found. depends where one is coming from, perhaps
<fengb>
Hmm that’s a good point
<metaleap>
compiler guides one nicely, mostly. i imagine in C it would just gobble up whatever and leave the headscratching for run time not comp-time
<metaleap>
at least from my most recent impression of C, ca. late 90s :D
<treeshateorcs>
>parameters are immutable
<metaleap>
yes
<treeshateorcs>
no way to change function arguments?
<metaleap>
i'm not sure if you can change them as locals but wouldnt be visible to the caller
<metaleap>
except for ptrs (incl slices) not declared const
<metaleap>
these, you can write into (the members / elements) or call their mutating methods
<treeshateorcs>
so if i want to change an array i need to declare it as a slice?
<metaleap>
either pass a ptr to the arr or a slice of it (which is also a ptr to the arr with len info too)
<metaleap>
hence your func can write inside it and the caller will get to keep the changes
<treeshateorcs>
thanks
<mq32>
<treeshateorcs> no way to change function arguments?
<mq32>
nope, as zig allows to compiler to decide if an argument is passed by-value or by-reference
<mq32>
which means, zig can decide that it's faster to pass a structure as a pointer
<mq32>
which is really nice for performance
epmills has joined #zig
<treeshateorcs>
according to my feeble-brained tests zig is at least 10 times faster than rust. i wonder why performance is not even a goal
<metaleap>
compared dbg-vs-dbg builds and releasefast-vs-releasefast builds?
<karrick>
I don’t think Rust ever wanted to solve performance related problems. They seem more interested in solving programming safety.
<treeshateorcs>
release vs release
<treeshateorcs>
releasefast vs release
<karrick>
As in make the Rust language impossible to write memory unsafe programs with
<pixelherodev>
Zig is also AFAIK the fastest non-asm language currently alive, language-wise at least
<pixelherodev>
Idiomatic Zig outperforms idiomatic C and idiomatic C++ at runtime, with a metaprogramming interface vastly superior to C++'s
<torque>
not sure it's reasonable to make such bold claims on the basis of such a trivial example
<pixelherodev>
True
<pixelherodev>
But in terms of the standard library / syscall count, I don't doubt it
<pixelherodev>
In terms of actual language performance on large scale projects? We'll have to wait and see
<torque>
but I think the coolest part of that blog post that I haven't seen anybody acknowledge is that zig is the only language there that has explicit error handling
<pixelherodev>
For starters though, it's gotten easier to write the Zig example Drew used
<pixelherodev>
Only one try is needed thanks to - IIRC Andrew's work - making it so that getting stdio couldn't fail on win
<pixelherodev>
Size seems to have gone down *slightly* to 10.2KiB instead of 10.3KiB for release small :P
<metaleap>
treeshateorcs: you on zig nightly or your distro's 0.5.0 pkg?
<treeshateorcs>
i switched to zig nightly
<pixelherodev>
I'm on git master branch
<treeshateorcs>
before running this test
<pixelherodev>
Updated yesterday
<pixelherodev>
I think
<pixelherodev>
yeah, definitely; it's up to date with the caveat that failingallocator and loggingallocator are broken because of unfinished changes
<pixelherodev>
Huh - release-safe seems to have gotten a bit bigger actually
<pixelherodev>
by 4KiB (from 11.3->15.3KiB)
<pixelherodev>
And there's now a fourth syscall (though still three unique syscalls)
<pixelherodev>
Though to be fair I shouldn't be trying to replicate Drew's results
<pixelherodev>
Differing Linux distro / LLVM version / Zig version / kernel / etc, and he's explicitly said trying to replicate those would be a waste of time
<fengb>
Back to function args, Zig can decide that a simple struct (8 bytes) should pass by register, slightly bigger ones can pass by multiple registers, and large ones by pointer. It’s a “free” optimization compared to C
<Snektron>
Im pretty sure thats a perfectly valid thing to do for a C compiler
<Snektron>
it requires a little more work to make that happen though due to ye olde headers
<fengb>
C spec defines how args are passed. Zig intentionally marks it undefined
<Snektron>
but LTO or inlines should do the trick
<Snektron>
I doubt compilers have to adhere to c calling convention with non-exported funcitons
Akuli has quit [Quit: Leaving]
rageoholic has quit [Ping timeout: 265 seconds]
kristoff_it has joined #zig
<metaleap>
Snektron: but then such compilers should hopefully detect arg mutation inside a func where it decides to use a pointer for a syntactically "value-copy pls" signature
<metaleap>
and that would go for propagating to subsequent calls etc. because in my limited understanding in C you write what you want and get it. but might be missing something , my only hands on ptr exposure outside of zig was go
jjido has joined #zig
<pixelherodev>
Third try on regression fixing the failingallocator and loggingallocator pushed
<pixelherodev>
This attempt requires that the alignment passed to FailingAllocator.shrink and LoggingAllocator.shrink be comptime known, which IIUC is basically true anyways
<treeshateorcs>
so does zig automatically inline functions when possible?
<pixelherodev>
99% sure
<treeshateorcs>
nice
<pixelherodev>
Because it uses the same backend Clang does
<pixelherodev>
And most optimizations for LLVM-based languages are done at the IR level IIUC
<treeshateorcs>
IR?
<pixelherodev>
Intermediate Representation
<pixelherodev>
Basically, meta-assembly language
<treeshateorcs>
ah
<treeshateorcs>
i need to read up on that
<pixelherodev>
Only if you plan on doing toolchain work
<epmills>
want to target wasm and return struct from zig back to js. anyone have luck with 'complex types'? i understand passing/returning ints.
<pixelherodev>
Not a clue sorry
<pixelherodev>
Haven't used WASM
<epmills>
pixelherodev: thx
<metaleap>
treeshateorcs: prepend `inline` to `fn` if for some cases you wanna be sure / enforce it
<pixelherodev>
Yeah, unlike in C, a function marked `inline` in Zig will always be inlined.
<metaleap>
or else compile-time fail, so you know whats up
<treeshateorcs>
yeah, i read in the docs that if it can't be inlined it will be a compile time error
<treeshateorcs>
right
<pixelherodev>
How do you open a directory?
recombinant has joined #zig
<pixelherodev>
Not a subdir, just a directory from an absolute path
<pixelherodev>
A lot of the functions have been deprecated, and when they reference a function to use instead, it refers to a relative path
<mq32>
cwd().openDirList("/")
<pixelherodev>
... huh. That's... odd.
<mq32>
yep
<pixelherodev>
Either way, found std.fs.openFileAbsolute, which is sufficient
metaleap has quit [Quit: Leaving]
<pixelherodev>
Only the null-terminated version shows up under std.fs listings
metaleap has joined #zig
metaleap has quit [Client Quit]
metaleap has joined #zig
metaleap has quit [Client Quit]
metaleap has joined #zig
metaleap has quit [Client Quit]
metaleap has joined #zig
<MaiDouH>
Small question to you all! Is it possible to initialize a `struct` field with the result of a `comptime`block?
<pixelherodev>
I think so?
<treeshateorcs>
>fn intRangeAtMost(r: *Random, comptime T: type, at_least: var, at_most: var) var
<treeshateorcs>
this is from std.rand.Random
<treeshateorcs>
what should be the first argument?
<MaiDouH>
I have an array that i use to represent memory for small emulator, i would like to initialize the reserved area with whatever static values have to go in there. Seems like `comptime`is the perfect candidate
livcd has joined #zig
<pixelherodev>
treeshateorcs, that's a self argument, isn't it?
<pixelherodev>
That is, it's used as `random.intRangeAtMost(T, at_least, at_most)`?
<livcd>
is there any real world zig cli tool ?
<treeshateorcs>
doesn't seem like it, pixelherodev because the compiler gives me an error, when i give it only 3 args
<pixelherodev>
livcd, such as?
<livcd>
anything ?
<pixelherodev>
treeshateorcs, not std.rand.Random.intRangeAtMost()
<pixelherodev>
I meant, you have some `r` (maybe std.rand.Random.init()?) and you call `r.intRangeAtMost`
<treeshateorcs>
how do i init this r?
<pixelherodev>
Ah, you need to use a specific type
<pixelherodev>
e.g. SequentialPrng
metaleap has quit [Quit: Leaving]
metaleap has joined #zig
<pixelherodev>
treeshateorcs, DefaultPrng or DefaultCprng
<livcd>
is there a production ready app in zig that people use?
<pixelherodev>
s/Cp/Csp
* pixelherodev
shrugs
<pixelherodev>
Part of the compiler is written in Zig
<pixelherodev>
A C -> Zig translator used for @cImport
<metaleap>
livcd: "production ready" isnt clearly defined, but for most interpretations of that phrase, zig is still experimental fast-evolving early days
<metaleap>
so there's no k8s/docker/redis/rabbitmq/etc equivalent project done in zig and deployed in the wild, yet, AFAIK =) to compare, go appeared 2009 and zig iirc ~2016
<metaleap>
if thats what you consider "real world"
<livcd>
ah i get i was just curious
<livcd>
did not think of docker or similar
<livcd>
coule be a conky plugin for what do i care
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<metaleap>
well you can certainly stdin/stdout with ease by now so if stuff like this exists here or there i wouldnt be surprised
<metaleap>
just not sure about the state of networking in stdlib at present
<metaleap>
then you attempt to give the slice-typed a an array. not on
<metaleap>
& in front, or slice [0..] at the back
<Snektron>
The point is, what lifetime does a zero-sized array literal have if you cast it to a slice
<metaleap>
"cast to a slice" means taking the address. means here the same address that any zero-size value has
<metaleap>
do a `std.debug.warn("{*}", .{ &[0]u8{} });` and compiler errors with "pointer to size 0 type has no address"
<Snektron>
Suppose that means i can pass a stack-address
<Snektron>
or well, what would be a stack address for a nonzero sized array
<metaleap>
=)
<metaleap>
in the above, if you used {s} instead of {*} it would be "conveniently" coerced into the empty string, easily seeable with eg. a ">{s}<" fmt-str
<metaleap>
same i guess if assigned to a []const u8 var. since the len must be 0 the address never really "matters" so maybe you dont get mauled by the compiler but try doing anything useful with it :D
<treeshateorcs>
i can't seem to find anything on the new rules of interpolation in the docs. (this thing - .{}) it was different in 0.5.0
<Snektron>
you might need to look at the source code
<treeshateorcs>
it's called interpolation right?
<Snektron>
I think you might have more hits with "format"
<metaleap>
treeshateorcs: for now your autoritive source of intel is lib/zig/std/fmt.zig from line ~47 :D
<SyrupThinker>
Not usre whether I undestand the question correctly
<metaleap>
if you wanna see the placeholders supported i mean
<metaleap>
the .{} is usually filled with values to be placed into the string, its as simple as std.debug.warn("Name: {s}, Age: {d}", .{ name, age })
<treeshateorcs>
that's what i wanted to hear. thanks
<metaleap>
using this fmt stuff outside of std.debug.warn is a bit hairy .. when constructing a longer string into a buffer, I made me a shorthand helper thusly: https://github.com/metaleap/atem/blob/master/src/zutil.zig#L3 --- this illustrates also what the various std.fmt.format* funcs accept in terms of "callback and such malaises" args
<metaleap>
on the plus side its a thoroughly "as much comptime as possible" api as possible which i'm digging when it comes to compiletime sanity-checks on my string-formattings
metaleap has quit [Quit: Leaving]
metaleap has joined #zig
<pmwhite>
I'm on my Pinebook Pro, and I'm hitting an error that says `reached unreachable code` while switching on an enum. The code works fine on my x86 laptop, so something must be on ARM.
zfoo has joined #zig
metaleap has quit [Quit: Leaving]
epmills has quit [Remote host closed the connection]
<fengb>
metaleap: format() will be changing “soon”. The current signature has been a blocker for async OutStream
<pmwhite>
Note that I'm not hitting an `unreachable` part of my own code, so I'm wondering if this is a bug in the Zig compiler.
pfg_ has joined #zig
<fengb>
We have std.fmt.bufPrint and std.fmt.allocPrint as simple helpers for what you want to accomplish
<treeshateorcs>
what is the equivalent of argc, and argv in zig?
<treeshateorcs>
command line arguments in other words
epmills has joined #zig
kristoff_it has quit [Remote host closed the connection]
<pixelherodev>
pmwhite, probably a compiler bug yeah - I'd definitely open an issue; worse case, it's not, and the issue gets closed
<shakesoda>
pmwhite: how's the pinebook pro been treating you? i'm intending to pick one up on next batch
<mq32>
treeshateorcs: .{} is an anonymous struct literal (so a struct value with an implicitly created type). if you write .{ a, b, c }, you will get a struct with with field names @"0", @"1", @"2" which you can asses like any other field
<mq32>
this is conveniently used for foratting, as it removes the need for varargs in Zig
<treeshateorcs>
ah
<mq32>
so you can use this to store some random stuff as well:
<mq32>
var foo = .{ a, b };
<mq32>
foo.@"0" = 10;
<treeshateorcs>
what type are a and b?
<mq32>
they are just placeholders for anything
<treeshateorcs>
ah, okay
<treeshateorcs>
i have a kinda feature request but i don't know what it is called. would be nice if when you would run `zig build run -- arg ` it treated arg as an argument to the executable
svmhdvn has joined #zig
<treeshateorcs>
to the executable that was built by that command
<Snektron>
I think that was already added
<mq32>
yeah afaik that is possible
<treeshateorcs>
Snektron: it wasn't. at least it's not working right now on master
<mq32>
you probably have to add some stuff in your build.zig, it won't work out-of-the-box
<mq32>
but afaik you can just parse arguments to "zig build run" and pass them to the executable started
svmhdvn has quit [Remote host closed the connection]
svmhdvn has joined #zig
<svmhdvn>
Hi, does anyone know where I can find some documentation on how exactly "dot syntax" works when calling methods on struct instances? Specifically, I'm reading the `lib/std/array_list.zig` source file and I noticed that methods that have a pointer type as the first argument can be called normally on a instance value using dot syntax.
<svmhdvn>
For example, `array_list_val.deinit()` and `array_list_val.append(item)` are both valid. In the former, array_list_val is passed as a Self and in the latter, array_list_val is passed as a *Self. I would like to learn more about these method calling semantics.
mht has joined #zig
<fengb>
Method calls are sugar for passing the first argument in. Similar to Python or Go
<svmhdvn>
Yes I understand that much from the documentation page
<svmhdvn>
but as far as I can see, that makes sense in the first example I gave, but in the second one, the method is expecting a *Self parameter, but the type of the `array_list_val` expression is a Self (i.e. an ArrayList(...)) right?
<fengb>
Ah that’s Zig comptime. ArrayList(...) returns a type so it’s a generic
metaleap has joined #zig
<svmhdvn>
Yes, but when does it get implicitly cast to a pointer before getting passed to the function as its first argument?
<pfg_>
if the first argument is a pointer
<svmhdvn>
the function signature for deinit is `fn deinit(self: Self)` and the function signature for append is `fn append(self: *Self, item: T)`, but the function is being *called* in the same manner: `array_list_val.<method>(...)`
<metaleap>
treeshateorcs: you can out of box do `zig run foo.zig -- arg1 arg2` but the same isnt supported by `zig build`, why is that? `zig build` gets its subcommands such as `run` from your project's build.zig
<treeshateorcs>
ah, okay, understood
<metaleap>
here's how i added what you wanted to my proj the other day: passes in all args after ` -- `
<mikdusan>
and then you make it a pointer if self modifyig
<hryx>
mikdusan: hey, sorry for the silence lately, crazy week. I just got home and tried your patch! Looks great although some tests result in a null deref -- I will investigate after I get some food
<mikdusan>
hryx: I mostly did that patch to verify some assumptions. speculating on the real solve, probably going to involve moving CheckSwitchProngs out of the branch and make it unconditional. and the "right way" to make analysis run on ranges/items instructions
<svmhdvn>
mikdusan: I don't think that section of the documentation answers my question. I see that I should write a function with a pointer first argument if I *want* it to self-modify the instance I'm calling it with. However, I want to know the exact calling semantics so that I know how exactly the instance I'm calling it with is being implicitly cast to a *pointer* type.
<mikdusan>
svmhdvn: if it's `self: Foo` the compiler will choose for you. and you won't know. if you want to know, make it either `self: *Foo` or `self: *const Foo`
<svmhdvn>
ah okay that makes sense, thanks!
recombinant has quit [Read error: Connection reset by peer]
svmhdvn has quit [Quit: WeeChat 2.7]
<hryx>
mikdusan: ah, gotcha
<daurnimator>
andrewrk: Re: cpu features, were you serious about 64 of them? note that x86-64 already has more than that.