<pixelherodev>
Got install step working by overriding file name after `step.install()`
<pixelherodev>
The nice thing about that performance optimization work is that the hello world lexes in ~0.02 seconds in release-fast mode :D
<pixelherodev>
Can probably do a bit more optimization and get that down to the single digit milliseconds range
<pixelherodev>
... heh. The only reason it's that slow is the 800k token capacity default :P
<pixelherodev>
file.getEndPos() gives file size?
<pixelherodev>
Yep, I can just read through the source :)
<fengb>
One day we’ll have reliable docs too
<betawaffle>
pixelherodev: what are you up to?
<pixelherodev>
Writing the first codegen backend for my libLLVM replacement :)
<pixelherodev>
Using `file size / 6` as the size of the token list boosts perf by ~35% on the hello world, and leaves the self-lexing alone in terms of speed
<pixelherodev>
Well, 35% in debug mode, 80% in release fast mode
<pixelherodev>
It can lex the hello world in 4ms
<pixelherodev>
Here's an idea: a readUntilDelimiterOrEOF written *over* a bufferedstream to use the internal buffer instead of taking a user-provided buffer
<pixelherodev>
That allows for higher performance...
<pixelherodev>
Going to add that to my todo list
mahmudov has quit [Remote host closed the connection]
<daurnimator>
andrewrk: no I was talking of calling printf.... last time I tried I hit a TODO...
<daurnimator>
ah excellent; I *did* leave a comment there
<pixelherodev>
#4418 opened
<pixelherodev>
Reuses the existing `disable-bin-generation` instead of making a new bool `emit-bin`, though it could just be refactored and inverted
<pixelherodev>
The lexer is so fast on the hello world that 10% of time is on platform initialization code beneath main :P
backwhack has joined #zig
<tdeo>
how well does the non-libc dynamic loader work? can it load something as complex as a graphics driver or does it just work on small stuff?
<daurnimator>
tdeo: not an answer to your question... but your graphics driver probably depends on libc itself.....
adamkowalski has joined #zig
knebulae has joined #zig
adamkowalski has left #zig ["ERC (IRC client for Emacs 28.0.50)"]
_Vi has quit [Ping timeout: 256 seconds]
<pixelherodev>
... wow. Okay, so I knew compilation time had gotten worse... but this is *bad*. 60s to compile the lexer after switching some work over to comptime
<pixelherodev>
After quickly changing the functions back to runtime, compilation time goes back down to ~3-5s
seoushi has quit [Ping timeout: 245 seconds]
<tdeo>
daurnimator: yeah, but i feel loading libc at runtime is more "portable" than linking it directly
<tdeo>
feels more like "pure zig" even though it gets loaded
<tdeo>
might not really matter in practice
<daurnimator>
tdeo: libc will really want to be linked as early as possible. there are certain things that can only be done once-per-process on linux. and libc wants to do them
<daurnimator>
s/linked/loaded/
rjtobin has quit [Quit: Leaving]
seoushi has joined #zig
<andrewrk>
tdeo, non-libc dynamic loading is still experimental. it'll work fine eventually
<shachaf>
You're writing your own dynamic loader for this?
<andrewrk>
one of my goals is to ship a video game as a static executable that works on every linux
<andrewrk>
(but still uses the graphics driver and windowing system)
<daurnimator>
shachaf: yeah we had to write the first half of it to use the VDSO; and the second half to inspect our own debug info (used for stack traces).
<shachaf>
How are you going to pull that off?
<daurnimator>
shachaf: what do you mean?
<shachaf>
Calling libGL from a static binary.
<shachaf>
Do you ship your own static libc to link it against?
<daurnimator>
that's the plan.
<andrewrk>
not necessary; the vulkan shared object will link against dynamic libc. so all that is needed is to properly dynamically load everything
<andrewrk>
if there is a libc-specific complication to work around, so be it. the loader can detect which version of libc is being pulled in and emulate that style of dynamic loading
<shachaf>
So you do want to load the system libc, just to do it yourself rather than with ld-linux.so or whatever?
<andrewrk>
I don't care how it's done, I just want to ship a static binary that works everywhere
dingenskirchen has quit [Remote host closed the connection]
<andrewrk>
hard coding a path to a system dynamic linker is a non-starter, since some distros have different paths
<shachaf>
I mean, I also want to do that, I'm just skeptical that it's really possible in practice.
dingenskirchen has joined #zig
<shachaf>
But maybe you can make it work in practice for just about all systems that exist.
<daurnimator>
I know in gobo linux they just hit it from getdents
<andrewrk>
zig has special code to detect the "native dynamic linker path" by inspecting its own dynamic library dependencies, looking for the dynamic loader
<daurnimator>
oh right; the whole nix "patchelf" thing is how they do it
drp_ has quit [Remote host closed the connection]
<andrewrk>
but if you use zig to cross compile on nixos, targeting the same cpu that you're running on, it won't work without qemu or patchelf
<andrewrk>
because zig will put the standard dynamic library path in there, as expected for cross compiling
dddddd has quit [Ping timeout: 265 seconds]
<daurnimator>
andrewrk: I guess we need a --elf-interpreter option to build-exe ?
<andrewrk>
--dynamic-linker [path] set the path to ld.so
<daurnimator>
ah k..... what does that do for non-elf targets?
<andrewrk>
ignored
<daurnimator>
do we have rpath management as well?
<daurnimator>
We'd need to add support for $ORIGIN magic
<shachaf>
At one point I'd like to see linkers turned into a library rather than a program that you run, where you can just do the thing that you want instead of writing bizarro "linker scripts".
<daurnimator>
shachaf: you mean compile-time linkers?
<shachaf>
Yes.
<daurnimator>
or dynamic linkers?
<companion_cube>
"how hard can it be anyway"
<daurnimator>
but also we have a plan to deprecate linker scripts :)
<daurnimator>
but also..... we already use lld as a library
<daurnimator>
so you're sort of conflating 3 things there
<daurnimator>
shachaf: IIRC the LLD API essentially takes command line arguments and runs in-process
<andrewrk>
yes and I've had to send them a few patches because they don't test this way
<shachaf>
Right, that's what I'd expect.
<shachaf>
Is incremental linking really that important?
<shachaf>
Even if you're going through LLVM, your linker is probably not going to do the expensive part of LLVM's linker (which I assume is LTO).
<andrewrk>
really, nothing short of owning the entire process from start to finish is going to give us the performance within the desired range
<andrewrk>
but as a concrete example, linking is the slowest part of the edit-compile-test cycle of zig stage1 compiler
<andrewrk>
by far
<daurnimator>
shachaf: we intend to support multiple backends for this sort of thing: you might e.g. use the zig one for debug builds and use llvms for release builds/
<daurnimator>
or if your platform of choice isn't supported by lld (e.g. xtensa) then use e.g. gcc
<shakesoda>
is zig build multithreaded
<fengb>
There’s like 5 people in this channel that start with “sh” and I can never get them straight >_>
<andrewrk>
shakesoda, not yet
<shakesoda>
ok, just curious
waleee-cl has quit [Quit: Connection closed for inactivity]
<fengb>
Because i := 0; i < total; i += 1 is too many letters
<andrewrk>
we've had this exact same discussion several times in #zig. someone asks how to loop over a range. a clever person suggests `for ([1]void{{}} ** 10) |_, i| {}`. I ask people to plz don't do that
<pixelherodev>
I second that request
<pixelherodev>
Please nobody ever do that
<shakesoda>
that is certainly nasty
<fengb>
Sure, u0{0} is shorter 🙃
<shakesoda>
is there a preferred way to do a range iteration that doesn't also leave your counter in the parent scope as happens with the while
squeek502 has joined #zig
<shakesoda>
the entire `var i = 0; while (i < n) : (i += 1)` construct is kind of bizarre and long feeling for what it is
<shakesoda>
and those ways with `for` are just plain freaky
<andrewrk>
surround it with { }
<andrewrk>
it teaches to not be afraid of using blocks to limit variable scope
<shakesoda>
suppose that solves for the scope, it's just... even longer
<shakesoda>
and weirder
<fengb>
It’s only weird because we’re all used to 3 statements shoved into 1 in C for loops :P
<andrewrk>
I'm tempted to delete for loops from the language\
<companion_cube>
bikeshedding will not stop before 1.0!
<shakesoda>
fengb: i'm actually more used to lua and haxe's loop iterators which don't use c's iterator form at all
<companion_cube>
just do ruby/crystal style blocks ;)
<andrewrk>
forgot to make a separate "it" variable. oh well
<shakesoda>
fengb: both of which are very short in the typical case of a range iteration: `for i=1,n do`, `for (i in 0...n)`
<andrewrk>
when I merge #4404 it's going to close 9 bugs
<shakesoda>
9 at once! excellent
<fengb>
Async is leveling up!
<andrewrk>
yeah big time. next step is making behavior tests with --test-evented-io pass on windows & bsds without spotty test failures
<andrewrk>
then async gets CI test coverage
<shakesoda>
andrewrk: if for goes away, while might as well just be called loop
<shakesoda>
or repeat or something
<andrewrk>
there is value in overlapping keywords with other languages, especially C
<andrewrk>
less @"loop" required
<shakesoda>
i can agree to that
<shachaf>
One day I'll make my compiler for the language that has "for the rest of this block" flow control and see how well it works in practice.
<companion_cube>
monads would like to have a word with you :)
<companion_cube>
(well… maybe)
<shachaf>
I think delimited continuations are the thing that would like to have a word with me.
<shakesoda>
shachaf: sounds kinda like (pseudocode)... `:here defer goto here`
<shachaf>
But I have some words for them too.
<pixelherodev>
huh. Removing the comptime part speeds up compilation by around 70% but slows down runtime so little it might as well be a statistical error (assuming I didn't mess up my testing)
<shachaf>
I mean that instead of writing "if (b) { ... }" you can write something like "{ if(b)`; ... }"
<pixelherodev>
I guess that means it was the restructure that improved performance more than the comptime offloading
<fengb>
Why not just implement full COMEFROM
<companion_cube>
shachaf: ah, effects maybe
<shachaf>
"{ x := for(xs)`; y := for(ys)`; if(x + y == 0)`; ... }"
<companion_cube>
(still looks awfully like a do-block to me)
<shachaf>
Not very ontopic in here, I suppose. I'd like to figure it out eventually.
<shachaf>
companion_cube: It does, except it's not associative.
<companion_cube>
`;` is always right-associative, is it not?
<shachaf>
Just like if you have C++-style destructors, { { A a; foo(); } bar(); } isn't the same as { A a; { foo(); bar(); } }
<companion_cube>
well each { } is its own do-block
<shachaf>
Sure, but do { a; do { b; c } } == do { do { a; b }; c } is a monad law.
<companion_cube>
but you're right, these might be associative by construction.
<companion_cube>
yeah ok. fair point.
<shachaf>
It's like delimited continuations, where {} means reset and ` means shift, or something.
<pixelherodev>
I mean, if you're comparing destructors to Zig, that `A a;` is equivalent to `const a = A.init();defer a.destroy();`
<companion_cube>
if you make implicit stuff like destructors explicit, the do block becomes non associative too
<shachaf>
Sure, defer has the same property. Should've used Zig notation.
<shachaf>
Anyway this isn't the monad channel.
<companion_cube>
:D the one starting with #h and ending in askell?
<shakesoda>
on another note entirely, what does anyone think about the idea of using anonymous literals to also define structs, a friend of mine mentioned this yesterday
<shakesoda>
since .{ foo: type } is unambiguous from .{ .foo = value }
<shakesoda>
i didn't have a way to shoot that down when asked
ur5us has quit [Ping timeout: 240 seconds]
<shakesoda>
i suppose this brings in the problem of "what about unions and enums?"
<pixelherodev>
Why?
<pixelherodev>
Why is it needde?
<pixelherodev>
s/dde/ded?
<pixelherodev>
So we can use `.` instead of `struct`?
<shakesoda>
essentially, yes, but i'm really just curious here
<pixelherodev>
I think typing an extra five characters and being less ambiguous is better
<pixelherodev>
As is, if you see `.{` you can immediately know what you're looking at
<pixelherodev>
You don't need to see anything else
<shakesoda>
if you see .{ you see one of a couple things
<shakesoda>
until you see what's immediately following you don't yet know if it's going to be a list or a struct init
<pixelherodev>
ah right
<pixelherodev>
Forgot you could do structures like that
<pixelherodev>
Here's a thought for release-fast mode: is it possible to detect when a call can be made at comptime but isn't?
<andrewrk>
that's the halting problem
<pixelherodev>
Let's say I do a runtime `math.pow(2, 9)`; can the compiler detect that all args are comptime known and convert the call to a comptime call?
<pixelherodev>
How so?
<pixelherodev>
Ah right
<andrewrk>
zig actually used to have that. you had to explicitly annotate a function as opting out of being called at comptime when all the parameters are comptime known
<pixelherodev>
Now that I'm looking for it, I can see what you mean
<pixelherodev>
How about a keyword to guarantee that it halts?
<pixelherodev>
Ah
<pixelherodev>
Literally what you linked :)
<andrewrk>
calling a function at comptime is a special case of inlining
<andrewrk>
which the optimizer already does
<andrewrk>
but I do want to somehow get to a place where asserts with a comptime parameter run at comptime
<andrewrk>
there are some tricky design problems to solve there, however
<pixelherodev>
Well, if the main issue is the halting problem, maybe just `halts`?
<pixelherodev>
Sort of like Rust's unsafe code; you're saying that you've checked yourself and it's definitely fine
<andrewrk>
it would integrate with @setEvalBranchQuota
<andrewrk>
what you would need is the ability to tell zig to not try to run it at comptime
<pixelherodev>
That's opt-out; I'm talking opt-in
<pixelherodev>
The `halts` keyword proposal: if a function is marked halts, then in release-fast mode (and *only* in release-fast mode), if all arguments are comptime-known, a call can be converted to a comptime call
<andrewrk>
nah that's just `inline`
<pixelherodev>
The `halts` keyword is a hint to Zig that it can try to run it at comptime, which it defaults to not doing
<pixelherodev>
Wait, inline calls are translated like that already?
<andrewrk>
or rather the auto inliner
<pixelherodev>
Huh... that's interesting, and possibly problematic
<pixelherodev>
The use case I was thinking of: I want debug compilation times to be as fast as possible, so I removed some comptime calls to speed it up
<pixelherodev>
However, in release-fast mode, I want maximum runtime performance regardless of the comptime cost
<andrewrk>
the auto inliner is quite agressive in release-fast mode
<andrewrk>
llvm is perfectly capable of running functions at compile-time too, did you know that?
<pixelherodev>
Huh, no I didn't
<pixelherodev>
The autoinliner might explain why removing the explicit comptime calls didn't affect release-fast performance
<andrewrk>
yeah. comptime function calls are a special case of inlining
<pixelherodev>
Is that a different compiler path from explicit comptime calls?
<pixelherodev>
Explicitly calling it at comptime butchers compile times
<andrewrk>
in theory zig's comptime features can run about as fast as CPython. in practice, it is something like 100x slower
<pixelherodev>
I've had 70s compilation times; removing the explicit `comptime` from a single function call (well, something million; it's an EXTREMELY hot path) reduces compile times to ~3 seconds
<andrewrk>
mostly due to my own fault, since the stage1 code has evolved rather than been designed to work the way it does from the start
<pixelherodev>
I was considering profiling stage1 and making an unmaintainable snapshot of 0.6 that's hand-optimized for performance to the point that the code is completely unreadable
<pixelherodev>
Then I remembered I don't know the compiler internals well enough to do that :P
<andrewrk>
my plan is to just know wtf I'm doing this time since zig already exists now, when I make the self-hosted compiler
<andrewrk>
instead of making it up as I go along
<pixelherodev>
Basically, you make the language up as you go with stage 1, then use the language to write a spec
<pixelherodev>
Then, you rewrite the compiler from the spec, resulting in a good-by-design compiler
<pixelherodev>
That about right?
<andrewrk>
yes
<pixelherodev>
Anyway, I'm going to get back to my LLVM backend now - working on the AST generation now
<pixelherodev>
Annoyingly, it takes much longer to get this thing working now that I've actually bothered *designing* it instead of hacking it together
<pixelherodev>
On the bright side, the hello world-esque tests worked first try without having to hack anything together to "trick" the code into compiling
<pixelherodev>
On a different but related note, just wanted to express my gratitude to you and everyone else who has dedicated real time and effort to make this project a reality
<andrewrk>
:)
<pixelherodev>
Which reminds me, I should put some more of *my* time and effort into the PRs I've opened but not finished
<pixelherodev>
Assuming I typed that URL correctly
<pixelherodev>
I'm happy with #4418 now; going to try getting the null-shrink-fn branch working again
<andrewrk>
thanks
<pixelherodev>
Gah, okay; 4418 just needs to have the `--test-evented-io` lines merged in, which is a minor rebasing issue
<pixelherodev>
Fortunately, GitHub lets me do that easily :)
<pixelherodev>
*Now* it's good.
<pixelherodev>
I think the selection of output name needs to be reworked to check explicitly for bin/asm/llvm, but there's nothing *regressing* (behavior is effectively identical to master) so that can be a future change
<pixelherodev>
That is, output name should be reworked into separate functions for outputName{Bin,Asm,LLVM}
<pixelherodev>
Given that I plan on, eventually, using this project with upstream Zig as a potential compiler backend: is it reasonable for a compiler backend to error out with a poor message if given garbage input in exchange for higher performance on valid inputs?
<pixelherodev>
If it's explicitly only meant to handle compiler-generated inputs, the only situation in which the error messages appear is if the compiler is busted...
<pixelherodev>
I mean, maybe a `comptime if` so it does additional error checking only in debug mode?
<pixelherodev>
Does that async PR mean that tests are run in parallel now?
<andrewrk>
not yet
<pixelherodev>
But it creates the architecture that can be used to enable that?
<pixelherodev>
Would that theoretically speed up CI?
<andrewrk>
yes once async std is more stable, it'll be easy to improve zig build system to make appropriate things run in parallel
<pixelherodev>
That'll be awesome :)
<pixelherodev>
If I need to do a bunch of small allocations, would a good way be to do one large heap allocation and then make a FBA out of that?
<pixelherodev>
This'll be fun: an arena allocator wrapping a fixed buffer allocator wrapping a std.heap.page_allocator allocation :P
<pixelherodev>
.... oh wait, arena isn't needed
<pixelherodev>
Just need to free the original allocation
<pixelherodev>
... well this is great. I get a segfault in file reading if I stop linking in libc...
marmotini_ has joined #zig
_Vi has joined #zig
marmotini_ has quit [Ping timeout: 272 seconds]
seoushi has quit [Ping timeout: 240 seconds]
backwhack has quit [Quit: Connection closed for inactivity]
bheads has quit [Quit: bheads]
bheads has joined #zig
_Vi has quit [Ping timeout: 256 seconds]
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
waleee-cl has joined #zig
return0e has joined #zig
_Vi has joined #zig
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
dddddd has joined #zig
FireFox317 has joined #zig
<daurnimator>
andrewrk: I assume that multibuilds and dependant issues will not be done in 0.6.0. Do we want to shift them all the way to 0.8.0?
dddddd has quit [Ping timeout: 268 seconds]
qazo has quit [Ping timeout: 268 seconds]
dddddd has joined #zig
dddddd_ has joined #zig
dddddd has quit [Ping timeout: 240 seconds]
dddddd_ is now known as dddddd
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
bheads has quit [Quit: bheads]
<fengb>
Gosh, this async IO change fixed everything
<shakesoda>
define everything, i have not used async stuff yet
dingenskirchen has quit [Read error: Connection reset by peer]
dingenskirchen1 has joined #zig
dingenskirchen1 is now known as dingenskirchen
<fengb>
All the bugs
<fengb>
There’s like 2 dozen that are fixed
<companion_cube>
think of all the street cred you now have fengb
<companion_cube>
in 10y you'll be "oh I was using zig before async really worked"
<mq32>
"in the old days, we were packing our structs by hand!"
<fengb>
“I implemented janky async before BDFL showed me how it’s done”
<shakesoda>
back in my day we still had to put a c before some string literals because reasons
<mq32>
before my days, we had "return%"!
<companion_cube>
back in my day the syntax was not rust-like :-°
<mq32>
rust-like?
<fengb>
Back in my day I had to use C
<companion_cube>
mq32: I still hope for some changes in the syntax 0:-)
<BaroqueLarouche>
companion_cube: like what ?
<companion_cube>
mandatory {} in if/while/for (and no ()), for a start, and being a bit more expression oriented by not forcing blocks to have a label for them to return a value
backwhack has joined #zig
<mq32>
companion_cube, that's stuff i like about zig grammar as it's more verbose that way
<mq32>
i liked the Go argumentation on "you don't need () on if, but {}. Don't nag, it's the same amount of characters!"
<FireFox317>
damn, so many issues closed today, nice to see that!
<mq32>
wait, those were 20 issues or something?
<BaroqueLarouche>
Even though the syntax is not elegant, I'm looking forward for https://github.com/ziglang/zig/issues/1717 it will bring more consistency to the language
<mq32>
BaroqueLarouche, yeah that's actually a great thing
<mq32>
and i think it's quite elegant, just uncommon
<mq32>
so most people aren't used to that
<mq32>
Also: Vexu is on fire right now.
<mq32>
Someone: Issue. 30 Minutes later: PR with a fix by vexu
<FireFox317>
Jup indeed mq32, he also found a lot of issues that we solved by andrew's fix yesterday
<andrewrk>
rather than the "triple" having an "arch" field, it's going to have a "cpu" field. and you can be vague and only give an architecture for the cpu. or you can be very specific and name a cpu
<mq32>
i thought so!
<companion_cube>
(anyway, I was just talking about syntax I wish zig had, not syntax it will have)
<mq32>
you always have a plan, andrewrk
<andrewrk>
companion_cube, fun fact, zig used to have that exact syntax
<mq32>
companion_cube, yeah but it's good to discuss about such things. There's always stuff to learn
<companion_cube>
well, it's my personal experience, also.
<andrewrk>
it was awkward to have 2 different ways to return things
<companion_cube>
well imho `return` is the odd one :D
<companion_cube>
(only to be used for early returns, imho)
<fengb>
Ruby has particularly bad accidental returns, but I don't think a typed language would have the same issue
<companion_cube>
in OCaml I've never been bitten by composite expressions returning values, but by dangling else (i.e not having the mandatory {}) many times
<andrewrk>
I have to do that thing now where I go through issues and face the fact that they will not get done in time for 0.6.0 and change the milestone
zfoo_ has joined #zig
<mq32>
do we have an issue for cortex-m3 build is broken due to compiler_rt?
<andrewrk>
not that I'm aware of
<andrewrk>
is that a regression?
<mq32>
seems so?
<mq32>
i've tried compiling for cortex-m3 once and it worked
<mq32>
created #4425 for that issue
<andrewrk>
thanks mq32. this seems like a regression caused by the cpu target features branch
<mq32>
yeah, probably
<andrewrk>
or maybe it is revealing a latent flaw
<mq32>
but that change is *really* a great change
<andrewrk>
yes it's certainly on the path to global maximum
<mq32>
it just feels good to say: "I want cortex_m3!" and it just works (at least in theory)
<andrewrk>
yes and this can certainly be fixed because compiler_rt itself can ask what the CPU is too
<mq32>
which is even more cool
<mq32>
this makes writing high performance code reliable and easy for different target platforms
<fengb>
Oh and at a future point, we can generate feature targeted functions and swap them at load time
<fengb>
Does the pinephone work decently with an external keyboard?
<andrewrk>
there is no software that works decently on it, it's very alpha
qazo has joined #zig
adamkowalski has joined #zig
_Vi has quit [Ping timeout: 260 seconds]
<adamkowalski>
is there a breaking change from yesterdays master to todays? My code no longer compiles haha, is there a commit I should look at so I can get a head start to know what to change
<andrewrk>
yes there were some breaking changes recently
<adamkowalski>
okay looking at the compile error it seems like the signature for std.fmt.format changed?
<andrewrk>
the output function is now required to be comptime
<adamkowalski>
ah, thanks, i'll change that and see if it is fixed!
<adamkowalski>
Yup that's all I needed! Should we consider packing up the arguments for std.fmt.format into a struct so the signature isn't as long? zig fmt doesn't like when I try to format it like in the standard library where each argument is on a new line, so it ends up giving me one really long line with the full signature and it wraps around on my editor
<andrewrk>
put a comma after the last argument and run zig fmt again
<FireFox317>
adamkowalski, did you add a comma after the last argument in the function?
<FireFox317>
what andrewrk said xd
<mq32>
btw, andrewrk: thanks for allowing trailing commas in the function calls
<andrewrk>
of course
<andrewrk>
alright, I'm giving up on the "safety" sub-project of 0.6.0 milestone. that'll have to be a 0.7.0 project
<mq32>
maybe 0.6.0 is the "a lot of breaking changes"-milestone?
<adamkowalski>
that works perfect thanks
<fengb>
What's the goal for the rest of 0.6?
<andrewrk>
stabilization/robustness of async std lib on all tier 1 operating systems, and using that to self-host the compiler
adamkowalski has quit [Remote host closed the connection]
<fengb>
Oh wow, full speed on self-hosted compiler?
<companion_cube>
🚀
<andrewrk>
yeah. package manager is also important, but the thing is, that's going to reveal even more of stage1's flaws - namely memory consumption and lack of incremental compilation
<andrewrk>
we're getting away with stage1 for now because people aren't really taking advantage of each others' code yet
* mq32
just wrote his first arm-linux program with hand-coded syscalls
<andrewrk>
but also robustness of async std lib is halfway to package manager anyway. most of the work is downloading a tarball
<andrewrk>
congrats mq32 :)
<mq32>
it's nice to hack such stuff for work
<mq32>
we're developing software for cortex-m3 processors and i want to build a simple test framework based on qemu-arm and a freestanding target
lunamn_ has joined #zig
<fengb>
Oh I’ve been meaning to add an issue for zstd. Let’s skip xz >_>
<andrewrk>
we need a few available-by-default formats, and then there can be "additional ways to download things" packages which act as plugins for the package manager
<companion_cube>
what's wrong with zlib, fengb? :)
<mq32>
yeah. i think the mvp is ".tar+checksum", no compression or fancy stuff
<companion_cube>
for just shipping sources around, it should do the job
lunamn has quit [Ping timeout: 265 seconds]
<companion_cube>
and there's mini-z that's really tiny enough to ship with MVP imho
<andrewrk>
e.g. you depend on "ipfs-package-downloader.tar.gz" package in a special "download plugin packages" field, and then you can now depend on ipfs URL packages
<mq32>
with dependencies between the plugin loaders? *grin*
<andrewrk>
yes and it all works fine as long as there is not a dependency loop, of course.
<andrewrk>
anyone want to remove the only remaining 'A' windows library call?
<pixelherodev>
I should not be working on this without sleep. I wrote a lexer cleanup function which, among other things, consolidates TYPE LPAREN [COMMA-SEPARATED ARGLIST] RPAREN ASTERISK into a single TYPE token representing a function pointer
<pixelherodev>
Then I wrote part of the AST gen which takes a token and returns a LLVMType node. Want to guess how I implemented that for function pointers?
<pixelherodev>
I'll give you a hint: the lexer takes a stream, and I used a SliceInStream. :P
seoushi has joined #zig
<FireFox317>
andrewrk: regarding #2584 and #3893 should the `.decls` slice be lazy or each entry of that slice?
<FireFox317>
I'm trying to solve that issue
<andrewrk>
yes
<andrewrk>
it's a bit tricky, you have to read the other LazyValue code and see how it works
<FireFox317>
The whole slice?
<andrewrk>
you want to prevent resolve_decl from being called unless it is accessed
<FireFox317>
I guess that makes sense, because for the length of that slice to be known you have to resolve the decls
<FireFox317>
Yes indeed, okay thanks i'm gonna try a bit
<andrewrk>
you don't have to resolve the decls to determine the length
pfg_ has joined #zig
<pfg_>
is there any way to use something like pkg-config with the zig build system?
<andrewrk>
pfg_, yes in fact zig build automatically integrates with pkg-config
<andrewrk>
when you call linkSystemLibrary
<FireFox317>
well currently it is checking whether or not a function is a test and that is only known when it is resolved i guess?
<andrewrk>
whether a decl is a test or not is known after parsing, no semantic analysis needed
<FireFox317>
yeah indeed of course, i'm gonna try to play with it a bit :)
_Vi has joined #zig
Barabas has joined #zig
dingenskirchen has quit [Read error: Connection reset by peer]
dingenskirchen1 has joined #zig
dingenskirchen1 is now known as dingenskirchen
return0e has quit [Remote host closed the connection]
pfg_ has quit [Remote host closed the connection]
mahmudov has joined #zig
<Barabas>
Hello, I was taking a look at the documentation on master and I see it's been expanded on quite a lot since the last time I took a look. Very nice! However, I came across the allocator interface and I was a bit disappointed with the functions that are part of the interface. I don't understand why it pretty much just has a realloc function which
<Barabas>
will copy the memory for you if it has to allocate a new (larger) block of memory. There are many cases where this is far from optimal. Better would be to let the user copy his data, because he will know how to copy it best (if at all even). The most obvious example would be inserting an element into an array. And similar but way worse is when you
<Barabas>
have a large matrix which needs to append a row/column (whichever is the one that is least efficient). You definitely don't want to copy everything twice in those cases, but that's what you'll end up with. (Btw, is this the right place to discuss it or should I make an issue on github?)
<metaleap>
andrewrk does `zig` executable have some known command-or-args combination that will as a side effect print out (somewhere in its output) the stdlib path it would use for compile/build unless overridden
<metaleap>
since we have no GOPATH-like thing in zig (even go is doing away with it hehe) i want to: "given that there is some `zig` reachable from PATH, what is the stdlib path it will default to"
<andrewrk>
Barabas, sounds like some good ideas there. best place will be an issue
<metaleap>
(keep in mind the `zig` in PATH may be a symlink to /my/obscure/path/zig/versionxyz)
<andrewrk>
we don't have a GOPATH-like thing in zig
<metaleap>
exactly hence the question
<metaleap>
`zig stdlibpath` command also doesnt exist
<andrewrk>
ah, I misread, apologies
<andrewrk>
metaleap, yes I think it would make sense to have a sub-command for introspection
<andrewrk>
it can print cache paths, std lib path, etc
<metaleap>
👍will make an issue for that, what say you?
blackbeard420 has quit [Quit: ZNC 1.7.5 - https://znc.in]
<fengb>
Is there a way to generate a switch block at comptime?
<fengb>
Something equivalent to `inline for / if` but possibly more efficient
<mq32>
fengb, i think that is either possible when we will be allowed to modify AST at comptime
<mq32>
but other than that you could probably use recursive if-else-stuff
<fengb>
Yeah that's what I'm doing, but I get the feeling that it's slower
<fengb>
Just a feeling though. I should benchmark it :P
<BaroqueLarouche>
isn't this some zero-cost abstraction or what ?
<mq32>
no, that is compiler optimization
<BaroqueLarouche>
I know
<mq32>
sadly, Rust sells some stuff that is achieved by the optimizer as zero-cost abstraction
<mq32>
zero-cost means that even in a debug build you don't get cost
<companion_cube>
you can still use -O1 in debug mode I think
<mq32>
you can always use optimized builds
<mq32>
zero-cost abstraction is for example std::vector<T>
<mq32>
you can code all that by-hand, but the C++ template abstraction makes stuff simpler and doesn't cost more than coding the C equivalent by hand
<fengb>
Rust: let's make LLVM figure it out. Also Rust: why is the compiler so slow??? 🙃
<companion_cube>
you're harsh, they're working on it, that's partly why MIR was introduced
<fengb>
Yeah I know I'm being a dick -_-
<companion_cube>
it's ok, if you recognize it :p
<metaleap>
hmmmmmm. `std.fs.Dir.path(self: std.fs.Dir)` doesnt seem to be thing?
<metaleap>
but ok, dont suppose cwd() ever changes throughout the run time of a program, right?
<mq32>
cwd() changes quite often
<mq32>
and you should not rely on that
<mq32>
on windows, every file dialog navigation changes cwd
<metaleap>
in that case i need to take the cwd *path* at program startup
<metaleap>
hm i could use the env var but it might not exist on windows :D
<metaleap>
seriously i scanned all `pub fn`s in struct `Dir` and found zilch, will repeat might be blind, gettin late
<mq32>
what do you want to know about the dir api?
<mq32>
you can always store a Dir to the cwd() at program startup
<metaleap>
i'm making a tmp dir from cwd at startup. at prog end i want to delete it. so i really need to figure out the abs path at startup. so if what i'm given is not `path.isAbsolute` i need to `path.join(cwd_full_path, given_tmp_dir_path)``
<mq32>
just keep a handle on the directory
<metaleap>
oh! so when cwd changes over the time, as long as I keep the orig handle from main() it'll keep pointing to the cwd-at-startup?! if true, good enough thx mq32
<mq32>
that's what i thought
<Barabas>
andrewrk, alright cool. I'll make one today or tomorrow. :)
<mq32>
you could use cwd().openDirTraverse(".") to obtain a handle on the cwd() that allows you to keep it
<mq32>
keep in mind though that you have to close the handle returned by openDir
<metaleap>
understood
<mikdusan>
so c++20 std::span - what does this sound like? "span describes an object that can refer to a contiguous sequence of objects with the first element of the sequence at position zero. A span can either have a static extent, in which case the number of elements in the sequence is known and encoded in the type, or a dynamic extent." and "A typical implementation holds only two members: a pointer to T and a size."
<companion_cube>
like rust's slices! am I right? 🙃
<mikdusan>
+1
<BaroqueLarouche>
yeah it's a mutable slice
<mikdusan>
🍪🍪
<BaroqueLarouche>
yum!
<metaleap>
.net also introduced at long last slices and called them..
<metaleap>
drum-roll..
<metaleap>
system.span<T>
<mikdusan>
<span>too much like html</span>
<companion_cube>
so java will get Span<T> in 10 years
<mikdusan>
I bet eventually c++ will find some way to overload a fn that takes a span, and permit 2 args "ptr,len" to be accepted
<fengb>
We should designate different emojis per choices\
<mikdusan>
github needs a syntax for xterm-256-dark-bg so we can copy-paste terminal output with colors. and terminals should make it easy for us to copy with ansi-color escape sequences
<mq32>
you can probably xclip your escape codes into the terminal
<mikdusan>
let's say I have a gdb session, want to add it to an issue post. I'd like to be able to highlight copy and paste into github comment. with color. and no png.
<mq32>
yeah true
<mikdusan>
images work and github have relaxed their over-compression so I can actually from macos screen shot a window, and just paste right into comment as a decent image... but that image is not textual and people can't copy commands from it easily
marijnfs has joined #zig
<fengb>
They should auto OCR images and apply an overlay so you can select the text out 🙃
<fengb>
The solution to technical problems is always more layers!
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 240 seconds]
<metaleap>
return type of `os.execvpe` is designated thusly: ` (ExecveError || error{OutOfMemory}) `
<metaleap>
no !void
<metaleap>
trying `catch |err| doSth(err)` gives:
<metaleap>
expected error union type, found 'std.os.error:985:16'
<metaleap>
seems if i execvpe `zig init-lib` once its done it takes down the calling process (mine)
<metaleap>
not even HERE_1 is being output anymore
marijnfs has joined #zig
<mikdusan>
because it succeeded
<metaleap>
not even my "all tests done" msg at the end shows up anymore, seem to be getting killed
marijnfs_ has quit [Ping timeout: 260 seconds]
<metaleap>
so execvpe on success kills the current process?
<mikdusan>
oh yes
<mikdusan>
the success path is... your call site is gone. replaced.
<mikdusan>
if you want to keep parent/child then you want spawn
<metaleap>
well that has to go into the doc-comments :D ahh thanks, i only looked for exec and didnt catch spawn
<metaleap>
TIL thx mikdusan
<mq32>
metaleap: exec is usually "replace the current process with the selected executable"
<mq32>
spawn/create child process is usually done by fork/clone with exec
<mikdusan>
3 general unix thingees. exec = replace and run. spawn = run in a child-process another executable. fork = run in a child-process a function in your code.
return0e_ has quit [Remote host closed the connection]
<metaleap>
yeah i lived in go mostly last few years where the os/exec pkg doesnt reuse said meaning for "exec process". their way to act cross-platform is often to hide uniquely-unixy subtleties from the apis
<metaleap>
now i get why zig & node have separate `child_process` modules outside of `os` or `process` (php too i reckon? =)
return0e has joined #zig
<mikdusan>
apparently in go you have to use syscall.Exec for replacement behavior
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 272 seconds]
<metaleap>
yeah but it's really not a remotely common scenario in that ecosystem afaik
zfoo_ has quit [Read error: Connection reset by peer]
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 268 seconds]
marmotini_ has joined #zig
<metaleap>
ChildProcess.init() has an `errdefer` right before a proper `return`. what's this pattern about?
<metaleap>
i know the keyword but above from my understanding its a noop
<fengb>
In this case, it might be a noop. Maybe it used to have a body before the return?
<FireFox317>
probably the childprocess struct was changed and removed the need of try's when initializing the struct. thus now it cannot fail to init anymore
<FireFox317>
except for the OOM ofcourse
<metaleap>
ah ok just wondered if there's some unknown-to-me subtlety i was missing, yeah likely some refactoring-incurred thing
<metaleap>
any linter-writers out there take note :P
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 240 seconds]
FireFox317 has quit [Ping timeout: 265 seconds]
FireFox317 has joined #zig
jonathon_ is now known as jonathon
marmotini_ has joined #zig
marmotini_ has quit [Read error: No route to host]
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 260 seconds]
waleee-cl has joined #zig
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 260 seconds]
metaleap has quit [Quit: Leaving]
metaleap has joined #zig
Barabas has quit [Ping timeout: 260 seconds]
<metaleap>
any windows user here? can you look into any of your zig-cache/h/*.txt files and let me know if the paths in there use / or \
<metaleap>
tia =)
<Sahnvour>
metaleap: \
<metaleap>
Sahnvour: thanks!
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 240 seconds]
seoushi_ has joined #zig
marijnfs_ has joined #zig
seoushi has quit [Ping timeout: 260 seconds]
marijnfs has quit [Ping timeout: 268 seconds]
FireFox317 has quit [Quit: Leaving]
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 272 seconds]
ur5us has joined #zig
nikoala has joined #zig
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 265 seconds]
<daurnimator>
companion_cube: I've been bit my accidental returns that caused production outages. It's why we mandated the move away from coffeescript at an old employer of mine
<companion_cube>
I wouldn't compare coffeescript with a properly typed language
<fengb>
Coffeescript has a lot of issues :P
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 260 seconds]
<mikdusan>
neat; I setup a 4 GiB ramdisk for builds; make an APFS container on it. add 3 APFS volumes, and mount each into a git worktree build directory. they all share same total 4 GiB and I can rm -fr _build dir, and it stays put but is emptied.
dimenus has joined #zig
<jaredmm>
pixelherodev: I don't know if stepping away from WASM would help. As much as I'd like to, we're not getting away from heavy webapps now. We have GIS libraries that we have to maintain parity across Java, JavaScript, and C. Being able to write them once in Zig, then use them via native, WASM, or JVM bytecode would be a huge gain for us.
<jaredmm>
I didn't catch the complete context of your WASM comment, but as stupid as the whole webapp thing is there are benefits to people forcing it away from JS.
<fengb>
WASM is the least bad cross-platform bytecode
<daurnimator>
at least we're back below 1000 issues now :)
<andrewrk>
does that send notification emails when I change the milestone?