ChanServ changed the topic of #zig to: zig programming language | | be excellent to each other | channel logs:
jjido has quit [Quit: Connection closed for inactivity]
btbytes has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<andrewrk> nrdmn, mmmm no, that should only be possible when exporting
<andrewrk> exporting variables needs an audit right now
MajorLag has joined #zig
MajorLag has quit [Read error: Connection reset by peer]
MajorLag has joined #zig
<daurnimator> andrewrk: welcome back :)
<andrewrk> thanks daurnimator
tgschultz has quit [Ping timeout: 248 seconds]
MajorLag is now known as tgschultz
<daurnimator> Aransentin: andrewrk: the "async stream abstraction" is sort of what I'm working on with the uring work
<daurnimator> --> currently figuring out the lower level bits. Once we get coroutines the 'nice' user API can be made.
<nrdmn> I'd like to assign an array of arrays. Currently I'm using [][2]i8{ []i8{1, 2}, []i8{3, 4} }. The inner []i8 seems redundant. Is there any way to avoid such redundancy in this example?
<daurnimator> nrdmn: I know there's an issue around for that...
<nrdmn> daurnimator: ah, thanks
<daurnimator> nrdmn: maybe throw your comment in there too. different example use-cases are nice IMO
<nrdmn> not sure if I was just overthinking that loop :D
marijnfs_ has joined #zig
<daurnimator> nrdmn: jeez, make yourself a Point() type
marijnfs has quit [Ping timeout: 268 seconds]
<daurnimator> re: point types: it would be cool if you could make aliases for array members... e.g. with a point type you often want it to be implemented with a @Vector. but you'd like to access members via 'x', 'y', etc.
<daurnimator> which I think is related to interesting thing I ran into last night: I have struct members that needs to be accessed atomically (get with .Acquire, set with .Release): I had to write getters/setters.
<daurnimator> --> is there something zig can do to make getters/setters nicer to use?
<nrdmn> aliases for array members... Isn't that just a struct?
<daurnimator> maybe some special syntax? e.g. (probably a bad idea) reading mystruct.x -> invokes `mystruct.x()`. only works for functions that take no arguments and annotated with 'getter'.
fengb has joined #zig
<daurnimator> nrdmn: struct layout in zig isn't defined for non-extern structs
<nrdmn> not even for packed structs?
<daurnimator> nrdmn: i.e. union{Vector: @Vector(i32, 2), XY:struct{x: i32, y: i32}} -> nothing says zig can't reorganise the struct!
<fengb> “Unlike normal structs, packed structs have guaranteed in-memory layout:”
<daurnimator> ah. I thought packed just meant "no padding"
<daurnimator> TIL
<AlexMax> how would a packed yet out-of-order struct even be useful?
fengb has quit [Ping timeout: 256 seconds]
<daurnimator> AlexMax: to tell zig to optimize memory usage and don't bother with alignment or making it fast to load/store members. so e.g. pointers can be unaligned. bitfields are packed as tight as possible. etc.
<AlexMax> *nods* That's fair
<daurnimator> oh, project for someone: dns packet formats
fengb has joined #zig
<fengb> Is there a way to create a strict type alias? I have 3 different types of u8s and would like to keep them distinct
<fengb> Aha
<daurnimator> fengb: what's your usecase?
<lunamn> daurnimator: your dns issue is interesting because I've been working on a zig dns parser for the last couple of days
<daurnimator> fengb: also I had an idea... distinct integer types seem like it could be similar to non-exhaustive enums..... what if `distinct(i32)` was effectively: `enum(i32) {_}`
* daurnimator leaves that as a comment
<emekankurumeh[m]> daurnimator, wouldn't that getter stuff violate "no hidden control flow"?
<daurnimator> emekankurumeh[m]: yep.
<daurnimator> emekankurumeh[m]: I was trying to come up with a different syntax for it. e.g. mystruct:x instead of mystruct.x.... which I've been meaning to propose as a resolution to
<daurnimator> oh hyrx already sort of did
fengb has quit [Ping timeout: 256 seconds]
<daurnimator> lunamn: got a link? :)
<lunamn> daurnimator:
<daurnimator> lunamn: thanks :) packet.zig isn't far from what I was thinking of
<daurnimator> lunamn: perhaps volunteer in the issue; and if it gets "approved" by andrewrk then you can send a PR?
<andrewrk> daurnimator, the packed but out of order use case you described is planned with
<andrewrk> idea being you can specify 1 byte alignment on all the fields
<andrewrk> well maybe this needs a separate proposal - but if you were able to specify sub-1-byte alignment then zig would be free to pack stuff
<daurnimator> andrewrk: how about `align(0)` -> align to anything you want, even to a bit.
<andrewrk> hmm yeah I do think this needs a separate proposal
<andrewrk> that's a good starting point, and then we need to explore how it would work in various examples
<daurnimator> andrewrk: on the topic of bit field packing... is it possible to create a struct specifying the bit offsets? would be useful for flag arguments
<daurnimator> e.g. mmapflags = struct { shared: offset(MAP_SHARED) u1, private: offset(MAP_PRIVATE) u1, ... }
<daurnimator> (actually those mmap flags are a bad example... substitute a different flags example of your choice)
fengb has joined #zig
<fengb> daurnimator: emulator. I have 8 bit registers, 8 bit memory addresses, and strings
<fengb> In C, I wrapped them with a struct so I didn't accidentally pass the wrong pointer / value
<daurnimator> fengb: you can wrap them in a struct in zig too
<fengb> Yeah but it's still clunky :P
<daurnimator> fengb: would my non-exhaustive enum idea be better?
<fengb> It's not the most obvious solution but yeah it'd work
<fengb> Although I'm actually rethinking how I'm structuring registers... so maybe it won't be a big deal
<fengb> Hmm, can you stick methods onto enums? Go lets you add methods to any custom type, even "primitives"
<daurnimator> fengb: yes. Ctrl+F isClubs
<fengb> Oh cool
<fengb> Not sure how I missed that
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jevinskie has joined #zig
coolreader18 has quit [Ping timeout: 258 seconds]
<fengb> daurnimator: welp you're right, I need metadata for this allocator
fengb has quit [Ping timeout: 256 seconds]
_whitelogger has joined #zig
jjido has joined #zig
avoidr has quit [Quit: leaving]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jjido has joined #zig
euantor has quit [Ping timeout: 250 seconds]
euantor has joined #zig
rivten has joined #zig
jjido has quit [Remote host closed the connection]
rivten has quit [Ping timeout: 256 seconds]
FireFox317 has joined #zig
_whitelogger has joined #zig
FireFox317 has quit [Ping timeout: 256 seconds]
hio has joined #zig
marijnfs_ has quit [Ping timeout: 272 seconds]
marijnfs has joined #zig
marmotini_ has joined #zig
very-mediocre has joined #zig
<merlyndmg> Yup, looks like you can't really link to a DLL without manually wrapping the definitions with: extern "somedll" stdcallcc - I decided to just compile libepoxy statically instead, and cimport start working again. Would be nice to get a version of that which let you specify the lib name (and possibly also the right calling convention).
<merlyndmg> (a version of cImport/cInclude)
Zaab1t has joined #zig
Zaab1t has quit [Remote host closed the connection]
noonien has joined #zig
<merlyndmg> ...and I got the tetris version building running on a Windows host and running. Should I do a write-up somewhere?
<merlyndmg> (well, that was redundant. super late... definitely not writing anything tonight)
marmotini_ has quit [Remote host closed the connection]
_whitelogger has joined #zig
rivten has joined #zig
heitzmann has quit [Quit: WeeChat 2.4]
heitzmann has joined #zig
halosghost has joined #zig
<andrewrk> merlyndmg, nice work. I'll look into the DLL thing at some point. seems like there may be an issue there
<andrewrk> I'm focusing on other things for now but once we have the package manager I'm going to focus intensely on the various use cases of building stuff. building things that can or cannot be packaged
<andrewrk> for the tetris example specifically all of its dependencies could be packaged and thus it should be an example that can be cross-compiled on any target for any target
Zaab1t has joined #zig
fengb has joined #zig
FireFox317 has joined #zig
<FireFox317> Hi guys! I'm new to Zig and I just build the compiler and tried to use zig fmt. I was trying to run `zig fmt -h`, because i thought that would show me the options I could use. This resulted in a segfault and a stack trace with only questionmarks. I would like to solve this issue, however I need some help. I already found out that the code for this is in 'userland' stage2 zig code, but I would like some tips to better debug this. So
<andrewrk> hi FireFox317
<andrewrk> I think your message got cut off after "So"
<FireFox317> I would like to solve this issue, however I need some help. I already found out that the code for this is in 'userland' stage2 zig code, but I would like some tips to better debug this. Sorry for this long message :)
<andrewrk> I'm happy to help. When debugging a segfault, the most straightforward way to solve the problem is with a debugger
<andrewrk> on linux or freebsd, gdb. on windows, msvc. on macos, lldb
<FireFox317> Ah okay, I'm on Linux, so I'm gonna try to use gdb. Thanks for the suggestion! I'm wondering whether the compilers zig code is built in debug or release mode?
<andrewrk> FireFox317, debug mode
<andrewrk> FireFox317, when I do `zig fmt -h` I don't get a segfault, I get an error message, and I get an error return trace that shows where the error came from
<andrewrk> ah, there is a segfault at the end of the trace
<FireFox317> Jup, it takes some time indeed
<andrewrk> the slowness is a recent regression:
<andrewrk> anyway the segfault is coming from the stack trace itself. it's not the reason for `zig fmt -h` not working. you can actually debug this without a debugger (if your goal is to implement -h)
<FireFox317> Ah i see, however in my case I don't get any text in the stack trace:
<andrewrk> FireFox317, hmm, so that's a separate problem. something to do with zig's dwarf parsing code
<FireFox317> Ah yes indeed, I'm gonna try to figure out why that is happening. Thanks for the help anyway! I really like and appreciate your project
Zaab1t has quit [Quit: bye bye friends]
Zaab1t has joined #zig
<andrewrk> thanks
<mikdusan> andrewrk: i'm adding some unit tests for stacktraces; i see that release-fast/small simply emit "error: [stringname]"
<mikdusan> and release-safe does a trace, but it's showing the same function in each frame. i'll put up a pastie in a sec.
<mikdusan> ; so is this expected stack-trace behavior for release-safe?
<andrewrk> mikdusan, look at std/special/bootstrap.zig specifically the function that calls main(), that will explain some of that
FireFox317 has quit [Ping timeout: 256 seconds]
<tgschultz> I've found a comptime bug I've never seen before. When this code is run at runtime it works fine, but at compile time it infinite loops until Linux kills it.
<tgschultz> at least I assume it is infinite, it may just be looping a lot during eval where "a lot" is fewer than 1 million and yet enough to exhaust memory.
rivten has quit [Quit: Page closed]
<tgschultz> interesting. @compileLog reports that a value is somehow magically becoming runtime during the comptime evaluation
<tgschultz> screw it, I'll just comment out the test. Who needs interfaces that work at comptime anyway?
<andrewrk> yeah one thing at a time. I can take on the issue of making those work at comptime at some point
<tgschultz> As you've probably notice, I've been particularly frustrated by comptime evaluation bugs lately. I feel these latest iterations of interface reform will have pretty much fully explored the concept of doing it in userland and put the ball in your court, andrewrk, for how to proceed. With that off my plate I'll be interacting with comptime evaluation bugs less often and my mood should improve.
<andrewrk> tgschultz, makes sense to me. thanks for your efforts
<andrewrk> I have to balance bug fixing with language modifications, because language modifications change the premises of the codebase and therefore introduce bugs
<andrewrk> it kinda makes sense to let things be a little buggy until it's time to stabilize everything
<tgschultz> I get it. And I don't even mind if all this work ultimately gets thrown out. Every time I go to rewrite my image libraries in a more zig-like fashion (streams instead of allocating large chunks of memory) I can't help but think about how poorly the the streams interface optimizes currently, so I needed to do something toward making interfaces better, even if it was just to show that the alternatives are worse.
<tgschultz> One thing I've come to realize is that the current pattern has a significant advantage in its simplicity and not relying on type erasure.
<tgschultz> Someone wrote a go program to convert ELFs to LEs. That may help my plans for using Zig with DOS.
<andrewrk> in theory the current pattern should optimize just fine. I'm not sure why it doesn't
<tgschultz> if that gets fixed, then the only significant feature of what I've done will be that it removes the common footgun, which would honestly be better handled by the uncopyable struct/field idea. ErrorSet management is still an issue, which the iteration in my current PR makes a bit easier, but I personally think that pattern is too complicated. I think it will come down to which we want more: ErrorSets that are
<tgschultz> different depending on the implementer, or a universally usable interface. Having both is, in my opinion, messy.
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
meheleventyone has joined #zig
avoidr has joined #zig
<merlyndmg> sounds good! builds on all platforms does seem like a priority that will really come into play with package management
meheleventyone has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Zaab1t has quit [Quit: bye bye friends]
very-mediocre has quit [Ping timeout: 256 seconds]
wootehfoot has joined #zig
Sahnvour has joined #zig
Ichorio has joined #zig
FireFox317 has joined #zig
<FireFox317> Andrewrk: are you going to stream tonight?
<andrewrk> FireFox317, no - I'm catching up on pull requests
<tgschultz> sadly this ELF to LE converter seems to expect some very specifically structured ELF file. Another bust.
FireFox317 has quit [Read error: Connection reset by peer]
halosghost has quit [Quit: WeeChat 2.4]
DanKHNT has joined #zig
Ichorio has quit [Ping timeout: 264 seconds]
Sahnvour has quit [Quit: Leaving]
DanKHNT has quit [Quit: Page closed]
Ichorio has joined #zig
wootehfoot has quit [Read error: Connection reset by peer]
Ichorio has quit [Ping timeout: 252 seconds]
<tgschultz> andrewrk: it occurs that the only time specific ErrorSet information is really desired from an interface is when you switch on the error, right? And specific ErrorSet information is the reason we have a differentiation between "comptime" and "runtime" interfaces and do all the convoluted stuff we do with Streams right? So... what if we just had a different channel to build that resulting error set and cast
<tgschultz> before you switch on it? We're already partly there because of what we have to do to work around error inferrence bugs. Then all interfaces could be anyerror and you'd only use the specific ErrorSet info when a) all pieces of the interface (like a chain of streams) are comptime known and b) you actually care.
fengb has quit [Ping timeout: 256 seconds]
<nrdmn> How can I copy a struct? I can't seem to find anything on that in the documentation
<merlyndmg> The docs seem to gloss over it, but I think assignment to another struct instance will copy the struct by value. Seems to work that way in the test program I just ran
fengb has joined #zig
coolreader18 has joined #zig
return0e_ has quit []