<ifreund>
C bitfield support would be really great to have
slowtype1 has joined #zig
alexnask has quit [Quit: Leaving]
<leeward>
Working packed structs would be really great to have, but we have to wait until stage1 is ready for it.
<ifreund>
i think you mean stage2?
<ifreund>
but yeah I agree, a proper stage1 implementation would be wasted effort
<leeward>
Yes!
<leeward>
What I should have said was self hosted.
<leeward>
I am looking forward to getting them though. They're important for replacing C.
<leeward>
Bitfields have always been kind of a crappy hack anyway.
stripedpajamas has quit [Quit: sleeping...]
Snetry has joined #zig
<ttmrichter>
leeward: You mean implementation or notionally?
<leeward>
implementations
<leeward>
they tend to be bad
ur5us has quit [Ping timeout: 260 seconds]
nephele has quit [Ping timeout: 246 seconds]
<leeward>
Also, the syntax is feels tacked on (probably because it is).
<leeward>
s/is//
ur5us has joined #zig
<ttmrichter>
What bugs me about them most is that the relationship between the bit fields and the bits is undefined.
<ttmrichter>
You can have a standards-compliant C that sets aside a full machine word for every bitfield, regardless of size.
<ttmrichter>
Which renders the one thing I REALLY want to have them for completely pointless.
<leeward>
Yeah, it turns out C is really not designed for embedded systems. It just happens to kinda work ok in them.
<fengb>
C was also not specced out for a long while
<fengb>
So when implementations disagreed with each other, the spec just decided to leave it implementation defined
<ttmrichter>
C became popular because the Unix kernel was free and written in it. That is all.
<leeward>
yep
<ttmrichter>
By any metric C is a terrible programming language.
<leeward>
False! It's very easy to implement.
<leeward>
That's a metric :)
<companion_cube>
is it though? :)
<ttmrichter>
It's easier to implement a Modula.
<ttmrichter>
Modula-2, for example.
<ttmrichter>
Back when I was in practice I could toss out a Modula-2 parser in an afternoon ... maybe a day.
<companion_cube>
was it pascal with ML-like modules?
<leeward>
Parser is a bit different frum implementation, but sure, Modula-2 is also easy to implement.
<companion_cube>
I heard about modula but don't know much else
<ttmrichter>
companion_cube: Basically. Pascal was Wirth's teaching language. Modula-2 was the language he advocated for real work.
<companion_cube>
damn
<leeward>
I mean, if you look at C and see a weird decision, the reason for it is likely "it was easier to implement."
<companion_cube>
another path that'd have been, indeed, better than C
<ttmrichter>
leeward: That or "we couldn't decide which way to go so we threw up our hands and gave up".
<leeward>
Sure, or that.
<ttmrichter>
Modula-2 gave actual modularity, actual data types with actual enforceable properties. (Arrays had SIZES and weren't just syntax saccharine for pointer notation!)
<companion_cube>
wait, is Wirth still working on Oberon?
<leeward>
Arrays with sizes? That'll never catch on.
<ttmrichter>
You could declare variables as falling within a given range: "This is an integer from -3 to +8".
* leeward
looks around shiftily.
<ttmrichter>
companion_cube: I think so, though "work" is a strong term. He seems to have pretty much retired.
<companion_cube>
ah, well, makes sense
<ttmrichter>
Isn't Oberon now up to Oberon-3? I never really followed the Oberon branch.
<companion_cube>
godamnit, and of course, modula-2 has sum types
<companion_cube>
curse you, C
knebulae has quit [Read error: Connection reset by peer]
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 240 seconds]
aruniiird has joined #zig
<ttmrichter>
C was a hack made to provide a high-level assembler to quickly port something to a PDP-11.
<ttmrichter>
Modula-2 is a language designed for engineering purposes.
<ttmrichter>
The difference in feel is palpable.
aruniiird is now known as arun3rd
<ttmrichter>
That feel carries on through Modula-2+ (adding coroutines, if memory serves?) and Modula-3 (adding OOP, and threading). I never worked with 2+, but 3 was nice.
arun3rd is now known as aruniiird
jayschwa has joined #zig
<jayschwa>
Is it possible to `@export` a function without mangling it by prefixing an underscore? I'm messing around with Zig and DOS, and the DJGPP (DOS cross compiler) linker and crt0 use "start". When I declare `fn start() callconv(.Naked) noreturn` and `@export(start, .{ .name = "start" })`, `zig build-obj` is prepending an underscore when I inspect the
<jayschwa>
output with `objdump`.
stripedpajamas has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
stripedpajamas has quit [Quit: sleeping...]
<daurnimator>
it shouldn't for naked calling convention....
<andrewrk>
daurnimator, no I don't see the comment
<andrewrk>
marler8997, btw `nosuspend` does not modify the behavior of suspend points - it's actually an *assertion* that there will be no suspension at runtime
<andrewrk>
it's UB in unsafe build modes if you have a suspend point actually do a suspension in a nosuspend block
<andrewrk>
it won't prevent them, it just promises to the compiler that it will never happen
<daurnimator>
andrewrk: on april 4: > n the traditional libc/POSIX ungetc api, you are only allowed to put back what you last read: a subsequent read makes it undefined if you can fit things in or not
<andrewrk>
I'd like to see that in the doc comments and probably also the function name/return type
<andrewrk>
although, an even better API would be a fixed reserve size
<andrewrk>
if the perf didn't suffer, that would be ideal
<daurnimator>
I don't think a fixed reserve size is a useful idea
<daurnimator>
`putBack` is used in situations where you read something; realise its not what you wanted after all; and put it back
aruniiird has quit [Ping timeout: 256 seconds]
<andrewrk>
I'm ok with that API but it should be reflected in the doc comments and also the function signature\
<andrewrk>
you shouldn't have to use `catch unreachable` for the main use case of an API
stripedpajamas has quit [Quit: sleeping...]
jayschwa has quit [Remote host closed the connection]
_whitelogger has joined #zig
opDispatch has quit [Quit: Konversation terminated!]
riba has joined #zig
riba has quit [Ping timeout: 258 seconds]
stripedpajamas has joined #zig
dddddd has quit [Ping timeout: 264 seconds]
aruniiird has joined #zig
frett27 has joined #zig
penguinicus has quit [Ping timeout: 245 seconds]
frett27 has quit [Ping timeout: 256 seconds]
penguinicus has joined #zig
rappet has quit [Remote host closed the connection]
rappet has joined #zig
ur5us has quit [Ping timeout: 260 seconds]
cole-h has quit [Quit: Goodbye]
_Vi has joined #zig
marnix has joined #zig
knebulae has joined #zig
stripedpajamas has quit [Quit: sleeping...]
tines9 has joined #zig
ur5us has joined #zig
aruniiird has quit [Ping timeout: 260 seconds]
slowtype1 has quit [Quit: WeeChat 2.8]
dermetfan has joined #zig
st4ll1 has quit [Quit: WeeChat 2.8]
<dch>
how are the official ziglang.org/download tarballs generated? They're used in zigler (from last zig.show) and I'd like to see if I can make a freebsd aarch64 tarball at least locally
<andrewrk>
dch, given that I'm not entirely sure what your use case is, I suggest to follow the directions exactly, except where you understand the details enough to stray from the suggestions
<JimRM>
dch, given that I'm not entirely sure what your use case is> we have been looking at ziglar - which is a cool zig integration with Elixir. Ziglar automatically downloads a zig package based on host arch + platform. So to get it working on FreeBSD+Aarch64 we would need a tarball for that combo available.
<JimRM>
andrewk: ^
nikita` has joined #zig
<JimRM>
Assuming the FreeBSD+AARCH64 combo builds without incident, (which it should, I got 99% of the way there on my Rpi4 until I got OOM) - how would we help/look at making this something available as a downloadable package alongside all the other arch+platform combos?
penguinicus has quit [Remote host closed the connection]
Nilium has quit [Ping timeout: 265 seconds]
Tharro has quit [Remote host closed the connection]
Nilium has joined #zig
Tharro has joined #zig
st4ll1 has joined #zig
gazler has quit [Ping timeout: 264 seconds]
gazler has joined #zig
st4ll1 has quit [Ping timeout: 264 seconds]
st4ll1 has joined #zig
ur5us has quit [Ping timeout: 260 seconds]
alexnask has joined #zig
aruniiird has joined #zig
slowtyper has joined #zig
aruniiird has quit [Ping timeout: 246 seconds]
amohan has joined #zig
dddddd has joined #zig
<gonz_>
mq32: Is that a german Spongebob song you have open in the Showtime talk? :D
<mq32>
what are you referring to? My wifi name? *grins*
<gonz_>
Ahh, perhaps
<mq32>
the thing in the bar below is my wifi name
<gonz_>
Is it a Spongebob reference?
<mq32>
yes
<mq32>
"is here the crusty crab?" is my primary wifi, the guest wifi is called "no, here is patrick!"
waleee-cl has joined #zig
st4ll1 has quit [Quit: WeeChat 2.8]
st4ll1 has joined #zig
amohan is now known as aruniiird
<fengb>
Cute
penguinicus has joined #zig
tgschultz has joined #zig
<leeward>
So I was thinking about iterator protocols, and it seems like it's inconsistent with Zig's philosophy. They'd necessarily be implemented with functions, and "no hidden control flow" feels inconsistent with "implicitly calls a function sometimes, unless it's an array or a slice." Is that an accurate interpretation?
<leeward>
The conclusion being that if we want iterators, we have to use `while` and conventions.
<ifreund>
i mean, iterators that work with `while (it.next()) |item|` are already in use and work well
<leeward>
Right.
<leeward>
It's just been suggested that there would be some official sugar that, say, automatically calls next if an iterator is put in a for loop. It seems to me like that's not in the cards.
stripedpajamas has joined #zig
<ifreund>
I agree
penguinicus has quit [Remote host closed the connection]
<shakesoda>
leeward: +1
<shakesoda>
magical sugar for iterators doesn't... fit
<shakesoda>
i also don't want to have to remember how they work
<mq32>
i don't think it's required to have sugar for iterators
<shakesoda>
if you don't then you're just left doing what we already do, which is fine?
<shakesoda>
the case i find the most painful is without question basic numeric for
<shakesoda>
where you have to put a loop counter outside, maybe do the weird glued on :() thing etc and it's just very awkward
<leeward>
I think the fact that there's no way to initialize the thing in the while loop inside the scope of the while loop is the biggest issue. It's surprising to people coming from pretty much every other language.
<shakesoda>
i kind of feel like the funky usage of :() is the real problem i have, it is just absolutely bizarre
<leeward>
Something like `while (var i: u32 = 0; i < 10) : (i+=1)` would solve it.
<shakesoda>
in a "why does this exist, seemingly useful in only this specific case?"
<leeward>
The :() syntax is wierd, but it makes sense since `for` is only for arrays.
<mq32>
shakesoda: i would even go that far and just remove the :() iteratr
<mq32>
it's not necessary in any way
<mq32>
while(a < 10) { defer a += 1; … }
<mq32>
is equivalent
<shakesoda>
mq32: yeah, i'd actually be in favor of that
<fengb>
Breaking the loop skips the iter increment
<fengb>
But it would not skip a defer
marnix has quit [Ping timeout: 265 seconds]
<leeward>
fengb: Good point.
<mq32>
i'm willing to accept this
<mq32>
i've used defer instead of :() in some places already
<shakesoda>
leeward: if we had that kind of form with init;condition then we're already most of the way to just having a c for
<leeward>
shakesoda: Yep.
<shakesoda>
which, while i'd like, is the specific thing being avoided
<leeward>
If the only reason not to do something is "C does it" I'm not convinced. Scoping the loop variable to the loop is available in every language I know that has mutable variables and loops.
<leeward>
Wrapping your while loop in {}s is...hacky at best.
<shakesoda>
the actual reason is that it's special syntax for one specific case where you're doing 3 separate statements in one
<shakesoda>
which is just super inconsistent and weird
<shakesoda>
and also confusing to learn (when you're not coming from a language that works this way, and have forgotten that it is weird)
<leeward>
I get that there's a high bar for syntax that takes mental effort to use, but it's _such_ a common use case.
<shakesoda>
rather, the actual reason AFAIK
<shakesoda>
maybe not the true one :)
<shakesoda>
the while loop increment strikes me as the weirdest syntax exception in zig
<leeward>
Heck, since we can iterate until null, we could make a sensible userland iterator protocol if we only had initialization and a thing to run per-loop: `loop-keyword (iterator = range(10)) : (iterator.next())`
<leeward>
|capture| of course
aruniiird has quit [Ping timeout: 240 seconds]
<leeward>
Heh, we could confuse a lot of people with `do <initialization> while (condition) : (next) |capture| {`
<shakesoda>
now that i think about it, the syntax of `test` is also unique
<shakesoda>
the difference being that i don't really care ;)
<mq32>
test "x" { } is something i've seen before
<shakesoda>
leeward: single expression do, where the entire while is the expression?
<shakesoda>
mq32: i've seen it before, but it's not internally consistent with zig's other stuff
* mq32
made a C++ testing framework which is TEST("Foo") { }
<leeward>
shakesoda: the expression between do and while is only for initialization
<mq32>
shakesoda: ah, true. still okay with me though, it should stand out
<leeward>
Unusual syntax doesn't bother me, as long as the semantics are unsurprising.
<mq32>
leeward: it's important to have consistent syntax
<leeward>
Consistent, sure. But it doesn't have to be consistent with other languages.
<shakesoda>
mq32: i'm just wondering if maybe we could take what it needs and make a useful and more consistent thing of it
<leeward>
Just internally
<shakesoda>
like turn tests into functions after 1717, and a way to do string identifiers so you can name tests the same way... then test can just be a special class of variable, or something
<shakesoda>
then you can have a legal syntax of test "foo" = fn() {} which is almost the same, but you can also name other stuff like "foo" whenever you want
<mq32>
would have to be in a comptime block though to be callable
<leeward>
If a thing is inconsistent, it needs to be made easier to use by the inconsistency. I think test passes that.
<shakesoda>
perhaps subject to some restriction about if you can export it
<shakesoda>
leeward: if the inconsistency can be removed without meaningfully making it more difficult, i think that's a win for everyone
<leeward>
Right, that's another way of phrasing what I was saying.
<marler8997>
andrewrk, yes that's what I thought, my explanations on reddit may not have come accross that way
<marler8997>
andrewrk, it took me a few attempts and some time to think, but I think I've come up with a way to start integrating the new allocator interface. I've updated my PR when you get a chance to take a look: https://github.com/ziglang/zig/pull/5064
<shakesoda>
mq32: @test makes sense, i can't decide if i *like* it, but it's consistent and straightforward
<mq32>
i actually don't like it :D
<mq32>
i think test "foO" { } is totally fine
Akuli has joined #zig
<shakesoda>
mq32: figured i'd at least mention the inconsistency
<mq32>
yeah
<shakesoda>
it's functionally equivalent to something that doesn't really need syntax
<shakesoda>
nor does having the syntax save lines, just a few characters
<shakesoda>
but i don't mind test either.
cole-h has joined #zig
<fengb>
std.test.add(name, fn() !void {})
<leeward>
Where does that call live? Certainly not in main.
<mq32>
comptime { }
<marler8997>
whoa, did github just get a new look?
<alexnask>
maybe an @export option could make sense
<pixelherodev>
CI had the same issue I did, so it definitely wasn't a local issue
<andrewrk>
marler8997, I'm having a look now!
waleee-cl has quit [Quit: Connection closed for inactivity]
<andrewrk>
pixelherodev, I don't have the tests passing in that branch
<pixelherodev>
I know
<pixelherodev>
But this gets them *building*
<pixelherodev>
I should probably fix the tests first
<pixelherodev>
Before modifying the harness
<pixelherodev>
Good chance to get a better understanding of src-self-hosted too
<leeward>
Are friendly error messages on the back burner until self-hosted?
<pixelherodev>
Wdym?
<pixelherodev>
What errors are unfriendly?
<pixelherodev>
And I'm willing to bet patches fixing them would be accepted into stage1
<leeward>
The specific one I'm thinking of is "type 'blah blah.ErrorSet!RealReturnType' does not support field access" which could be made friendlier by highlighting the fact that it's an error union and you forgot to `try`.
<marler8997>
andrewrk, great
<andrewrk>
leeward, there's an issue open for this somewhere
aruniiird has quit [Quit: Leaving]
stripedpajamas has quit [Quit: sleeping...]
<leeward>
andrewrk: Any hints on how to find it? Is it for this specific error message or errors in general? I've turned up nothing so far.
<alexnask>
Another one is when using try in a function that does not return an error
<alexnask>
I see a lot of beginners confused by that one
<alexnask>
s/does not/cannot
<fengb>
Not just beginners. I've spent hours staring at that error before :P
<fengb>
Rite of passage to finally surpass that hurdle
<leeward>
Isn't there something in zig zen about not hazing the newbies?
<ifreund>
together we serve end users?
<leeward>
Yeah, I'd say that qualifies.
<leeward>
I have to say, it will be a nice change to have an actual low-level language where gotchas are actively stepped on.
<pixelherodev>
Only haze newbies!
<pixelherodev>
Who else are we going to haze? Haze?
<ifreund>
i don't think haze uses irc
<pixelherodev>
yeah, I don't think she's on here
<pixelherodev>
It was just a pun though :P
<pixelherodev>
See, it's a play on words, and that's where the humor comes in
<leeward>
Could you explain the joke more? I don't think it's funny enough yet.
<leeward>
And as we all know, the more a joke is explained, the funnier it gets.
<leeward>
Wow, it hurt to say that. I'm done.
<gonz_>
At some point it becomes so unfunny that it wraps around, though.
<gonz_>
Around the time someone makes a dissertation on why the joke is funny.
<leeward>
Maybe funny in theory, but I would not want to read it.
<marler8997>
it gets so unfunny, the joke overflows...that's why Zig was made, to protect from that
<pixelherodev>
Nobody gets my references.
<leeward>
test "joke"...integer overflow
<alexnask>
I got it for once phd
<leeward>
pixelherodev: It's hard to tell if nobody gets it or if it's just not funny. I have that problem all the time.
<pixelherodev>
Nah, it's easy in this case
<pixelherodev>
Like I said, nobody gets my references
<pixelherodev>
The "joke" wasn't actually intended to be funny, it was a reference
<marler8997>
which reference "See, it's a play on words, and that's where the humor comes in"?
<pixelherodev>
and the "nobody gets my references" :P
<pixelherodev>
Two references
<marler8997>
I recognize the first one, I can't remember exactly where though
<fengb>
It takes a lot of skill to tell jokes so bad it's funny
<andrewrk>
that's why tommy wisaeu is the greatest actor, director, screenwriter, and producer of all time
<fengb>
lol
<BaroqueLarouche>
hahahaha
<pixelherodev>
pft
<pixelherodev>
"We should watch the greatest movie of all time: The Room!"
<pixelherodev>
Convincing someone to watch it when they have no idea what they're in for is probably the worst sin someone can commit
<BaroqueLarouche>
I have a signed DVD copy that my friends bought from his website
<alexnask>
Nice
frett27 has joined #zig
stripedpajamas has joined #zig
<marler8997>
anyone know where that proposal is for custom integer type ranges?
<pixelherodev>
found the test failure, but I'm not 100% certain if this was deliberate or not
<pixelherodev>
nvm, I see what's going on here
<shakesoda>
wow i was just wondering if zig could do exactly that
<marler8997>
alexnask, thanks
<tgschultz>
result location is still TODO in the docs. What's the current state? Is it yet possible to safely return a struct instance that has a pointer to itself?
<leeward>
Is there a Zig way to spell "this loop does something, don't optimize it out" other than to have it modify a volatile pointer?
<andrewrk>
that's an important language design question that doesn't have a stable answer yet
<leeward>
Seems like a good job for a built-in.
<leeward>
Unless the debate is over whether or not such a thing should exist, in which case I'd weigh in on the "yes" side for the sake of people writing delay-loops on microcontrollers whose timer interrupts are all being used.
<andrewrk>
for this use case try this workaround: `asm volatile("":::"memory");` inside the loop
<andrewrk>
marler8997, couldn't std.mem.Allocator have all the functions of both ExactAllocator and InexactAllocator? I'm confused why there is a need for separation
<leeward>
Yep, that's an awful lot like what I do in C.
<marler8997>
thinking...
riba has quit [Ping timeout: 240 seconds]
<marler8997>
so for page allocator, exact and inexact allocations cannot be mixed
<andrewrk>
I was thinking keeping all the existing API exactly the same, and adding a couple new functions, which I expect to be more rarely used, which request inexact allocations
<marler8997>
you can't take an exact allocation and pass it to an inexact allocation function
<marler8997>
and vice versa
<andrewrk>
the allocator implementations would always be inexact, but the Allocator interface could provide exact functions on top of it. why is that not possible?
<marler8997>
it could
<marler8997>
I started out that way
<marler8997>
so this design stems from wanting the type system to be able to distinguish between exact and inexact allocators
<marler8997>
so functions could indicate whether the allocator they use needs to be exact or not
<andrewrk>
hmm I actually see that as a downside
<andrewrk>
I see it as unwarranted type complexity
<marler8997>
the touble I had with mixing the two
<marler8997>
is that you can't mix allocations
<andrewrk>
not sure I follow - can you elaborate?
<marler8997>
so if you allocate an inexact allocation, you can't pass it to exact allocation functions
<marler8997>
we could solve that by prefixing all the functions with something like exact... and inexact...
<marler8997>
I tried that
<marler8997>
using 2 different types ended up being alot simpler, but I'm definityl open to other ideas
<marler8997>
I have a few different branches with different attempts
<andrewrk>
hmm just checking, did you see this idea in the doc comments of my proposed resizeFn? /// The length of `buf` is a hint to the allocator, to help it find the allocated
<andrewrk>
// block more efficiently. The hint may be too small, but too large is illegal behavior.
<marler8997>
yeah
<marler8997>
the interface allows for that
<andrewrk>
this should let you call the inexact function, get a slice, and then return a smaller slice
<andrewrk>
I'm still not able to understand the need for 2 interfaces
<pixelherodev>
re: decl analysis, if I fix up the other branches in analyzeDecl, I end up with something realllly weird
<marler8997>
yes, because allocators may need the exact size
<pixelherodev>
Segfault with non-pointers
<marler8997>
for example
<marler8997>
say you allocate a 16K buffer from mmap
<marler8997>
but the caller changes it to 4K
<pixelherodev>
`std.debug.warn("test {} == {}\n", .{ a, b });` reading b there causes a segfault, but b isn't a pointer...
<marler8997>
and then only passed a 4K buffer when freeing it
<marler8997>
the c allocator would be fine with that
<marler8997>
but the mmap allocator would not
<pixelherodev>
IMO that's correct behavior?
halbeno has quit [Quit: Leaving.]
<andrewrk>
marler8997, I see, thanks - let me think about that
<marler8997>
this allocator stuff has been kicking my butt
<pixelherodev>
I don't see why that would be a bad thing?
<marler8997>
one thought is we may be able to remove the ExactAllocator once clients' logic change to support inexact allocations
<marler8997>
at minimum, I would expect most code to use InexactAllocator, and an ExactAllocator would be an one-off thing someone could use
<andrewrk>
one thing to consider is that we don't necessarily *need* a page allocator. Once we have a good general purpose allocator, I'm not sure there would be any use case for it
<pixelherodev>
Ehh, I like the idea of an allocator that takes in the length while freeing instead of tracking it
<pixelherodev>
That allows for lower memory usage anyways
<pixelherodev>
Since it means not needing to track it internally
<pixelherodev>
And clients often want to track it anyways
<marler8997>
maybe
<marler8997>
I think having an inexact allocator interface is pretty useful in general
<marler8997>
it's what arraylist would be using for example
<marler8997>
but the thing is, some allocator inherintly support exact allocations (the C heap allocator) and some do not. If you do not, you would implement the InexactAllocator interface, if you do, you would support the ExactAllocator interface.
<pixelherodev>
Uninitialized pointer, okay that makes sense, no idea how this is turning into a segfault *at 0* though...
<marler8997>
And code using allocators, could decalre which kind they need, ExactAllocator or InexactAllocator
<andrewrk>
marler8997, another idea: "The length of `buf` is a hint to the allocator, to help it find the allocated block more efficiently. The hint may be too small, but too large is illegal behavior. === new part ===> If a given allocation returns the exact size requested, the hint must be exactly correct."
<andrewrk>
this would make page allocator work without tracking size, and no need for 2 interfaces
<andrewrk>
and this rule is easy for clients to follow
<pixelherodev>
Huh, I like that
<pixelherodev>
hmm
<pixelherodev>
I think there's a compiler bug
<marler8997>
that puts the burden on the allocator to track the size if it requires it
<pixelherodev>
If you have an uninitialized pointer, and you do e.g. `std.debug.warn("{}", .{ &uninted_ptr.val });` it seems to infinite loop
radgeRayden has joined #zig
<pixelherodev>
in debug mode
<marler8997>
by supporting an InexactAllocator, the caller can decide where to store the exact size if it is required
<marler8997>
Either in the allocator (using InexactToExactAllocator) or just storing the exact size itself
<marler8997>
so the interface is less flexible, because it only allows the allocator to manage the exact size
<pixelherodev>
But that requires extra interfaces, which aren't needed.
<marler8997>
The InexactAllocator already supports that rule
<marler8997>
If you don't care about inexact allocations, you can forget about it and just use ExactAllocator
<pixelherodev>
But that's my point
<pixelherodev>
There shouldn't be multiple allocator interfaces
<marler8997>
You can think of InexactAllocator as an internal detail if you want
<tgschultz>
I read that differently, I read it as the client being responsible for keeping the size if it isn't exact, which would work fine for my purposes where I have an allocator that uses the size of the allocated memory to find it.
<marler8997>
A way to share code between inexact allocators
<marler8997>
to make then exact
<pixelherodev>
but that's only useful if nothing uses it directly
<pixelherodev>
Clients should never use anything other than std.mem.Allocator
<marler8997>
> There shouldn't be multiple allocator interfaces...I'm not sure where this rule comes from or what it means exactly
<marler8997>
> Clients should never use anything other than std.mem.Allocator
<marler8997>
I started with that
<pixelherodev>
hmm
<pixelherodev>
I'm going to have to backtrack :P
<pixelherodev>
Reread from the start
<marler8997>
the problem came up when I provide functions to allocate "exactly" and functions to allocate inexactly
<marler8997>
you can't mix the 2, because an inheritnly inexact allocator would need additional metadata to track the exact sizes of inexact allocations
<marler8997>
which means that buffers returned by std.mem.Allocator, would only be able to pass them back to some of the functions, but not others
<pixelherodev>
What do you mean by "inherently inexact?"
<marler8997>
this is a disaster of an interface
<marler8997>
mmap is an example
<pixelherodev>
Ah, in that it will definitionally provide extra RAM until the page end?
<marler8997>
meaning it can only allocated certain sizes of allocations
<pixelherodev>
Why?
<marler8997>
because it's minimum allocation size is 4K, so if you request anything less than 4K, it still needs to reserve/allocate 4K
<marler8997>
if you request 10 bytes, it will reserver 4096 (hence the name inexact)
<pixelherodev>
Right, so?
<pixelherodev>
Why does that matter for the interface?
<marler8997>
You asked what inherintly inexact meant
<pixelherodev>
It's not great in terms of efficiency of course, but that shouldn't matter
<marler8997>
what do you mean so?
<marler8997>
I answered your question
<pixelherodev>
Why does such an allocator need to track exact sizes?
<marler8997>
I already explained this example in the cat
<pixelherodev>
> it would need additional metadata to track the exact sizes of inexact allocations
<alexnask>
The point is that if you provide functions for exact and inexact allocations for every allocator
<marler8997>
*chat
<marler8997>
but I suppose I will explain it again
<pixelherodev>
Sorry :P
<alexnask>
The allocator will need to keep track of the actual allocation size to free it if the inexact allocated memory is freed with an exact function
<andrewrk>
marler8997, you've clearly put a lot of work into this, I just want to make it clear that work is appreciated, and your observations are valuable, having done that work
<marler8997>
thanks, and I'm not claiming I know all the answers
<marler8997>
New ideas are very much appreciated, and I happy to discuss
<tgschultz>
If I understand the inexact allocator problem correctly: if you allocate 5000 bytes, reslice it to 1000, then free it, you leak memory, however I think that is already against the API: thou shalt free the exact slice you were allocated.
<andrewrk>
I think we're already asking a lot from people to care about allocators at all, I just want to weigh all the options before further complicating that
<pixelherodev>
*If* you reslice it, yes, but that's not related to exact / inexact
<pixelherodev>
That's true for exact allocators oo
<pixelherodev>
too*
<marler8997>
tgshultz, yes
<marler8997>
but the problem is, that allocators cannot resize allocations to be smaller
<marler8997>
some allocatos cannot resize things to be exactly a particular size
<pixelherodev>
ahh, so it's related to shrink?
<marler8997>
and alot of code requires that behavior
<pixelherodev>
Well, for mmap, you can pretend it is
<marler8997>
pixherodev, yes
<pixelherodev>
and the results are 100% correct
<tgschultz>
mmap is a bad example then, since you can free unused pages
<pixelherodev>
More than that
<pixelherodev>
If you have 0x4001 bytes (two pages)
<marler8997>
mmap kinda
<pixelherodev>
and you free 0x4001
<pixelherodev>
it'll free both full pages
<pixelherodev>
So it won't leak at all
<pixelherodev>
*unless you reslice*, which, as pointed out already, is already illegal
<marler8997>
if you allocate 3 pages with mmap, and resize it to only be 2 pages when you free, then that 3rd page will leak
<pixelherodev>
Yeah, so?
<pixelherodev>
YOu're *not allowed to do that*
<tgschultz>
I have an allocator that meets the criteria though: it allocates things based on the smalles Po2 they fit into. Thus shrink causes a problem.
<pixelherodev>
If you allocate memory, and don't free it, it'll leak
<marler8997>
pixelherodev, that was the proposed interface
<marler8997>
to allow clients to reslice before freeing
<pixelherodev>
... why?
<pixelherodev>
What's the use case for this?
<marler8997>
so then we don't have 2 interfaces
<andrewrk>
ok hear me out: resizeFn docs: "The length of `buf` is a hint to the allocator, to help it find the allocated block more efficiently. The hint must be >= the *requested* allocation size and <= the *actual* allocation size, otherwise illegal behavior is invoked."
<pixelherodev>
*Why do we need any interface for it*?
<marler8997>
so that clients that want inexact allocations (access to the full allocation) can have it
<pixelherodev>
I'm not seeing why we need to allow reslicing before freeing
<andrewrk>
so basically the client either tracks how much it requested or how much it received. the allocator implementation has to accept both
<pixelherodev>
That's the problem to me though
<marler8997>
if you request 10 bytes, but you get 4096, you want to know you actually have 4096 bytes
<pixelherodev>
I don't like the idea of increasing the burden on allocators
<marler8997>
this doesn't increase the burden on allocators
<andrewrk>
pixelherodev, if you do allocator.alloc(Foo, 10) you need to get a slice with 10 Foos in it, not more
<tgschultz>
I don't think that's actually the problem though andrewrk, it's that shrink cannot fail and must resize in place.
<pixelherodev>
Why is that?
<pixelherodev>
I remember seeing that, but I think I ignored it in my implementation lol
st4ll1 has quit [Ping timeout: 240 seconds]
<marler8997>
oh, allowing resize to accept a sub-slice does put the burden on the allocator, I misread what you were saying
st4ll1 has joined #zig
<andrewrk>
tgschultz, in which allocator is it a problem? for PageAllocator, this latest rule that I outlined would make it work fine
<marler8997>
andrewrk, actually no
<marler8997>
if you allocate 3 pages, and resize it to 2 pages, you leak the 3rd page
<andrewrk>
nah you unmap the 3rd page
<andrewrk>
that's what we do right now
<marler8997>
oh, you're saying that you call resize
<tgschultz>
None that are in the stdlib, but allocators like one I wrote or, IIRC, rpmalloc.
<marler8997>
not that you sub-slice the buffer without calling resize?
<marler8997>
is that right andrew?
<tgschultz>
right, with mmap shrink can just free the third page
<andrewrk>
the client would be responsible for tracking either the requested size or the actual size. if it wanted to track a smaller number than requested size it would be required to call resize
<shakesoda>
cool, moved everything on my rpi to the ssd. build times are distinctly better
<marler8997>
but I thought the proposal was, the client can slice the allocation without telling the allocator
<marler8997>
so mmap wouldn't know there is a 3rd page to unmap
<marler8997>
oh, requested or actual size
<andrewrk>
that was a side effect of my initial doc comments proposal, but that wasn't the goal
<marler8997>
that would work for something like mmap
<shakesoda>
andrewrk: if ~/.cache/zig is symlinked to somewhere missing/gone, zig hangs and eats all ram
<andrewrk>
the main goal is to allow implementations to return more than requested, and allow clients to optionally take advantage of it
<shakesoda>
just ran into this :D
<marler8997>
I think the current InexactAllocator accomplishes that goal
<pixelherodev>
Uhh, this is almost definitely a compiler bug...
<tgschultz>
for the record: I just accepted the limitation of the std interface and ate a byte of every allocation to store the Po2 the memory is part of.
<alexnask>
tgschultz, are you using buckets for every power of 2? (just curious)
<pixelherodev>
andrewrk: thx
<pixelherodev>
Wow
<pixelherodev>
That's... a *lot* of bugs in stage1
<pixelherodev>
Valgrind: "More than 1000 different errors detected. I'm not reporting any more."
<pixelherodev>
"Go fix your program!"
<tgschultz>
If that's the goal, andrewrk, we could return a struct with the requested slice and a total size. Client is free to take advantage of extra memory if desired.
<pixelherodev>
Wowzers
<tgschultz>
alexnask: yeah, that's how it works.
<andrewrk>
tgschultz, the client already knows the requested size, and the proposed interface returns the total size, so I think we are in agreement
<marler8997>
the questio is, when you need a slice of an allocation, who tracks the size, the allocator, or the client?
<tgschultz>
yeah, as long as the client doesn't reslice the memory before freeing it it shouldn't be an issue (except in my particular case because of the implementation details).
<marler8997>
I decided to punt and say that either could track it, it's up to the caller
<marler8997>
there are some allocators that already track the exact size (like the C allocator)
<andrewrk>
status quo: the client tracks how much it requested, and the allocator returns always the requested amount
<marler8997>
right
<andrewrk>
my proposal to keep only 1 Allocator interface: client tracks either how much it requested, or the actual amount returned by the allocator. Allocator impl returns either requested amount, or more, and has to support freeing/resizing based on both requested amount and actual amount that it returned
<marler8997>
that might work
wootehfoot has joined #zig
<marler8997>
can they pass in a size in between the 2?
<pixelherodev>
I really dislike this idea
<andrewrk>
I think it would be reasonable from a client's perspective for it to be required to be only one or the other
<marler8997>
so if they need to reslice it to a value in the middle, they need to call resize
<andrewrk>
yes
<marler8997>
pixelherodev, do you have another idea?
<pixelherodev>
I would prefer it if we just kept the "slicing returned values is a no-no" rule, but as long as allocators remain simple, it's really not a big deal IMO
<tgschultz>
I don't hate this idea, but I feel like it overcomplicates things.
<pixelherodev>
^
<pixelherodev>
Yeah, exactly
<pixelherodev>
I think it introduces unnecessary complexity
<andrewrk>
with my proposal the Allocator interface stays the same, and gains a couple of "advanced" functions
moo has joined #zig
<marler8997>
andrewrk, yes I think it's a good proposal
moo has quit [Remote host closed the connection]
<andrewrk>
from an allocator implementation perspective, you now have the option to return extra bytes. that's all
moo has joined #zig
<pixelherodev>
andrewrk: the bug is exactly what I said it was earlier
<pixelherodev>
Using an uninitialized value
<marler8997>
andrewrk, I'll work on that proposal
<pixelherodev>
But the *secondary* bug is that the "Segfault at addr" message is giving the wrong number
<andrewrk>
marler8997, I know you just put a lot of work into this, I'm sorry to push back again. But I really think this is going to make zig's "you have to think about allocators now" approach more palatable for people in general
<fengb>
So to summary... we're allowed to use the requested size or the returned value, but anything in-between requires an explicit resize?
<marler8997>
andrewrk, I don't consider it push back, I consider us all pushing forward together
wootehfoot has quit [Disconnected by services]
<andrewrk>
nice, I like that :)
<andrewrk>
fengb, yes that's the current proposal
wootehfoot has joined #zig
<pixelherodev>
Yeah, that's a good way of putting it :)
<pixelherodev>
Hmm
<pixelherodev>
Worse is that there's a number of errors in stage1
<pixelherodev>
`Use of uninitialized value at 0x9F2446: ir_resolve_type(IrAnalyze*, IrInstGen*)` for instance
<fengb>
It feels a little odd... but I guess that makes sense. Existing code will still work and we unlock "natural" sizing
<andrewrk>
pixelherodev, have you discovered UB when compiling self-hosted?
<pixelherodev>
Yes
<pixelherodev>
Well
<pixelherodev>
When compiling the test suite at least
<pixelherodev>
But it might be my fault, been working on fixing resolveDecl
moo has quit [Client Quit]
<pixelherodev>
Lotttts of memory leaks in stage1 though, I think
<andrewrk>
pixelherodev, you know the original strategy for stage1 was "never free anything" right?
<alexnask>
stage1 wasnt freeing for the longest time
<pixelherodev>
...
<pixelherodev>
So I've heard, yes
<pixelherodev>
From someone who was... rather unamused by it :P
<andrewrk>
honestly once we are shipping self-hosted, we can probably go back to not freeing anything in stage1 again
<andrewrk>
if self-hosted was done sooner we would never have had to care about memory management in stage1
<pixelherodev>
...
<pixelherodev>
uh
wootehfoot has quit [Quit: Leaving]
<pixelherodev>
Seriously, what's the reasoning there?
<andrewrk>
how much peak rss is reasonable to use for bootstrapping?
<pixelherodev>
IMO? Not a lot.
<andrewrk>
how much?
<pixelherodev>
I'd like it to be able to be bootstrapped reasonably on e.g. a RasPi
<pixelherodev>
4GiB *tops*
<shakesoda>
that's a heck of a lot still!
<pixelherodev>
For sure
<pixelherodev>
and I'd hope it'd be nowhere near that
<pixelherodev>
That's as a bare maximum
<pixelherodev>
Preferably, 1GiB at worst
* shakesoda
is working on a pi right now, experiencing painful zig build times
<pixelherodev>
The lower the resource requirements to run it, the more often we can e.g. run CI / test suites
<pixelherodev>
Which means minimizing RAM and CPU usage is definitely worthwhile if only for that
<fengb>
My pi only has ~250mb available ram :(
<andrewrk>
1 GiB, so that's how much RAM you need to build your self-hosted components. if you don't need to free anything to hit that goal, that's the simplest way to do it
<alexnask>
can llvm compile hello world with 250mb of ram? /s
<shakesoda>
alexnask: no :(
<shakesoda>
fengb: i'm currently on one of the shiny new 8gb models, feels very luxurious
<shakesoda>
fengb: i usually work on a zero w, very different machine
<fengb>
Yeah I'm on a zero atm. Mostly setup for playing games
<fengb>
I wonder if I can reclaim vram without a reboot. Probably not
<andrewrk>
it's also possible, and I know this in away goes against what I've been saying the whole time, but it's also possible that we do a *one time* event where we generate C code from self-hosted, and make that stage1. The output C code would then become source, deobfuscated, commented, and maintained
<andrewrk>
this is just an idea, not a plan
<shakesoda>
i've been doing little games and a toy desktop env
<shakesoda>
zero is very fun for such things
<pixelherodev>
I really don't see why it's worthwhile to avoid free()ing
<pixelherodev>
Even if we don't *have* to, it's still worth doing IMO
<shakesoda>
maximum simplicity and discouraging actually using it :D
<pixelherodev>
Ugh
<shakesoda>
given a choice though i want things to use the least resources they can
<pixelherodev>
That's not simplicity.
<pixelherodev>
That's inefficiency and wastefulness
<alexnask>
/pats stage1 on the head "I still love you buddy"
<andrewrk>
not freeing is the same thing as using one giant arena allocator for the whole process. there are valid use cases for it
<pixelherodev>
I mean
<shakesoda>
well, it's both.
<pixelherodev>
Not when it reaches the triple digit MBs IMO
<shakesoda>
it's not like you lose the ram forever
<shakesoda>
but yes it's absolutely wasteful
<pixelherodev>
Of course
<leeward>
Ok, people who complained about new github are right. This text box is way too wide.
<andrewrk>
the way stage1 is built right now it's not really possible to free ZigValue structs. it's a problem, yeah. self-hosted is designed much differently because of it. But ZigValue wasn't planned from the start, it arose organically as the language evolved over time
<tgschultz>
new github is a good example of how modern design trends often make things arbitrarily worse.
<andrewrk>
the freedom to put data wherever without having to sit down and plan out where everything goes, while still designing the language, was a freedom that helped quick iteration early on. I don't regret it
<shakesoda>
how far from usable is self hosted anyways
<andrewrk>
still pretty far
<tgschultz>
I recall at one point my dev environment couldn't actually compile zig because it had too little memory, even with swap.
<pixelherodev>
Depends on your definition of usable
<pixelherodev>
:P
<shakesoda>
how far in terms of release cycles lol
<alexnask>
You can use it if you really like inline asm
<shakesoda>
i know it's a current focus
<alexnask>
:D
<tgschultz>
that was a particularly tiny dev env though
<pixelherodev>
alexnask: not yet lol
<andrewrk>
I haven't given up hope of shipping it in this release cycle. it's a long shot but not impossible
<pixelherodev>
After the next few PRs, yeah
<leeward>
pixelherodev: usable defined as "passing all the tests we're passing now"
<pixelherodev>
If I had to guess, 0.8 at the absolute latest
<pixelherodev>
leeward: then very far
<shakesoda>
ok, that's a pretty good picture of the situation
<andrewrk>
there are still a few Hard Design Problems to solve in self-hosted, before we really start cruising
<pixelherodev>
On that note
<pixelherodev>
re: decl lookup, is the only thing needed for resolveDecl to change the hash function used?
<andrewrk>
progress will feel slow, and then once those problems are sorted out, it will suddenly feel very quick
<pixelherodev>
Because it looks like moving it to scope.fullyQualifiedHash should be fine
wootehfoot has joined #zig
<pixelherodev>
`const name_hash = scope.fullyQualifiedNameHash(mem.spanZ(old_inst.name));`, rather
<pixelherodev>
Hmm
<pixelherodev>
Seems to infinite loop in tests when looking an undefineds
<gonz_>
tgschultz: I don't think the GitHub redesign is particularly bad. Is there anything in particular I'm missing?
<leeward>
gonz_: Are you running it full screen on a wide monitor?
<gonz_>
Yeah.
<leeward>
Comment threads in English do not need to be 135 characters long.
<leeward>
er, wide
<gonz_>
Hmm, I'm getting very constrained viewports for the time being.
<gonz_>
As in taking up maybe 40-50%, slightly offset to left of center.
<fengb>
Everything should be 80 chars max :P
<pixelherodev>
Eh
<pixelherodev>
Depends on font size and screen size, among other things
<leeward>
fengb: Agreed 100% firm rule no exceptions.
<leeward>
(mostly serious)
<gonz_>
This screenshot is from my 1080p secondary screen, if I move it to my bigger one it keeps the same proportions. This is with 110 zoom across all of GitHub, by the way.
<leeward>
gonz_: That's about what I see.
<gonz_>
I like it, to be honest. I'm sure there will be other things I notice that I don't like about their redesign, though, but we'll see.
<leeward>
For what it's worth, I wrap my comments at 70 characters. English just doesn't need to be that wide, and humans are way better at reading up and down.
<pixelherodev>
andrewrk: found the new test failure in self-hosted
stripedpajamas has quit [Quit: sleeping...]
<pixelherodev>
resolveInst is returning an undefined pointer when it should be erroring
<shcv>
hey; I'm still trying to build the lastest zig, but am getting stuck on "undefined reference to clang::driver::(...)" errors when linking zig0... any suggestions? I have clang installed with all of its libraries, so I'm pretty sure those files are available
<pixelherodev>
PREFER_DYLIB, or something like that
<pixelherodev>
shcv: try setting ZIG_PREFER_CLANG_CPP_DYLIB on
nikita` has quit [Quit: leaving]
<shcv>
like "cmake -DZIG_PREFER_CLANG_CPP_DYLIB=ON .." ?
<pixelherodev>
Yeah, exactly
<shcv>
I'm also wondering if the list of paths to look in in the cmake files are wrong, or at least don't include the place mine are stored
<shcv>
I don't know much about cmake though
<marler8997>
I'm seeing an issue with the latest allocator proposal, one is that there are some places where a client needs to get the full size of an allocation when they possibly have a partial size
<marler8997>
for example, in failing_allocator.zig, when a buffer is freed, it doesn't know whether the buffer being passed in is the requested size of the full size, so it doesn't know how much memory is actually being freed
<marler8997>
one way to solve this, would be to add an allocator function, getFullSize, instead of returnning the full size from allocFn
<pixelherodev>
That doesn't matter though
<marler8997>
another place where this can matter, is when invalidating memory
<pixelherodev>
failing_allocator just passes it through
<marler8997>
failing_allcoator keeps track of the memory allocated and memory freed, and validates it has all been allocated and freed
wootehfoot has quit [Quit: Leaving]
<pixelherodev>
Ah right, gotcha
<pixelherodev>
I see what you mean now
<marler8997>
this issue also comes up during realloc, first we try to resize in place, but if that fails, it may return a size larger than what was passed in, so we have to restore the original size, but we don't know the original size
<pixelherodev>
Ohhh, I see the big issue here
<pixelherodev>
Decls use the AST / ZIR node index now, not the source index
<shcv>
ok, managed to get past the clang libs issue, but now I get "CommandLine Error: Option 'mc-relax-all' registered more than once!"
<pixelherodev>
Oof
<pixelherodev>
That's definitely a known issue
<pixelherodev>
Don't remember the solution though
<pixelherodev>
LLVM's fault :P
ur5us has quit [Ping timeout: 260 seconds]
<shcv>
of course :(... I'll be glad when I can use zig's build system instead
<shcv>
unfortunately, the 0.5.0 compiler I have isn't recent enough
<alexnask>
shcv, You can donwload a nightly build on the website if you only want to use it and dont have a particular need to compile it yourself
<pixelherodev>
^
<pixelherodev>
I do that to work on stage2
<gonz_>
Wasn't shcv one of the ones who wanted to run on FreeBSD aarch64?
<alexnask>
ah, idk I guess they will have to struggle with llvm then :P
<gonz_>
Or was that someone else? In that case I'm not sure there are builds up?
<gonz_>
I may be misremembering.
<gonz_>
Ah, his nick was dch
dermetfan has quit [Ping timeout: 272 seconds]
alexnask has quit [Quit: Leaving]
<pixelherodev>
Got transformation tests *running*, but they're producing zero ZIR :P