<fengb>
I find myself revisiting that every so often
<fengb>
And questioning my life choices
<hryx>
life choices make good target practice
<hryx>
> Compiling the stage2 compiler to C or WebAssembly does not satisfy the problem, because the C code or WebAssembly code would be output, rather than source code
<hryx>
^ I suppose that answers my curiosity
<hryx>
my instinct is "that's too bad". but I'll read it over again and think some more
<fengb>
I think it's good to have multiple compilers, even in the same source root
<andrewrk>
if you think about it, why not use the generated assembly code to bootstrap, right? assembly can be source code
<andrewrk>
but it's the same thing as generating C, if you're generating it, then it's not source code
<emekankurumeh[m]>
zig ir is undocumented right?
<hryx>
presumably, the distinction is that a human wrote it directly?
<hryx>
as opposed to a machine transformation
<andrewrk>
emekankurumeh[m], it is extremely undocumented. not only is it undocumented but the meaning of different instructions changes arbitrarily from commit to commit
<fengb>
One day, we'll have AI generate readable source code :P
<andrewrk>
emekankurumeh[m], also if you were to redesign zig ir today, rather than evolve it as it has been, you'd probably make very different decisions
<fengb>
Will Zig IR be stable at some point? Or is it an implementation detail that'll just vary
<andrewrk>
hryx, yes. if you're looking for well written beard-stroking, chin-scratching philosophy about what constitutes source code or not, I believe the Debian Free Software Guidelines have really taken it upon themselves to do that
<andrewrk>
fengb, implementation detail
<andrewrk>
we can potentially reconsider this after the first non-llvm backend
<hryx>
I see. andrewrk, if it were up to you and not Debian, would you just maintain self-hosted and maybe output C? (Maybe that's an unfair or unproductive question)
<hryx>
I don't mean to belabour the point though, it just grabbed my interest tonight
<andrewrk>
no, I see value in maintaining stage1 independent from debian
<andrewrk>
one important thing is how small the path is from source to source to source to working zig binary
<andrewrk>
if we were really sophisticated, zig would come with a kit to bootstrap a compiler from straight-up machine code - no c
<fengb>
How would that work?
<andrewrk>
"type this tiny machine code file with a hex editor. next, use that to build this primitive assembler. next, a simple C compiler. next, clang. etc"
<hryx>
that'd be hecka steps
<hryx>
but an interesting thought!
<andrewrk>
the idea is that you start with readable, documented, commented steps where everything is easily verifiable
<andrewrk>
I saw a related project recently, what was it called...
<daurnimator>
oh that reminds me of a question I had
<daurnimator>
do vectors work universally across targets?
<daurnimator>
e.g. if I target avr and use 128bit vectors...will it do the right thing?
<andrewrk>
I say this without having tested it: yes
avoidr has quit [Quit: leaving]
<emekankurumeh[m]>
i think that's up to llvm?
<andrewrk>
zig the language defines the answer to be yes
<andrewrk>
it should work fine, because llvm knows whether a target has vectors and how wide they are, so it's easier to flatten vectors into non-vectors
<andrewrk>
that's the whole point of using vectors is that de-vectorizing is much simpler than vectorizing
<fengb>
Some of these old issues are enlightening and confusing
ntgg has joined #zig
<ntgg>
what does [_] mean? I can't find it in the documentation
<daurnimator>
ntgg: its a inferred length array literal
<IntoxicatedHippo>
I want to be able to change the length of the array but I suppose I could just make the array bigger then I'll ever need
<daurnimator>
IntoxicatedHippo: you can use ++ to concat arrays at comptime
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 245 seconds]
<emekankurumeh[m]>
if you have `@This()` in a struct and you `usingnamespace` that struct, does `@This()` refer to the original struct or the one that `usingnamespace`'ed it?
<scientes>
emekankurumeh[m], yes you can do a pointer to a vector
<scientes>
but it has an alignment requirement and that is very important
<daurnimator>
andrewrk: why are AT_* constants in bits/linux/$arch.zig instead of just bits/linux.zig?
<scientes>
haven't tested unaligned vectors, but llvm should also work for that
<emekankurumeh[m]>
scientes: i mean you have some bytes and you want to do vector/SIMD operations on those bytes
<scientes>
emekankurumeh[m], yes you can do that
<scientes>
but I haven't tested unaligned
<scientes>
it probably only works with aligned, cause that is what is like in C
<emekankurumeh[m]>
my alignment should be 1 because i'm using packed types
<emekankurumeh[m]>
how would you go about doing that?
<scientes>
I've been doing that with assembly in C
<emekankurumeh[m]>
so zig `@Vectors` don't support that yet?
<scientes>
It is certainly a valid use case, but I have not managed to get the generic stuff to work with that
<scientes>
but I have not looked into it
<scientes>
not sure what the interface should be either, (or for other unaligned loads), because in C you would have two versions of the struct, one with align 1 and another with native alignment
<emekankurumeh[m]>
perhaps support for only packed structs?
<scientes>
maybe zig should have a @unalignedLoad @unalignedStore
<scientes>
or some other way to change the alignment just for a load-store separate from aligned pass-by-reference
<andrewrk>
zig already has alignment in pointer metadata that correctly propagates to loads and stores
<daurnimator>
ntgg: but also. usually you run `zig test libraryentrypoint.zig` and in there you would import your tests from other files
Ichorio has joined #zig
Ichorio has quit [Read error: Connection reset by peer]
kristoff_it has quit [Ping timeout: 248 seconds]
nifker has joined #zig
nifker was kicked from #zig by ChanServ [Banned: disrespect !T 1w]
avoidr has joined #zig
<ntgg>
daurnimator: In my project. Why is the file with all the tests imported preferred? seems much more complicated than automatically collecting all tests.
<ntgg>
to the user, not the compiler.
<daurnimator>
ntgg: I'm not totally sure; you'll have to ask someone else
<daurnimator>
but in general zig isn't meant to be easy to write; it's meant to be simple to understand/read/debug. I would think that explictly listing paths is the path of least "magic" so that someone can follow exactly why a given test is being run
<IntoxicatedHippo>
Is there a cleaner way to do this? std.mem.copy(u8, code[5..], @sliceToBytes(([_]usize{@ptrToInt(func)})[0..]));
<IntoxicatedHippo>
func is a fn()
<daurnimator>
IntoxicatedHippo: o.o why are you seemingly serialising a function pointer?
<IntoxicatedHippo>
I'm generating machine code at run time
<daurnimator>
IntoxicatedHippo: what is `code` there? perhaps you would rather a `packed struct`?
<daurnimator>
IntoxicatedHippo: otherwise perhaps you want to be writing to `code` via a std.io.OutStream
very-mediocre has quit [Read error: Connection reset by peer]
very-mediocre1 has joined #zig
porky11 has joined #zig
<daurnimator>
How do I get from a u1 to a bool?
jjido has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
very-mediocre1 has quit [Read error: Connection reset by peer]
very-mediocre has joined #zig
<mq32>
daurnimator: what about (my_u1 == 1) ?
kristoff_it has joined #zig
jjido has joined #zig
<ntgg>
is it possible to switch on a string?
<daurnimator>
mq32: ah yep that works. but to complicate it, I need to do it when the dest type is dynamic: bool_or_u1(0)
<daurnimator>
I'm currently writing out: if (dest == bool) x != 0 else x
<mq32>
introduce a new function "to_bool_or_u1" which takes a u1 and outputs a comptime type?
<ntgg>
daurnimator: is there a reason you can't use @boolToInt for the bool?
<ntgg>
@boolToInt returns a u1
<daurnimator>
ntgg: that's the opposite way around
<daurnimator>
ntgg: I have a u1, and I want either a bool or a u1 depending on the variable `type`
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
very-mediocre has quit [Read error: Connection reset by peer]
very-mediocre has joined #zig
kristoff_it has quit [Ping timeout: 272 seconds]
<via>
i'm trying to link my mostly embedded c project (which requires newlib) against newlib, but when i specify "c" as a library, and even specify the correct library path for my newlib installation, zig complains about being unable to provide a libc
<via>
is a way i can make it treat it as any other static library i want to link against?
<via>
i see where need_system_paths gets set in build.zig, but i don't see that its used in any non-native case, thus it just kinda prevents "c" from being linked against?
<via>
i suppose i could rename the static archives ...
Akuli has joined #zig
_whitelogger has joined #zig
<very-mediocre>
Say you've got `const next_byte = somethingThatCanError() catch |err| switch (err) { error.EndOfStream => null, else => return err, }` in the body of a function that returns `!void` - it seems zig things the outer function can return error.EndOfStream?
<very-mediocre>
thinks*
avoidr has quit [Quit: leaving]
very-mediocre has quit [Read error: Connection reset by peer]
very-mediocre1 has joined #zig
<daurnimator>
currently getting "error: unable to evaluate constant expression".... and no other info => *why* wasn't zig able to evaluate it?
<andrewrk>
daurnimator, that's a good thing to do, will take some nontrivial changes to semantic analysis to implement
Akuli has quit [Remote host closed the connection]
<daurnimator>
no but really.. wtf am I doing wrong here >.<
<andrewrk>
if you're willing to crack open the debugger, you can look at the zig ir instruction it's pointing at, by putting a breakpoint on add_node_error and then going up the stack until you get into ir_exec_const_result
<andrewrk>
it's looking at a zig ir instruction that it's determining has side effects and wasn't able to be determined at comptime
<andrewrk>
the id of the ir instruction and type could be a clue
<andrewrk>
function calls are runtime known unless the return type requires comptime, so your HashFunc call is probably returning a runtime-known function pointer
<andrewrk>
I think I opened a proposal recently that would solve this
<andrewrk>
daurnimator, I suspect this might be it ^
<daurnimator>
andrewrk: ah yes it was!
<andrewrk>
one hint is that if it's pointing at the ( then it's actually talking about the entire function call result. self-hosted handles this a bit better (underlines the entire expression)
<ntgg>
fg
<ntgg>
whoops
<daurnimator>
Also re: @popCount: I think the argument checks are wrong? I'm getting `error: expected type 'u6', found 'u8'` when I call `@popCount(u6, a_u8)`
<andrewrk>
that looks correct to me. the first argument just sets the type of the second parameter, and you can't implicit cast a u8 to a u6
<andrewrk>
if the first arg feels redundant then use @typeOf(a_u8)
<daurnimator>
andrewrk: I thought the first argument set the type of the result?
<andrewrk>
daurnimator, the docs explain this
<daurnimator>
andrewrk: the docs for @popCount are pretty broken. I commented on that just a few hours ago :P
<andrewrk>
how so?
<daurnimator>
andrewrk: uh... have you tried reading them?
<daurnimator>
"@popCount(comptime T: type, integer: T) Counts the number of bits set in an integer." okay so far
<daurnimator>
"If integer is known at comptime, the return type is comptime_int." ... but what is T for?
<andrewrk>
the first argument just sets the type of the second parameter
<andrewrk>
if the first arg feels redundant then use @typeOf(a_u8)
<daurnimator>
andrewrk: the result of a @popCount should be Log2Int of the argument
<andrewrk>
that's also mentioned in the docs
<andrewrk>
it's not necessarily Log2Int
<andrewrk>
because of non-power-of-2 integers
<daurnimator>
ah right its Log2Int+1
<daurnimator>
e.g. I have the u8 0b11111111 => the max population. which is 8. which fits in a u4.
<andrewrk>
ok so the popcount doc issue can be closed then?
<gonz_>
Am I missing something? It says pretty clearly what it returns and why T is there
<daurnimator>
I guess I'm used to the many functions where the first parameters is the result type. e.g. all the casts, or mem.readVarInt.....
<daurnimator>
andrewrk: okay wait a second then.... if the integer is comptime known it suddenly changes the return type?
<daurnimator>
@popCount(u8, comptime u8(42+5)) // is the result a comptime_int?
<andrewrk>
that's a bit of a weird characterization of the behavior, lots of operations have a comptime_int result when the operand(s) are comptime_int
<andrewrk>
oh I see the question here. yeah that is how it works. comptime_int is designed to be always preferable when possible
<daurnimator>
is there anything else in zig that has that special case?
<daurnimator>
being comptime-known affecting the type seems.... super weird
<andrewrk>
implicit casting integers works when comptime known, where otherwise it would be a compile error
<andrewrk>
e.g. a u64 to a u8 normally can't implicit cast, but it can if comptime known
<gonz_>
I was gonna say, it's only bad if it puts more restrictions in the special case
<gonz_>
but this is the opposite (?)
<andrewrk>
you can think of the result type of @popCount as "as few bits as possible" and when the operand is comptime-known, that's even better
<andrewrk>
however it would be reasonable to make the type consistent, because the result would still be comptime known
<andrewrk>
so it could still participate in casts and such
<gonz_>
andrewrk: What's the policy on the standard library and Win32 headers? There's a lot of expansion to be / that can be done there, but maybe bloating the standard library code base with everything kernel32, etc. is inadvisable?
forgot-password has joined #zig
<andrewrk>
gonz_, the plan is to have whatever we need in there for the standard library itself. the endgame will be to have a separate package (available with the package manager) for a more complete windows API. such a package can import the std lib namespaces and add the rest, so as to be compatible
<daurnimator>
gonz_: we do essentially need to translate all kernel32 and nt headeres into zig
<gonz_>
Mhm, ok
emekankurumeh[m] has joined #zig
<via>
is there any way with zig build to link against newlib for a non-native target? the code seems to special-case linking against c or m
<andrewrk>
via, what target os?
<via>
arm freestanding
<andrewrk>
is it a special fork of newlib or is it actual newlib?
<via>
i have newlib static archives, i just need to link against it
<via>
actual newlib
<via>
but i would like to link against what the archives i have for consistency if possible
<andrewrk>
what functions are missing when you don't link it?
<andrewrk>
consistency with what? sorry for all the questions, just collecting data on this use case
<via>
i'm trying to use zig to compile an existing c project, so that i can start slowly porting parts to zig
<via>
it uses various libc things, including sprintf and family
<andrewrk>
if zig was able to provide sprintf & family automatically, would that be satisfactory?
<via>
probably not, but maybe, but even if it can i want a baseline that is more or less what i have now with very few changes
<via>
i can ween it off the libc deps, but i need to make it work first
<andrewrk>
stick with me for a minute though, why would that probably not work? what would go wrong?
very-mediocre1 has quit [Read error: Connection reset by peer]
<andrewrk>
I'm suggesting that you'd be able to build your existing c code with no changes with zig, without even needing newlib, and everything would build
<via>
i would really like to change as little as possible at once, i'm pretty familiar with the limitations and performance of the arm newlib code, and want to be able to benchmark my z vs zig-built code
<via>
c*
<via>
its already a big jump for me to be building with clang instead of gcc
forgot-password has quit [Ping timeout: 245 seconds]
<andrewrk>
I see, ok, that's fair enough. so I think what I'm suggesting is still a good idea, it's just a bit unscientific to go from where you were before to there all at once
<via>
yeah, i mean, i've got no issue with going that route, but for me in this particular case, making changes is dangerous
<andrewrk>
one way to make a smaller leap is to use zig to build a library and still use gcc to link
<andrewrk>
so build all your C code into a .a with build-lib, but still do the link step with gcc
<via>
yeah, i was considering that too, but was hoping to switch to zig-build given that i don't love my makefile
<via>
yep
<andrewrk>
this is just a test though right? if it went well, and then if zig was able to provide the rest of those symbols, you could go all in
<via>
though it does feel a little silly that i can't just linkSystemLibrary("c") when i have a libc.a here
<via>
yeah, but this is a long term thing, it might be a while
<andrewrk>
fair enough. hmm ok, let me think about how to solve this use case
<via>
is there a hack i could do now to try it at least? short of recompiling zig without that check
<via>
i was looking at the libc-path file thing, but that doens't seem to be used by zig-build
<andrewrk>
I'll push a quick patch to add a zig build API for the --libc parameter
very-mediocre has joined #zig
<via>
then it would respect a path file?
kristoff_it has joined #zig
<andrewrk>
use `zig libc` to create a template file, then edit those paths, and you'll be able to use this file in the build
<via>
okay, cool, thank you
<andrewrk>
there may need to be a couple other changes if newlib has different path conventions
<via>
i was wondering -- is {static_}crt_dir used to determine where the alib is?
<andrewrk>
by alib you mean libc.a right?
<via>
yeah
<andrewrk>
I think for this workaround right now, you'll need crt_dir set and nothing else. and we'll pass --library-path for libc.a
<andrewrk>
you can test this without zig build to make sure it works with `zig build-exe` while I make this patch
<dimenus>
do i have to deref pCallbackData somehow?
<andrewrk>
dimenus, probably a bug or oversight
<andrewrk>
sounds like it should be improved
<andrewrk>
I think it should be a compile error actually, unless the format string specifies that it's null terminated
forgot-password has joined #zig
<dimenus>
how do you do that?
<via>
andrewrk: well, that worked perfectly
<via>
i mean, i think, let me test some things
<dimenus>
hmmm, casting / assigning it a new name as type [*]const u8 makes it work
<dimenus>
so it's maybe it's just the user level code not handling the type properly?
<andrewrk>
via, I still want to make it work without the newlib dependency though :)
<via>
i think thats hard to do in a way that matches the newlib nosys use case
<andrewrk>
why's that?
<via>
i mean, how do you implement things that do io? with newlib the idea is it gives stubs for things like _write
<andrewrk>
your linker errors didn't include any io
<andrewrk>
were you planning on using those features?
<via>
it did, through _exit and _abort -- other than that i did just use _write myself
<via>
but those won't show as missing symbols, its just that i'm implementing stubs that newlib expects
<via>
i know with zig i can do that by implementing the panic handler myself
<via>
but with newlib you can implement a few stubs and more or less use fopen and fprintf directly if you want, and i'm guessing some embedded projects do that
<andrewrk>
that's good to know
<andrewrk>
how does fopen work in this case?
<dimenus>
why do we truely need *T and [*]T? wouldn't it be better to just always ensure that an array/slice is created before trying to index/slice/etc?
<andrewrk>
my idea is that zig will provide all the non-os functions in freestanding mode, and if you get linker errors for, e.g. fopen, then you can simply export that function to satisfy the linker
<dimenus>
[*]T is non-safe anyway
<dimenus>
unless I'm missing something
<andrewrk>
*T is also non safe
<dimenus>
agreed
<andrewrk>
we don't truly need anything, we could just use C
<dimenus>
hah
<andrewrk>
the idea is to make it harder to shoot yourself in the foot
<via>
that would be nice, though newlib does that a bit more lower level -- there are like 17 syscalls it expects to be implemented. newlib implements fopen, but expects _open and _isatty to be implented if you use them (it provides empty stubs if you don't, through -lnosys)
<andrewrk>
via, and then you keep track of integer file descriptors? that's a bit of an invasive abstractino
<via>
thats true. though i tihnk most people using them only implement stdin/stdout
<andrewrk>
oh that's a good idea, zig could provide weak symbols that return ENOSYS unless you override them
<via>
yeah
<via>
well, my binary does nothing seemingly, i'll get swd and a debugger hooked up, but i think i've got it from here
<via>
thanks for the help
<andrewrk>
no problem thanks for indulging my questions
<via>
unfortunately i'm running into some llvm-y issues that might be above my head (zig compiled c code is using blx instead of bl to jump to code when it shouldn't be switching modes, and its already in thumb)
<andrewrk>
via, hmm, is this something that also happens if you use clang instead of gcc?
<daurnimator>
is there a constant time compare in the std lib?
<via>
i haven't tried, probably should have before doing this. i'll dig further
<andrewrk>
via, btw you can pass --verbose-cc to see the args passed to clang
<daurnimator>
well I tried calling the vector type, and not failing with at least a message in my segfault: `unreachable: /home/daurnimator/src/zig/src/analyze.cpp:handle_is_ptr:4086`
<via>
andrewrk: the intermediate objects have the correct calls, so i think the linking stage is whats breaking -- is there any way to add lld options?
<daurnimator>
s/not/now/
<andrewrk>
via, you can use --verbose-link to find out the linker line, and then manually invoke lld (if you have it installed)
<via>
i didn't have it installed, was trying to figure out how zig used it lol, but yeah i'll just install it
lunamn has joined #zig
<andrewrk>
maybe we're not passing the correct -m option
<via>
the issue is very specific to strcmp, and probably related to `ld.lld: error: ../../../../../../../newlib/libc/machine/arm/strcmp-armv4.S:127: unrecognized reloc 40
<andrewrk>
yeah sounds like it
<andrewrk>
LLD devs are pretty active with ELF stuff, are you up for filing an upstream bug report?
<andrewrk>
they haven't branched for LLVM 9 yet so the timing is good
<andrewrk>
also we can carry LLD patches in zig source
<via>
i can, though i'm pretty unfamiliar with exactly whats not working here, might be an unimplemented relocation. let me see if i can get more
<andrewrk>
it sounds like an unimplemented relocation, which would hopefully be straightforward to fix, and a nice upstream bug report would hopefully provide some motivation to the devs to do it
* daurnimator
goes to bed. I'm currently trying to solve the test failure on the bloomfilter branch https://dev.azure.com/ziglang/zig/_build/results?buildId=2567 only seems to fail in non-debug modes. managed to replicate locally..... but compiler seems to be getting stuck in an infinite loop sometimes; other times crashing; other times the error you see in CI.
<via>
R_ARM_THM_CALL, though it looks like they're all that, so why is strcmp failing specifically...
<via>
i can't see that there is a relocation type 40
<via>
actually i might have just fixed it, will report back in a minute
very-mediocre has quit [Read error: Connection reset by peer]
very-mediocre has joined #zig
laaron- has quit [Remote host closed the connection]
darithorn has joined #zig
<via>
holy crap it works. newlib has many sets of static libs, i was using the ones in thumb, i needed to be using the ones in thumb/v7e-m
<andrewrk>
ah
<andrewrk>
zig's provided libc would have solved that :)
<via>
maybe, though do you really want to be basically maintaining your own libc?
<andrewrk>
yes
<via>
fair enough, though that sounds like a project by itself
<andrewrk>
zig is ambitious
<andrewrk>
simplicity is hard work
Flaminator has joined #zig
<via>
for whatever reason i have to also build libopencm3 with clang, or else it hangs forever waiting for the oscilator to stablize. i dunno how to even begin debugging that
<andrewrk>
sounds like an ABI mismatch
<andrewrk>
if you look at the output of `zig targets` that's the purpose of the C ABIs list
<andrewrk>
maybe hf vs non-hf?
<via>
i'm building everything with hf, and actually if i build with clang either hf or nonhf it works, gcc it doesn't
<via>
i mean, i kinda want to know wtf, but it is working, and i'm fine using clang
<via>
i should probably do a lot of testing before i go plug this into my car
brakmic has quit [Read error: Connection reset by peer]
brakmic has joined #zig
fengb has joined #zig
IntoxicatedHippo has quit [Ping timeout: 258 seconds]
brakmic has quit [Read error: Connection reset by peer]
brakmic_ has joined #zig
<via>
performance looks good, not more than about a 10% perf decrease vs gcc with lto (a critical part taking 250 us instead of 220 us)
<andrewrk>
hmm I have not considered doing LTO across the C and Zig code, but that is in fact possible
<via>
yeah, thats what i started asking/talkign about in here last week
<via>
i got everything to build using lto, but zig wouldn't auto inline the c parts
<via>
but ... meh, not a huge requirement, just a nice to have
<andrewrk>
would you mind opening an issue to track this use case?
<andrewrk>
I think it's reasonable
<via>
sure, i had a good test case handy, let me get it more presentable
brakmic_ has quit []
brakmic has joined #zig
very-mediocre has quit [Read error: Connection reset by peer]
very-mediocre1 has joined #zig
HelloThere54321 has joined #zig
<HelloThere54321>
Hello the people, i was wondering if it is possible to provide extern values to a zig test
<HelloThere54321>
Im writing an OS and the original externs come from the linker script
<HelloThere54321>
yes, but when i run 'zig test FILE.zig' i get lld: error: undefined symbol: KERNEL_PHYSADDR_START
<andrewrk>
oh for a test. you'll have to pass your -target and --linker-script args to `zig test`
<andrewrk>
and it probably won't be able to run your test
<HelloThere54321>
are, coolio, i didnt know if u could provide the linker script to the test command
<andrewrk>
because it'll be a non-native target
<via>
andrewrk: https://github.com/ziglang/zig/issues/2845 except in producing that, i've found more weirdness -- i do not know why those udf opcodes are being created, i can look into that too
<andrewrk>
thanks via
gustav_o has quit [Ping timeout: 248 seconds]
<via>
i'm awful at computers, dunno how i closed that, but fixed the description and reopened
rjtobin has joined #zig
fengb has quit [Ping timeout: 260 seconds]
laaron has joined #zig
andersfr has joined #zig
Akuli has quit [Quit: Leaving]
very-mediocre1 has quit [Read error: Connection reset by peer]
very-mediocre has joined #zig
gustav_o has joined #zig
andersfr has quit []
lunamn has quit [Ping timeout: 258 seconds]
lunamn has joined #zig
lunamn has quit [Ping timeout: 246 seconds]
tdog has quit [Quit: Leaving]
very-mediocre has quit [Read error: Connection reset by peer]
very-mediocre has joined #zig
darithorn has quit [Quit: Leaving]
gustav_o has quit [Quit: gustav_o]
<emekankurumeh[m]>
andrewrk: why does windows have 2 bits.zig files?
<andrewrk>
one is posix
<andrewrk>
all the msvcrt libc stuff that is compatible, such as types that go with fopen
brakmic has quit [Ping timeout: 272 seconds]
brakmic has joined #zig
littleli has joined #zig
marijnfs has joined #zig
very-mediocre has left #zig [#zig]
marijnfs has quit [Client Quit]
return0e has quit [Remote host closed the connection]
return0e has joined #zig
<hryx>
I just spent a while brainstorming and mocking up what closures might look like in zig. it's so tricky when you want to have explicit memory management
brakmic has quit []
<hryx>
I'm wondering if it's worth it. What would closures bring to zig that isn't already possible?
porky11 has quit [Quit: Leaving]
<hryx>
I think I've been staring at it too closely
<Tetralux>
Personally, I think that being able to have fns in imperative scope are just fine.
<Tetralux>
The most you want, if anything, is a lambda syntax.
<Tetralux>
So you can do things like `var filtered = array.filter(x -> 2*x);`
<Tetralux>
(.. That's the obv example, but you get my point.)
<hryx>
I think the anonymous function syntax is great (hence my proposal) but it's the closure state that I'm questioning
<emekankurumeh[m]>
perhaps we can reuse the `@Frame` concept that async is introducing?
<Tetralux>
The only reason closures are handy at all is that you remove the need to pass a thing in as an argument that you otherwise would have to.
<hryx>
Tetralux: for reference, here's the proposal for anonymous function syntax, but does not address closure-specific issues https://github.com/ziglang/zig/issues/1717
<Tetralux>
hyrx: Ta.
<hryx>
emekankurumeh[m]: I was thinking about that, but my brain hasn't evolved enough yet to figure anything out
<Tetralux>
I'm not sure about using the syntax for fn declaration.. but for anonymous fns, sure.
<Tetralux>
You could have some sort of explicit variable capturing.
<hryx>
Tetralux: yep, but that's not the big problem
<hryx>
the problem is, what happens if you capture a stack variable reference, then go out of scope?
<Tetralux>
What's an example of code that does that?
<Tetralux>
Do you have a specific example in mind?
<hryx>
maybe I can whip up an example and share it
<mq32>
hryx: C++ does it the easy way: don't do it or die trying
<mq32>
(capturing stack references)
<Tetralux>
Oh -- I think I understand
<hryx>
mq32: that makes sense and is so far the best I've come up with O_o
<mq32>
yeah
<mq32>
c# had its problems with capturing as well ^^
<Tetralux>
A var you capture in the closure is a var in the fn you're creating the closure in, and is therefore a stack var.
<mq32>
foreach(var x in list) { add(() => print(x)); } would capture a reused loop variable ^^
<mq32>
so all captures would reference the same variable
<Tetralux>
The simple way to solve that is to not have implicit captures.
<mq32>
hryx, maybe you want to look up the GCC nested functions:
<mq32>
i think the only reasonable way is what GCC does with trampolines
<mq32>
because Zig does not have callable types
<Tetralux>
That seems overkill.
<mq32>
trampolines would also have the advantage to be compatible to existing C code
<Tetralux>
Why not just have it be syntax sugar?
<hryx>
anonymous functions, and functions-in-functions, are coming to zig I believe. I don't think they're huge issues. I'm just stuck on closure state
<mq32>
what hryx says. thinking (and talking) about the same problem
<mq32>
nested functions are no problem for a compiler, that's just a different name to assign
<Tetralux>
I forget what trampolines are - I've never needed to care about the terminology xD
<mq32>
"runtime composed function stubs" would most probably fit
<Tetralux>
I'm not sure that's any clearer xD
<Tetralux>
But it sounds overcomplicated.
<mq32>
it's just some runtime generated assembler instructions
<mq32>
"push those arguments to the stack, then jump to this function"
<Tetralux>
Is there a good reason not to have closures just be normal fns that get auto-generated and the captured vars are just passes as invisible ptrs into it or something?
<mq32>
Tetralux, have you ever programmed in assembler?
<mq32>
trampolines can only be created in assembler, it's a really low level feature
<mq32>
anyways, i have to go to sleep
<Tetralux>
mq32: Ahhhh.
<Tetralux>
Yeah - not done much of that.
<Tetralux>
I know a few asm instructions - that's about it. xD
<Tetralux>
hryx: Based on the fact that I'd have to read that code several times to understand what it was doing, that seems like a bad idea xD
<Flaminator>
I am pretty sure local functions in c# are not syntactic sugar for lambdas.
<Tetralux>
I guess every time you call c() it incrs count and gives you it.
<Tetralux>
.. But count goes out of scope.
<Tetralux>
I mean... could you global it I suppose.
<hryx>
Tetralux: it's tricky isn't it! I just updated that gist with a more sinister example
<hryx>
good night mq32
hspak has joined #zig
<Tetralux>
Hmmm. I think I'd expect the captured count to be the same var as the original count.
<Tetralux>
That's what it reads like.
<Tetralux>
In which case, count is the count in newcounter.
<Tetralux>
But that's also a stack var.
<hryx>
yeah. the second example works a bit like how captures work in today's for loops, for example. |x| vs |*x|
<Tetralux>
But when you return a fn that captures a stack var, Zig could do something speciail with it.
<Tetralux>
In this case, it's clear it can't remain a stack var after newcounter is called.
<hryx>
yep, but exactly what that something is... that's the problem :)
<Tetralux>
How is the allocator thing being solved with the coroutine rewrite?
<andrewrk>
hryx, it can work if the reference to the function does not escape the outer function
<Tetralux>
andrewrk: You mean if you don't return c?
<hryx>
andrewrk: would adding escape anlysis be worth it? I'm starting to wonder if the effort outweighs the benefits
<Flaminator>
The one thing I noticed from most languages that reverse the order of name and type is that they don't reverse it for function signatures.
<andrewrk>
escape analysis is planned
<hryx>
holy moly, I almost forgot about the "make everything safe in Debug mode" idea
<andrewrk>
yeah for that issue
<hryx>
game changer then, maybe. maybe closures are allowed with certain constraints then?
<hryx>
*could be allowed
<andrewrk>
your example wouldn't work with what I'm saying
<hryx>
yeah
<andrewrk>
what you've created is basically a generator. there's a good possibility we will have those after coroutine rewrite
<andrewrk>
because coroutines are functions that have more complicated lifetimes
<Tetralux>
Ohhhh - That's true.
<andrewrk>
I have a suspicion that any use case that wants closures can be rewritten to use stackless coroutines
<andrewrk>
oh there's a 2nd example here
<hryx>
that's exciting. honestly I've just had too much coffee and should be focusing my energy on fixing more bugs or something @____@
<Tetralux>
I'm curious about how coroutines will work after the rewrite, because they seem a little mindbending with the docs I read.
<Tetralux>
I have hope in them ;p
<andrewrk>
the main goal is to be able to model pipelines with zig code
<andrewrk>
in a way that allows code reuse-
<andrewrk>
that's essentially what async/await is
<Tetralux>
Define pipeline in this case.
ltriant has joined #zig
<Flaminator>
Might I ask what is the reason is why functions are not written like: "function_name fn(....) type {}" or something similar instead of the current "fn function_name(...) type {}"?
<Tetralux>
andrewrk, Either way, I'm looking forward to some example code that uses it. :)
<Tetralux>
I guess it'd be useful when you have several parallel things you need to do and you have work that makes it's way through each one of them.
<Tetralux>
Or I suppose the "several parallel things" is the important part.
<Tetralux>
I'm not sure how/if you'd use it for anything else though.
<Tetralux>
I guess that's the problem I have. I'm having a hard time visualing where/how I'd use it.
<andrewrk>
a pipeline is a directed graph of nodes and the goal is to complete the pipeline or otherwise maximize the throughput / minimize the latency of data flow
<andrewrk>
directed meaning that some nodes depend on each other
<andrewrk>
nearly all software can be modeled as a pipline
<andrewrk>
hot code swapping is something that will have a minimum viable product and then incremental improvements
<andrewrk>
it can depend on OS-specific features
<andrewrk>
an MVP will probably be as simple as all functions being dynamically linked, and then atomically updated on a new version
<hryx>
oh, I gotcha
<andrewrk>
there could potentially be taking advantage of debugger features (ptrace on linux)
<andrewrk>
that would require special privileges on macos, but I think that is reasonable
<hryx>
yeah
adtac has quit [Quit: WeeChat 2.3-dev]
HelloThere54321 has quit [Ping timeout: 260 seconds]
<andrewrk>
damn, I appear to not have debug symbols for zig0.exe on windows
<hryx>
andrewrk: I was just looking at what it would take to implement #211 (runtime check for undefined). this caused me to look at optionals under the hood. does the "maybe bit" eat into the size of a scalar type?
<andrewrk>
it does not
<hryx>
interesting. trying to see where that bit lives
<hryx>
for pointers I assume 0 means null
<andrewrk>
yes
<andrewrk>
the generated type for optionals is struct { payload: T, is_non_null: bool }
<andrewrk>
is_non_null currently takes up a byte; we could simply treat it as a byte and look for 0xaa to detect undefined in safe modes
<hryx>
gotcha, thanks. I was confused because I just tested @sizeOf with nullables, and of course it's the same for both optional and regular scalars (of the same type)
<hryx>
so obviously sizeOf is aware if it's null and looks under the hood
<andrewrk>
I would expect @sizeOf(?u8) to be 2 and @sizeOf(u8) to be 1
<hryx>
I must have screwed something up. It is as you expected
<hryx>
That 0xAA detection seems appealing since it doesn't involves messing with types in the compiler
ltriant has quit [Ping timeout: 245 seconds]
<hryx>
thanks for answering all my questions. hoping this knowledge will accumulate to the point where I can help with compiler internals a little