mahmudov has quit [Remote host closed the connection]
Snetry has quit [Ping timeout: 240 seconds]
Snetry has joined #zig
seoushi has quit [Ping timeout: 265 seconds]
ForLoveOfCats has quit [Quit: Konversation terminated!]
<student069>
hey would anyone mind looking over some zig code and giving some constructive criticism? I made a little version of "tail" :). https://yld.me/BiF
ofelas has joined #zig
return0e has quit [Remote host closed the connection]
<fengb>
Few quick things: replace `foo() catch |err| return err` with `try foo()`
<student069>
ohhh i forgot that is syntactic sugar and == same
<fengb>
Generally you want to check the error and only handle what makes sense.
<fengb>
switch (err) and match specific ones, returning the rest. It’ll prevent new errors from being eaten if the api changes
<student069>
oh neat that makes sense... so i really only want to catch a specific error (like Unseekable or something for seekTo)
<fengb>
There should be a read until eof helper
<student069>
oh yea i was wondering about that actually. There is an error it returns if the buffer is too small... is that something i should just catch and continue looping on?
<student069>
using readUntilDelimiterorEOF makes sense i think then. I went a little out of my way when somethign is there it seems haha
<fengb>
actually I think what you have makes more sense
Snetry has quit [Ping timeout: 272 seconds]
<student069>
oh? ok cool
Snetry has joined #zig
<student069>
fengb do you think thats something that could possibly improved upon upstream? I wouldn't mind taking a shot at helping out :D
frmdstryr has quit [Remote host closed the connection]
backwhack has joined #zig
<student069>
oh cool thanks bruv. Appreciate your help
Snetry- has joined #zig
Snetry has quit [Ping timeout: 268 seconds]
seoushi has joined #zig
<pixelherodev>
Regarding range iteration: could easily write a RangeIterator type
<pixelherodev>
Then do `var i = RangeIterator(min, max); while (i.next()) |index| {}`
<pixelherodev>
There's just not much point
<pixelherodev>
Since the equivalent untyped code is simpler and smaller
waleee-cl has quit [Quit: Connection closed for inactivity]
jicksaw has quit [Quit: ZNC is kill]
jicksaw has joined #zig
<seoushi>
is there something like calloc? where an alloc will also zero out the memory?
<mikdusan>
for external C structs?
<seoushi>
no, just got allocated memory for zig
<pixelherodev>
`allocator.alloc();std.mem.set`?
<seoushi>
thanks.. looks like there is @memset as well but the docs say a for loop like I'm doing will be turned into a memset anyways. So I think I'll stick with the for loop
<fengb>
Oh hey, if we get tuple declarations, I think we can get a pretty decent struct of arrays
Snetry has quit [Ping timeout: 260 seconds]
Snetry has joined #zig
<pixelherodev>
fengb, sure, but did you tune for perf yet?
<pixelherodev>
The fastest there is a manually optimized version
<pixelherodev>
Right?
<fengb>
I took a quick look at the other tuned versions and didn't find any glaring differences
<fengb>
Although we're still better than the tuned Rust implementation so yay :P
<pixelherodev>
Sure, but until it beats C++ I'm not happy :)
<pixelherodev>
Maybe compare LLVM IR produced by Clang with that from Zig?
<pixelherodev>
Clang's is 1.05, so that might provide some useful hints
<fengb>
The only thing I noticed with C++ was using references
<pixelherodev>
As opposed to?
Snetry has quit [Ping timeout: 240 seconds]
<fengb>
Mutating references instead of returning pointers
<pixelherodev>
I mean, you're already using an arenaallocator
<pixelherodev>
Ohhh
<pixelherodev>
You're using the pageallocator?
<pixelherodev>
I don't think that's exactly highly performant
<pixelherodev>
IIRC that's a placeholder
<fengb>
That too. I could glue in a C allocator real quick
<pixelherodev>
Basically, a *correct* allocator to hold off until the general purpose one is ready
<pixelherodev>
I was just going to suggest that :)
<pixelherodev>
Does the C++ version do error checking?
<pixelherodev>
` 0 => try tree.insert(cur),`
<pixelherodev>
If not, maybe try a `catch unreachable` instead?
<pixelherodev>
That'll get optimized out of the release build, which is *bad*, but again, I highly doubt the C++ version checks if allocations succeed
<pixelherodev>
Yep
Snetry has joined #zig
<fengb>
About the same with both changes
<pixelherodev>
Just to confirm, building in release fast mode?
<pixelherodev>
In a similar vein, I assume you ran the tuned test locally?
<fengb>
Yeah
<pixelherodev>
Mind pasting the IR for both somewhere?
<pixelherodev>
If you do, I can always generate it locally
<fengb>
lol nope, `*#69 = Assertion failed at /Users/benjamin.feng/projects/zig/src/ir.cpp:10379 in const_ptr_pointee. This is a bug in the Zig compiler.`
<fengb>
But only when doing verbose-ir
Snetry has quit [Ping timeout: 265 seconds]
<pixelherodev>
Not verbose-ir
<pixelherodev>
`verbose-llvm-ir`
<pixelherodev>
I don't know Zig IR that well :P
<pixelherodev>
And it'd be useless for comparison to Clang's output
<fengb>
Segmentation fault: 11
<pixelherodev>
... huh
<pixelherodev>
Guess I'll do it locally then
<fengb>
Oddly, it got to "optimizations"
<pixelherodev>
Emits locally w/o issue
<fengb>
So maybe it printed okay? But then it could be corrupted IR
<pixelherodev>
That's what I intend to work on if I apply for a Zig project
Snetry has joined #zig
<pixelherodev>
self-hosted linking is mentioned at present; I'm referring to a full backend
marmotini_ has quit [Ping timeout: 260 seconds]
dddddd has quit [Ping timeout: 246 seconds]
<daurnimator>
BaroqueLarouche: what if I want a raw file but not installed?
<pixelherodev>
fengb, wait really? Could've sworn I upgrade less than two weeks ago
ur5us has quit [Ping timeout: 272 seconds]
Snetry has quit [Ping timeout: 265 seconds]
Snetry has joined #zig
<pixelherodev>
Oh wait, probably easier to just look at the assembly
<pixelherodev>
That way, there's not all the metadata in the way
<pixelherodev>
Or maybe I'm too used to writing assembly directly :P
<pixelherodev>
Okay, so I get ~0.32s for `clang -O3` with the tuned C++ version, and ~0.44s for `zig --release-fast`
<pixelherodev>
Going to do proper profiling (i.e. callgrind)
<fengb>
You care a lot more than me :P
<fengb>
Is it possible to doc comment the file? Just /// at the very top?
* pixelherodev
shrugs
<mikdusan>
try calling libc's rand()
seoushi has quit [Ping timeout: 260 seconds]
<pixelherodev>
That's worse
<pixelherodev>
Though that might be because of int casting
<pixelherodev>
Ohhh, it might be because the Zig RNG uses a larger type for rand
Snetry has quit [Ping timeout: 268 seconds]
<pixelherodev>
I take that back
<pixelherodev>
It's probably faster
<pixelherodev>
But my CPU is under intense load right now :P
<pixelherodev>
mikdusan, if there's a real difference, it's tiny
<pixelherodev>
Like, ~50ms average tops
<pixelherodev>
at a rough estimate
<fengb>
50ms is 10% of execution time :P
<pixelherodev>
That's because I meant 5, not 50 :P
<pixelherodev>
Hold on,integrating my earlier suggestions and retrying
<mikdusan>
not a big diff
<pixelherodev>
Switching to the C allocator doesn't noticeably improve perf either
<pixelherodev>
If anything, it's slightly worse now
Snetry has joined #zig
<pixelherodev>
It's possible the overhead of the extra function call ~1,000,000 times might be bad if the allocator call isn't inlined
<mikdusan>
could make a bump allocator to factor it out
<pixelherodev>
Or just modify that call to be inline locally :P
<fengb>
That's what the arena was for :P
<mikdusan>
it's an interface
<pixelherodev>
"unable to inline func"
<pixelherodev>
Yeah
<pixelherodev>
fengb, that won't help; it's still dealing with overhead on each call
<pixelherodev>
That removes the overhead of `free`
<pixelherodev>
The jumparound to get to malloc is still there
<fengb>
Ah well allocators can't be inlined atm
<mikdusan>
arena remove overhead of free, and makes allocs ridiculously fast
<fengb>
Erh interfaces
<pixelherodev>
"ridiculously fast" sure, but on a practical level that's still multiple extra `call + ret` pairs that the C++ version doesn't have
<pixelherodev>
two calls and two rets for every single allocation
<pixelherodev>
Of which there are *many*
<pixelherodev>
That's easily more than four million extraneous instructions
<pixelherodev>
Add in the casting and such, and it's probably a bit higher
<fengb>
So... get rid of the allocator, make an array of nodes and bump it forward?
<pixelherodev>
Maybe
<fengb>
Feels a little cheating heh
<pixelherodev>
Sure, but that's kind of the point
<pixelherodev>
I mean, for a tuned version
<pixelherodev>
The simple/expressive version should definitely stick to a std.mem.Allocator
<mikdusan>
well I gave it a bump allocator and no gains
<pixelherodev>
I'm going to do actual profiling; rule one of optimizing: humans suck at it :)
<fengb>
I destroyed the productivity of this room
<pixelherodev>
:P
<pixelherodev>
Or, possibly, you may have found some performance problems that need to be addressed so Zig can live up to its promised "faster than C" performance :)
<fengb>
Oops, I never called free. Leak!
<pixelherodev>
Yeah you did...
<pixelherodev>
`defer arena.deinit()`?
<fengb>
I meant inside the tree
<fengb>
So wiring in c_allocator would leak like a sieve
<pixelherodev>
So? Shouldn't that be going through the arenaallocator?
<daurnimator>
pixelherodev: can you put a proposal on the GSoC ideas page? and.... who would you want/expect to mentor it?
<pixelherodev>
daurnimator, yes to the first
<pixelherodev>
Not sure
<pixelherodev>
Anyone who is interested I suppose?
<fengb>
Maybe ~10ms faster with a simple bump allocator
<daurnimator>
I've been considering putting up a http library as an option..... but I don't think we have the work unblocked enough
<daurnimator>
Maybe I should put up the command-driven io layer I've been thinking about for a while
<pixelherodev>
If this helps, ~52% of time is spent in Node.splitBinary, and about 40% is Node.merge
<pixelherodev>
The arena is only ~2.5% of CPU usage
<pixelherodev>
s/arena/allocations
<pixelherodev>
RNG is similarly ~2%
<daurnimator>
that's actually quite high
<pixelherodev>
Well yeah
<daurnimator>
the interface abstraction is going to be a significant portion of that
<pixelherodev>
But relatively speaking it's not that much
<pixelherodev>
fengb, is it actually valid to give splitBinary a pair of nulls?
<daurnimator>
if you tried out mixins you would probably drop those 2.5 and 2% away....
<fengb>
No idea. I just translated the code. I wasn't even confident it's correct, but it matches the answer
<pixelherodev>
I'm going to work on improving the performance (as the person who probably cares the most :P), I'll let you know how it goes
<pixelherodev>
Hmm
<fengb>
Great, I have 3x versions of the same enum and now it's coming to haunt me
adamkowalski has joined #zig
<pixelherodev>
daurnimator, the interface abstraction shouldn't cost that much, should it?
<pixelherodev>
Hold on, clarification: which interfaces?
<daurnimator>
pixelherodev: e.g. `arenaallocator.free()` despite being theorectically a no-op needs to go through a pointer lookup and a function call
<daurnimator>
and for a bump allocator; I believe that we can't optimize (i.e. inline) across the allocator interface?
<pixelherodev>
Oh right, yeah...
<pixelherodev>
fengb, how big did the allocator need to be?
<pixelherodev>
Going to try cheating a little bit more
<pixelherodev>
Ohhh I think I know why Zig is losing out
<pixelherodev>
Pretty sure the C++ tuned version effectively uses a *pooled* ArenaAllocator
<pixelherodev>
Which means it doesn't even need to bother with actual malloc() calls more than a few times *ever*, so regardless of whatever allocator we use our allocations are significant
<pixelherodev>
`total heap usage: 9 allocs, 9 frees` for the C++ version
<pixelherodev>
Whereas IIRC a Zig ArenaAllocator will be making a loooot of them
<pixelherodev>
daurnimator, Zig actually spends less time in RNG than C++ does
<pixelherodev>
C++ is 4% of X, Zig is 2% of 1.1x; half the *relative* time, and only slightly more *real* time, so probably 2/3rds tops
<pixelherodev>
Which explains why switching to rand made it worse; I think Zig's RNG implementation outperforms C's
<mikdusan>
i didn't see any effect switching all usize -> u32, and using c.rand(). I saw a 4.5% improvment by using a bump allocator for all nodes.
<pixelherodev>
I saw a decrease of ~1-2% by using c.rand
<mikdusan>
heh i just made at file scope `var heap: [1024*1024]Node = undefined;` and then `var heap_next: usize = 0;` lol
<daurnimator>
mikdusan: make a GSoC proposal :)
<pixelherodev>
Here's an interesting note: the C++ functions don't return values, they return void
<pixelherodev>
They use output pointers passed through as arguments
<fengb>
I had trouble getting the stack to compile. Kept getting seg faults
<mikdusan>
daurnimator: regex
<fengb>
String/html template engine?
tucibi has joined #zig
<adamkowalski>
can default fields of structs reference other fields?
<adamkowalski>
I want to have a struct which holds a allocator, and a hash map. If no hash map is provided I want to create one using the structs allocator field
tucibi has quit [Ping timeout: 260 seconds]
ur5us has joined #zig
<fengb>
Probably better off with an init function
<Snektron>
Also, adamkowaldki, you really gotta watch out with that
<Snektron>
If the struct moves the reference to your allocator becomes invalid of course
<pixelherodev>
Hmm, yeah, looking at the C++ source, not returning values was part of the perf tuning
BaroqueLarouche has quit [Quit: Connection closed for inactivity]
<pixelherodev>
According to the chart on GH, that change brings its perf from 1.2x to 1.1x the fastest, whereas we're currently at ~1.25x
<pixelherodev>
Closer to 1.4x for me actually
nofmal has joined #zig
<nofmal>
hello, i was wondering if arena allocator is the closest thing equivalent to c malloc?
<pixelherodev>
No, arena allocator isn't a normal allocator at all
<pixelherodev>
The closest current equivalent is probably std.heap.page_allocator
<fengb>
We don’t have a general purpose allocator in std yet
<nofmal>
i see, so page_allocator it is. thank you
<nofmal>
fengb: yeah i knew that, which is why i asked
<mikdusan>
nofmal: page_allocator + arena make good choices. page allocator alone is probably not a good idea
<nofmal>
you can combine the two? how?
<mikdusan>
arena is initialized with a backing allocator
<mikdusan>
use page_allocator as backing
<nofmal>
you meant fallback_allocator?
<nofmal>
backing allocator as in fallback_allocator?
adamkowalski has quit [Remote host closed the connection]
<mikdusan>
I don't want to nitpick but never liked the term fallback-allocator. To me that implies failure. So arena uses a child/underlying/fallback/backing allocator to do the _Actual_ allocations in larger chunks. then it dishes them out to call sites of arena.allocate in granularity.
<mikdusan>
and you don't have to call arena.deallocate -- it's a noop. you free all accumulated allocations at once by calling arena_state.deinit()
<fengb>
Just to be confusing, sometimes it’s called a child allocator :P
<mikdusan>
lol
<mikdusan>
I know right
<nofmal>
so this is how you use the code i'm guessing?: `var arena_allocator = ArenaAllocator.init(page_allocator);`
<nofmal>
and then `arena_allocator.deinit()` right?
<mikdusan>
in that example Buffer will use arena. possibly multiple times. and at end of block arena frees all memory it may have allocated via page_allocator
<nofmal>
i see, thank you!
<pixelherodev>
It possible to do a release fast build that still has debug info?
<mikdusan>
daurnimator: I don't really know which would be a good base. I use ruby often so Onigmo is fine but maybe perf is paramount other choices
<pixelherodev>
I'd vote standard
<pixelherodev>
Don't want to optimize based on profiling data of the debug build, but release-fast build doesn't have enough good info
<pixelherodev>
... those are two different conversation threads.
nofmal has quit [Quit: "quit"]
<daurnimator>
mikdusan: re2 is notable for it's predictable resource usage
<mikdusan>
pixelherodev: I understand that clang has a few specialized options, not sure what codegen selects to be honest. clang front end exposes -Og, -g, and I don't know what -g0, -g2, -g3, -ggdb0 ... -ggdb3 or -glldb or -gsce can do :(
<pixelherodev>
There a way to change it with Zig?
<mikdusan>
pixelherodev: not that I know of
return0e has joined #zig
<mikdusan>
hey there's a GSoC idea. implement zig userland to show all compiler options used. and have stage1 emit that info during --verbose-codegen . zig0 need not apply :)
<pixelherodev>
Keep in mind GSoC is supposed to last for a decent while
<mikdusan>
sleep a microsecond (yes something small). then expect NEVER to have 50ms time spread... on a non-realtime scheduled OS... running in my slow VM... :)
<daurnimator>
mikdusan: context?
<mikdusan>
about 1-in-10 times that test fails during usual `zig build test`
<mikdusan>
it also could be because time_1 - time_0 can be 0 too
<mikdusan>
well maybe not. sleep( 1 million ns which is 1 millisecond ). so I guess milliTimestamp() is guaranteed to bump
<mikdusan>
but 50 milliseconds margin ... not guaranteed between a get-time / sleep iota / get-time
<SyrupThinker>
I'm working on a pure Lua 5.4 implementation that tries to keep the API mostly compatible, no ETA yet though. Currently only have parts of the parser done
<shakesoda>
daurnimator: how lazy is the evaluation? can you define your own pop that does the settop to work around?
<daurnimator>
SyrupThinker: 1. 5.4 isn't released yet so you're chasing a moving target. 2. never start a lua implementation from the parser! start from lvm.c; you'll do much better
<daurnimator>
shakesoda: yes you can.
<shakesoda>
i can certainly live with that as a temporary state of affairs
<SyrupThinker>
daurnimator: Pff, you're not my mom :P
<SyrupThinker>
Also I'm confident the language won't change much considering its beta
<SyrupThinker>
Also the grammar is quite simple, why wouldn't I write the parser from scratch?
<SyrupThinker>
Being implementation incompatible but reference compatible exposes a bug in the reference implementation the way I see it
<fengb>
Zig moves so fast, everything else looks stable 🙃
<daurnimator>
SyrupThinker: because you'll want to be using output of luac to compare anyway :)
<mq32>
fengb, true dat!
<SyrupThinker>
The bytecode isn't specced the way I see it so I'm not targeting that, at least for the moment
<daurnimator>
SyrupThinker: it's worth it to start with
<SyrupThinker>
How so, then I would need to implement a bytecode generator and/or interpreter that I do not plan on using.
<daurnimator>
because it means you can work on just one first; and use the existing extensive test suites
<SyrupThinker>
And I'll definitely start chasing a moving target trying to stay compatible with clua's bytecode
<daurnimator>
it doesn't move that fast
<SyrupThinker>
Faster than the language itself
<daurnimator>
? not really
<SyrupThinker>
You have no guarantees for the bytecode so it can change between every compiler release
<SyrupThinker>
And incompatible language change otoh is quite unlikely
<SyrupThinker>
*An
<daurnimator>
depends if you mean minor or major changes
<SyrupThinker>
I think we are going off topic though
<shakesoda>
is there anything particularly of note in lua 5.4
<shakesoda>
i live in luajit land so i'm a bit out of the loop with puc lua
<SyrupThinker>
They added destructors for lexical scopes
<shakesoda>
like zig's defer?
<shakesoda>
or what
<daurnimator>
yep
<SyrupThinker>
And change some type coercion stuff.
<SyrupThinker>
The way I understand it yed
<shakesoda>
neat
<shakesoda>
oh, they added const
<SyrupThinker>
I thought that was part of 5.3
<daurnimator>
nope
<SyrupThinker>
Also its not quite defer because its a metatable attribute
<SyrupThinker>
Huh, misremembered, must have heard of the const change way earlier than close
<daurnimator>
andrewrk: LMK when you are around. finishing off GSoC thing now
<Snektron>
Is there a more elaborate list of patch notes of lua 5.4?
<daurnimator>
Snektron: its not released yet..... so no :P
<Snektron>
The main ones are not very useful
dddddd_ has joined #zig
<Snektron>
oh, i see
dddddd has quit [Ping timeout: 260 seconds]
dddddd_ is now known as dddddd
frmdstryr has joined #zig
BaroqueLarouche has joined #zig
<BaroqueLarouche>
daurnimator: you mean without the Zig build system ?
<BaroqueLarouche>
daurnimator: for install raw
<fengb>
Is there a way to doc comment the file?
<daurnimator>
BaroqueLarouche: no I mean with
_Vi has quit [Ping timeout: 252 seconds]
BaroqueLarouche has quit [Quit: Connection closed for inactivity]
BaroqueLarouche has joined #zig
dddddd has quit [Quit: ]
dddddd has joined #zig
dch has quit []
dch has joined #zig
l1x has quit []
strmpnk has quit []
l1x has joined #zig
strmpnk has joined #zig
<daurnimator>
We need a good description of zig...
<daurnimator>
Our homepage goes straight to a list of features
<daurnimator>
without an actual mission or anything
<shakesoda>
isn't it wonderful?
<shakesoda>
straight to the point!
<shakesoda>
i quite like the homepage and how easy it is to get to most of what i care about (although the standard library documentation is buried)
<betawaffle>
I wish I could do `.Variant{ ... }` as a shortcut for `.{ .Variant = .{ ... }, }`
<daurnimator>
betawaffle: that would be ambiguous
<fengb>
Didn't Zig used to have a summary, and people on HN complained there's no examples?
<betawaffle>
daurnimator: oh?
<betawaffle>
is there not enough type info at that point?
<shakesoda>
what would it be ambiguous with?
<daurnimator>
betawaffle: hmmmm, I guess not? I was thinking inside of `{}` it could be either a tuple with 1 element or a union
<daurnimator>
fengb: can have both :p
<companion_cube>
ambiguities are something any parser generator will tell you about :)
<betawaffle>
right, the union is what i'm trying to shorten
<betawaffle>
we already have .Variant (an enum, which coerces to a void union variant)
<betawaffle>
it would only work for struct-like values, similar to the other only working for void-like values
<shakesoda>
unrelated: thinking about reimplementing my rendering library in zig for some good practice -> https://github.com/shakesoda/tinyfx
<betawaffle>
daurnimator: i guess what i'm suggesting is syntactic sugar for that pattern of a single field of a struct-like thing which has a value that is also struct-like
<betawaffle>
afaik, that's just invalid syntax now, is it not?
return0__ has joined #zig
return0e has quit [Ping timeout: 265 seconds]
<daurnimator>
frmdstryr: I haven't seen that one before I think. file an issue :)
<frmdstryr>
Thanks, just did
dddddd has quit [Ping timeout: 260 seconds]
_Vi has joined #zig
bheads_ has joined #zig
bheads has quit [Ping timeout: 265 seconds]
bheads_ is now known as bheads
metaleap has joined #zig
marijnfs has joined #zig
davidkrauser has joined #zig
<metaleap>
lol wikipedia.. "Some early C compilers had the feature, now seen as an annoyance, of generating a warning on any function call that did not use the function's returned value."
seoushi has joined #zig
<fengb>
Well, it's a warning. Those are generally annoying
<fengb>
And there's no good way to silence it, so double annoying
<metaleap>
in zig its an error and never found it annoying. yeah warnings blow tho
<fengb>
Because we can do `_ = foo()`
<metaleap>
ah yeah just occurred to me C likely never had such
Snetry has quit [Ping timeout: 260 seconds]
<via>
(void)foo() was the way to silence those iirc
<metaleap>
so i had a []foo typed struct field, and a method mutating inside it. but it was initialized via &[_]foo{....} with no runtime values, all kinda constants/statically known. mutation caused a segfault and i believe that was simply some sort of constant data region not to be written to. so far so fair. but my question:
<metaleap>
couldnt this be a compiler error? a case of "cannot assign to constant". in fact the &[_] should maybe "type into" a `[]const foo` in other words?
<metaleap>
(so to clarify there were just statically-known string/int literals in the initialization of the []foo typed field with &[_]foo{...} )
SimonNa has joined #zig
<Snektron>
The &[_]foo{...} was probably created on the stack
omglasers2 has left #zig [#zig]
<metaleap>
yeah ok but in this case the mutation happened inside the same fn as the initialization, just in the very next statement
<metaleap>
as in the ptr to the struct itself was still valid
<Snektron>
can you link me the code?
<metaleap>
its already gone :D will repro shortly
cncl has quit []
cncl has joined #zig
decentpenguin has quit [Quit: decentpenguin]
Akuli has joined #zig
return0e_ has quit []
ForLoveOfCats has joined #zig
return0__ has quit [Read error: Connection reset by peer]
<ForLoveOfCats>
I'm trying to understand what portions of the bootstrap compiler in C++ is optimized and what portions are not. It seems from reading the CMakeLists.txt that the software float library is compiled with -O3 as are the files `blake2b.c` and `parse_f128.c`. Is my understanding of this correct?
<andrewrk>
ForLoveOfCats, yes
return0e has joined #zig
<ForLoveOfCats>
Thank you for confirming. How best can I compile the rest of the source with -O2 for experimentation purposes?
<andrewrk>
configure with -DCMAKE_BUILD_TYPE=Release
<ForLoveOfCats>
Awesome, thank you for your time
<andrewrk>
no problem
<fengb>
andrewrk: is there a way to doc comment the file?
Snetry has joined #zig
<andrewrk>
I think it's not implemented but accepted proposal to make the first doc comment in a file apply to the struct that is the file itself
<andrewrk>
oh
<andrewrk>
we have //!
<andrewrk>
like rust
<fengb>
Oh okay cool
<fengb>
And files as full structs with fields is the new gold standard right?
<andrewrk>
yes although I haven't tried it yet so maybe you run into something I haven't thought of
<metaleap>
so an @import yields not a struct{...}{} ("isntance") but a struct{...} `type`-of-sorts
<metaleap>
?
ForLoveOfCats has quit [Quit: Konversation terminated!]
<fengb>
Yeah, all files are structs. The std currently assumes it's always an empty struct but you can put fields in it
<andrewrk>
it makes things consistent when dealing with reflection
<student069>
I was wondering if someone could answer a question I had about the stat structure? It looks like if I wanted to access the allocated (block) size of a file I would need to call OS specific stat calls. Is that correct?
dddddd has joined #zig
<andrewrk>
student069, that's correct - the file system is accessed via OS-specific syscalls
<betawaffle>
what about supporting both, with [start..end] and [start..+len] (or something along those lines?
<andrewrk>
also because [start..end] emits a subtraction. and this pattern is common: [start..start+len] which is silly because now zig is emitting a sub and an add that cancel each other out. the actual slice has len
<fengb>
[start..end] [start...len] 🙃
<betawaffle>
that could be a huge footgun
<fengb>
[start....inclusive_end]
<andrewrk>
#863 means that comptime len will be useful, but if your `start` is runtime-known, then `start+len` will be runtime known even if `len` is comptime known. that's the main problem
<andrewrk>
so we'll start to see [start..][0..len] which is more punishing to type than it should be, since it's handy type-wise
<fengb>
I do like ..len. It seems like most of the time I care about len more than end
<betawaffle>
it doesn't help that start+len also tends to be more verbose
<betawaffle>
len is more generally useful
<betawaffle>
so if you want end, it would become [start..end-start]
<fengb>
Although `decl.name[2..2]` this looks funny
<andrewrk>
if the transition happens, I think we'll temporarily have [start,len] (the , sort of indicates that these are fields of the slice struct)
<fengb>
More intentful but weirder looking as opposed to `decl.name[2..4]`
<andrewrk>
sorry, the , would be permanent, but having both .. and , would be temporary
<andrewrk>
decl.name[2,2]
<metaleap>
slicing is from start to end in my book. think intuitively that all [] are "indexers", taking an index. slicings repurposing that syntax is ok if its still "talking indices" rather than "one thing left, another thing right".
<fengb>
[2,2] looks a little better since it's not a weird range
<seoushi>
that kinda reads like a multi array index
<metaleap>
true
<metaleap>
.. is almost "universally understood" in contrast
<seoushi>
I don't think .. is used with a length tho. usualy a range
<metaleap>
yeah.
<fengb>
Yeah
<metaleap>
would rather have it stay that way,
<betawaffle>
definitely not
<fengb>
But... it'd also get rid of the confusion between `slice[0..len]` and switch { 0...end =>`
<andrewrk>
I've been conventionally using "end" to mean "exclusive"
<betawaffle>
hey... while we're talking about indexing... can we add support for "indexing" bits in integers?
<betawaffle>
and slicing them to shorter int types, et
<betawaffle>
etc*
<andrewrk>
"add support for" words of my nightmares
<betawaffle>
like, as a shortcut to @truncate(uN, src >> start)
<student069>
andrewrk so anything not in the Stat struct abstraction would need to be os specific called? Thanks :D
<andrewrk>
student069, that's correct. you can also make a case for adding to the abstraction
<andrewrk>
betawaffle, more seriously - I think the language provides enough tools that a userland implementation of that API would be reasonable
<student069>
andrewrk what would you think about allocated size (vs. just normal size)? :P
<betawaffle>
how can you do userland indexing?
<fengb>
PackedIntArray probably does all of what you want
<metaleap>
"also because [start..end] emits a subtraction" why is this? would instead rather have expected [start..len] to emit an addition?! :D
<metaleap>
as i'm assuming start-addr + len-val
<betawaffle>
metaleap: it's because the length is stored in the slice, not the end
<metaleap>
aah i get it for the new len
<metaleap>
betawaffle: yup thx =)
<metaleap>
yeah ok now i can get on board with this, but indeed range-syntax .. could be background-distracting for the habitual code-reader & more so for the newcomer. now [,] looks like multi-dim arrs but go's syntax [x:y] is also an option perhaps? not too ugly at least, and not so pre-loaded with meaning as range [..]
<betawaffle>
well, zig has multidim arrays and that isn't the syntax for it
<betawaffle>
so i think it's ok
<metaleap>
oops ok i didnt realize about them
_Vi has quit [Ping timeout: 248 seconds]
<andrewrk>
zig's translate-c requires a C tokenizer and parser, which is now exposed in std.c
<betawaffle>
:o
darithorn has joined #zig
<fengb>
metaleap: we're already using `[:0]` for sentinel termination
<metaleap>
aah you're right
<metaleap>
havent needed it so far, hence dropped from head's l1 cache
strmpnk has quit [Ping timeout: 245 seconds]
<andrewrk>
it's mostly behind the scenes, making sure you don't accidentally get a buffer overflow
<betawaffle>
is there a use-case for non-zero sentinels?
l1x has quit [Ping timeout: 248 seconds]
cncl has quit [Ping timeout: 246 seconds]
dch has quit [Ping timeout: 272 seconds]
<fengb>
Replicate cobol systems with 999 sentinels? :P
<Snektron>
Theres always some weird system out there that uses it
<Snektron>
kind of like CHAR_BIT not being 8
<fengb>
More seriously, we needed both 0 and null, so instead of making sentinels specially hard coded, it makes more sense to support any value
<andrewrk>
^
<andrewrk>
maybe the return value of readLine(). it solves the problem of "does the result have the line in it or not?" answer is no but it's there in memory if you want to rely on it
<pixelherodev>
Or, if you have an enum with a special marker for "no more of this enum," you could have e.g. a `[*:EndMarker]EnumType`
ur5us has joined #zig
_Vi has joined #zig
<andrewrk>
finally have llvm10 branch running with debug llvm build (asserts enabled) with some chance of the tests passing. will find out in 20+ hours
<jaredmm>
I started going through the LSP spec page about six months ago. I figure I'll be done by 2022.
<metaleap>
hehe whats worse they update current-version-nr as they see fit. by chance i saw sth for 3.15 yesterday that wasnt there 2 weeks ago when i transcribed the typescript defs to zig type-decls
<metaleap>
a solid joy to code such things with comptime powers tho, thats for sure.
protty has quit [Remote host closed the connection]
<wilsonk>
metaleap: is your code on github for the lsp?
<metaleap>
(going slow because aiming for protocol-completeness-from-the-outset rather than cobble together bits and pieces as desired haphazardly. the way to not get things Done :)