kristoff_it has quit [Remote host closed the connection]
doublex has quit [Quit: Quit]
doublex has joined #zig
doublex has quit [Quit: Quit]
<shritesh>
Tetralux: AFAIK, there was some discussion about being able to import a struct from a file directly. Instead of doing `const Yolo = @import("yolo.zig").Yolo`, you could do something like `const Yolo = @import("yolo.zig")` for the same effect. I might be wrong tho.
<Tetralux>
shritesh: I don't remember that, but I haven't seen them all.
<gonz_>
shritesh: That doesn't really even make sense, though...?
<gonz_>
Is there an issue for this?
<gonz_>
Becaus
<gonz_>
because that would somehow mandate that structs are uppercase as well as make it non-obvious at a glance what you're actually importing.
<shachaf>
Where you can give it some memory and it'll write into it until it runs out of space, and if it does you can resume it with more memory later.
<shachaf>
This sort of thing seems a bit more flexible than the callback API format() uses, and it can avoid copying.
<andrewrk>
interesting
<shachaf>
It's effectively turning sprintf into a coroutine, and I wonder whether the async @Frame() transformation can be used to do something like that automatically.
<andrewrk>
that sounds more like a generator, which I haven't ruled out as including in the language
<andrewrk>
they are related
<andrewrk>
but note that a generator could be async - in which case getting the next value would be a suspend point - and you could "async" getting the next value and then await it
<andrewrk>
if you try to use async/await to implement generators, you give up this use case
<andrewrk>
which is one reason I think it might be a reasonable language feature
<shachaf>
What's the distinction you're making between async and generators? The fact that there's a scheduler, or something else?
<shachaf>
They seem like the same feature to me in most respects -- the main trick is turning regular stack frames into @Frame structs, and being able to suspend execution.
<andrewrk>
with a generator, the caller is in charge of resuming it, and asking for the next value. with async, resuming the frame is a safety panic. the only thing you can do is await it, which just suspends until the result is available
<fengb>
Both can be implemented with stackless coroutines, so generators can exist as a userland thing
<shachaf>
The result becomes available through *someone* resuming the frame, presumably, no?
<fengb>
But semantically they're used rather differently
<shritesh>
Now I'm wishing that there was some way to declare a file as a tagged union. My structs are `const SomeStruct = @import("some_struct.zig")` but tagged unions are now `const SomeTaggedUnion = @import("some_tagged_union.zig).SomeTaggedUnion`.
<andrewrk>
shachaf, with zig's async/await, it's not the caller's responsibility to resume - it's the async function itself, which suspended itself, which must make sure it gets resumed
laaron has joined #zig
<andrewrk>
shritesh, yeah... and generic functions, and enums... idk. I think we have to just stick with structs
<andrewrk>
it's one thing to say files are just structs. another thing entirely to start trying to annotate files and other crazy things
<shritesh>
Yeah
laaron has quit [Remote host closed the connection]
<shachaf>
I see. Those seem pretty closely related to me but I can see why you'd distinguish them.
<shritesh>
We need javascript's `export default` /s
<fengb>
The implementation can be based on the same thing, and you can always implement one using the other, but without both you can't do async generators
<andrewrk>
nrdmn came in and worked on UEFI support
<andrewrk>
I still have a PR to merge regarding that
<knebulae>
it looks great.
laaron has joined #zig
<knebulae>
All the C cleanup is sweet too. Very nice work!
<knebulae>
*C pointer cleanup
<andrewrk>
ah right, you came in and experienced the worst of it right before I did that work
<andrewrk>
nice work on Isaac64
<knebulae>
Yes, it was hairy. Thank you btw.
<knebulae>
I'm working my way up into porting some of the C code I worked on in the past several months to Zig. I use this lib extensively, so this was step 1.
shritesh has quit [Quit: Leaving...]
laaron has quit [Remote host closed the connection]
laaron has joined #zig
cgag has quit [Ping timeout: 272 seconds]
cgag has joined #zig
<bgiannan>
i get that zig wont add two int of different types, but does it really need both operands of a comparison to be of the same int type?
cgag has quit [Ping timeout: 268 seconds]
cgag has joined #zig
drazan has quit [Remote host closed the connection]
drazan has joined #zig
tines9 has quit [Quit: leaving]
tines9 has joined #zig
Tetralux has quit [Read error: Connection reset by peer]
<knebulae>
@andrewrk: re-reading my comment from earlier, I meant that the whole C pointer shenanigans were hairy, not porting the Isaac64 code. That was mostly straightforward. I figure there has to be a more idiomatic "Zig Way" to write some of this code.
<knebulae>
*though
<hspak>
bgiannan: I believe you do unless you want to follow C's implicit integer promotion model
ltriant has quit [Quit: leaving]
abbiya has joined #zig
alexander92 has joined #zig
cgag has quit [Ping timeout: 245 seconds]
cgag has joined #zig
influx6 has joined #zig
influx6 has quit [Remote host closed the connection]
ntgg has joined #zig
alexander92 has quit [Ping timeout: 245 seconds]
<bgiannan>
how can i define a runtime variable that is accessible accross all my zig files?
ntgg has quit [Ping timeout: 268 seconds]
nitram91 has joined #zig
nitram91 has quit [Remote host closed the connection]
ntgg has joined #zig
FireFox317 has joined #zig
FireFox317 has quit [Remote host closed the connection]
<mq32>
i think it's not possible to do runtime code in variable initialization
<mq32>
and Self.init() is not const-evaluatable
<mq32>
so you have to init RNG.Current in your main function
<bgiannan>
yeah
<bgiannan>
did something like that earlier with no luck, let me try again
<bgiannan>
seems to work in a test main, but still constanst expression error somewhere else related to that variable
<mq32>
oh
<mq32>
pub var Current = Self.init();
<mq32>
init may return an error ;)
<bgiannan>
So i initialize RNG.Current in main.zig with a try. When i reference it from another file i get `unable to evaluate constant expression` right when i try to reference it with `@import("./rng.zig").RNG.Current`
<mq32>
huh
<bgiannan>
ah maybe i should not do it in a global variable
<mq32>
how is your variable defined now?
<bgiannan>
but when i need to reference it
<bgiannan>
Current?
<mq32>
pub var Current : Self = undefined; // should be correct to my knowledge
<bgiannan>
yes that's it
<bgiannan>
ok i think i got it
<bgiannan>
i tried to reference RNG.Current when initializing a global variable
<bgiannan>
when i just import RNG and do RNG.Current.random when i need it then it works
<bgiannan>
so i guess global variable are comptime
<vegai>
gonz_: yeah, I wasn't certain whether that would be wanted, since the azure pipelines already highlighted the problem
kristoff_it has quit [Ping timeout: 258 seconds]
<Snektron>
There should be a nicer way than @hasDecl everywhere in std/os/linux.zig
<Snektron>
and i've noticed a mistake in it too
kristoff_it has joined #zig
laaron has quit [Remote host closed the connection]
laaron has joined #zig
alexander92 has quit [Ping timeout: 245 seconds]
shritesh has joined #zig
shritesh has quit [Remote host closed the connection]
shritesh has joined #zig
shritesh has quit [Client Quit]
FireFox317 has joined #zig
<FireFox317>
andrewrk: Next week the big async/await, networking etc stream is coming?
SimonN has quit [Ping timeout: 246 seconds]
SimonN has joined #zig
samtebbs has joined #zig
SimonNaa has joined #zig
SimonN has quit [Ping timeout: 246 seconds]
rivten has joined #zig
<rivten>
hey everybody ! quick question : i am building some zig code either to a DLL or to an EXE file, is there a way, within the source code, to differentiate between the two in the file at comptime ? (like I want to take different paths in the code)
<rivten>
I couldn't find anything like that in LinkExeObj that could either tell me what was the target type, or set some comptime known value from the Builder (like is_exe for example)
<fengb>
That needs to happen at link time
<fengb>
comptime is too early to detect since it’s spitting out build objs
<rivten>
samtebbs : well i'm trying it on the main branch and it seems to work very fine on my side
<fengb>
But but... pluto was demoted
rivten has quit [Remote host closed the connection]
<samtebbs>
fengb: Hmm interesting, I can never get the compiler to recognise @import("build_options")
<fengb>
I think you tagged the wrong person. I'm just here for the snark
<samtebbs>
Oh lol I did
<samtebbs>
rivten: ^
<samtebbs>
Seems to be working now anyway
mmx870 has quit [Ping timeout: 245 seconds]
shritesh has joined #zig
mmx870 has joined #zig
alexander92 has joined #zig
<andrewrk>
Snektron, @sizeOf(usize) will tell you the size of a pointer. if that's what you want, that's good. you also have full access to comptime constants about the target
<andrewrk>
have a look at the stdout of `zig builtin`. that's an example of what you get with @import("builtin")
<andrewrk>
I'm happy to report that after 1 fix the llvm9 branch has passed all tests, including optimized builds, with a debug build of llvm9 with all the asserts on
<samtebbs>
andrewrk: Nice one, what big improvements do you predict us getting from llvm 9?
<samtebbs>
That should actually mean that some of my llvm patches will be in Zig
<andrewrk>
RISC-V support
<andrewrk>
that's about it as far as I'm concerned. but it's important to stay up to date
<andrewrk>
I also don't run the full test suite with llvm assertions on very often, so it's always a relief when it passes
<scientes>
I like the version pinning better than other LLVM-language's staleness
<samtebbs>
Nice, I want to see if I can generate any arm MVE code from zig too
<samtebbs>
That may be in llvm 9
<andrewrk>
thanks for the fix mikdusan
<shritesh>
AVR support by default too I think
<scientes>
well, llvm's AVR never worked as well as gcc's
<scientes>
avr-8 that is
<shritesh>
I think the Rust folks have put in a lot of effort to improve it recently
<andrewrk>
yay, thanks rust
<scientes>
shritesh, yes they have
FireFox317 has quit [Ping timeout: 245 seconds]
<shritesh>
I will be working on some simple hardware projects this weekend with Zig running on Arduino Uno, Teensy 4.0, Raspberry Pi 3B+ and a Sparkfun Edge to demo at my NashMicro talk on Tuesday.
<scientes>
on "Using LLVM's portable SIMD with Zig"
<andrewrk>
AVR is not one of them, but I enable it for ziglang.org/download builds
<andrewrk>
scientes, for what convention?
<scientes>
LLVM Dev Mtg October 22-23
<scientes>
in San Jose
<andrewrk>
oh wow neat! that should be enough time to make more progress on SIMD upstream and make your life easier
<samtebbs>
Oh cool, it would be great to hear about it afterwards
GiovaniAbel has quit [Ping timeout: 245 seconds]
samtebbs has quit [Quit: leaving]
<Snektron>
Is there any particular reason why getdents64 takes a [*]u8 and not an os.dirent64?
<Snektron>
and why are both getdents and getdents64 provided?
<Snektron>
Doesn't getdents64 supersede that? it seems to make more sense to add a hasDecl on both getdents and dirent
<andrewrk>
Snektron, the struct has a variable length last field, and it's easier to interface with as [*]u8
<andrewrk>
as for that other thing... I'll have to read the code and refresh my memory
GiovaniAbel has joined #zig
<andrewrk>
hmm that's strange, musl only has getdents and aliases getdents64 to it
<andrewrk>
aha: if getdents64 is provided then it undefs it and defines SYS_getdents to SYS_getdents64
<andrewrk>
Snektron, I agree with you and think we should follow musl's lead
<Snektron>
there are a few other such syscalls, and arm happens to be one of the platforms where those are implemented
<Snektron>
i've just been putting @hasDecl on the affected ones, yet i wonder if thats the best method
<Snektron>
also, i wonder whats the best way to deal with that annoying long long in 32 bit linux calling convention in Zig
<Snektron>
musl defines a few macros to help out with that, but thats not possible here
<Snektron>
btw, the zig source code contains undefined behaviour because it has a function called 'tokenize' ;)
<andrewrk>
orly? I'm happy to change that. we probably should care about that because the main point of stage1 is bootstrapping. getting rid of technically undef behavior is in scope
<andrewrk>
but, I would rather prioritize that after we have stage2 working
<andrewrk>
Snektron, btw feel free to do smaller pull requests to improve arm32, that would be easier for me to code review, and prevent merge conflicts since master branch changes quickly
<andrewrk>
there have been a few similar attempts in the past that were abandoned because the contributor tried to do a massive PR that did everything at once, and then couldn't keep up with the merge conflicts
<Snektron>
theres actually not quite a lot of change, just some small changes and added definitions, but if you want to i can make a PR for what i have now.
<Snektron>
The stuff about the syscalls is more general for 32-bit platforms i believe
<andrewrk>
it's up to you. but I'm predicting that you're going to get minimal push-back and quick merges
<scientes>
Snektron, did you get the C ABI working?
<scientes>
actually, I don't think it is possible with current zig, because of "homogenous aggregates"
<Snektron>
scientes: what do you mean exactly?
<andrewrk>
that's one of the tests that gets run in ./zig build test-standalone
<scientes>
the C ABI is the hardest problem of adding a new platform to zig
<Snektron>
ah, well most of the platform support was already there
<scientes>
except C ABI
<andrewrk>
ah, the test is only enabled for x86_64 currently
<scientes>
ninja build won't work without at least some of it, only ninja zig0
<Snektron>
there was just some stuff for linux missing really
<andrewrk>
Snektron, have a look at test/stage1/c_abi/cfuncs.c and test/stage1/c_abi/main.zig
<Snektron>
that and a compile error due to a wrong cast of u64 to usize
<Snektron>
andrewrk: it might be worth it to disallow implicit casts to usize
<andrewrk>
this is what scientes is talking about. and you can see the test is only enabled for x86_64 in test/standalone.zig
<Snektron>
ill have a look in a moment
<scientes>
I also asked the LLVM developers to move the C ABI from clang to LLVM, and they explained that that isn't really possible
<andrewrk>
but yeah if you got that working that would be a huge contribution. it's not required to do other std lib improvements
<andrewrk>
oh, why is that scientes?
<scientes>
because it is heavily connected to codegen, like if you use sizeof() and offsetof()
<andrewrk>
ah
Akuli has joined #zig
<andrewrk>
it would be nice if they did it for the C calling convention though.
<scientes>
that said, the Power backend does implement the C ABI
<scientes>
which was suprising
<scientes>
there are even tests for it
kristoff_it has quit [Ping timeout: 245 seconds]
<Snektron>
andrewrk: is it possible to compile tests but not run them?
<Snektron>
My poor old raspberry pi is certainly not powerfull enough to compile zig, and just compiling the tests for a different architecture is probably easier than setting up a cross compilation environment
<andrewrk>
Snektron, have you tried passing -target?
<andrewrk>
it works
<Snektron>
that will just run them, no?
<andrewrk>
$ zig test test.zig -target aarch64v8-linux
<andrewrk>
Created /home/andy/tmp/zig-cache/o/64isfUkAB5uKWsB2cbzFTy9ijBJamsg0x23M8YjFTxnQ6zIoMKudhukTjWNNdUki/test but skipping execution because it is non-native.
<Snektron>
aha, shame on me for not just trying it
<andrewrk>
if you want a nicer output path you can pass --output-dir too
laaron has quit [Remote host closed the connection]
laaron has joined #zig
cgag has joined #zig
<Snektron>
by default zig will use the included musl right?
casaca has quit [Ping timeout: 258 seconds]
<andrewrk>
Snektron, zig will use the included musl if you use one of the targets listed under "available libcs" in the output of `zig targets`
<andrewrk>
zig targets | grep musl
<Snektron>
im really not thinking today, i literally just passed armv6-linux-musleabihf to it
<andrewrk>
that should work :)
<Snektron>
strange
casaca has joined #zig
<andrewrk>
this works for me: zig build-exe --c-source hello.c -target armv6-linux-musleabihf --library c
<andrewrk>
it takes a minute to build musl the first time
<Snektron>
i've found an error in musl for starters
Ichorio has joined #zig
<Snektron>
andrewrk: Where exactly does zig get the standard C headers from? lib/libc/musl/include or lib/include?
<andrewrk>
Snektron, you can see with --verbose-cc
casaca has quit [Ping timeout: 258 seconds]
<andrewrk>
from the install directory of zig, lib/zig/libc/include has libc headers; lib/zig/include has C language headers
casaca has joined #zig
casaca has quit [Ping timeout: 258 seconds]
casaca has joined #zig
<Snektron>
So why isn't alltypes.h.in used for the selected architecture when building with musl?
<Snektron>
musl defines architecture-specific type sizess in those, yet i can't see those being translated into a header anywhere
<Snektron>
instead, the types are taken from generic-musl/bits/alltypes.h, which defines _Int64 to 'long'
<Snektron>
A long is only 4 bytes on arm, so that yields a compile error on the test
<Snektron>
arm-linux-musl/stdint.h only defines up until uint32_t
cgag has quit [Ping timeout: 268 seconds]
<andrewrk>
Snektron, when I do this with musl v1.1.23: make DESTDIR=build-all/arm install-headers ARCH=arm
<andrewrk>
this produces build-all/arm/usr/local/musl/include/bits/alltypes.h
<andrewrk>
this file has #define _Int64 long
GiovaniAbel has quit [Ping timeout: 268 seconds]
tgschultz has joined #zig
<andrewrk>
this does seem weird though. I'm going to ask about this in #musl
casaca has quit [Ping timeout: 258 seconds]
casaca has joined #zig
<Snektron>
andrewrk: am i missing something by simply compiling zig? shouldn't that also produce the right musl files?
<andrewrk>
not sure what you're asking
<Snektron>
The build command you sent is for musl itself right?
<Snektron>
Oh i see, but shouldn't the current libc files also work without updating them?
<andrewrk>
to find out why alltypes.h was not what was expected, I was repeating the instructions for updating musl, to find out how alltypes.h got to be what it is. that's what led me to discover this surprising thing that is probably a bug in musl's build script
laaron has quit [Remote host closed the connection]
<Snektron>
aha
<andrewrk>
so, they fix that, we run the instructions for updating again, and then we have our fix
laaron has joined #zig
return0e has quit [Read error: Connection reset by peer]
<andrewrk>
Snektron, isn't that what std.os.linux.write is?
<Snektron>
i suppose, but the main functionality im hinting at is the last. It's easy to overlook the 32-bit case
<Snektron>
though there are only a few affected
<andrewrk>
I think the appropriate abstraction layer is the one that is calling syscallN()
wootehfoot has quit [Read error: Connection reset by peer]
cgag has joined #zig
<shritesh>
Are recursive functions still problematic? I'm getting broken LLVM module errors using recursive functions with error sets.
<andrewrk>
there is some work I'm doing on recursion at the moment, but I wouldn't expect that to happen
<andrewrk>
it's expected that you would get a compile error saying "unable to infer error set; function still being analyzed"
<andrewrk>
and to work around it, give the function an explicit error set. you can start with an empty one and the compiler will tell you which items are missing
<shritesh>
Hmm.
avoidr_ has quit [Quit: leaving]
avoidr has joined #zig
marler8997 has joined #zig
<marler8997>
andrew made a comment about deprecating use/usingnamespace...is there an alternative that has been introduced or any info on how to write code without it?
<andrewrk>
use is deprecated; usingnamespace is planned to stay
<andrewrk>
zig fmt changes the former to the latter automatically
<andrewrk>
and it works if you flip suspending_implementation to false
<andrewrk>
now all I have to do is make detected recursion automatically make all the functions in the call graph cycle async, and we have accomplished safe recursion