<FireFox317>
Thanks you so much mikdusan! I solved the issue, because of your helpful messages :)
strmpnk has quit []
strmpnk has joined #zig
strmpnk has quit [Client Quit]
strmpnk has joined #zig
FireFox317 has quit [Ping timeout: 268 seconds]
<mikdusan>
nice! hopefully there are no unwanted side-effects from that insert
qazo_ has quit [Read error: Connection reset by peer]
qazo has joined #zig
seoushi has quit [Ping timeout: 265 seconds]
jicksaw has quit [Quit: ZNC is kill]
jicksaw has joined #zig
seoushi has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
SimonN has joined #zig
SimonNaa has quit [Ping timeout: 272 seconds]
<seoushi>
hmm that was interesting. I got an array out of bounds error 100%. then I decided to add a warn to print the len and index and the error stopped. removed it and it came back again. updated zig and it works.. Guess I found a regression that was fixed.
doublex__ has quit [Remote host closed the connection]
doublex__ has joined #zig
rappet has quit [Ping timeout: 248 seconds]
rappet has joined #zig
<seoushi>
hmm and now it's back again. Seems to be some sorta timing issue or something. Gonna see if I can find a small repro case
<daurnimator>
mmm, I've started getting mysterious errors more often lately
<daurnimator>
errors that seem to be unrelated to the code at hand
<seoushi>
so I can't make a small test case but I know that the same code on my other machine worked fine
<seoushi>
guess I can see what commit I was and bisect to see where it broke
notjones has quit [Quit: Lost terminal]
<seoushi>
hmm nope. So it works fine on my macbook but on my arch linux laptop it doesn't
<seoushi>
same revision now
<seoushi>
broken on my pop os desktop as well. so perhaps something was broken on linux.
<seoushi>
daurnimator, what os are you running?
<daurnimator>
seoushi: linux (x86_64)
leeward has joined #zig
<leeward>
Is it a bug that @exp2 doesn't work for integer types?
<wilsonk>
seoushi: if you have the code available I can test it on a couple operating systems
<seoushi>
wilsonk, sure I can tar it up
<seoushi>
I don't have a small repro case tho
<wilsonk>
no problem, I can compile up whatever you have there
<wilsonk>
have you tried windows?
<seoushi>
I don't have a windows machine
<wilsonk>
ok, I can test on there as well if needed
<wilsonk>
index out of bounds and array_list.zig:60?
<wilsonk>
that is what I am getting here with 'zig build play' with the newest zig from 2 minutes ago
<seoushi>
yeah
<wilsonk>
that is on Ubuntu 16.04
<seoushi>
in entitySysteView.zig line 37 if you uncomment the debug.warn then it's fine
<wilsonk>
ok
<seoushi>
err entitySystemView.zig
<wilsonk>
hmm, nope I removed all cached files and it still gives me the same error here
<seoushi>
hmm interesting
<seoushi>
let me try deleting the cache with the warn and see if it happens then
<wilsonk>
actually it is slightly different, it says 'iterator is 0 len is 140494185971728' on the first line of output
<seoushi>
with the warn I get "iterator is 0 len is 1"
<seoushi>
I deleted the zig-cache folder and built again as well
<seoushi>
latest zig from git. "0.5.0+ab4ea5d3c"
<wilsonk>
0.5.0+14970a1 ... that is from a few minutes ago
<seoushi>
ok will rebuild latest then
<seoushi>
hmm. I'm confused. git says I'm on the latest
<wilsonk>
oh, nope sorry have a merge in there. Your version is the latest
<seoushi>
:)
<wilsonk>
still doesn't explain the different len's though...weird
<seoushi>
is there a standard way for checking for leaks or memory stomping?
<seoushi>
I'm not ruling out that it's my fault lol
<daurnimator>
seoushi: run under valgrind
<seoushi>
did a c allocator and it says an invalid read on line 39. when reading the len of the array I'm guessing
<wilsonk>
sorry, was rebuilding on ubunu 18.04. Still got the same problem with the large len...just so you know
<seoushi>
thanks for testing. not sure what I'm doing wrong.
<seoushi>
the only thing I can think of is entitySystem.zig line 55 doesn't work as I expect
<seoushi>
ok I figured it out. I took a pointer to something that moved because appending it in a arraylist makes a copy (which makes sense). so the pointer got invalided. Why it worked with a debug warn on this system and always on my mac is beyond me tho
<wilsonk>
yeah, that sounds weird
<wilsonk>
which lines did you change?
<seoushi>
in entitySystemView.zig : ~103 I added "self.systemView.__entities = &self.entities;". that fixes it but I'm reworking some design now because it's probably not the only place I made this mistake
<wilsonk>
ah, ok
<leeward>
If anyone wants to use libsodium with Zig, I started a wrapper. https://hg.sr.ht/~nmichaels/sodium-wrapper I was using it at work, and error handling in C made me feel a strong need to do it in Zig.
<daurnimator>
leeward: FYI libhydrogen is created to replace libsodium
<leeward>
There's another one?
<leeward>
Sigh
<daurnimator>
essentially libsodium should only be used for compat with existing libsodium applications
<daurnimator>
libhydrogen is by the same author.
* leeward
researches.
<leeward>
Does it have the kind of rigor behind it that NaCl has?
<daurnimator>
yes
<leeward>
I'm not seeing a lot of security engineers in the contributor list.
<leeward>
Though I do see a conspicuous single commit contributer at #10.
<daurnimator>
it's essentially all the lessons of libsodium distilled into a new library
<leeward>
Huh, there's a link to libhydrogen at the top of the libsodium docs, but...no text about it.
<leeward>
Well, too late to do anything with it tonight, but I'll take a look at it tomorrow.
<daurnimator>
leeward: *and*.... you might realise that the zig standard library has most of the lego pieces in it to clone libhydroden
<leeward>
daurnimator: I stay away from actually implementing crypto stuff. Too fraught.
<daurnimator>
FWIW I found the gimli papers to be some of the most approchable crypto papers I've ever seen
<daurnimator>
I feel like I really understood how it works and why the decisions were made; instead of getting lost like in other papers and having to trust the math..
lunamn has quit [Ping timeout: 272 seconds]
lunamn has joined #zig
lunamn has quit [Ping timeout: 272 seconds]
lunamn has joined #zig
seoushi has quit [Ping timeout: 260 seconds]
ur5us has joined #zig
mikdusan1 has joined #zig
mikdusan has quit [Ping timeout: 248 seconds]
return0e_ has joined #zig
_Vi has quit [Ping timeout: 246 seconds]
leeward has quit [Remote host closed the connection]
<mq32>
i really should start looking at the source instead of the online docs. there's just too many functions missing
ur5us has quit [Ping timeout: 260 seconds]
mikdusan1 is now known as mikdusan
waleee-cl has joined #zig
qazo has quit [Ping timeout: 272 seconds]
_Vi has joined #zig
<daurnimator>
mq32: that just means you need to add more tests
<mq32>
heh, yeah... :D
<mq32>
i cannot argument against it
qazo has joined #zig
aperezdc has joined #zig
return0e_ has quit [Ping timeout: 240 seconds]
return0e_ has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
Snetry has quit [Quit: left Freenode]
Snetry has joined #zig
marmotini_ has joined #zig
dddddd has joined #zig
marmotini_ has quit [Ping timeout: 268 seconds]
<betawaffle>
oh *that's* why the docs are missing so many things?
<mq32>
yep
<mq32>
the current doc generator can only document what is referenced by the code
<betawaffle>
does it skip stuff that has doc comments but aren't referenced?
<mq32>
yes
<mq32>
doc comments dont instantiate functions
waleee-cl has joined #zig
Barabas has joined #zig
<Barabas>
Hey, when I run 'zig fmt' it seems to create a backup file or something next to the source file. How do I disable this? It's really annoying since my editor runs fmt automatically everytime I save a file. So I end up with a gazillion of these.
<fengb>
Zig skips analyzing anything that's not referenced. It's a boon and a curse
<betawaffle>
surely a flag could be added to force analyzing unreferenced things
<betawaffle>
like, it would also be nice to occasionally be able to see "what isn't referenced"
<fengb>
There's an issue for that. It's not as simple, becuase that'd force all of the OS libraries into existence at once
<betawaffle>
fair enough
<fengb>
Laziness is how Zig handles comptime feature detection
<betawaffle>
but surely there could be a certain "level" of forced analysis that would be sufficient for things like doc comments
<fengb>
Lemme find the issue
<fengb>
There's a plan. Library docs weren't really on the plan for stage 1 but people complained enough >_>
<betawaffle>
does llvm have a C backend? it'd be neat to be able to output to C in some situations
<BaroqueLarouche>
unfortunately no
<Barabas>
Why do you want to read C code?
<betawaffle>
i don't want to read it
<BaroqueLarouche>
GCC has more backend for legacy CPU targets
<BaroqueLarouche>
many embedded board has custom forks or proprietary C compilers
<betawaffle>
my thinking was for situations when you want to convert a zig program into C for compilation where zig isn't available
<Barabas>
Ah
<fengb>
Zig's plan is the opposite
<betawaffle>
could be a good way to bootstrap, don't you think?
<fengb>
Stage 1 should work in any C++ native target, then bootstrap the real compiler
<betawaffle>
right, but that requires maintaining enough of a compiler in C++ forever
<fengb>
I think having a C backend is nice, but I don't think it's on anyone's radar atm
<fengb>
Of course, C++ isn't C so... still not as nice
<fengb>
Oh there's a comment on why C backend isn't ideal for the main usecase
<fengb>
I think it's definitely a nice to have though
<betawaffle>
hmm, well his response about C code doesn't make much sense to be, since C is source code (in a sense), it's not the original source, but it can be part of the tarball for the bootstrapping scenario
<betawaffle>
and the reason i think it would be ok, is that the C code would (ideally) be cross-platform, such that it's the same code everywhere, trust is not such an issue
<fengb>
It's generated and unreadable. Distro maintainers tend to trust the actual source instead of intermediate code
<betawaffle>
fair enough
<fengb>
For what you're asking though, it makes perfect sense. But wouldn't it be nicer to port Zig to the platform instead? 🙃
<fengb>
(I know that's not always possible because of proprietary compilers, but I can dream)
<betawaffle>
by writing C++ code? nah
<betawaffle>
for me, C++ means a project i'm OK using, but not contributing to
<betawaffle>
if it was Java, i wouldn't even be super comfortable using it
<BaroqueLarouche>
the stage1 compiler code is more C-like and use C++ features only when really necessary, of what I have looked so far
<fengb>
Yeah most of the C++ is templates, methods, and integrating with Clang/LLVM
<betawaffle>
yeah, from what i saw it didn't seem all that bad
<shakesoda>
i definitely avoid contributing to c++ projects too, as a (begrudging) long time c++ user
<betawaffle>
i wish i wasn't such a rewrite-it-in-ist
* shakesoda
vastly prefers to use C when given a choice
<companion_cube>
what about C+basic templates?
<shakesoda>
betawaffle: nice thing about zig is that you don't have to go all in on that just to start
<fengb>
I told an old coworker I'd much rather use C than C++ and he basically gave me the middle finger
<BaroqueLarouche>
I have a stockholm syndrome with C++
<shakesoda>
fengb: it's a good filter for people to not work so much with ;)
<fengb>
Yep, he's the reason I left the job :P
<betawaffle>
i definitely prefer C, but that's because I don't have to use either on a daily basis
<fengb>
Of course, reimplementing generics in C is pretty terrible
<companion_cube>
for me C++ is in projects I'd rather not contribute to, but sometimes I guess C++ was the best choice at the time
<betawaffle>
i can say what i want up on my ivory tower high horse
<fengb>
C++ has that 20% of features people like. Unfortunately it's not the same 20%
<shakesoda>
companion_cube: i'm largely okay with c++ uses c++-isms sparingly
<companion_cube>
fengb: i think pretty much everyone agrees on templates + RAII
<companion_cube>
(simple templates, mind you)
<shakesoda>
not me!
<fengb>
Templates are better than void*, but people also abuse the hell out of templates
<shakesoda>
not much a fan of raii, and templates cause absolute madness :\
<companion_cube>
they should od a subset of the language…
<shakesoda>
i vastly prefer c99 or so
<fengb>
Call it... C++--
<companion_cube>
shakesoda: really? can't even write a vector without them :/
<shakesoda>
companion_cube: have you seen "orthodox c++"
<betawaffle>
i still can't get over how much better zig does generics compared to every other language i've seen
<companion_cube>
how do you survive
<BaroqueLarouche>
if the epoch proposal gets accepted, it will allow the commitee to finally remove legacy from the language and clean things up
<shakesoda>
betawaffle: +1, for many other aspects of zig too
<fengb>
I think it's amazing that Zig's generics wasn't even a solution, but a byproduct of comptime
<companion_cube>
shakesoda: haven't
<shakesoda>
zig's design in general tends to align with my interests, enough of the time that i'm here & enthusiastic :)
<shakesoda>
companion_cube: you can do vectors and such without them, but yes they are certainly helpful for doing containers like that
<companion_cube>
not in C you can't
<betawaffle>
i was really surprised to find that zig had solutions to most of the things i was bugged about other languages not addressing at all
<shakesoda>
i'm far too used to doing my data structures in c, they always end up simpler without any of the c++ madness...
<BaroqueLarouche>
Zig is going to be the C++ replacement I wanted for so long, after trying D, Rust
metaleap has joined #zig
<companion_cube>
shakesoda: i don't want to *do* data structures, I want to use them, they should already be there
<companion_cube>
and C does't give you anything to enable that (please don't say "macros" :p)
<shakesoda>
companion_cube: i don't really want to get too deep into this language fight :(
<betawaffle>
i still think zig could do a lot better in some aspects of close-to-the-metal problems
<betawaffle>
bools in packed structs are not good enough yet.
<companion_cube>
shakesoda: we can take that in pv if you want, I'm really curious, it's what makes C unbearable to me
<betawaffle>
i know there are proposals to address some of my problems, though
<shakesoda>
BaroqueLarouche: i agree
<shakesoda>
and it does it by... not trying to be like c++ :D
<fengb>
I'm just happy that Zig solves all of my needs from C without adding a bunch of things I don't understand or really care about
<BaroqueLarouche>
D has been started in early 2000 and hasn't taken off yet, going with a GC for a system language was a huge mistake
<shakesoda>
companion_cube: i have no aversion to implementing specific data structures nor to throwing a macro around for stretchy arrays - these things are perfectly tolerable and clear to me personally
<fengb>
Go is totally a system language 🙃
<Barabas>
If you use C++ enough you'll learn to hate it. :P
<Barabas>
Some things are nice, sometimes... but most of it just helps you shoot yourself in the foot.
<betawaffle>
fengb: except it doesn't interface well with C or debuggers generally
<betawaffle>
i love go, fwiw
<fengb>
I'm joking. That was a jab at the marketing when it first came out
<shakesoda>
companion_cube: i take no issue with this not being the case for anyone else, but for my purposes i don't actually miss any of the language features c lacks except for lambdas
<fengb>
Barabas: but C++ is so good, you can shoot everyone in the foot!
<shakesoda>
the generics issue just isn't really one that... matters, in the vast majority of my code
<Barabas>
fengb yeah that's the cool thing about it!
<Barabas>
At work I continue to see bugs that happened because of C++ features.
<Barabas>
All kinds of implicit crap, mostly conversions actually, that end up being unintended.
<shakesoda>
Barabas: that's been *constant* in every single c++ codebase i've ever worked on
<shakesoda>
Barabas: and constructs which are just plain incomprehensible, usually brought in by someone who decided it'd be okay to haphazardly throw in some boost headers
<fengb>
shakesoda: generics lets you write a reusable library that's properly typechecked. I do agree that it's easier to write my own in C, but with generics I can just import a LinkedList instead of writing it for the nth time
<Barabas>
I hate boost with a passion =D
<BaroqueLarouche>
Barabas: who doesn't expect people contributing to boost ?
<fengb>
Same problem in Go actually. Because it has no generics, the libraries have crazy hacks to pretend like there's generics and it's really easy to get wrong
<betawaffle>
and performance/clarity can suffer
<Barabas>
One of the problems with C++ is that it has some things which seem nice... but they have all these ugly hooks and things
<Barabas>
And on top of that all the features it has work together in ways which nobody can every truly understand.
<shakesoda>
fengb: i'm not particularly concerned about the correctness of type checks at all times
<Barabas>
And then people abuse the crap out of it =D
<shakesoda>
similarly, i don't mind thinking about memory myself instead of something trying to hide it away
<Barabas>
That's one thing I hate about OO code in C++
<mq32>
shakesoda: the ability to rely on type checks is a wonderful thing, especially if you have critical software that may never do "a wrong thing"
<shakesoda>
this is not also to say that i don't care, just that my distaste for the ever unpopular void* isn't really that strong
<shakesoda>
mq32: absolutely, i don't mean to doubt the value of good type checking
<shakesoda>
mq32: i just mean that when writing C, not always having it doesn't really matter a lot to me - it's just a bonus in these situations
<shakesoda>
not sufficiently compelling for me to jump ship entirely and use c++ or so, with all the new problems that'd bring in
<Barabas>
Things which are nice about C++ is destructors and simple templates. (But I don't always want destructors and templates quickly become complicated.)
<Barabas>
All the other things I really don't care about.
<shakesoda>
defers are *such* a better solution to cleaning things up than... anything else i've ever used
<Barabas>
Yes! <3
<Barabas>
Also because maybe you don't want to clean up.
<fengb>
I agree with that. RAII has too many semantics and I tend to get confused
<shakesoda>
defers and the error handling mechanism are for me the killer feature for zig
<shakesoda>
wonderfully simple and clear
<Barabas>
Yes, it's great. And I really like the comptime stuff.
<betawaffle>
i *really* like the magic error set stuff
<betawaffle>
i kinda wish i could make custom types with that behavior
<shakesoda>
i'm always a bit hesitant with the concept of comptime for the sake of really wanting to avoid inflating build times
<betawaffle>
like dynamic enums
<fengb>
Ha, I have a sorting algorithm running at comptime. It's... slow
<shakesoda>
slow builds are my kryptonite
<fengb>
andrewrk mentioned that comptime is currently 100x slower than what he wants it to be
<shakesoda>
ow!
<Barabas>
That's one problem with features like these. You can go crazy with them.
<shakesoda>
there are a lot of build performance todos, aren't there? at minimum faster comptime, threaded builds, etc
<fengb>
But... it won't be a priority until stage 2, which start soon 🤞
<shakesoda>
and a backend to skip llvm stuff for debug, i think?
<Barabas>
By the way, does anyone know what happened to Vectors/SIMD?
<fengb>
I a verb
<Barabas>
I thought someone was working on that a while ago, but I didn't notice any progress now that I looked.
<metaleap>
i'd like to understand the major motivation(s) for the zig project to drag along a minimal-scoped c++-based zig compiler basically "forever" (iirc)
<metaleap>
do most OSes have a cpp toolchain preinstalled by default? nope.
<Barabas>
fengb aww that's too bad
<fengb>
So any C++ compiler can bootstrap all of Zig
<fengb>
It's important for a new language to receive adoption. e.g. Debian would not allow just any compiler into core unless it was verifiable
<fengb>
Barabas: I think scientes lost interest in carrying the torch, and we haven't had anyone else who's familiar with SIMD and Zig
<metaleap>
fengb: ok if thats the reason (ie. social/cred stuff), i have no need to further elaborate counterpoints. thx =)
<metaleap>
could become a millstone tho --- once adoption is there, it can be dropped to ease & maximize fluid contributions-to-zig currently held back by a cpp and/or and upcoming joint-zig/cpp setup
<fengb>
I think the goal is once stage 2 is real, the C++ compiler will be in maintenance mode and only be tested to compile the stage 2 compiler. No real robustness or anything
<metaleap>
s/and/an
<Barabas>
How do other compilers bootstrap themselves? I guess they start with an old binary?
<metaleap>
fengb: sounds good yeah if it isnt meant to be kept in sync with zig language/compiler capabilities to 100%
<metaleap>
if i were to set up a bootstrappable scenario, i'd devise a byte-code format that's ugly+slow in every aspect except it's easy+most-succinct to write an interpreter for in any lang, any stack, anywhere, any time, in half an afternoon.
<metaleap>
step 2, have that format as one of the compile-output formats
<Barabas>
interesting
<fengb>
Crossplatform byte-code? Sounds like wasm 🙃
<metaleap>
hence there's an interpretable source of the compiler that may take hours to come up and "build itself for real", but who cares
<betawaffle>
metaleap: you could theoretically do that with LLVM, assuming LLVM supports the target in question
<metaleap>
yeah would probably do wasm nowadays here
<metaleap>
it was the old pascal success story with p-code: you could write that interpreter in asm for dozens/100s? of architectures (early 70s was very diverse)
<metaleap>
then you interpret the p-code for "pascal itself" and you get to a binary for your system. maybe not a half-afternoon scope but very succesful & popular back then.
<metaleap>
today it isnt about architectures, but wouldnt it be fun if you could "bootstrap your lang from any python / typescript / go / c#" tiny interpreter hand-coded from a fairly comprehensible recipe =)
<metaleap>
but then soon you'll easily find a good enough wasm interpreter for any system, i expect
<fengb>
Well... wasm isn't a particularly nice language to write by hand.
<metaleap>
not the idea here
<metaleap>
altho it was a nececitty back then with pcode/asm
<fengb>
Hmm I had a stupid thought: what if I create a "full" lisp on top of wasm?
<metaleap>
then you could write a wasm interpreter in that lisp , for one
<fengb>
Since wasm is already sexprs, I should be able to hack in a macro system and translate anything down at the source level
<fengb>
... I need to stop finding new stupid projects
<BaroqueLarouche>
^ my life
<metaleap>
fengb: once you have a few levels of wasm-lisp-wasm-lisp, next, you're gonna wanna get into reynold's definitional-interpreters rhubarb =)
<Barabas>
Another thing I like about Zig is the build-in unit-test stuff
<metaleap>
zig is really full of killer features, but it dawns on one little by little over time. it's almost utopia for me lol
<Barabas>
haha
<Barabas>
HMMMmmm now it found a memory leak in my code...
<Barabas>
Oh, I'm an idiot =D
<metaleap>
i had a beautiful leak the other day. list.ensureCapacity(list.capacity() + foofactor) for a forever-living list. blew up a usually-constant-~3MB-RAM program to gigs in minutes
adamkowalski has joined #zig
<metaleap>
this kind of stupid can be caught by no linter compiler or other tooling :D
<fengb>
Try out the new testing.allocator. It counts allocations for you :)
<Barabas>
Was that in a loop or something?
<fengb>
The strategy is super stupid atm but it's uncovered a few leaks in std
<metaleap>
kinda. stdin-processing main loop with regularly in-streaming input
<metaleap>
fengb: good tip will take a look!
<Barabas>
Super stupid and correct is better than super smart and wrong ^^
<fengb>
It's not correct. It just counts the allocations and makes sure it matches the frees
<fengb>
number of frees*
<fengb>
There's a much better debug allocator in the works so I didn't spend too much time on this >_>
<metaleap>
took a gander, good stuff! (it's also on the side very helpful as a nice minimal template for anyone doing from-scratch custom allocators!) so using your .validate() would happen at program end i reckon. i'm gonna use this for dbg-builds
<mq32>
fengb, std.testing.allocator is by you? neat thing! such practical
<Barabas>
Ok, how do I convert an `f64` to a `[] const u8`?
<mq32>
note that you have to cast to an array of the correct size
<mq32>
and you can slice that array
<Barabas>
Yes
<mq32>
for reinterpreting memory for referencing it later, you can use @ptrCast
<Barabas>
I get: Unreachable at E:\Libraries\Zig\src\codegen.cpp:3327 in ir_render_bit_cast. This is a bug in the Zig compiler.
<mq32>
huh
<mq32>
what exactly are you trying to do?
<metaleap>
Barabas: never forget to report everything "this is a bug in the zig compiler" you hit!
<metaleap>
fengb: it's one idea to count alloc/free calls but couldnt one rather track bytes alloc'd/dealloc'd? if i alloc(10bytes) and then only free(5bytes) is this currently detected? from checking this src i think not but not fully sure (given that allocators implement realloc/shrink, not alloc/free)
<Barabas>
Well, I want to hash my `f64`, and my hash function accepts a `[] const u8`
<metaleap>
fengb: if not might take a stab at hacking that in if feasible. dunno if "old_mem.len" is truthful or rather if it ever *can* be known
<fengb>
metaleap: yes you can, I just quickly slapped something together that wouldn't throw false positives
<fengb>
No guarantees on false negatives! :P
<metaleap>
what i dunno is whether inside any custom realloc/shrink implementation one can tell exactly how many units were intended to be alloc'd/free'd by the caller. gotta read up again the thankfully detailed doc-comments in std.mem
return0e_ has quit [Remote host closed the connection]
<metaleap>
never know how to handle `error.Unexpected` :P
<metaleap>
also `while (canErr() catch |e| switch (e) { error.Foo => continue, }) |item| {}` --- cannot `continue` from the also-technically-existing-in-the-loop parensed-"header" of the `while` =/
FireFox317 has joined #zig
metaleap has quit [Quit: Leaving]
metaleap has joined #zig
<betawaffle>
that's a goofy use-case metaleap
<metaleap>
yeah a while(true) was cleaner in the end anyway
<metaleap>
(with check and break etc inside etcpp)
wilsonk has quit [Ping timeout: 260 seconds]
wilsonk has joined #zig
metaleap has quit [Quit: Leaving]
zfoo_ has joined #zig
adamkowalski has quit [Quit: Lost terminal]
ur5us has joined #zig
_Vi has joined #zig
mikdusan1 has joined #zig
mikdusan has quit [Ping timeout: 265 seconds]
riba has joined #zig
metaleap has joined #zig
adamkowalski has joined #zig
mahmudov has joined #zig
Akuli has joined #zig
Barabas has quit [Ping timeout: 260 seconds]
riba has quit [Ping timeout: 240 seconds]
mikdusan1 has quit [Quit: WeeChat 2.5]
FireFox317 has quit [Remote host closed the connection]
Akuli has quit [Quit: Leaving]
zfoo_ has quit [Read error: Connection reset by peer]
jjido has joined #zig
FireFox317 has joined #zig
<metaleap>
fengb: LeakCountAlloc lookin' good: https://i.imgur.com/HLBH2Dl.png but about that "index out of bounds" / "panicked during a panic", known issue, or unavoidable side-effect? not worrysome for common usage, given its the last step of program/only-test lifetime, but =)
<metaleap>
(doesnt happen when not calling .validate() btw)
<metaleap>
fengb: the print succeeds so no idea here
<metaleap>
basically the validate returns its .Leak just fine, so it's sth happening on the outside but still (in my scenario) provoked by calling .validate()
FireFox317 has quit [Ping timeout: 260 seconds]
seoushi has quit [Quit: WeeChat 2.7]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<frmdstryr>
Does using `const field = somestruct.field` in a fn do a copy & require stack space?
<frmdstryr>
Or does it get optimized out somehow?
<metaleap>
frmdstryr: if it does, i'd wager it isn't guaranteed by the lang but the occasional unpredictable goodie
<fengb>
The emitted code will do a copy, but LLVM can choose to merge it back
<metaleap>
is my newb-to-mem-mgmt interpretation of "reallocFn" semantics here correct? (for the typical case)
<metaleap>
waah imgur link gone from clipboard :D 1 sec
<metaleap>
is my newb-to-mem-mgmt interpretation of "reallocFn" semantics here correct? (for the typical case) --- https://i.imgur.com/sqgAsL5.png
<metaleap>
ah bug in L29 already
<metaleap>
no its ok
<metaleap>
but bug in L32 :D
<metaleap>
ok L32 would be in my understanding `me.bytes_allocd += new_size-old_mem.len;` but otherwise? missing anything?
ltriant has joined #zig
<metaleap>
looks like it can be just 2 lines: me.bytes_freed += old_mem.len; me.bytes_allocd += new_size;
mahmudov has quit [Ping timeout: 265 seconds]
mahmudov has joined #zig
<metaleap>
defer being block-scoped raises an interesting little question: if (foo) { defer bar(); } vs. if (foo) defer bar(); --- same or not? "current scope" is a funky consideration
<mikdusan>
I'm convinced cmake syntax was strongly influenced by COBOL
<daurnimator>
fengb: FYI there are a few places around in the standard library that make their own allocator using a stack buffer that should be converted to your testing allocator
<daurnimator>
e.g. `test_allocator` in http.headers
<daurnimator>
fengb: you can probably find them by searching for `FixedBufferAllocator`
<fengb>
Oh yeah I had a branch that started replacing those
rappet has quit [Remote host closed the connection]
rappet has joined #zig
gchristensen has joined #zig
flokli has joined #zig
<fengb>
Submitted a PR. I remember having some trouble with some of the JSON as well as a few other files
mahmudov has quit [Ping timeout: 260 seconds]
adamkowalski has quit [Remote host closed the connection]