ChanServ changed the topic of #zig to: zig programming language | | be excellent to each other | channel logs:
aconbere has joined #zig
chivay has quit [Remote host closed the connection]
chivay has joined #zig
<ifreund> ok, who made this?
layneson has joined #zig
<yeti> wasn't me, mom! I promise!
<andrewrk> looks like it was Ben Jakob, who in fact asked permission to do it and Loris encouraged him to go for it
<ifreund> I wonder if it has zig syntax highlighting :D
<ifreund> pretty cool regardless though
zags has quit [Ping timeout: 245 seconds]
squeek502 has joined #zig
<andrewrk> not that you need permission to create a zig forum, as long as you don't pretend to be "the official one" since there isn't one
layneson has quit [Ping timeout: 256 seconds]
g-w1 has quit [Ping timeout: 246 seconds]
layneson has joined #zig
layneson has quit [Client Quit]
sebonirc has left #zig [#zig]
ave_5 has joined #zig
Miaourt1 has joined #zig
linuxgemini0 has joined #zig
osa1_ has joined #zig
meatcar_ has joined #zig
msirabella has joined #zig
xentec_ has joined #zig
kragacles_ has joined #zig
sundbp has quit [Ping timeout: 245 seconds]
shachaf_ has joined #zig
dreda_ has joined #zig
washbear has joined #zig
doublej41 has joined #zig
g-w1 has joined #zig
mht-technology has joined #zig
decentpenguin has quit [Quit: ZNC crashed or something]
osa1 has quit [*.net *.split]
xentec has quit [*.net *.split]
dreda has quit [*.net *.split]
SimonNa has quit [*.net *.split]
terinjokes has quit [*.net *.split]
kragacles has quit [*.net *.split]
doublej472 has quit [*.net *.split]
mht has quit [*.net *.split]
shachaf has quit [*.net *.split]
meatcar has quit [*.net *.split]
Nypsie has quit [*.net *.split]
ave_ has quit [*.net *.split]
racoon has quit [*.net *.split]
linuxgemini has quit [*.net *.split]
Miaourt has quit [*.net *.split]
mjsir911 has quit [*.net *.split]
marler8997 has quit [*.net *.split]
ave_5 is now known as ave_
kragacles_ is now known as kragacles
linuxgemini0 is now known as linuxgemini
Miaourt1 is now known as Miaourt
meatcar_ is now known as meatcar
mht-technology has quit [Ping timeout: 264 seconds]
mht has joined #zig
SimonNa has joined #zig
earnestly has quit [Ping timeout: 256 seconds]
marijnfs2 has quit [Ping timeout: 260 seconds]
gazler has joined #zig
gazler_ has quit [Ping timeout: 245 seconds]
cCCCCcccccCCc has joined #zig
reductum has joined #zig
gpanders_ has quit [Ping timeout: 268 seconds]
jicks has quit [Quit: ZNC is kill]
jicksaw has joined #zig
shachaf_ is now known as shachaf
reductum has quit [Quit: WeeChat 3.0.1]
tomku has quit [Ping timeout: 246 seconds]
tomku has joined #zig
tomku has quit [Ping timeout: 246 seconds]
tomku has joined #zig
knebulae has quit [Read error: Connection reset by peer]
ur5us has quit [Ping timeout: 264 seconds]
<mikdusan> tl;dr: macOS 11 no earlier than "April" and no clarity if that means just x86_64 or both x86_64 and arm64
jumpnbrownweasel has joined #zig
bitmapper has quit [Quit: Connection closed for inactivity]
sord937 has joined #zig
sundbp has joined #zig
sord937 has quit [Remote host closed the connection]
sord937 has joined #zig
<andrewrk> ifreund, branch is up:
<andrewrk> it's not incredibly contributor friendly yet, but starting to get there. I think once I work through the compile errors it will start to make sense how people could jump in
<andrewrk> zir.zig is done. Sema.zig is mostly done. Module.zig is mostly done. astgen.zig is nearly untouched.
<andrewrk> next problem to solve is resolving LazySrcLoc during ZIR=>TZIR phase because (for now) TZIR wants byte offsets only.
waleee-cl has quit [Quit: Connection closed for inactivity]
cole-h has quit [Ping timeout: 264 seconds]
sundbp has quit [Ping timeout: 245 seconds]
riba has joined #zig
yyp has joined #zig
<mikdusan> til about rclone. wow.
forgot-password has joined #zig
gpanders has joined #zig
<ifreund> andrewrk: nice, I look forward to digging in :)
riba has quit [Ping timeout: 260 seconds]
yeti has quit [Remote host closed the connection]
earnestly has joined #zig
yeti has joined #zig
sundbp has joined #zig
ur5us has joined #zig
<mikdusan> when generate makefiles, a build happens
<mikdusan> when generate ninja, a build fails with:
<mikdusan> ninja: error: multiple rules generate zig1.o
<mikdusan> if I disable BYPRODUCTS then cmake proceeds to build
<mikdusan> err then ninja can build
<mikdusan> can't put my finger on it exactly but this might be introducing a race condition in make. I had weird out-of-dep-order building happening but didn't narrow it down and resorted to -j1 (make)
jumpnbrownweasel has quit [Ping timeout: 240 seconds]
halbeno_ has quit [Remote host closed the connection]
halbeno has joined #zig
<dutchie> huh, there's no btreemap in zig std. i'm implementing one for a little fun side project, would it be worth me tidying it up and submitting it?
<dutchie> ah, i was just perusing
Piraty has joined #zig
zags has joined #zig
tnorth has joined #zig
marijnfs has quit [Ping timeout: 265 seconds]
fireglow has quit [Quit: Gnothi seauton; Veritas vos liberabit]
marijnfs has joined #zig
ur5us has quit [Ping timeout: 264 seconds]
yyp has quit [Quit: disconnected]
yyp has joined #zig
fireglow has joined #zig
fireglow has quit [Remote host closed the connection]
fireglow has joined #zig
sord937 has quit [Ping timeout: 268 seconds]
sord937 has joined #zig
<ikskuh> heya o/
<ikskuh> is there already a tracking issue for how to solve the character limit of the windows command line args?
knebulae has joined #zig
<cepheus> since i brought this up I figured i would leave it here but here is a working version of the abandoned serialization code for current (as of a couple days ago) zig master
<cepheus> working inasmuch that it passes the pre-existing tests and i've validated it against serialized data written with data structures serialized from zig 0.7, anyway
forgot-password has quit [Ping timeout: 264 seconds]
forgot-password has joined #zig
forgot-password has quit [Quit: leaving]
<Cadey> does zig work if you compile it to wasi?
fireglow has quit [Quit: Gnothi seauton; Veritas vos liberabit]
<g-w1> yes, it even has some wasi stuff in the stdlib:
fireglow has joined #zig
fireglow has quit [Remote host closed the connection]
fireglow has joined #zig
g-w1 has quit [Ping timeout: 264 seconds]
cole-h has joined #zig
yyp has quit [Quit: disconnected]
yyp has joined #zig
yyp has quit [Client Quit]
gpanders has quit [Quit: ZNC -]
yyp has joined #zig
gpanders has joined #zig
<mikdusan> ugh. azure has a bad apple or two in their mac pipeline pool. filesystem is floppy-disk slow.
yyp has quit [Read error: Connection reset by peer]
yyp has joined #zig
aconbere has quit [Ping timeout: 246 seconds]
fireglow has quit [Quit: Gnothi seauton; Veritas vos liberabit]
mikdusan has quit [Read error: Connection reset by peer]
mikdusan has joined #zig
zags has quit [Quit: zz]
aconbere has joined #zig
powerofzero has joined #zig
g-w1 has joined #zig
bitmapper has joined #zig
dimenus has joined #zig
mikdusan has quit [Quit: WeeChat 3.0.1]
dimenus|home has joined #zig
dimenus|home has quit [Quit: WeeChat 3.1]
decentpenguin has joined #zig
Rum has joined #zig
aconbere has quit [Ping timeout: 276 seconds]
aconbere has joined #zig
aconbere has quit [Ping timeout: 265 seconds]
aconbere has joined #zig
gpanders has quit [Quit: ZNC -]
yyp has quit [Ping timeout: 260 seconds]
Akuli has joined #zig
yyp has joined #zig
fireglow has joined #zig
fireglow has quit [Read error: Connection reset by peer]
fireglow has joined #zig
waleee-cl has joined #zig
powerofzero has quit [Ping timeout: 256 seconds]
fireglow has quit [Quit: Gnothi seauton; Veritas vos liberabit]
gpanders has joined #zig
<aconbere> Hmmmm I'm looking at a simple parser, curious if there is a standard pattern to peek a reader?
<aconbere> I don't see any seek methods on it that I could reset the pointer, and I don't see a peek method off hand
<aconbere> Maybe I could just read into an array list and then check a slice of that
<aconbere> and then just keep mutably reading into that?
<ifreund> aconbere: if you don't need the parser to be streaming it's much easier to just read the file into memory and parse the buffer
<ifreund> if you want an example of a streaming parser, see the one in std.json
fireglow has joined #zig
<ifreund> aconbere: oh and there's also
fireglow has quit [Client Quit]
gpanders has quit [Quit: ZNC -]
Nypsie has joined #zig
gazler has quit [Remote host closed the connection]
<aconbere> cool! thanks I'll play with it
<aconbere> I mean, I'm still not writing anything where the goal is the outcome so much as the learning
<aconbere> eventually I'll want to know how to use streaming io
<aconbere> likely for parsing :)
fireglow has joined #zig
aconbere has quit [Ping timeout: 264 seconds]
fireglow has quit [Client Quit]
bitmapper has quit [Quit: Connection closed for inactivity]
fireglow has joined #zig
marijnfs has quit [Quit: WeeChat 2.8]
braket has quit [Ping timeout: 276 seconds]
mikdusan has joined #zig
Rum has quit [Quit: Leaving]
fireglow has quit [Quit: Gnothi seauton; Veritas vos liberabit]
aconbere has joined #zig
braket has joined #zig
fireglow has joined #zig
fireglow has quit [Client Quit]
tnorth has quit [Ping timeout: 260 seconds]
<andrewrk> Cadey, are you asking if the self-hosted compiler supports being compiled for WASI? or just if zig supports -target wasm32-wasi ?
<Cadey> andrewrk: the former,
<andrewrk> I'm guessing there are some errors that would be hit, but could be overcome with some std lib improvements
fireglow has joined #zig
<andrewrk> I have a branch where I got it successfully compiling for wasm32-freestanding
<andrewrk> I decided not to merge it yet because it was a bit invasive of a patch for this early in the development
fireglow has quit [Quit: Gnothi seauton; Veritas vos liberabit]
<g-w1> andrewrk: is there a reason for Sema to have a branch_quota field if it is not used?
<andrewrk> g-w1, it's used - it was moved from each Block having a pointer to it
<andrewrk> now each block has a pointer to Sema, so it's in there
<andrewrk> instead of block.branch_quota.* it's now block.sema.branch_quota
<g-w1> ah, I got confused with branch_count and branch_quota since some of the code was not updated; got it
<g-w1> so Sema has branch_quota but block has branch_count
sord937 has quit [Ping timeout: 268 seconds]
<andrewrk> yeah it's tricky when some of the code is still wip and erroring!
<andrewrk> I think I can get it compiling today, with the help of some @panic("TODO")
sord937 has joined #zig
<g-w1> nice :)
<g-w1> ill try to fix the zir_sema stuff that I have worked on in the past
fireglow has joined #zig
sawzall has quit [Read error: Connection reset by peer]
sawzall has joined #zig
<aconbere> Is there a way to get more information about a test that panics?
<aconbere> `thread 65433 panic: test failure` and a stacktrace is what I get
<aconbere> but I don't get any information about what might have caused it to panic
<mikdusan> andrewrk: these files can be nuked from :
sord937 has quit [Quit: sord937]
Piraty has quit [Quit: ---]
Piraty has joined #zig
<aconbere> huh
<g-w1> aconbere: you can debug it with gdb; just see the command that failed and debug that binary
<aconbere> Can anyone help me understand why this panics?
<aconbere> given that when I make it check[0..2] I'm confused about the way that slice offsets work
<aconbere> My intuition was first that the "end" was inclusive so [0..1] would give me the slice {'H', 'T'}
<yyp> slice[start..end] goes from start to end - 1
<yyp> That's also true in other languages (Python I think)
<aconbere> yyp: yeah makes sense, but then I would have expected to get back just ... a smaller slice {'H'}
<aconbere> and I would have expected that mem.eql would return false
<aconbere> I was surprised by the panice :)
<aconbere> panic
<yyp> Well, you use testing.expect which panics when the supplied value is false
<aconbere> ohhhhhhh
<aconbere> huh
<aconbere> is there a better test function to use?
<yyp> You could have used something like"{}", mem.eql(...))
<yyp> And it will output it in the console
<g-w1> no; you want it to panic
<ifreund> aconbere: testing.expectEqualSlices() iirc
<ifreund> and yeah you want it to panic, that's how you trigger test failure
<aconbere> I mean I get I want a test failure :)
<aconbere> this is just surprisingly unhelpful test output
<aconbere> that's what surprised me
<ifreund> expectEqualSlices() will give you better test output
<aconbere> I would typically expect a fairly verbose statement of what had failed, what was different, the stack trace to be local to the test that failed etc.
<g-w1> i get a nice backtrace
<ifreund> this is what you get if you use the proper test function
<aconbere> g-w1: my stack is full of stuff in the std library
<aconbere> like it takes me to where the failure was, but it's not telling me a lot about how my program isn't working :)
<g-w1> ah, makes sense :)
<ifreund> that's exactly what testing.expect() does. It's an opaque bool to the std code
<ifreund> the std can't know that you are passing the result of mem.eql() on two slices
<aconbere> so I mean, my example there was just a small reproduction
<ifreund> instead using testing.expectEqualSlice() which IS then aware you are comparing slices and can print a nice message
<aconbere> in reality what's happening is that the function I was calling was returnning an error
<yyp> I wouldn't say that expectEqualSlice is that nice
<aconbere> ooo maybe not
<aconbere> maybe it's just a different enum value
<aconbere> but I couldn't tell haha
<aconbere> I think I probably want expectEqual
<aconbere> I've just been plodding along from what I read in the std library and ziglearn
<ifreund> yyp: I said can not does to be fair :P
<ifreund> as you can see there is a TODO in the function
<ifreund> expectEqualStrings is actually nice
<yyp> Let me check that
<ifreund> aconbere: totally fair, the std is certainly not well documented yet, nor is that the top priority
<aconbere> yeah expectEqual is way better
<yyp> Yep, that's really nice
<aconbere> it's cool! That's why I asked
sundbp has quit [Ping timeout: 264 seconds]
<aconbere> Maybe just to ... reply my mental model because I think it might shed some light on how expect could be better
<aconbere> I expected panics to be... unusual rather exceptional even
<aconbere> my initial concern was that my function was panicing in some way
<aconbere> I'm messing with this peekStream and readers in ways that I'm unfamiliar with
<aconbere> I looked into wether my reader was being passed in incorrectly and getting the wrong anytype
<aconbere> and poking into the wrong memory
<aconbere> I was worried that my [0..1] slice was creating some sort of weird memory
<aconbere> or an invalid call in some way
<aconbere> so the hard part for me was differentiating the panic behavior of `testing.expect` from the potential panic'ing of my own software
<aconbere> :)
<ifreund> the panic message of "test failure" should make that clear...
<aconbere> haha
<ifreund> but I guess that's probably only obvious to someone already familiar with how this stuff is set up
<aconbere> I couldn't tell if the test suite was catching the panic
<vent> I'm trying to pass a slice from std.os.argv into std.mem.joinZ, but I'm getting a type error. The compiler claims "slice type child '[*:0]u8' cannot cast into slice type child '[]const u8'". It is possible to cast a var into a const, right?
<aconbere> and being like "yo, your code panic'd thus failure"
<ifreund> vent: indeed, but a [*:0]u8 is a null terminated pointer not a slice.
<ikskuh> vent: [*:0]u8 is not a slice type but a pointer to many
<ifreund> you can iterate and find the length with std.mem.span()
<ikskuh> you can use std.mem.spanZ() to obtain a nul-terminated slice
<aconbere> ifreund: I don't think this is horrible, but I think it's useful to hear from neophytes just so we walk about the experience :)
<aconbere> s/walk/talk
<ifreund> ikskuh: don't use spanZ() here, you don't need it
<ikskuh> it removes less information from the type though
<ifreund> that's only necessary if you have e.g. an array with 0s somewhere in the middle
<ifreund> ikskuh: std.mem.span() should return a [:0]u8
ur5us has joined #zig
<ifreund> does it not?
<ikskuh> not sure
<ifreund> the doc comment says it does...
<ikskuh> yeah true
<ifreund> the code looks like it should work too, but I'm to lazy to test it
fireglow has quit [Quit: Gnothi seauton; Veritas vos liberabit]
<ifreund> ikskuh: span and spanZ have the exact same return type...
<ikskuh> ah well :D
* ikskuh stupid
<ifreund> Oh I was definitely guilty of using spanZ() without need for a while until I looked more closely :D
<ikskuh> well
<ikskuh> spanZ will guarantee you the shortest span :D
<ikskuh> i think it's actually better to use spanZ by default
<ikskuh> as you get the "expected" result when working with sentinelled data types
<ifreund> I disagree, passing a [:0] to spanZ() wastes cycles
<ifreund> you only need to do spanZ() when you have a [N:0]u8 that has early sentinels
<ifreund> I guess [:0]u8 could have early sentinels as well, but it generally doesn't
<yyp> I decided to make expectEqualSlices a bit nicer:, Unfortunately printing slices with {any} works only on Git
fireglow has joined #zig
<vent> So, I'm still a bit lost, I need to iterate through each of the args that I want to pass to joinZ, right? Should I be passing each through span and storing that slice in a seperate array, then pass that array to joinZ?
<ifreund> if you have a fixed number of args you could do mem.joinZ(ally, ",", &[_][]const u8{mem.span(os.argv[1]), mem.span(os.argv[2])})
<vent> That seems good, but I don't have a fixed number of args.
<vent> A maximum limit on the args is okay though
<ifreund> then yeah just collect the slices returned by mem.span() in a [42][]const u8 before colling joinZ()
<vent> Okay, I think I'm getting closer. joinZ is now complaining that it expected a []const []const u8 but found a [256][]const u8
<ifreund> you're just one & away, pass joinZ a pointer to the array instead
<ifreund> (which will coerce to the expected slice of slices)
<vent> Ah, yeah that's done it. But it looks like I'm getting an integer overflow in joinZ:
<ifreund> could you paste the full code?
<ifreund> vent: the problem is that joinZ is trying to join the whole array, while not all of the 42 items are defined
<ifreund> you want to pass args[0..argv.len - 1] to joinZ
<vent> Nice! Yep, that worked!
<ifreund> :)
<vent> Thanks for helping me out, appreciate it
<ifreund> no problem! one other thing you probably want to do for robustness is add a check if there are more args than fit in your buffer of length 42
<ifreund> you could also just allocate a buffer of the correct size using your fixed buffer allocator
sundbp has joined #zig
<andrewrk> mikdusan, thanks will do
<vent> Yeah, I've changed the buffer to 256 bytes. AFAIK 255 bytes is the limit for file paths on most filesystems. Although it looks like exFAT's limit is 255 UTF-16 characters, so I think I'll make it 512 bytes.
<andrewrk> vent, we have std.fs.MAX_PATH_BYTES
<vent> andrewrk: Ah awesome, using that now. Thanks.
<ifreund> vent: that's not the same as the max number of args
<andrewrk> ah my bad I did not read any context
<ifreund> I don't think there is a maximum there, just a cap on the total amount of memory argv can take
<ifreund> see the execve(2) man page for some info
<mikdusan> andrewrk: I'm working on a new ci job for macos-arm64. what do you think, should we switch to ninja?
powerofzero has joined #zig
<yyp> `var arr: [10]u8 = undefined;` makes an empty array of 10 u8s, right? Or will it crash once I try to use something?
<ifreund> yyp: using a undefined value is illegal behavior
<yyp> -.-
<ifreund> s/using/branching on/ to be more precise
<yyp> how do I create an empty array then?
<ifreund> define empty?
<g-w1> wdym empty?
<ifreund> if you want a array full of 0s: var arr = [1]u8{0} ** 10;
<yyp> Yeah, that was it, thanks!
<andrewrk> mikdusan, ninja might save a few minutes of time - go for it!
<andrewrk> yyp, if you are passing to a parameter (or other context where you have a type to coerce to) you can use this form: &.{}
<andrewrk> const empty_string_list: []const []const u8 = &.{};
<yyp> I was just wondering how FixedBufferAllocator works when you give buffer of undefined
<andrewrk> undefined bytes, or undefined pointer?
<dutchie> is &.{} now considered more idiomatic than &[_]T{}?
<dutchie> i gues it's a few chars shorter
<yyp> andrewrk: undefined pointer
<andrewrk> dutchie, it can be convenient to omit the type
<g-w1> yyp: then you get ub :)
<yyp> but it did work
<dutchie> andrewrk: true
<g-w1> wdym undefined ptr? that should segfault
<yyp> nevermind, I didn't actually use FBA
<yyp> Hm, passing &buf (buf = undefined) to Reader.readUntilDelimiterOrEof worked fine
<yyp> I honestly have no idea why
<g-w1> what is type of buf?
<yyp> [512]u8
<g-w1> it seems like the *value* is undefined which is fine
<dutchie> that's expected, the reader will do the equivalent of `buf[0] = thing i just read` so you never get back undefined
<g-w1> yeah the pointer is not undefined; the value is
<yyp> Okay, got it
<yyp> I still don't get why it could index into undefined
<g-w1> its not indexing into undefined
<dutchie> indexing is basically just pointer arithmetic, like in c
<g-w1> the pointer is totally defined; it is the addr of buf
<andrewrk> yyp, how do you know it worked fine?
<yyp> Looks like I don't understand Zig's undefined yet
<yyp> andrewrk: it read the text
<aconbere> hmmm
<yyp> nevermind, I passed undefined VALUE not a pointer
<andrewrk> I think we need to see some code to understand what's happening :)
<g-w1> undefined in zig is the same as `var buf: [512]u8;` in c
<aconbere> my peekstream does not appear to be peeking
<yyp> Problem solved: that was just me not understanding Zig yet
<g-w1> andrewrk: what is happening is they are writing into a buf that is undefined which is perfectly fine. the type of the buf is [512]u8. the ptr is not undefined, the buf is.
<cepheus> if a pointer is undefined, then dereferencing it is undefined
<cepheus> if a pointer is to an undefined value, dereferencing it is fine
<ifreund> nope, only branching on the undefined value is illegal
<ifreund> s/nope,// I didn't read well enough
<mikdusan> hmm I added a build-artifact to azure pipeline. Is there a download button somewhere?:
<andrewrk> mikdusan, IMO the less we integrate with azure for CI stuff the better
<mikdusan> yes but i need to grab it to inspect
<andrewrk> ah I'll look for ya
<yyp> I should have understood what undefined actually does or just use [_]u8{0} ** 512 instead to avoid magic :)
<yyp> Thanks everyone!
<andrewrk> mikdusan, click "BuildMacOS_arm64" and it has "1 artifact" underlined
<andrewrk> I can access it logged out
<mikdusan> oh sweet thanks!
<g-w1> andrewrk: when you have a chance, could you look at my pr again? I think I fixed the issue
<andrewrk> yep
yyp has left #zig ["TODO: come back later"]
sawzall has quit [Read error: Connection reset by peer]
sawzall has joined #zig
<andrewrk> merged :)
aconbere has quit [Ping timeout: 246 seconds]
<g-w1> hmm, if i do @setBranchEvalQuota in a lower block, then exit the block, is the higher quota still there?
<g-w1> or am I missing something, like is there a different sema per block? or a branch quota stack?
jumpnbrownweasel has joined #zig
<andrewrk> g-w1, you can only ever increase the quota, not decrease it. the quota is shared by all inline and comptime function calls for a given Decl
<andrewrk> Decl is an important concept to wrap your head around in stage2
<andrewrk> it's the "root" of ownership of memory and other things such as branch quotas
<g-w1> ah I see, every decl has one Sema
<g-w1> this would allow better multithreading too
<andrewrk> fyi is accepted now, so we can use null termination (if we want to) to save bytes in ZIR
<andrewrk> yeah I am thinking we want to be able to analyze 2 different Decls at the same time with threads
<g-w1> then the Module would be the blocking thing i guess but that can be optimised
<g-w1> it seems best to keep reliance on Module at a very minimum to reduce the amount of locks
CodeSpelunker has joined #zig
<andrewrk> yeah that's the idea
<andrewrk> that's why we don't do global string interning and global type interning
g-w1_ has joined #zig
<ed_t> I could use some advice here.
mikdusan has quit [Killed ( (Nickname regained by services))]
mikdusan has joined #zig
<ed_t> I want to go from strings like: const aPipe = "gen(100) | a: exactdiv(5) | b: fanin | console ? a: | exactdiv(9) | b:"
<ed_t> which when executed outputs: 0 5 9 10 15 18 20 25 27 30 35 36 40 45 50 54 55 60 63 65 70 72 75 80 81 85 90 95
dimenus|home has joined #zig
<ed_t> gen is function which I have in a struct (so @field can be used to find it)
cole-h_ has joined #zig
<oats> so you want to make a number processing language of some kind?
<andrewrk> step 1: tokenize, step 2: Abstract Syntax Tree
<ed_t> its sig looks like: fn gen(self:*Stage, limit:usize) callconv(.Async) !void
<ed_t> I've figured out how to create tuples with the function and args. now I need to go from the string 100 to the value. Also instead of 100 there could be a variable.
<ed_t> I am not sure how to get these values into the tupples
<ed_t> btw this uses async on each of the stages (gen, exactdiv, fanin etc)
<ed_t> it provides a easy para-dyne for using async
cole-h has quit [*.net *.split]
g-w1 has quit [*.net *.split]
dimenus has quit [*.net *.split]
knebulae has quit [*.net *.split]
<ed_t> and it gets even more fun. In that there maybe many pipes in a program, also a stage like (gen) may also contain a pipe which can be connected in various ways to the parent pipe.
jicksaw has quit [Ping timeout: 246 seconds]
<ed_t> zig's async fits pipes very well and the low level stuff (eg running the pipe etc is 'easy'). Its how to handle the the pipes and there args which is giving me headakes (std.meta.Tuple and ...ArgsTuple are handy_
jicksaw has joined #zig
<ed_t> I find it quite confusing to understand exact what zig is doing at comptime vs runtime (simple in concept, hard in understanding)
powerofzero has quit [Ping timeout: 244 seconds]
Akuli has quit [Quit: Leaving]
<ed_t> oats I want to adapt "CMS Pipelines" to zig. It cannot be an exact mapping but should be close enough to be quite useful.
<oats> well, I might be missing some details here, but have you ever written an interpreter? I wonder if following the traditional parser -> AST -> tree-walking interpreter paradigm might be simpler
<oats> why do you want to use async things?
<oats> do you need to be able to programmatically put together "pipelines" at runtime?
<ed_t> its how to get from astage(arg1,arg2...) and end up doing something like tuple[index of astage][1][1]=arg1, [astage}[1][2]=arg2 (currently [astage][0] is the stage function, and [astage][1][0]=is a pointer to a stage structure.
<ed_t> oats google cms pipelines
<ed_t> to implement that you need to use async (or threads, but async fits better)
<oats> sorry, I'm having trouble following what you're trying to do then :(
<oats> maybe someone else will have something useful
<ed_t> in the example above gen output numbers from 0 to 100, each number is passed to exactdiv, if it divides exactly its passes to fanin and then to console, if it does not exactly divide it gets passed to the second exactdiv which ignores anything that does not divide by 9 and passes the numbers that divided exact to the fanin stage.
<ed_t> (think directed graph)
<ed_t> the idea is to make the item passed anytype, so you could do things like, read a file, sort the lines, apply filters, and write the results back to a file or arraylist etc
<ed_t> oats been around quite a while (my first computer had all of 2K of ram to put it in perspective). My knowledge is more practical than anything else, I've used more languages that most (from machine code, assemblers, things like forth, to many different high level compilers and interpreters).
<ed_t> my goal here is to get pipelines so they can be used as a zig utility with a library of builtin stages and the ability to easily add your own stages.
powerofzero has joined #zig
aconbere has joined #zig
proteusguy has quit [Ping timeout: 246 seconds]
viaken has joined #zig
notzmv has quit [Ping timeout: 256 seconds]
proteusguy has joined #zig
eax has joined #zig
aconbere has quit [Ping timeout: 260 seconds]
CodeSpelunker has quit [Quit: CodeSpelunker]