ChanServ changed the topic of #zig to: zig programming language | | be excellent to each other | channel logs:
doublex has joined #zig
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.
marijnfs_ has joined #zig
<shritesh> This is what I am talking about
marijnfs has quit [Ping timeout: 272 seconds]
<shritesh> The solution was just to use `usingnamespace`
<gonz_> I guess I'm not seeing what the common bits between what you said and the issue are.
<gonz_> `usingnamespace` is for bringing everything from an import into scope, no?
<gonz_> `import` in Elixir, `open` in OCaml, etc.
<shritesh> Correct. I thought it was some sort of new mechanism that was being worked on. Instead, `usingnamesapce` is what I was looking for.
<fengb> Not sure if it’s intentional... but you can declare fields into the top level file struct
<fengb> So you can treat the file as a real struct
<shritesh> Ohh. I didn't know that. That's interesting
kristoff_it has joined #zig
<shritesh> I'm going to (ab)use the hell out of that :D
kristoff_it has quit [Ping timeout: 272 seconds]
<andrewrk> I haven't started taking advantage of it yet but I think that's the direction things are headed
<andrewrk> shritesh, see also
<shritesh> Honestly, I like it.
<andrewrk> yeah. the main benefit is that reflection on a file is easy to understand because it's literally just a struct
<shritesh> "A source file is just a special case of a struct."
<shachaf> Hmm, does the current async/await plan allow for a state-machine-style API for format(), rather than the current callback API?
<andrewrk> I'm not sure how to answer that question
<shachaf> Let me be more concrete.
<shachaf> I was thinking that in C I want an sprintf API that can be used like this:
<shachaf> char buf[100]; SprintfState state; sprintf_init(&state, "test %d %s\n", 123, some_string); while (!state.done) { sprintf_chunk(&state, buf, sizeof buf); write(1, buf, state.chunk_size); }
<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
laaron has quit [Quit: ZNC 1.7.1 -]
<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> fengb, that's a good way to put it
<knebulae> Long time no speak guys. Just wanted to throw out that I've ported the Isaac64 CSPRNG to Zig. Verified against the C code results.
<andrewrk> oh hi knebulae
<knebulae> hey man!
<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]
kristoff_it has joined #zig
laaron has quit [Quit: ZNC 1.7.1 -]
laaron has joined #zig
GiovaniAbel has joined #zig
<mq32> hey
<bgiannan> hey
<mq32> anti-rant: please never remove the possibility to declare local types from Zig
<mq32> i'm coding in c# right now and it's just annoying that you can't declare function-local types
<mq32> tuples just don't do good semantics
laaron has quit [Remote host closed the connection]
ntgg has quit [Ping timeout: 244 seconds]
laaron has joined #zig
laaron has quit [Remote host closed the connection]
donpdonp has quit [Read error: Connection reset by peer]
laaron has joined #zig
<bgiannan> can i put a runtime variable inside a struct?
<bgiannan> something like: const MyType = struct { pub var random = somethingRandom() }?
<bgiannan> keep running into `unable to evaluate constant expression` errors
<mq32> should work, as a var in a struct is just the same as a global variable
<bgiannan> here's my usecase:
<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
avoidr has quit [Quit: leaving]
laaron has quit [Quit: ZNC 1.7.1 -]
<bgiannan> this is slowy getting into high-level and/or scripted languages guy
<bgiannan> this sentence is horrible
laaron has joined #zig
alexander92 has joined #zig
<vegai> so, the macos build isn't working in master. Is anyone on that?
cgag has quit [*.net *.split]
tines9 has quit [*.net *.split]
marijnfs_ has quit [*.net *.split]
samtebbs has quit [*.net *.split]
tgschultz has quit [*.net *.split]
sammich has quit [*.net *.split]
mq32 has quit [*.net *.split]
marler8997_1 has quit [*.net *.split]
marler8997 has quit [*.net *.split]
nrdmn has quit [*.net *.split]
hryx has quit [*.net *.split]
shachaf has quit [*.net *.split]
torque has quit [*.net *.split]
programisto has quit [*.net *.split]
so has quit [*.net *.split]
sammich has joined #zig
hryx has joined #zig
mq32 has joined #zig
programisto has joined #zig
tines9 has joined #zig
shachaf has joined #zig
torque has joined #zig
<gonz_> vegai: The most consistent way to get it solved is probably to make an issue.
abbiya has quit [Quit: abbiya]
<vegai> mikdusan: ah great
<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
laaron has quit [Quit: ZNC 1.7.1 -]
<rivten> yeah but maybe in the build.zig file I can set something in the source file at comptime ?
laaron has joined #zig
<rivten> like I could maybe say at comptime that var is_exe = true in the source file from the build file ?
<rivten> (i don't know if that's clear or not ^^)
<rivten> i think basically my question boils down to : how do we do #ifdef in zig and how can we define the ifdef in the build.zig file ?
<fengb> ifdef etc. is done using comptime. Using `if (comptime var)` allows the compiler to eliminate dead branches immediately
<fengb> I'm not sure how to inject values at build time though
lunamn_ has joined #zig
lunamn_ has quit [Client Quit]
lunamn_ has joined #zig
lunamn has quit [Ping timeout: 246 seconds]
<rivten> found it :) pub fn addBuildOption(self: *LibExeObjStep, comptime T: type, name: []const u8, value: T) void {
<FireFox317> rivten: it is possible to @import("build_options"), see this example:
<FireFox317> and indeed use `addBuildOption` in your build.zig
<fengb> Ah cool
<rivten> cool !! thanks a lot :)
<Snektron> Whats the best way to check if a you're compiling for 32 bit?
<Snektron> just @sizeOf(usize) == 4?
waleee-cl has joined #zig
<rivten> if you use a build.zig file, you have a Target member in a LinkExeObjStep that you can check
<samtebbs> rivten: Last time I checked, "build_options" wasn't recognised by the compiler. Here's my working attempt at build options
<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> oh yeah, my LLVM talk was accepted
<andrewrk> the list of non-experimental targets for 9.0 is here:
<scientes> on "Using LLVM's portable SIMD with Zig"
<andrewrk> AVR is not one of them, but I enable it for 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 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?
<andrewrk> yeah, it's from the "how to update the bundled musl" instructions:
<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]
return0e has joined #zig
avoidr has joined #zig
SimonN has joined #zig
laaron has quit [Quit: ZNC 1.7.1 -]
SimonNaa has quit [Ping timeout: 268 seconds]
laaron has joined #zig
shritesh has quit [Remote host closed the connection]
cgag has joined #zig
casaca has quit [Ping timeout: 245 seconds]
casaca has joined #zig
<andrewrk> instructions are updated so next time it will be correct too
gunnara has joined #zig
<Snektron> thank you
<andrewrk> thanks for discovering this, that was a rather nasty bug
casaca has quit [Ping timeout: 268 seconds]
casaca has joined #zig
mmx870 has quit [Ping timeout: 244 seconds]
<gunnara> hspak - hi! I looked into the and is that a bug in the build pipeline? I can
<gunnara> not understand what failed it
mmx870 has joined #zig
<andrewrk> gunnara, this was fixed in master by mikdusan's commit 966670645a
<gunnara> andrewrk - oh, so a rebuild would fix this?
<andrewrk> yes a rebuild against master
<gunnara> ok
<andrewrk> you can see the green checks here:
<Snektron> im surprised noone noticed it before
<Snektron> I think it should produce wrong results on every non-64 bit system
<andrewrk> yeah. I don't think we have many C programmers using zig to cross compile C yet
<andrewrk> I believe it will happen soon after the package manager is working smoothly
<andrewrk> because it will solve cross compilation for C programmers as well as zig programmers
<Snektron> guess im doing that now though
<Snektron> only have an old rpi lying around, it controls my drawing robot which i made last year
<Snektron> but i burned out on the project before i was able to program it
<andrewrk> neat!
<Snektron> that and there was some problem with powering the stepper motors, ill have to look at that after i get some i2c stuff working
<gunnara> How is a rebuild triggered?
<andrewrk> gunnara, is this for a pull request?
<gunnara> yea, I know its not my PR but I
<gunnara> am trying to understand the bug fixing process and tools :)
<andrewrk> if it was your pull request, you could rebase it against master and force push
<gunnara> ah ok thank you
shritesh has joined #zig
return0e has quit [Read error: Connection reset by peer]
return0e has joined #zig
gunnara has quit [Ping timeout: 245 seconds]
avoidr_ has joined #zig
avoidr has quit [Ping timeout: 268 seconds]
gunnara has joined #zig
laaron has quit [Remote host closed the connection]
laaron has joined #zig
wootehfoot has joined #zig
Akuli has quit [Quit: Leaving]
waleee-cl has quit [Quit: Connection closed for inactivity]
gunnara has quit [Ping timeout: 245 seconds]
<Snektron> andrewrk: what do you think about adding prototypes to syscall constants?
cgag has quit [Ping timeout: 245 seconds]
<Snektron> say for example defining SYS_write as Syscall(0, fn(u32, [*]u8, usize) usize);
<Snektron> where Syscall has a .call function
<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/ 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> it's just a keyword change
<marler8997> oh thanks for the clarification
<andrewrk> I've done it
<andrewrk> in a local branch, this code works:
<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