ChanServ changed the topic of #zig to: zig programming language | | be excellent to each other | channel logs:
m3t4synt4ct1c has joined #zig
_whitelogger has joined #zig
<m3t4synt4ct1c> I finally figured things out - I just had to merge in a bunch of @typeOf(package.struct.method).ReturnType.ErrorSet for all of the things I try until I had all of them in my Error set
<m3t4synt4ct1c> it's ugly, and I hope there's a better way to do it, but it compiles and appears to run correctly now
<scientes> m3t4synt4ct1c, if you use error sets too much you will crash the compiler and need my patch
<andrewrk> scientes, please don't direct new users to an unsupported zig fork in the official irc channel
<andrewrk> if there's a bug, link to the github issue
<m3t4synt4ct1c> it hasn't been crashing for me
<scientes> its a small patch, not a fork
<andrewrk> I'm not interested in arguing about definitions. I just want to make sure that new users don't get unnecessarily confused about the officially supported way to use zig
<andrewrk> anyway let's talk about productive things
<tyler569> I'd like to express how impressed I was at the experience of porting zig+the stdlib to add my hobby os as a target. Barring some annoying asm() issues, it was a thoroughly pleasant experience
<tyler569> stark contrast to C compilers :)
<andrewrk> glad to hear that. I do plan to go through your asm issues and see what can be done
<tyler569> I appreciate that, I hope you don't think I'm annoying or confrontative in them at all, just trying to communicate what I'm seeing succinctly
<Xe> is there a URI parser for zig yet?
<scientes> Xe, write it and submit it to the stdlib
<Xe> ah, i was hoping someone else would have done it already lol
<andrewrk> tyler569, definitely, I appreciate that you took the time to file issues
<scientes> xe, there isn't even ipv4/ipv6 handling yet
<Xe> scientes: sometimes you get lucky
<scientes> and ipv4/ipv6 handling is a bit tricky, the rest is straightforward
<mikdusan> andrewrk: how did your talk go?
<andrewrk> mikdusan, I think it went pretty well! hopefully they'll have the recording up soon
<mikdusan> good stuff. look forward to it.
<andrewrk> I also might have found another sponsor, so that's good for the sustainability of the project
<andrewrk> this consulting company seems to be of the opinion that they better start learning some zig now, in case it blows up in popularity, and then they can be sort of the go-to experts in that case
redj has quit [Ping timeout: 258 seconds]
avoidr has quit [Ping timeout: 252 seconds]
avoidr has joined #zig
<m3t4synt4ct1c> that's great
<andrewrk> not to be confused with the goto experts, since zig doesn't have that feature ;)
<m3t4synt4ct1c> so they're the break :label experts?
fengb_ has joined #zig
<hryx> ooooh, awesome. I'm excited to see the talk
<hryx> and for lots of new maybe support from maybe sponsor
<fengb_> Is there a list of upcoming events?
redj has joined #zig
<andrewrk> fengb_, no but I was thinking, it would be neat if there was some kind of community-editable "calendar wiki"
<andrewrk> surely something like this must exist
dbandstra has joined #zig
m3t4synt4ct1c has quit [Ping timeout: 250 seconds]
<daurnimator> Xe: URI parsing is harder than you think
<Xe> daurnimator: that's why i was hoping someone else had already done it lol
<daurnimator> and even harder if you want to support internationalized uris
<daurnimator> Xe: why do you need to parse uris? we don't even have network support yet
<Xe> i was thinking about making something as a proof of concept for a friend
<Xe> part of the olin API involves URI parsing, i think i may be able to obviate that though
<hryx> that could be a fun project even before networking
<scientes> daurnimator, IDNs are not that difficult
<daurnimator> hryx: FWIW I was planning on doing it as a showcase of the PEG stuff
<daurnimator> scientes: you think? .... turns out you need all sorts of fun tables from the unicode spec
<scientes> thats for the blacklist
<daurnimator> and... we don't have unicode stuff yet. I tried adding it, but ran into compiler issues that were on the roadmap..
<scientes> i re-wrote unicode.zig too
<scientes> and then ran into compiler issues which I fixed
<scientes> but none of this stuff ever got reviewed....
<scientes> but yeah, i didn't get unicode normalization in there
<daurnimator> scientes: you can lex with false positives if you don't have the unicode tables. but you can't parse correctly..... and yeah... false positives.
<scientes> why is false positive an issue, who wants a xn-- domain name?
<scientes> and firefox will display it that way anyways if it contains blacklisted characters
<scientes> but yeah i forgot about normalization
<andrewrk> scientes, I'm still interested in your patches if you're willing to submit them in a way that makes it easier for me to review and perform quality assurance
<andrewrk> for example, this did not answer my questions:
<andrewrk> what are you hoping I will do with that?
<scientes> It is in there because that is the most efficient place to put it.
<andrewrk> it's not enough to state something like that, you will have to provide justification that convinces others - often myself - that your statement is correct. Currently I do not share your opinion. So the default action will be to close your pull request
<andrewrk> quite frankly, if you're unwilling to put the meta-effort into pull requests, I'm not interested in them
<scientes> then it can go with the tokenizer
redj has quit [Read error: Connection reset by peer]
redj has joined #zig
<daurnimator> scientes: https://ȱ.com
m3t4synt4ct1c has joined #zig
scientes has quit [Ping timeout: 258 seconds]
hio has quit [Quit: Connection closed for inactivity]
qazo has joined #zig
qazo has quit [Ping timeout: 250 seconds]
tbodt has quit [Ping timeout: 264 seconds]
tbodt has joined #zig
dbandstra has quit [Quit: Leaving]
jevinskie has joined #zig
fengb_ has quit [Ping timeout: 256 seconds]
very-mediocre has joined #zig
hio has joined #zig
<mikdusan> o
<mikdusan> i'm trying to place a 'trait' marker on a struct by defining 'const foo = <some_trait_enum>;'
<mikdusan> having trouble checking for trait. is it possible to check struct defs[], look for one with (which is type) and compare types?
very-mediocre has quit [Ping timeout: 256 seconds]
jjido has joined #zig
m3t4synt4ct1c has quit [Ping timeout: 258 seconds]
<mikdusan> i worked around it by using a type (anon struct) as a trait marker.
TheLemonMan has joined #zig
slugm has joined #zig
slugm has quit [Remote host closed the connection]
tdc has joined #zig
<TheLemonMan> andrewrk, why was @setGlobalLinkage replaced by @extern? One may want to control the the linkage (and visibility) of other symbols too
jjido has quit [Quit: Connection closed for inactivity]
tdc has quit [Remote host closed the connection]
tdc has joined #zig
tdc has quit [Remote host closed the connection]
tdc has joined #zig
scientes has joined #zig
halosghost has joined #zig
<andrewrk> TheLemonMan: you mean @export right? What's an example symbol that worked with @setGlobalLinkage but not @export?
noonien has joined #zig
wb3 has joined #zig
wb3 has quit [Ping timeout: 256 seconds]
<TheLemonMan> andrewrk, an `extern const` that I want to declare as weak, @export works but it's quite confusing since I'm not really exporting anything
ysgard has joined #zig
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
wilsonk has joined #zig
wilsonk|2 has quit [Ping timeout: 250 seconds]
jjido has joined #zig
wilsonk has quit [Ping timeout: 245 seconds]
Barabas has joined #zig
squeek502 has quit [Ping timeout: 264 seconds]
wilsonk has joined #zig
Zaab1t has joined #zig
wootehfoot has joined #zig
<wilsonk> does zig link against dll's or only .lib's?
Sahnvour has joined #zig
_whitelogger has joined #zig
Zaab1t has quit [Remote host closed the connection]
redj has quit [Read error: Connection reset by peer]
redj has joined #zig
wootehfoot has quit [Read error: Connection reset by peer]
wootehfoot has joined #zig
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
<tgschultz> miksudan, see std.meta, in particular std.meta.hasDef() and std.meta.definitions()
<tgschultz> ugh, mikdusan ^
<tgschultz> I'm beginning to suspect I have a neurological disorder with how often I mistype things.
<wilsonk> tgschultz: did you use your win32 api package much? Ie. some examples?
<tgschultz> I haven't used it in a while, but I recall a program still working with 0.4.0 when I tested it. Anything in particular you're looking for?
<wilsonk> just wondering if you ever tried any COM interaction?
squeek502 has joined #zig
<tgschultz> that I definitely didn't. COM is all kinds of complicated and I only really used it for getting a window up, making OpenGL work, and getting input events.
<wilsonk> Ok. Yeah, I was able to get windows working with xinput and a couple other things...just not sound with dsound due to the COM interaction
<wilsonk> I also can't seem to get SDL2 to dynamically load? I put the dll next to xinput in system32 and syswow64 but it won't load? I don't understand that one
<wilsonk> Did you load OpenGL dynamically or use a .lib?
<tgschultz> Looks like I just load extensions manually through if I need them, which I don't usually because I mostly just use OpenGL to put a framebuffer on the screen. I used to use SDL2 though, I don't recall having any significant trouble getting it loaded dynamically.
<tgschultz> I just ran translate-c against the header and did a little hand editing (which may not be necessary anymore given the past year's improvements to translate-c).
<wilsonk> The header isn't the problem...literally win32.LoadLibrary(c"xinput1_3.dll"); works fine but with SDL2.dll it doesn't???! Umm, what. This libs are side by side...tried using download SDL2.dlll and built my own on this machine??? I don't understand!!!!
<wilsonk> UGH
<wilsonk> Both x86 and x64 libs are in C:\Windows\system32 and sysWOW64 respectively!!??
<wilsonk> Ok, strace says it loaded SDL2 from system32 and then immediately unloads it??
<wilsonk> Does the same with a local copy built from scratch?!?? What dark magic Windoze crap is this? Anyone have any ideas?
ysgard has quit [Remote host closed the connection]
<tgschultz> you're not linking with the stub lib at all?
<tgschultz> Have you tried using GetLastError to see why the loading failed?
<wilsonk> Nope, didn't know GetLastError existed
<wilsonk> sorry, what is a stub lib in this sense? I downloaded SDL2.dll (the x86 and x64 versions) from the website and placed them in system32 and syswow64...shouldn't that do the trick?
<tgschultz> if you arent using the header you're not using a stub lib to load SDL2.dll. Normally there's a static library that handles that for you. It should be possible to do it with LoadLibrary though.
<tgschultz> If LoadLibrary returns null, calling GetLastError will return an error code you can look up to see what the problem is.
<wilsonk> ERROR_BAD_EXEC_FORMAT? Umm, that doesn't make sense to me
shritesh has joined #zig
<tgschultz> You sure you put the right arch files in the right system directories?
<tgschultz> Assuming you're on x64 and haven't tried it, drop the x64 dll in the same directory as the executable
<wilsonk> yep, did it three times now...I am a little frustrated, unfortunately. I don't like windoze that much on the best of days but it is crap llike this that drives me crazy
<wilsonk> I can run the program in the VS debugging env and see that the libs are loaded from system32 and the local directory...but they both fail...the system32 one fails twice somehow under strace and the devenv
<tgschultz> I doubt Windows is wrong, something isn't right about the DLL. Best guess is its an arch mismatch, but I can't figure out how.
<tgschultz> or... it's possible there's a dependant VCRuntime that isn't installed?
<tgschultz> staying away from C is why I stopped using SDL2.
<wilsonk> I would love to stay away but I can't figure out how to get dsound to work so I THOUGHT this would be the easier route!!
<tgschultz> scratch that: " SDL does not depend on a C runtime at all, not even for malloc()" according to the wiki
<wilsonk> only a million people use sdl, so silly me, I assumed this would be a simple drag and drop into system32 or syswow
<tgschultz> it should be that simple. something is clearly wrong, we just don't know waht.
<companion_cube> is SDL used for anything else than games?
<wilsonk> I think some people just use it for windowing since it is cross platform
<shachaf> hi companion_cube
<tgschultz> So I just ran a quick test and I didn't have any trouble using LoadLibrary with SDL2.dll in the same dir.
<wilsonk> Ok, let me move the system one into the local dir just in case my compiled one is borked, I guess
<tgschultz> Do you still have the issue even with a minimal case that just callse LoadLibraryA("SDL2.dll")?
<wilsonk> Looks like it was a 64 vs 32 bit issue...somehow...
<wilsonk> So I guess I have the wrong dll in the wrond system dirs? Not sure how I did that, but at least it is working now (well loading at least...I am sure the pain has just is windoze after all). Thanks a ton tgschultz. Sorry for the sour tone :)
<tgschultz> well, system32 on a 64bit Windows is for 64bit dlls, and syswow64 is for 32bit dlls. That may sound backwards, and that's because it is what it is for legacy reasons. Syswow64 means "system Windows on Windows for 64bit", meaning 32bit windows dlls on a 64bit windows system. 32Bit applications actually have system32 redirected to syswow64.
<companion_cube> hi shachaf
<companion_cube> wilsonk: oh ok, like a basic UI library that works everywhere, neat
<tgschultz> then theres sysnative, another folder redirect which is how a 32 bit application could refer to 64 bit dlls.
<wilsonk> oh, well that would explain it...I am a dumb human that assumed 32 bit files would go into a system32 directory!! WOW M$ can be absolutely infuritatingly stupid at times...that is insane!!!
<tgschultz> nearly 30 years of legacy decisions for compatability have their consequences.
<tgschultz> it is not insane. MS (used to, sigh) take compatability very seriously. There are very few linux applications from 20 years ago you can, without recompilation, run today on a linux system, but you can do that on Windows.
<companion_cube> without recompilation? :o
<companion_cube> that's indeed pretty insane
<shachaf> The Linux kernel ABI is stable!
<shachaf> Just userspace is a mess.
<tgschultz> Yeah, that's an accurate statement.
<tgschultz> One of the reasons zig is distributed as a static binary for linux.
<shachaf> Unfortunately you have to use userspace libraries for some things.
<andrewrk> notably, graphics
<shachaf> Yes, talking to the GPU is one of the main ones.
<tgschultz> It's a bit dumbfounding to me that X, supposedly a protocol, requires linking with specific libraries.
<shachaf> I think you had a plan to use your own dynamic linker to use some GL libraries without the rest of the system?
<tgschultz> or was that requirement from GL? I forget
<shachaf> The only way GLX is exposed is as libraries.
<tgschultz> Windows has its own GL mess with only officially supporting 1.1 and needing to load everything else.
<shachaf> And those libraries take an Xlib Display * so you have to use Xlib for that even if you implement the protocol yourself.
<tgschultz> I feel like computing doesn't have to be this hard...
<shachaf> It sure doesn't.
<shachaf> (And yet.)
<companion_cube> wayland is there, though
<shachaf> Is the situation with Wayland any better?
<companion_cube> I think so, it's supposed to have a simpler API than X?
<companion_cube> (also, fasteR)
<wrl> in windows, since the GL context creation func doesn't take any attributes (so you can request a specific version), and GL extension functions can't be loaded without a GL context...
<tgschultz> It's differently worse, I think.
<wrl> it means you need to create a context, bind it, then lookup the "create a context but with attributes" func so you can create the *actual* context you want to use
<wrl> and then you unbind the old context and free it
<wrl> windows is a barrel of fun
<andrewrk> I think I have to agree with tgschultz's conclusion on wayland
<wrl> i'm not sure i'd say "worse" but it's definitely not perfect
<wrl> none of the windowing environments right now are anywhere close to perfect
<wrl> and whichever one somebody thinks is "least bad" really depends on their personal preference and alignment with their own personal priorities
<andrewrk> yeah, that's a pretty universally true statement about anything :)
<hryx> No stream today I assume?
<andrewrk> yeah rescheduling to tomorrow at some point. Just got home and need to do some household chores
<hryx> cool cool
halosghost has quit [Quit: WeeChat 2.4]
mindfv has joined #zig
wootehfoot has quit [Read error: Connection reset by peer]
shritesh has quit [Quit: Segmentation Fault]
Aruseus has joined #zig
<wilsonk> tgschultz: still had problems actually using functions from SDL2.dll (I could load the lib but would get an undefined symbol to SDL_Init, etc.) So I converted the .dll to a .lib, linked it with --library "complete_path_to_SDL2.lib", and now I can use tiehuis' zig-sdl2 lib without issues. Just thought I would mention it here so that others can see a solution (also searchable on whitequark)
<andrewrk> wilsonk, side note - once is done, I think it would be reasonable to directly use @cImport of sdl headers without zig-sdl2 bindings project
<wilsonk> Ah, ok cool
<wilsonk> andrewrk: have you tried to access an COM objects with zig code?
<andrewrk> I have not
<wilsonk> ok, no problems
<andrewrk> the self hosted compiler does this by having .cpp code do that and export a C API
<andrewrk> given that zig can build C code (and planned to build c++ code as well) I think that would be a reasonable approach
hio has quit [Quit: Connection closed for inactivity]
<wilsonk> ok, maybe I will look at the way it does that if this SDL thing doesn't work out the way I am thinking :)
mindfv has quit [Quit: Leaving]
<Aruseus> Hello all. I'm very new to zig, and I have a question. Does the standard library have a function that prints formatted output to stdout? So, basically std.debug.warn(), but with stdout instead of stderr? I didn't find anything like that in the documentation.
wilsonk has quit [Ping timeout: 258 seconds]
<andrewrk> Aruseus, const stdout_stream = &;
<andrewrk> try stdout_stream.print("hi: {}\n", x);
<andrewrk> if you're writing to stdout, it's no longer a "warning message", it becomes more important to handle, e.g. if stdout was a pipe that got closed, or if writing failed
wilsonk has joined #zig
<andrewrk> you can thank the Windows API for why has a possible error
<Aruseus> ok thanks. yeah that works. that's basically what I came up with as well. it just seems a little verbose
<andrewrk> yep. that's one of the concessions zig is willing to make in general - being verbose
<andrewrk> this issue is relevant though:
<Aruseus> at least it makes it clear that it can fail I guess, unlike C's printf
<andrewrk> the resolution of both of these issues could potentially impact this use case
<tgschultz> wilsonk, not sure what you were trying to do, but after you LoadLibrary you need to lookup the addresses of the funtions you want to use with GetProcAddress and bind them to a predifind function signature. If you were using my win32 library you'd find this difficult since I somehow didn't have GetProcAddress defined in it. I'll update that when I get home.
ltriant has joined #zig
<wilsonk> tgschultz: yeah, I added my own GetProcAddress but must have still been doing something wrong. I might take another look at it, but I just wanted a quick solution so I could test out an idea I have with SDL. Thanks for the win32 library bindings though, they have been really helpful. Things have gone pretty smooth until this SDL stuff ;)
<wilsonk> *still must have been..
Sahnvour has quit [Read error: Connection reset by peer]
qazo has joined #zig
jjido has quit [Quit: Connection closed for inactivity]
Barabas has quit [Ping timeout: 256 seconds]