ChanServ changed the topic of #zig to: zig programming language | https://ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
<andrewrk> pixelherodev, do we have an issue open for this "bring your own OS layer" concept?
ur5us has quit [Ping timeout: 245 seconds]
lunamn_ has joined #zig
lunamn has quit [Ping timeout: 276 seconds]
<marler8997> I'm not sure why I'm getting the "lld:error: unable to find -lC" in this example: https://gist.github.com/marler8997/a1334511af6aeef63f4e8aeb2c507417
<marler8997> maybe it's just my environment? does this work for anyone else?
<andrewrk> marler8997, -lc vs -lC
<marler8997> zig run --library c test.zig and zig run --library C test.zig give the same result
<marler8997> also, when I use --verbose-link, it shows a command with "lld" but it looks like it's actualy running "cc" (when I look at strace, since lld is not a program in my PATH)...is this an error?
<mikdusan> marler8997: old version of zig or master?
<marler8997> master
<marler8997> 0.5.0+cb38bd0a1
cmrs has quit [Quit: ZNC 1.7.1 - https://znc.in]
ur5us has joined #zig
<andrewrk> marler8997: zig doesn't shell out to anything, not cc, not lld
<andrewrk> It does run itself in a child process, however
<marler8997> ah I see
<marler8997> now makes sense why I can't find the exec call :)
<andrewrk> It's in link.cpp
<marler8997> any idea about the lld error about missing -lC?
<andrewrk> It's -lc not -lC
<marler8997> I'm not specifying -lC
<marler8997> I'm just running zig run --library z test.zig
<marler8997> --library c (not z)
<andrewrk> In your code you are
<mikdusan> yeah i have a partial dup of it. also seeing "-lC"
cmrs has joined #zig
<andrewrk> extern "C"
<marler8997> ooooooo
<marler8997> thank u!
ur5us has quit [Read error: Connection reset by peer]
<andrewrk> Np
* mikdusan facepalm
<marler8997> derp
<mikdusan> I blame seeing `extern "C"` for years in that _other_ language
<marler8997> yes, I've been poisoned by the Dark side
<fengb> There’s always redemption
<mikdusan> the zig way to redemtpion is through PRs. many PRs.
ur5us has joined #zig
shodan45 has quit [Quit: No Ping reply in 180 seconds.]
<frmdstryr> Is there something like a "noasync" keyword?
cmrs has quit [Ping timeout: 276 seconds]
cmrs has joined #zig
lunamn_ has quit [Quit: leaving]
cmrs has quit [Quit: ZNC 1.7.1 - https://znc.in]
cmrs has joined #zig
<frmdstryr> Also it appears that reading using the inStream doesn't work with the evenloop?
<frmdstryr> It just immediately exits with in std.os.read with EBADF
<andrewrk> frmdstryr, EBADF means your file descriptor is invalid
<andrewrk> and yep zig has a noasync keyword. currently it works on function calls only. more support is planned: https://github.com/ziglang/zig/issues/3157
<frmdstryr> Do you still have the chat code from your video a few weeks ago?
<frmdstryr> Replace the self.file.read(&buf) with a stream and it'll the give EBADF error
<frmdstryr> gives a more interesting error
<frmdstryr> which probably explains it better
<frmdstryr> Or that's more likely unrelated
<andrewrk> I'll be back in a bit
protty has joined #zig
<frmdstryr> If I use os.read in an @asyncCall it works but not using file.inStream().stream
<frmdstryr> Also works if using file.read in an @asyncCall
<frmdstryr> So the only thing I can see here is that the file handle copied file to the instream is wrong
<frmdstryr> readHandle: 2496776
kapil_ has joined #zig
<frmdstryr> Pretty sure this is due to #591
lukeholder has joined #zig
<frmdstryr> The handle and ptr from the inStream fn is "inStreamHandle: handle=15 at 140725463643632" but in the InStream.readFn it is "Instream readFn: handle=2496712 at 139681109254640"
lukeholder has quit [Quit: Textual IRC Client: www.textualapp.com]
lukeholder has joined #zig
lukeholder has quit [Max SendQ exceeded]
lukeholder has joined #zig
<daurnimator> frmdstryr: you need to take the addresss on line 49
<mikdusan> also if you look at andy's gist ust use self.file.read directly
<daurnimator> and if we merge stream mixins you'll be able to work on the file directly as well
<frmdstryr> So it should be "var stream = &self.file.inStream().stream;" ?
<frmdstryr> I want to use the readUntilDelimiter fn's
<daurnimator> frmdstryr: yep. or `const`.
<frmdstryr> That worked... can you explain why?
<daurnimator> frmdstryr: by doing `var stream = ` you made a copy of the stream member: which means its no longer in its struct. and hence you hit https://github.com/ziglang/zig/issues/591
<frmdstryr> Ah, ok. Thank you!
<andrewrk> hmm, I think with a couple more copy elision bug fixes, the codebase will be at a point where we can add compile errors for moving immovable fields
muffindrake has quit [Ping timeout: 276 seconds]
muffindrake has joined #zig
<companion_cube> andrewrk: are you familiar with ruby/crystal's blocks? They serve the same purpose as (some) closures, but (at least in crystal) are always inlined and can embed control flow structures, so you can `foo.each { |x| break unless x>0 }` or stuff like that
<companion_cube> it's a nice middle ground between full closures, and no higher-order constructs at all
[rg] has joined #zig
chemist69 has quit [Ping timeout: 250 seconds]
<andrewrk> companion_cube, yeah, I used ruby at a company I used to work for
chemist69 has joined #zig
<companion_cube> (check out crystal, it has typing and is fast)
<[rg]> reading documentation, what is meant by using stderr over stdout in the hello world
<[rg]> also how exactly is this portable, unless most os support these streams
<mikdusan> it's showcasing how `warn()` does not require error handling with `try`. versus `try stdout.print()` (or even `try stderr.print()`)
<mikdusan> as for portability, I suppose if an OS does not support streams, you'll either get an error, or if using warn() you'll never get an error. dealer's choice
<[rg]> thanks mikdusan
<andrewrk> it's planned to rename std.debug.warn to std.log.warn
<andrewrk> ooh nice all the prereqs are done for this issue
<andrewrk> this issue is now contributor friendly
<mikdusan> andrewrk: the last merge #3743 you did, it shows as "Merge branch ...." where as one I did shows as "Merge pull request #3776..." in commit logs,
<mikdusan> is this because you did a few edits?
<mikdusan> ie: local workstation, then push.. as opposed to github buttons
<andrewrk> mikdusan, yes in this case it was because I merged the branch locally and pushed
<andrewrk> I didn't make any edits in this case other than rebasing against master (so that there was only 1 merge commit into master, rather than an additional merge master into the branch)
<andrewrk> but the reason I had it checked out locally was just to run the tests on windows
<mikdusan> thanks. I'm just trying to understand the logs WRT merges of multiple commits, their timestamps, etc.
ltriant has quit [Quit: leaving]
<[rg]> is the documentation under the respective version all their is?
ky0ko_ has joined #zig
ky0ko has quit [Disconnected by services]
ky0ko_ is now known as ky0ko
ur5us has quit [Ping timeout: 250 seconds]
<mikdusan> [rg]: there is https://github.com/ziglang/zig/wiki/FAQ and at top it has link to std library docs too (latter is pretty new)
<[rg]> thanks again mikdusan !
lukeholder has left #zig ["Textual IRC Client: www.textualapp.com"]
lukeholder has joined #zig
protty has quit [Remote host closed the connection]
<lukeholder> ziggy the ziguana: https://jmp.sh/OX4JW5r
<daurnimator> andrewrk: 3155 though not everything I wanted was still mergable I think
<daurnimator> mmmm, maybe not because of the > TODO: check for un-encodable utf-8 first
[rg] has quit [Ping timeout: 260 seconds]
lukeholder has quit [Quit: Textual IRC Client: www.textualapp.com]
lukeholder has joined #zig
ur5us has joined #zig
mahmudov has joined #zig
<andrewrk> lukeholder, it's so good
<andrewrk> I definitely think he looks more like a ziggy than the other one
<andrewrk> the other one needs a different name
LargeEpsilon has joined #zig
<daurnimator> andrewrk: feedback on 3715 addressed.
reductum has quit [Quit: WeeChat 2.6]
ur5us has quit [Ping timeout: 250 seconds]
ur5us has joined #zig
return0e has joined #zig
ur5us has quit [Ping timeout: 245 seconds]
Pursche01 has joined #zig
lukeholder has quit [Quit: Textual IRC Client: www.textualapp.com]
LargeEpsilon has quit [Ping timeout: 268 seconds]
LargeEpsilon has joined #zig
return0e has quit []
return0e has joined #zig
return0e has quit [Remote host closed the connection]
return0e has joined #zig
return0e has quit [Remote host closed the connection]
return0e has joined #zig
return0e has quit [Ping timeout: 245 seconds]
return0e has joined #zig
vexu has joined #zig
Pursche01 has quit [Quit: Connection closed for inactivity]
protty has joined #zig
lukeholder has joined #zig
dimenus has quit [Remote host closed the connection]
<dom96> if anyone here is interested in talking about Zig at FOSDEM, today is the last day you can submit your talk to the Minimalistic, Experimental and Emerging Languages devroom. (https://forum.nim-lang.org/t/5577)
protty has quit [Remote host closed the connection]
waleee-cl has joined #zig
mahmudov has quit [Remote host closed the connection]
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen1 has joined #zig
dingenskirchen1 is now known as dingenskirchen
Akuli has joined #zig
<mq32> fengb: YAPL? :D
<fengb> I kinda like to learn about these other low level languages
<fengb> Oof, the C interopt syntax is pretty bad
<fengb> `fgets(s pointer #As("char *"), size int, stream pointer #As("FILE *")) pointer #Foreign("fgets")`
<mq32> oof
nairou has joined #zig
<fengb> I spy hidden allocations >_>
<mq32> it's weird how much syntax of a language changes the feeling of language
<mq32> being a bit more verbose than muon doesn't hurt, it's really hard to navigate without syntax highlighting
<nairou> Does zig's std lib have any string-to-number conversions yet? Like atoi() in C. I see std.fmt to do number-to-string, but I'm not seeing the opposite.
<fengb> Zig's old sigil based syntax scared me away. I don't think I'd enjoy it half as much
<mq32> fengb, yeah, old zig code also looks weird
<mq32> Nairou: std.fmt.parseInt would be a candidate
<fengb> There's also std.mem.readInt*
<nairou> Oh nice, thanks
<mq32> what i really dislike about some programming language projects is the focus. i see a lot of "i wanna do a programming language, so let me create syntax and a language server first"
<mq32> i think focus should be on creating a good, well thought programming language and not on a toy with perfect tooling
<fengb> On HN, they're complaining that new languages don't have perfect tooling lol
<fengb> I'm happy on how Zig is developing. There's a lot of churn but for good reasons
<companion_cube> tbh LSP should make it a lot easier to have decent tooling
<mq32> yeah, true
<mq32> but i'm still on the side "first: have a good language, then: have good tooling"
<companion_cube> I think the second can sometimes inform the first
<companion_cube> e.g. have easy, non ambiguous syntax, cause that helps making tooling
<companion_cube> (heyooo C++)
<mq32> heh, but simple grammar is also part of a good language
<mq32> the ability to tokenize zig by-line is a great example for good syntax
<companion_cube> I'd say it's nice to be able to tokenize context free, but well :)
<companion_cube> I like languages that are whitespace insensitive
<mq32> yeah true
<mq32> that's a point about zig i don't like, but i can live with that, as zig fmt fixes it
<companion_cube> has https://arewesimpleyet.org/ been discussed it? NIH is strong there :D
<mq32> git: WE OVERDID IT
<mq32> lul
<companion_cube> I mean, it's people who think C is too bi̵g… :D
<fengb> I'm really starting to hate the word "simple". It basically means whatever you want at this point
<fengb> Simple software in practice: Unicode
<fengb> o_O
<mq32> fengb: unicode is imho a hard requirement for most software today
<mq32> and utf-8 isn't the most simple encoding sadly
<mq32> but it's the most practical
<companion_cube> it's pretty simple still
<mq32> yeah, true
<companion_cube> you can do a lot of things as if it were ascii
<companion_cube> and still have it work
<fengb> Unless you deal with counting characters
<mq32> and you don't have to think about UTF-8 unless you do substrings and output
<companion_cube> (lots of things = tokenizing, line splitting on the wire, etc.)
<companion_cube> or capitalization
<companion_cube> if you have to _transform_ the text in a meaningful way, yeah, unicode matters
<fengb> Runes? Codepoints? I always forget the right terminology
<companion_cube> codepoints, then grapheme clusters I think
<companion_cube> if you really want to think about how stuff is displayed
<fengb> I love that I can delete a family emoji one person at a time
<nairou> o_O
<fengb> Anyway, my point is that C is simple for a compiler writer but really complicated for actual use due to all the footguns
<fengb> So calling it "simple" is technically true... but also not necessarily too helpful
<companion_cube> is it really that simple for a compiler writer, though? :D
<fengb> And everyone's pet tool is "simple", and all other competitors are too complex for "bad reasons"
<nairou> And C left way too much undefined, implementation specific
<companion_cube> you could have something even simpler that has a reasonable grammar :p
<fengb> Yeah, the spec was super vague becasue it was helpful for random compileers to match spec
LargeEpsilon has quit [Ping timeout: 276 seconds]
<fengb> ANSI was at least. Not sure if newer specs have more stringent reqs
<mq32> fengb: runes are this: ᚠᚢᚦᚩ
<mq32> C isn't simple for a compiler writer
<mq32> it is a type 1 language (whereas C++ is actually type 0)
<mq32> you cannot decide context free what "a * b;" means
<nairou> C++ is type WTF
<mq32> you can write C++ code where the semantics of the program is defined by the result of a turing machine
<mq32> so: evaluating C++ code to determine its semantics is actually the halting problem
<mq32> but even parsing C code isn't that trivial
<mq32> you need to know what symbols are valid to determine if something is a declaration or an expression
<companion_cube> I wouldn't mind a C-like lang with sum types and basic generics, like Myrddin
<mq32> "a * b;" can be the declaration of a pointer variable "b" that is a "pointer to a" or if it's a multiplication of "a" and "b"
<companion_cube> sadly it's hard to get traction
<Pistahh> in C it is also "funny" when someone accidentally writes 'char* a,b' :)
<companion_cube> -_-
<mq32> Pistahh: oh yeah :D
LargeEpsilon has joined #zig
vexu has quit [Quit: WeeChat 2.6]
<mq32> on C and weird syntax: https://stackoverflow.com/a/2000491
lukeholder has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<mq32> the whole thread is worth a read, but this one is kinda great :D
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen1 has joined #zig
dingenskirchen1 is now known as dingenskirchen
casaca has joined #zig
<Snektron> test
<Snektron> ah, matrix was acting up again
mahmudov has joined #zig
mikdusan has quit [Ping timeout: 265 seconds]
LargeEpsilon has quit [Ping timeout: 265 seconds]
return0e_ has joined #zig
return0__ has quit [Ping timeout: 265 seconds]
lunamn has joined #zig
return0e has quit [Remote host closed the connection]
return0e has joined #zig
quetzalb has joined #zig
return0e has quit [Remote host closed the connection]
return0e has joined #zig
soulofdeveloper has joined #zig
return0e has quit [Client Quit]
wootehfoot has joined #zig
FireFox317 has joined #zig
Ichorio has joined #zig
vexu has joined #zig
soulofdeveloper has quit [Quit: Leaving]
reductum has joined #zig
mikdusan has joined #zig
riba has joined #zig
wilsonk has quit [Ping timeout: 265 seconds]
wilsonk has joined #zig
cmrs has quit [Quit: ZNC 1.7.1 - https://znc.in]
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
cmrs has joined #zig
riba has quit [Ping timeout: 276 seconds]
ur5us has joined #zig
<jonathon> I'm confused with what I'm doing wrong with iterating over an array of structs: https://godbolt.org/z/A75vXg . I've tried with 0.5.0+7de138ad7 .
nairou has quit [Remote host closed the connection]
<jonathon> Accessing an element of the array directly does what I'd expect it to. Accessing as part of a for loop seems to do something odd with pointers?
<andrewrk> jonathon, godbolt's a.out output does not agree with your comment
Akuli has quit [Quit: Leaving]
<andrewrk> the code looks fine
<jonathon> whuuuu
<jonathon> OK :explode:
<jonathon> I have no idea what my local copy is doing wrong, but at least I know it _should_ work... :/
<andrewrk> it works for me locally too
<andrewrk> however valgrind does complain
<andrewrk> jonathon, oh, your payload1 variable is stack-allocated
<andrewrk> you could fix this by making it `const` and running the new function at comptime
<andrewrk> jonathon, you should practice running this with valgrind right now though, it would have helped a lot
<andrewrk> because you would see that it's also problematic on line 23 as well
nairou has joined #zig
<andrewrk> the problem is that payload1 is runtime-known. and so [_]TopicPayload{payload1} is also runtime known, which makes it stack allocated. i'm actually right in the middle of making this a compile error
<andrewrk> the question to ask yourself is, "where in memory is the []const TopicPayload pointing to?"
<mikdusan> just going to point out: [_] is an array (inferred-size but still an array). and the fn returns a *slice* of that array. a slice has no storage except {ptr,len} fields
<jonathon> Hmm... the snippet was supposed to be a minimally-working example of the error but that example does "work" locally, so somewhere in the rest of my code it's doing something else.
<mikdusan> sometimes undefined behavior "works"
<jonathon> Thanks both, I'll get my head round this type of programming at some point...
<andrewrk> jonathon, what OS are you on?
<jonathon> Linux
<andrewrk> do yourself a favor and run your code in valgrind
<andrewrk> valgrind ./test
<andrewrk> you'll gain 1 system programming level-up just by running this command once and looking at the output
<jonathon> Yeah, I have been doing, but the full code is where the issue in the comments happens, even within Valgrind
<andrewrk> hm. well let me see if I can finish up this branch, it might help you debug, since it will give you f resh compile errors for all your arrays that get coerced to references :)
<jonathon> Awesome :D
nairou has quit [Remote host closed the connection]
LargeEpsilon has joined #zig
LargeEpsilon has quit [Ping timeout: 250 seconds]
qbradley has joined #zig
FireFox317 has quit [Ping timeout: 240 seconds]
vexu has quit [Quit: WeeChat 2.6]
<emekankurumeh[m]> since we have anon structs perhaps we could use them for closures?
<jonathon> Oh, I missed that there is std.Arraylist... >.< That should do the job.
quetzalb has quit [Remote host closed the connection]
qbradley has quit [Remote host closed the connection]
<andrewrk> jonathon, just keep in mind that any references you have to elements become invalid when you change the size of an array list
<mq32> andrewrk, you wrote that *any* architectures are in scope of your assembler project
<mq32> i'm throwing in the parallax propeller architecture :D
<andrewrk> good
<mq32> i recommend you taking a look at it, as the official assembler syntax is quite special
<jonathon> Will do. I think I should be fine for this instance, I'm passing a pointer to an ArrayList(struct) to a function, appending some items to the target ArrayList, then iterating through the ArrayList.toSliceConst()... Valgrind doesn't complain at least... :D
<mq32> it has a configurable instruction set which means you have some kind of "particle bits" you can add to every function
<mq32> stuff like "execution", "write result", ...
<mq32> so you have something like "sub a, b" which can be used as a compare instruction by discarding the result with the "nowrite" particle and "w_z" particle for "write-zero-flag"
ur5us has quit [Ping timeout: 250 seconds]
kapil_ has quit [Quit: Connection closed for inactivity]
ur5us has joined #zig
<frmdstryr> Taking len on an empty buffer makes an integer overflow error
<mq32> frmdstryr, read the documentation on initNull
<mq32> i stepped into the same API trap
<mq32> you have to call resize first
<frmdstryr> Hmm... thanks
<mq32> yeah, it's a kind of footgun, but i can understand why that is needed
wootehfoot has quit [Quit: pillow time]
<frmdstryr> Can I add a timeout on an async call? Or somehow cancel at a later time?
<frmdstryr> It looks like the event loop uses infinite timeouts... so there's no way to prevent a DOS
frmdstryr has quit [Remote host closed the connection]
frmdstryr has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
qbradley has joined #zig
casaca has quit [Ping timeout: 268 seconds]
clktmr has joined #zig
mahmudov has quit [Remote host closed the connection]