<pmwhite>
Okay. So, I could make an array on the stack, right? If I passed it into the fixedbufferallocator, there would be no real dynamic allocation happening.
reductum has joined #zig
<fengb>
No the allocator interface is kinda borked with that bug
<fengb>
Well maybe not the interface but FBA does some pointer math that it’s not happy with
<pmwhite>
Gotcha, so you can do real dynamic allocation, just not with that interface?
<fengb>
What I’ve done is preallocate using an array and increment the value
<fengb>
Er, the tail pointer
<fengb>
Which works but keep in mind there’s no deallocation or GC so it’ll take up memory forever
aerona has quit [Remote host closed the connection]
aerona has joined #zig
<pmwhite>
That's kind of annoying. I guess it'll get fixed eventually and then I can switch to a real allocator.
<aerona>
since #1332 is accepted then that's the next logical step in my mind. though i wonder if the implementation of #1332 would solve your proposal at the same time
<aerona>
since it's already done with non-nullable int types: var x: usize = 0; if (x == 10) {} // no @as() needed
xackus has joined #zig
ur5us has quit [Ping timeout: 265 seconds]
<foobles>
right, thats what I'm thinking
<foobles>
I am the one implmenting 1332 at the time, so that is why i brought up this proposal in the first place XD
<aerona>
haha fair enough
aerona has quit [Remote host closed the connection]
ur5us has joined #zig
aerona has joined #zig
aerona has quit [Remote host closed the connection]
aerona has joined #zig
aerona has quit [Remote host closed the connection]
eleanor-nb has joined #zig
eleanor-nb has quit [Remote host closed the connection]
xackus has quit [Ping timeout: 256 seconds]
knebulae has quit [Quit: Leaving]
waleee-cl has quit [Quit: Connection closed for inactivity]
<daurnimator>
andrewrk: and I have a feeling a lot of it will end up being usable to implement a JIT
TheLemonMan has joined #zig
marijnfs has joined #zig
marijnfs1 has quit [Ping timeout: 264 seconds]
marijnfs1 has joined #zig
marijnfs has quit [Ping timeout: 264 seconds]
dddddd has joined #zig
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
knebulae has quit [Ping timeout: 265 seconds]
xentec has quit [Quit: memento mori]
bkleiner has quit [Ping timeout: 250 seconds]
ur5us has joined #zig
xentec has joined #zig
bkleiner has joined #zig
knebulae has joined #zig
<tdeo>
why does std.testing.expectEqual use the type of `expected` instead of `actual`? it'd be a lot less casting if it were the other way around, but the argument order would also have to be flipped
knebulae has quit [Ping timeout: 250 seconds]
<ikskuh>
tdeo: because you want to test for an expected type
<ikskuh>
imagine you want to test if a function returns a u3, but it returns a u9
<ikskuh>
u3 is implicitly castable to u9, when using the type of expected, this will fail
<ikskuh>
when using the type of actual, it will silently work
<tdeo>
ah, i see
<TheLemonMan>
ikskuh, it's not the linker that's dropping the symbol, it's Zig lazyness at play once again
<ikskuh>
no
<ikskuh>
it's both!
<ikskuh>
wait a minute, i'm writing a response
marijnfs has joined #zig
<TheLemonMan>
oh the linker GC may kick in, right
<ikskuh>
nah, not even that is the problem
<ikskuh>
the problem is that the section is zero-sized
marijnfs1 has quit [Ping timeout: 265 seconds]
<TheLemonMan>
oh well, I tested a non-empty array, a zero-sized array is certainly dropped
<ikskuh>
yeah doesn't make much sense to emit it anyways
<ikskuh>
you can just chose any address with an RNG :D
<ikskuh>
same difference in the end :D
<TheLemonMan>
I wonder why he's exporting an empty vector table
waleee-cl has joined #zig
ifreund has joined #zig
ur5us has quit [Ping timeout: 240 seconds]
FireFox317 has joined #zig
FireFox317 has quit [Client Quit]
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
<fengb>
Wow so self hosted and new backend are working?
FireFox317 has joined #zig
<FireFox317>
fengb, i think andrewrk currently implemented a mapping from zir -> elf
<FireFox317>
there is no mapping from zig source code -> zir yet
_Vi has joined #zig
Cogitri has quit [Quit: killed]
Cogitri has joined #zig
dermetfan has quit [Ping timeout: 252 seconds]
xackus has joined #zig
<tdeo>
is there a convenience function in std for a bounds checked slice access?
<tdeo>
like `fn at([]T) ?T`
<dimenus|home>
fengb: it's just code ZIR emission at this point, no connection with the existing frontend
dimenus|home is now known as dimenus
betawaffle has joined #zig
<fengb>
Hmm where’s the code? I wanna make a wasm backend :D
<fengb>
nvm it was literally the post I just read
<fengb>
I’m not very bright today
<dimenus>
fengb: consume more coffee :)
decentpenguin has joined #zig
dermetfan has joined #zig
<sanaris>
Guys, why is everybody is so obsessed with safety in languages?
<sanaris>
Dangerous programming is most joyful
<ifreund>
i like my programs simple, correct, and fast. Langauges that are truely safe generally fail at at least one of those
<ifreund>
zig seems to be the best bet so far
<fengb>
People make mistakes. It’s nice for a compiler to catch my stupidity
<fengb>
That said, sometimes a compiler can be too anal and gets in the way
<ifreund>
safety is nice, but it usually comes at the cost of complexity
<fengb>
Zig is a good middle ground. A lot better at catching things than C, but much lower cognitive overhead than Rust
<ifreund>
my thoughts as well. I learned enough zig to write fairly idiomatic, non-trivial code in a matter of days
<ifreund>
for rust that process took me months
<dimenus>
tdeo: slices have `.len` properties so you can just check it on the spot
<tdeo>
ended up writing my own one liner so i could do `switch (at(text, 0) orelse return null)`
<tdeo>
i have three lines like that one in the function
dimenus has quit [Remote host closed the connection]
decentpenguin has quit [Quit: decentpenguin]
dddddd has quit [Ping timeout: 256 seconds]
joey152 has joined #zig
lohengrin has joined #zig
<fengb>
In general, are jump tables faster or call indirect?
foobles has joined #zig
Akuli has joined #zig
<nephele>
I've added __powidf2 to compiler-rt for zig, so get a bit further in compiling minetest, but now i get lld: error: undefined symbol: __cxa_thread_atexit_impl; but i don't seem to find an implementation in llvm compiler-rt to port over, am i missing something?
<nephele>
Is that just not part of compiler-rt maybe?
<nephele>
ah seems to be in libcxx or libc... don't understand why it doesn't work then... compiling on alpine linux if that matters
betawaffle is now known as otherwaffle
betawaffle has joined #zig
<pixelherodev>
z
<pixelherodev>
Whoops, sorry
otherwaffle has left #zig [#zig]
<BaroqueLarouche>
i
<BaroqueLarouche>
g
waleee-cl has quit [Quit: Connection closed for inactivity]
foobles has quit [Remote host closed the connection]
joey152 has quit [Ping timeout: 256 seconds]
cren has joined #zig
cole-h has joined #zig
Invader_Bork has joined #zig
decentpenguin has joined #zig
foobles has joined #zig
cren has quit [Ping timeout: 240 seconds]
Vexu has joined #zig
<andrewrk>
nephele, zig can provide -lc++
<afontain_>
wait, `zig cc` can compile c++ code?
<ikskuh>
yep
<nephele>
andrewrk, I think it's using zig c++ anyway
<nephele>
was using zig cc and zig c++ for CC and CXX respectively passing them to cmake as such
cren has joined #zig
wootehfoot has quit [Ping timeout: 256 seconds]
st4ll1 has quit [Ping timeout: 256 seconds]
klltkr has joined #zig
dddddd has joined #zig
foobles has quit [Remote host closed the connection]
<andrewrk>
BaroqueLarouche, ZIR is not capable of more than hello world yet
<pixelherodev>
BaroqueLarouche, no
<pixelherodev>
I do plan on using this for a Zig backend, yes
<pixelherodev>
But it'll require a ZIR parser first
<pixelherodev>
And that'll require the x64 backend to be actually usable
* BaroqueLarouche
will surely put on hold all my Zig projects to help with the self-hosted compiler
decentpenguin has quit [Quit: decentpenguin]
cren has quit [Ping timeout: 240 seconds]
_Vi has quit [Ping timeout: 272 seconds]
<andrewrk>
I'm hoping to make self-
<andrewrk>
I'm hoping to make self-hosted contributor friendly as soon as possible
waleee-cl has joined #zig
Invader_Bork has quit [Ping timeout: 265 seconds]
FireFox317 has quit [Quit: Leaving]
<yrashk>
what's the target release for self-hosted? 1.0?
FireFox317 has joined #zig
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
<andrewrk>
it would be a major accomplishment to ship self-hosted with 0.7.0 but I have not given up on that prospect yet
<andrewrk>
I think with proper design and keeping it contributor friendly it is a possibility
<fengb>
Will ZIR be self-hosted only?
_Vi has joined #zig
Chris660 has joined #zig
<FireFox317>
andrewrk, #5122 passed the tests :)
ur5us has joined #zig
<fengb>
If I stick align in the first field of a packed struct, does that guarantee the alignment of the struct?
<andrewrk>
nice work FireFox317
xentec has quit [Remote host closed the connection]
<FireFox317>
had to disable quite some tests, but its one more target supported by zig :D
<andrewrk>
as long as the issue number is greppable that should be fine
<andrewrk>
really, this constitutes a lot more test coverage than before! great work
xentec has joined #zig
<andrewrk>
fengb, I think the answer to your first question is "yes". what would a "no" answer mean?
frett27 has joined #zig
cren has joined #zig
frett27 has quit [Read error: Connection reset by peer]
frett27 has joined #zig
frett27 has quit [Read error: Connection reset by peer]
frett27 has joined #zig
Xavi92 has joined #zig
<andrewrk>
the answer to the alignment question is yes
<fengb>
I meant whether you were gonna backport ZIR into the stage 1 compiler
<fengb>
Great, thanks
<andrewrk>
if it's clear that doing so would fix all the bugs, then that's a strong possibility
<andrewrk>
too early to tell
<andrewrk>
since outputting C is one of the planned options of self-hosted, it might be interesting, once we're shipping self-hosted, to backport ZIR + the C output code only, and replace all of stage1 with that
<fengb>
Oh wow, I didn't think direct C output was on target
<andrewrk>
then bootstrapping (without llvm+clang+lld abilities) will depend only on a C compiler
<fengb>
Hmm, didn't you mention that maintainers don't trust generated code?
<gonz_>
I was thinking about writing a type parser for creating types in different languages, but then I realized I could just write zig types and have zig tell me about them
<andrewrk>
that would land you with a fully self hosted zig, capable of whatever targets zig supports without llvm
<andrewrk>
not capable of translate-c or zig cc
<fengb>
Oh wow
klltkr has quit [Ping timeout: 240 seconds]
<andrewrk>
of course, the follow-up question is, "if we already have std.c.tokenizer and std.c.ast and we have a fully capable backend... why not write the glue code to make zig cc work even in the non-llvm compiler?"
<companion_cube>
why would it be in the stdlib though? and not a package?
<andrewrk>
same reason zig tokenization and parsing is in the std lib
<scientes>
oh RLY
<scientes>
C parsing is not simple
<gonz_>
Everything is relative
<gonz_>
:P
<scientes>
I don't see trigraph support
<gonz_>
It's not Lisp, but it's not exactly Haskell either.
<companion_cube>
(seems to me like haskell is probably easier to parse than C)
<scientes>
or special casing for #include <stdbool.h>, and the other special headers
<scientes>
or __attribute__ support
<scientes>
or the new [[attribute]] support
<companion_cube>
andrewrk: why is C compilation at the same level as zig compilation, though?
<gonz_>
companion_cube: I dunno, it doesn't feel like it'd be all that easy. It has a lot of gunk thrown into it. You can have tons of different things in a lot of places.
<gonz_>
companion_cube: Type applications, for example, were added relatively late and suddenly you can now have those in the beginning of all function calls.
<gonz_>
You can have package names before imports to specify where to pull a module from, etc., which you couldn't before(?), all because of an extension.
<gonz_>
Apart from being a maintenance nightmare in those circumstances I think the grammar itself is probably not super friendly.
<gonz_>
Other than that you have the offside rule instead of just reading until an `in` or some other token, etc.. I don't think they ever even considered making it easy to parse.
<companion_cube>
gonz_: I'm assuming haskell 98, though
<companion_cube>
it's indentation sensitive but otherwise it seems much cleaner than C
joey152 has joined #zig
<gonz_>
That's one hell of an assumption. Pretty much no one is using just Haskell 98 in 2020. People aren't even only using 2010.
<gonz_>
That's not to say that wouldn't be a great idea. I personally would want to peer into a hypothetical project that restricted itself to something a bit more basic.
<gonz_>
But yeah, everything is relative. I guess I'm underestimating the issues of parsing C a bit.
<companion_cube>
and haskell extensions are not too hard to parse, I think, it's when you want to typecheck that the fun starts
<gonz_>
They're hard enough for Haskell tooling to fail at auto-formatting, that's all I know. :D
<gonz_>
#justhaskellthings
<companion_cube>
what does formatting mean for a whitespace language? :D
<gonz_>
It means peace of mind instead of sitting there formatting manually like a troglodyte... :/
<gonz_>
There are standards, or at the very least there should be.
<gonz_>
Someone please make a standard...
<companion_cube>
I mean, it can't guess indentation for you, since indentation is part of the syntax, right?
<gonz_>
That part you have to get right, but then it can set other stuff up for you. There are tools, but they sometimes literally will break code. It'll usually figure out how to break lines for you in a reasonable fashion, etc.
dimenus has joined #zig
<gonz_>
`purty` does the same for PureScript, though it's made some choices I'm not a fan of. But I'm honestly happier to have a formatter than having my own style.
<gonz_>
companion_cube: Do you use ocpindent?
<companion_cube>
yes, but not ocamlformat
<companion_cube>
(also note that OCaml is whitespace insensitive)
<gonz_>
Sure, but they'll accomplish the same thing in many cases. I format(ted) our OCaml code exactly like I would my Haskell code.
<gonz_>
(in the places where it made sense)
<companion_cube>
I hope you didn't use the `;`-prefix style for records
<companion_cube>
or we won't be friends :p
<gonz_>
It's confirmed, we will *not* be friends.
<pixelherodev>
Noooooo
<gonz_>
If you mean item separators at the start of lines.
<pixelherodev>
Sorry, this is the closest thing to a drama that I watch
<pixelherodev>
;)
<companion_cube>
gonz_: yeah, it's bad style in OCaml imho
<companion_cube>
we have trailing `;`, use them, it's not hsakell
<gonz_>
It's great style everywhere IMO :D
<companion_cube>
haskell*
<companion_cube>
that's stockholm syndrome
<companion_cube>
the syntax doesn't make sense
<companion_cube>
`;` is a suffix, not a prefix
<companion_cube>
`{a; b; c;}` works, but `{;a ;b ;c}` doesn't
<companion_cube>
(note that `|` is a prefix)
<gonz_>
Wow, I see I've hit an Elm nerve
<gonz_>
:D
<gonz_>
(by way of Haskell, I guess)
<fengb>
Elm is lame 🙃
<companion_cube>
no, it just irks me to see that ugly syntax in OCaml
<companion_cube>
(or dhall, or other things reached by the dubious taste of haskell)
<gonz_>
Meh, it's fine IMO
cren has quit [Remote host closed the connection]
<fengb>
Aren’t they cousin languages?
<companion_cube>
not syntactically
<fengb>
Never seen so much infighting before 🙃
<gonz_>
If we had made open source stuff I would've cared, but it was literally just code for us.
layneson has quit [Quit: WeeChat 2.8]
joey152 has quit [Remote host closed the connection]
<dimenus>
is anyone working on aarch64? having weird issues with my repo when running a binary directly, everything works fine with the elf file though
<dimenus>
works fine in release-fast, prints garbage in debug
<andrewrk>
dimenus, what is the hex or binary interpretation of the garbage?
<andrewrk>
zig emits "undefined" as 0xaaaaaaaaa
<dimenus>
it's actually printing out the variables passed in 'logf' correctly
<dimenus>
just not the ro strings
<FireFox317>
dimenus, PiOS nice! My next project was an aarch64 kernel thing on the RPI too XD
<dimenus>
it's just weird that it works correctly in release-fast but not debug (and works fine when passed a real elf instead of a flat file)
<dimenus>
andrewrk: console.logf("{}", .{"Hello from PiOS v0.1\n"}); prints correctly
Vexu has quit []
<FireFox317>
dimenus, passed a elf to what?
<dimenus>
FireFox317: qemu
<FireFox317>
so it never works with a flat file?
<dimenus>
nope, it works with a release-fast flat file
<dimenus>
but doesn't print the compiled in strings in debug
<FireFox317>
so the entry stuff is correct. Maybe an alignment issue or something? Because ELF files sections are 4k aligned, and a flat binary isnot
<FireFox317>
you have set the exception handlers and stuff, so it will print if an exception happens?
<dimenus>
i have not set the exception handlesrs yet
<FireFox317>
so maybe an exception trigger, that could give you more info. Maybe you dont need the handlers and qemu can tell you more
klltkr has joined #zig
<dimenus>
that's totally the problem, thanks Firefox317
<dimenus>
it's an alignment issue
<dimenus>
i take that back
<FireFox317>
aarch64 is really picky about alignment, it doesnt allow unaligned memory access, and stack pointer should always be 4 byte aligned and stuff. :)
<frett27>
Hi folks, i had no success in building cross compile for armv7a, any succeeded here ?
<frett27>
when compiling, with arm-linux-gnu armv7a
<frett27>
parameters for zig-bootstrap
<frett27>
i had an error telling me the arch is not supported (list then the target and armv7a is not present in the list)
<frett27>
i also tried the "generic+v7a" in mcpu, with no success ?
<fengb>
v7a is listed as a feature. Which cpu are you targeting?
<frett27>
FireFox317, this is the same as the binary 0.6.0, but my need is to compile my iotmonitor (http://github.com/frett27/iotmonitor) on rpi / orangepi
<frett27>
i need the gnuabi
<frett27>
gnuabihf, more specificly
<andrewrk>
you need to dynamic link against glibc?
<frett27>
non, but leveldb
<frett27>
mosquitto is statically linked
<frett27>
ok, lets try then
<FireFox317>
so you just want to cross compile some c/c++ code or you actually want a working zig compiler on armv7a?
<FireFox317>
frett27 ^^
<frett27>
i want to have zig ARM, for building the project iotmonitor on the orangepi, the orangepi has some library (leveldb) i have to link the project to ?
<frett27>
s/?/:-)/
<andrewrk>
dimenus, was there a missing safety check for alignment somewhere?
<frett27>
building iotmonitor depends on having zig on arm :-)
<andrewrk>
frett27, no matter which target you select when using ziglang/bootstrap, the resulting zig compiler will have the same target capabilities
<dimenus>
andrewrk: false alarm, i didn't find it yet. still working on getting setup with gdb on qemu-multiarch
<dimenus>
i commented out all of the asm routines (other than start.S) and it still didn't do anything different
<andrewrk>
frett27, therefore I suggest to use `./build -j$(nproc) arm-linux-musleabihf baseline`
<andrewrk>
frett27, once you have zig executable on your orangepi machine, then you can use the native target (no -target option) and link with leveldb
<afontain_>
oh, maybe I could try to disable optimisations
klltkr has quit [Ping timeout: 240 seconds]
<mikdusan>
afontain_: yes `zig cc` produces an unusable exe when building on host alpine, and linking to a .so
<andrewrk>
ah is this the part where assuming musl is always static is being problematic?
<afontain_>
ah
<afontain_>
known issue then
klltkr has joined #zig
<mikdusan>
i think yes, there is no way to tell `zig cc` to use host musl. if musl is in target, it's going to be static.
Akuli has quit [Quit: Leaving]
<afontain_>
I guess I'm too used to the "if it compiles, it works" then
<afontain_>
but then it is not possible to make --target=…-musl using shared objects anywhere?
<FireFox317>
frett27, the issue you were found was fixed by TheLemonMan and is now in the master branch of zig. the zig-bootstrap repo though still has zig 0.6.0, so the fix is not in there yet.
<FireFox317>
You have to clone the ziglang/zig repo and move that one in the zig-bootstrap repo or something along those lines
<mikdusan>
afontain_: what I can say is if -musl is in the target, it's going to be built statically by zig when needing a libc; and libSDL.so has undef symbols it wants which are not going to get resolved by musl.a
<afontain_>
ok
<afontain_>
I'm trying to build it with libSDL2*.a at the moment
<afontain_>
there are missing symbols though
joey152 has joined #zig
<frett27>
FireFox317, thank's for your update, i currently have replaced the zig subfolder with master in bootstrap, it compiles .. :-) stay tuned
<mikdusan>
libSDL2.a is probably going to need some X11 libs
<mikdusan>
which then would need to be .a too.
<frett27>
i recompiled my project with the master, and did need any more the -lc++ and -lc++abi ... sweet !
<frett27>
s/did /did not/
<fengb>
It's working? Yay
<afontain_>
`ar t /usr/lib/libSDL2main.a` says SDL_dummy_main.c.o
<afontain_>
soo…
<afontain_>
let's link with the gcc linker then
ur5us has quit [Quit: Leaving]
<dimenus>
andrewrk: maybe i'm running an unsupported config. Your ClashOS runs the elf file instead of the flat binary file as well when using qemu
<GreaseMonkey>
hmm, is there a list of built-in errors i can refer to while there happens to be no list of built-in errors in the 0.6.0 docs?
<FireFox317>
GreaseMonkey, what do you mean by built-in errors?
<GreaseMonkey>
there are several errors in the error.* space which are built in
<FireFox317>
no? there arent
<GreaseMonkey>
...welp, alright then
<GreaseMonkey>
with that said there are definitely errors which have common meanings, e.g. error.EndOfStream
<GreaseMonkey>
i'm not sure if error.Underflow is what i should be using when underflowing a buffer, as it tends to be used for numerical underflow
<GreaseMonkey>
looking at some of the collection types in the stdlib, it seems they'd rather use assert() than return an explicit error when empty
<FireFox317>
uhm yeah if you really want to know that you should indeed look at the std library source
<FireFox317>
the docs aren't complete yet
<GreaseMonkey>
is there a good place to help w/ getting the docs complete?
dermetfan has joined #zig
<pixelherodev>
daurnimator, what was the issue with mixins?
<FireFox317>
GreaseMonkey, uhm well the zig code base xd. I mean there are issues with the docs generation, but also with code not having proper docs in it
dermetfan has quit [Ping timeout: 272 seconds]
Chris660 has quit [Ping timeout: 240 seconds]
<GreaseMonkey>
andrewrk: quick q, are there any guarantees on how long usize will be? for my purposes i'll need to make sure that it can handle enough for a very large file - so 32 bits won't be enough, but 64 should be good for now
<fengb>
usize = ptrsize
<GreaseMonkey>
...ouch.
<fengb>
So it varies between platforms. If you need exact size, use a u64
sanaris has quit [Quit: leaving]
<GreaseMonkey>
this *is* for a sliding window implementation though, and it does depend on if it's better to track an offset from the start or not
<GreaseMonkey>
said sliding window is intended for use in the LZ77 component of a deflate decompressor i'm working on
<GreaseMonkey>
for compression it's fine to not care about the offset from the start
<nephele>
andrewrk, I played around with minetest a bit more, addinc "-lc++" to the zig c++ commandline (and the zig cc commandline) did not help it for linking the __cxa_thread_atexit_impl symbol
<nephele>
And i somehow doubt -lc++ should be needed? Atleast minetest compiles without that explicit flag with gcc (and i think clang too)
Xavi92 has quit [Remote host closed the connection]
frett27 has quit [Ping timeout: 265 seconds]
<andrewrk>
GreaseMonkey, is your data all in memory in this example?
<GreaseMonkey>
andrewrk: no, it's being read from a file
<GreaseMonkey>
and i *think* i can get away with doing all offsets relative to the end of the sliding window for implementing an inflater
<andrewrk>
file offsets use u64
<andrewrk>
e.g. the offset parameter to pread and pwrite is a u64
<GreaseMonkey>
thanks for that, would uoff or uoffs be a sensible type to propose for that?
<andrewrk>
you want to change pread and pwrite to use a different type for file offsets?
<GreaseMonkey>
or would that be confused with somehow being equal to off_t in such a way that off_t could be 32-bit
<GreaseMonkey>
internally it should always be at least 64-bit
<andrewrk>
so far I don't see a reason for std lib to change in this regard
<GreaseMonkey>
so u64 is fine technically, i just happen to be a bit of a fan of explicit semantics, that's all
<GreaseMonkey>
yeah i think u64 should be fine for now
<andrewrk>
u64 is pretty explicit, what are you trying to accomplish by changing it?
<GreaseMonkey>
...y'know what, when we start seeing exabyte-level files it can be readdressed
<GreaseMonkey>
until then, i'm sold on u64
<andrewrk>
hm? pow(2, 64) > pow(1000, 6)
<GreaseMonkey>
>>> 1000**6/2**64
<GreaseMonkey>
0.05421010862427522
<GreaseMonkey>
1 exabyte is about 5% of the way towards the use of u64 for file offsets becoming a problem
<GreaseMonkey>
and i've yet to see a terabyte-sized file although they probably exist
<pixelherodev>
If people are making insanely large files that's their problem.
<GreaseMonkey>
exactly
<pixelherodev>
If you have a file big enough that it can't be represented in a 64-bit address space, pointer size is the least of your worries
<GreaseMonkey>
and also you'd need an OS that can handle files larger than that yeah
<pixelherodev>
A bigger one is probably that it *can't be represented in a 64-bit address space*
<pixelherodev>
Worth noting: we don't even have 64-bit address spaces yet
<pixelherodev>
I think the highest you can get today is 56-bit?
<pixelherodev>
and consumer hardware isn't even that high yet IIRC
<GreaseMonkey>
eh, systems with 32-bit address spaces can still handle multigigabyte files
<GreaseMonkey>
and i mean > 4GB
<GreaseMonkey>
they just can't mmap() the whole thing, that's all
<pixelherodev>
48-bit on amd64 systems, currently
<pixelherodev>
Sure, but you're still going to have issues
<GreaseMonkey>
and as for pointless facts, the N64's virtual address space i think is 40-bit, so 1TB
<pixelherodev>
So I just realized the lightzing example only works because the allocator is set to the page allocator :P
<pixelherodev>
It uses a `defer allocator.free(mmaped_memory);` :P
factormystic has joined #zig
marijnfs1 has joined #zig
<GreaseMonkey>
well that's interesting, after all that rearchitecting, my test archive now takes 21 seconds instead of 24 seconds w/ -Drelease-fast to decompress into a black hole
<GreaseMonkey>
and i now have a new collection which could be stdlibbable
<GreaseMonkey>
(for reference, gunzip into /dev/null takes about 8 seconds for this archive)
marijnfs has quit [Ping timeout: 264 seconds]
FireFox317 has quit [Ping timeout: 250 seconds]
<pixelherodev>
37% of a gunzip faster is nothing to scoff at :)
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
marijnfs1 has quit [Quit: Lost terminal]
<GreaseMonkey>
i'm mostly trying to get this into a form where you could actually use it in the stdlib