return0__ has quit [Read error: Connection reset by peer]
<andrewrk>
mikdusan, can we merge #4650?
<mikdusan>
yup
<andrewrk>
ok great, and freebsd is still excluded from blocking download page updates until it turns green, and then I'll revert c0c9303bd63468afe146ad729cf963ee06a1777f
<wilsonk>
hmm, I just pulled the newest master branch, rebuilt with 'make install', then tried to rebuild a project and got 'glibc/sysdeps/unix/sysv/linux/include/bits/syscall.h:3:10: fatal error: 'misc/bits/syscall.h' file not found' ... that file seems to be generated during the build process (according to bits/syscall.h). Anybody know what might have caused this? Or has anyone else run into this today?
<andrewrk>
short story is to rm -rf /home/wilsonk/Downloads/zig/build/lib/
<wilsonk>
ah, ok
<andrewrk>
glibc got updated, and it depends on a certain file *not* existing
<andrewrk>
but `make install` doesn't delete files
<wilsonk>
worked, thanks :)
<mikdusan>
ok #4653 should allow srht to get waay past `zig build install` now
<mikdusan>
(when merged that is)
<mikdusan>
hmm I should just rebase it
adamkowalski has joined #zig
adamkowalski has quit [Client Quit]
dimenus has quit [Remote host closed the connection]
redj has quit [Read error: Connection reset by peer]
redj has joined #zig
AndroidKitKat has quit [Remote host closed the connection]
AndroidKitKat has joined #zig
slurpie has quit [Ping timeout: 260 seconds]
<cncl>
hi, sorry if this is a dumb question. i tried to play around with zig a couple of months ago, but it was in the middle of some changes (string formatting, maybe?) that caused lots of examples to break. is now a better time to try it?
<mikdusan>
each binary tarball includes a copy of the same docs you see online, matching binary version exactly so there shouldn't be any example-breakage
slurpy has joined #zig
slurpy has quit [Remote host closed the connection]
slurpy has joined #zig
slurpy has quit [Client Quit]
slurpy has joined #zig
slurpy has quit [Client Quit]
waleee-cl has quit [Quit: Connection closed for inactivity]
slurpie has joined #zig
ur5us has quit [Ping timeout: 240 seconds]
mahmudov has quit [Remote host closed the connection]
<daurnimator>
cncl: maybe? we've got a release coming up on april 13; that would be a prime time to give things a try.
alichay has joined #zig
edr has quit [Ping timeout: 260 seconds]
<squeek502_>
daurnimator, we can talk here if that'd be helpful instead of going back/forth in the github issue
<mikdusan>
daurnimator: why would you expect fmt to escape an enum-literal ?
return0e has joined #zig
M-ou-se has quit [Quit: WeeChat 2.1]
M-ou-se has joined #zig
jjido has joined #zig
dddddd has quit [Ping timeout: 240 seconds]
return0e_ has joined #zig
M-ou-se has quit [Quit: WeeChat 2.1]
M-ou-se has joined #zig
M-ou-se has quit [Client Quit]
M-ou-se has joined #zig
<daurnimator>
squeek502_: hey
<squeek502_>
hi
<daurnimator>
mikdusan: `enum { foo, bar, @"with spaces" }`
<daurnimator>
squeek502_: so realpath is inherently racy
<daurnimator>
you need to do it inside of the `open` call.
<daurnimator>
(on windows essentially everything is done by opening)
<daurnimator>
e.g. to delete a file you open a file; set a flag that says "delete this file when I close it" and then close the file handle
<squeek502_>
not sure i follow, what is this relating to?
<squeek502_>
#4655 or #4658?
<daurnimator>
squeek502_: 4655
<squeek502_>
which open call?
<squeek502_>
the open within readFileAlloc?
<daurnimator>
yep
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<squeek502_>
so you're saying readFileAlloc should handle the path resolution on its own?
<daurnimator>
yes
<daurnimator>
also io.readFileAlloc is deprecated; should use `fs.cwd().readFileAlloc` instead.
<squeek502_>
right
<squeek502_>
it does seem like there needs to be a decision about what's valid to pass to the various fs functions, its unclear if `.\file` is expected to always be a valid input to any fs function on Windows or if it should be resolved before certain fs functions
<daurnimator>
indeed
<daurnimator>
on linux the only u8 values *not* allowed in a path component are '/' and '\0'. on windows the only u16 values *not* allowed in a path component is '\'. Even the null bytes is permitted!
<daurnimator>
On posix systems (including linux), `.` and `..` are reserved by the system. On windows you can actually just call a file `..`
<ArtifTh>
<daurnimator "on linux the only u8 values *not"> While NT kernel will eat such paths, shell will complain
<daurnimator>
ArtifTh: yep
<daurnimator>
ArtifTh: the question ends up being: when I input a path into a shell, what does the user expect it to be? and sadly the answer isn't consistent
FireFox317 has joined #zig
<daurnimator>
I think the best we can do is probably reimplement RtlDosPathNameToRelativeNtPathName_U_WithStatus and use it on user-entered paths
mforney has quit [Ping timeout: 240 seconds]
mforney has joined #zig
mahmudov has joined #zig
mforney has quit [Excess Flood]
mforney has joined #zig
<squeek502_>
daurnimator, RtlDosPathNameToRelativeNtPathName_U_WithStatus seems to be equivalent to `std.fs.path.resolveWindows` in terms of how it handles symlinks (i.e. it doesn't)
<daurnimator>
squeek502_: I guess you're right. Sadly that's very different to how things work on linux :(
<daurnimator>
So we come to the age old question of cross-platform compatibility
mahmudov has quit [Ping timeout: 260 seconds]
<daurnimator>
TheLemonMan: I might send a PR to your PR about the TEB
mahmudov has joined #zig
mahmudov has quit [Max SendQ exceeded]
mahmudov has joined #zig
slurpie has quit [Ping timeout: 240 seconds]
<daurnimator>
why the hell am I wasting time on windows stuff again? >.<
<alexnask>
"wasting" lol :D
<daurnimator>
I don't even use windows
<daurnimator>
(the answer: I'm doing this for attracting a good user community.... without windows support people avoid open source projects; so unfortunatly someone has to get it working)
<alexnask>
I use it thanks for wasting your time on it %%
<alexnask>
^^ *
<daurnimator>
alexnask: I'm so deep though that I'm at the stage that no one cares lol
* mq32
is looking forward for 1.0 and then introducing Zig in his working place for the sake of better software
<daurnimator>
e.g. I'm 15 minutes into googling if the `Name` member of `TEB_ACTIVE_FRAME_CONTEXT` is pointer to a u8 or u16 string
<daurnimator>
no one even knows what that structure is
<alexnask>
lol
<alexnask>
looks like some frame context of some kind /s
<daurnimator>
even the name is out of a debug symbol file that microsoft accidentally published one day
<daurnimator>
that also seems to have disappeared off the net since I last had it
<daurnimator>
looks like its a PCSTR deep down? though that's off someones interpretation of a summary of someone else's dump. so fucked if I know
FireFox317 has quit [Remote host closed the connection]
<mq32>
ah, i see andrewrk is playing "metaprogramming - the game" *grin*
<mq32>
have fun with Baba!
<daurnimator>
hmmm. @compileLog is printing my `[]const u8` as: `[]const u8{78,116,84,105,98`
<alexnask>
Yes this is annoying
<alexnask>
If you do an operation on a string literal it will then print it like that. If you just store the string literal it will print the string
<daurnimator>
I'm trying to print `@typeInfo(x).Struct.fields[0].name`
<alexnask>
Weird, works for me in a trivial example
<alexnask>
What is x?
<daurnimator>
my new TEB definition
<alexnask>
Is it just defined like `const x = struct { ... };`?
<daurnimator>
yep
<alexnask>
Hmm that is weird, @typeInfo literally just calls create_const_str_lit and init_const_slice to copy the names
<alexnask>
Which I would expect to result in a string print
_Vi has joined #zig
mahmudov has joined #zig
qazo has joined #zig
FireFox317 has joined #zig
FireFox317 has quit [Quit: Leaving]
dddddd has joined #zig
mahmudov has quit [Ping timeout: 240 seconds]
GoorMoon has joined #zig
frmdstryr has joined #zig
GoorMoon has quit [Remote host closed the connection]
metaleap has joined #zig
waleee-cl has joined #zig
<metaleap>
daurnimator: "without windows support people avoid open source projects" thats one sentence i'd like to send back a decade+ in time :D
<metaleap>
(together with ms buying github, cross-platforming .net, doing WSL, being a world major linux hoster (with the cloud stuff) and in general doing all sorts of prep work to be able to finally sunset that frail geriatric overdue and increasingly hapless zombie called "windows" =)
<companion_cube>
isn't windows still strong in companies?
<companion_cube>
(and gamers, but well)
<BaroqueLarouche>
it is
<companion_cube>
it's notable that crystal's 1.0 is delayed mostly because its windows support is weak
<metaleap>
sure. a big fat tanker doesnt turn on a dime but takes almost-imperceptably long to do so.. it's not dead. just very gently being helped on its way into hospice :P 2cts anyway.
<BaroqueLarouche>
sure, stay in your 1% bubble 😛
<fengb>
I left Windows 12 years ago and I'm happier for it
<BaroqueLarouche>
I was a Linux user and developer from 2004 to 2009, had to use Windows for university, and slowly never look back. Used Mac OS X for a while
<fengb>
But you still can't ignore that it's still around and will probably be forever
<companion_cube>
yeah, and microsoft is doing pretty well these days
<metaleap>
haha well i'm a bit tainted by a 10-month project in a windows-based and .net-based corp coming to a close. this whole stack really has no future, it's already cobol. the dev stuff AND the os.
<shakesoda>
i'm running windows 7 right now
<shakesoda>
re-upgraded from the hunk of junk that is 10
<companion_cube>
I have a windows 10 at home, mostly for steam
<BaroqueLarouche>
I lke Windows 10 to be honest
<shakesoda>
w10 is the most unpleasant os i have ever used :(
<shakesoda>
buggy, slow, full of ads, it hates me and i hate it back
<shakesoda>
it's not without any redeeming qualities whatsoever, but it frustrates me to no end to deal with it
<fengb>
People still sometimes talk about how XP was the golden age
<shakesoda>
2000 was the best
<shakesoda>
i still keep a win2k vm with a bunch of patches on it for later software compatibility
<metaleap>
and all i meant is the only investment i see from MS in "developer stuff" (the sort of impetus that did propel their OS to dominance in the first place) is all over the place except windoze
<BaroqueLarouche>
Windows 7 was really good
<companion_cube>
well they know that the OS isn't where the battle is fought anymore
<companion_cube>
it's about Azure, .net, github…
<fengb>
I'm kinda disappointed being a 90s kid in tech. 80s had some great hardware hackery, and same with the current landscape. But 90s was the epitome of Wintel bleh
<metaleap>
yeah but the only thing that held it up was battling. when it comes to intrinsic qualities? inertia is what keeps it alive-looking today
<shakesoda>
my biggest recurring problem with 7 is just that vsync is really spotty and unreliable
<metaleap>
which means they leave the orig core to come to a natural conclusion over time and do the needful to soften the process .. my impression
<fengb>
I didn't realize how much I missed not having a Commodore or Apple 2 :(
<shakesoda>
fengb: i really miss macos 8/9 and early (ppc) osx
<BaroqueLarouche>
if only Commodore management wasn't so bad
<mikdusan>
fengb: ProDOS ooooh shiny
<shakesoda>
been thinking about picking up a candy mac off ebay for such reasons
<fengb>
Windows is here to stay, unless Chromebooks (or ... actual linux...) can capture the everyday user
<fengb>
I was never a Mac guy before Intel+OSX. But I meant more of hackability in general. DOS / Windows did not include useful tooling for consumers
<shakesoda>
or the also likely scenario that people use computers/laptops ever-less and do yet more on phones and tablets
<fengb>
Javascript was jawdropping for a kid learning programming. That's just sad compared to what we had in the 80s
<shakesoda>
a surprising amount of my students do not own computers and also have little interest in having them
<BaroqueLarouche>
shakesoda: which age group ?
<shakesoda>
BaroqueLarouche: groups from 12-18
<metaleap>
shakesoda: i hope this trend keeps up so that the "coding" bubble will revert to a good natural-sized sub-cultural population of actual-aficionados
<shakesoda>
* 13
<BaroqueLarouche>
that's sad :(
<fengb>
Not really? 90% of people don't need actual computers to get things done
<mikdusan>
so how are they going to write up essays... with a PEN and PAPER? what!
<shakesoda>
well, the people interested in more technical stuff end up with them still, but there's a very obvious divide (once again)
<companion_cube>
how do you program without computers, though?
<shakesoda>
mikdusan: the school provides chromebooks for doing that, but you should *see* them type on phones!
<fengb>
Most people don't program
<shakesoda>
any one of them can write their essays that way lol
<companion_cube>
ah well, probably people will need computers less, for sure
<fengb>
Honestly, I'd rather see more Chromebooks. The amount of tech support I had to provide to my parents and brother... ugh
<metaleap>
i want programming to return to its proper status of "uncoolest thing ever" dammit. it was the real golden age. few bullshitters, few eggshells, pure capabilities-based cross-inspiration
<fengb>
Back in my day, I was beat up for using computers. And I liked it!
<shakesoda>
chromebooks are nice, but they impose some real limitations :\
<companion_cube>
just write in cobol, no one will look at you as being cool
<shakesoda>
I teach 3d modeling, and the things are less than worthless for it
<daurnimator>
metaleap: the eternal september is unfortunatly eternal
<shakesoda>
I had to scrounge up the last of the proper desktops in the entire school to run the class
<daurnimator>
I am very much in a minority now of not having a phone
<shakesoda>
and I do mean every one of them
<shakesoda>
daurnimator: haven't heard someone mention that in a while
<companion_cube>
wow, I don't even want to imagine how administrative life would be for me without a phone :(
<companion_cube>
it's asked everywhere with a "required" field
<metaleap>
daurnimator: thats related but slightly different. eternal september is forever but it could shrink back to "newbies but coming from affinity"
<shakesoda>
i don't answer phones and pretty much only use mine for some time wasting games and 2fa lol
<daurnimator>
companion_cube: uh, I should say: smart phone
<metaleap>
my smartphone aids me greatly as an alarm clock and the weekly mom call. same as the dumbphone did
<companion_cube>
ah I see.
<companion_cube>
I do use the map occasionnally, too :/
<mikdusan>
phone: texting/photos/videos; everything else give me a keyboard
<daurnimator>
everything can wait until I'm at a keyboard :P
<daurnimator>
or its important+immediate enough that voice is better
<fengb>
Voice is never better >_>
<companion_cube>
:D
<metaleap>
shakesoda: with your nostalgia for win2k you must surely be already following the serenityOS duder
<fengb>
I have social anxiety
<shakesoda>
metaleap: i am not
<shakesoda>
fengb: +100
<shakesoda>
voice is never, ever better for me either, between that and some other issues (i.e. hearing problems)
<metaleap>
shakesoda: he's trying to rekindle dat 2000 feel from scratch, so next time you're idling you know where to look
<shakesoda>
sounds noble
<fengb>
Other than my mom and my wife... I don't think I've talked on the phone for a year
<fengb>
And honestly, I'll be glad once they replace cashiers with robots >_>
<daurnimator>
I generally dont' like driving unless I'm on the phone....
<mq32>
<daurnimator> I am very much in a minority now of not having a phone
<metaleap>
fengb: jeez how come? dont you find humans the most amusing of mammals to observe and entertain?
<mq32>
I have a smartphone since about 3 months now and wasting waaay too much time with it atm
<shakesoda>
fengb: won't that be wonderful
<companion_cube>
me too, I'm reading too much HN
<mq32>
<fengb> I have social anxiety
<mq32>
is it weird for a hardcore nerd to have the opposite of social anxiety?
<shakesoda>
mq32: i feel like the hardcore nerds are split oddly down the middle on this
<shakesoda>
either unusually strong anxiety or the exact opposite
<fengb>
I'm like borderline. I need human contact but simultaneously hate it
<mq32>
hm. i had "quarantine" the last two weeks because of a cold and i'm now starved of social contacts
<shakesoda>
i've been known to go many months without any human contact besides roommates
<metaleap>
from a distance everyone appears like an NPC for most of the time so if you ever played games with humanoid creatures instead of turtles beetles dragons or orks there's nothing to be anxious about..
<fengb>
covid :o
<fengb>
I get super lonely... but I also can't talk to people worth shit. It's the best of both worlds!
<fengb>
metaleap: I'm always scared to mess up my dialog tree in games
<daurnimator>
/bed
<companion_cube>
I got into social dancing 2y ago, and it's awesome
<fengb>
Good night!
<mq32>
<companion_cube> I got into social dancing 2y ago, and it's awesome
<shakesoda>
fengb: i always want to get the dialogue trees right in games too so i end up save scumming them every time
<mq32>
social dancing as in couple dance?
<companion_cube>
yeah, swing dancing
<mq32>
neat!
<metaleap>
fengb: thats a weird meta-phenomenon in the human sphere where the only way to really mess up dialog is by worrying about this very possibility. yeah it only hit me very late as well
<shakesoda>
unfortunately, i can't save scum them irl, very inconvenient
<companion_cube>
I had just moved to the other side of the world and was lonely :)
<mq32>
i'm active standard and latin, two to three times a week, for a couple of hours. best counterpart to sitting in front of a computer
<fengb>
metaleap: yes I know that. I just don't believe it. I spent too much of my stats on int, not enough on wis
<shakesoda>
fengb: i describe myself in such terms as well
<shakesoda>
"i put all my skill points into int and art and none anywhere else"
<fengb>
FreeBSD build: `wget: unable to resolve host address 'ziglang.org'`
<fengb>
More fun stuff! -_-
<shakesoda>
mq32: my "get away from the computer for a while" is the class i teach weekly
<mq32>
shakesoda: teaching what?
<shakesoda>
3d modeling
<mq32>
ah, nice. modeling with clay or at the computer? *grin*
<shakesoda>
at the computer, but i'm not the one doing the modeling :)
<mq32>
ah :D
<shakesoda>
i did reduce my sitting at the desk time quite profoundly when i started drawing every day though, that's been a relief
<mq32>
yeah, dancing is really nice to be maximum away from a computer. just music and people
<fengb>
Music and people... sounds dreadful
<fengb>
:P
<shakesoda>
dunno why you'd want people to ruin perfectly good music!
<shakesoda>
:D
<fengb>
I need to find some social thing to do. I go to random tech meetups... but those are the worst lol
<shakesoda>
I, for one, am quite happy with this form of socializing
Akuli has joined #zig
<alexnask>
on smartphones: the trick is to crack your screen enough that it's annoying but not enough to make it completely useless
<companion_cube>
😂 life hacks
<shakesoda>
one of my friends has a record of doing that to 75% of his phones and he solves it with a layer of clear tape so he won't cut his fingers on it
<alexnask>
Would not recommend enough cracking to cut yourself when using it :P
<shakesoda>
you'd think, at this point, he'd just cover the screen with something proactively so this won't happen
qazo_ has joined #zig
qazo has quit [Ping timeout: 260 seconds]
<shakesoda>
metaleap: serenityos is neat, if only it weren't c++ :(
<shakesoda>
i will watch it but stay away from getting too deep in the guts of it
<metaleap>
we're in agreement on the c++ point, but i enjoy his coding vids & commute talks for sure.. when downtime
<companion_cube>
well, what else could have he used?
<metaleap>
still a down-to-earth old-skooler =)
<companion_cube>
I mean it's C++17 he uses, I think
<shakesoda>
c, at the least
<shakesoda>
c++ makes things more complicated pretty much automatically
<metaleap>
also avoids the stdlib and handcrafts according to personally-chosen restrictions (which seems fairly common to many cpp endeavours from what i gather)
<shakesoda>
that's at least fairly responsible
<shakesoda>
i poked around and it's still full of c++-isms that make code more complicated, though
return0e_ has quit [Ping timeout: 255 seconds]
<shakesoda>
inheritance for ui widgets etc -> you've already lost
<companion_cube>
well I think he wouldn't be nearly as productive with C
<shakesoda>
disclaimer: i'm a bit extra salty about c++ making life automatically hard due to my recent work fixing some incredibly complicated system
<shakesoda>
said system isn't especially bad, but my goodness is it a complicated maze
<metaleap>
in the end zig will be a great candidate for this sort of thing. i mean you can so smoothly code in like the "base" pattern that `ast` uses when you really need it , it stays self-contained understandable and doesnt infect outwards, yet you get the *actual* latent "productivity-boost(ish)" inheritance-ish flavour you did actually need in that one spot. sorted, solved, done.
<companion_cube>
yeah, Zig will be nice, it's just not ready yet
<shakesoda>
I've already started moving my game engine parts to zig
<shakesoda>
it won't exactly be the production one for a long while yet, but it's just so much more pleasant to deal with
<metaleap>
comptime really lets you "patch up the language surgically in just the few spots here & there that would truly benefit" but cleaner & more maintainable than macros
* shakesoda
isn't very into comptime and uses it sparingly
<companion_cube>
I don't think serenityOS uses macros much
<metaleap>
companion_cube: if C it would have to tho
<shakesoda>
c macros are less nasty than... most c++ features...
<companion_cube>
metaleap: exactly, so… no C
<shakesoda>
how sad is that
<companion_cube>
I don't agree, lambdas and auto and templates are better than macros :D
<metaleap>
sure in c++ you pick the pattern that fits the need, sometimes inheritance, sometimes templates etc.
<shakesoda>
lambdas and auto are indeed nice
<shakesoda>
metaleap: once you use inheritance you've already lost
<shakesoda>
;)
<companion_cube>
inheritance is useful in some particular cases, imho
<companion_cube>
it's just not a good "default" behavior
<companion_cube>
it's a specialized tool
<companion_cube>
(like, open recursion/visitor pattern)
<metaleap>
shakesoda: i really mean more "base-class-ish kinda thing" --- if you dig into the std/zig/ast.zig scheme (search for `base` and how all the specialized `Node`s have that field, and `Node` itself refers to fieldParentPtr) you'll get what kind of bare-bones "embedding=inheritance-ish" i had in mind. no full-blown multiple-levels-with-overrides inheritance
ave_ has quit [Quit: Connection closed for inactivity]
<metaleap>
i picked the wrong name probly for what i had in mind
<shakesoda>
companion_cube: i'm reasonably convinced class hierarchies were devised by demons to make code unknowable
<metaleap>
but otoh this pattern is all i ever did use "inheritance" in oop langs for! =)
<shakesoda>
you can design something better every single time without having it try to magically bring in functionality
<shakesoda>
especially in c++, which has so many of its own complicated rules if you interact with any of this stuff
<companion_cube>
shakesoda: ah yeah, agreed
<companion_cube>
but one virtual class for behavior + implementations to reuse that code, why not
<shakesoda>
there are certainly times where it can be a useful tool, but I do believe you can *always* do better
<shakesoda>
and you shouldn't do it through multiple levels
<shakesoda>
I've not actually missed lacking it even once when using languages that do not provide this, I've been left happier without that entire class of things that can go wrong.
<fengb>
imo, inheritance is a pretty poor way of sharing behavior and definitely lousy for sharing interfaces
<fengb>
And it's unfortunate that most people interpret OOP = classes / inheritance
<shakesoda>
fengb: but really, oop is the entire gang of ideas designed for the sole purpose of making your solutions to problems be convoluted! ;)
<shakesoda>
fwiw though, lambdas are *the* feature that make me reach for c++ over c when I do
<fengb>
Nah, things like generic array lists are fundamentally OOP based
<fengb>
And... most implementations wouldn't use inheritance
<companion_cube>
generic array lists, OOP? why?
<shakesoda>
yeah I'm not following that line of thought either
<shakesoda>
but also, I strongly favor specific over generic implementations until I need otherwise
<fengb>
Not sure about functional languages, but even the C implementation of a list would look like OOP patterns
<shakesoda>
people jumping right to generic ones for everything is a huge cause of needless complexity :\
<fengb>
And I don't mean inheritance. The type of polymorphism that you're exploiting is a lot more OOP than functional
<companion_cube>
hmmm for me an arrayList is just a template/generic
<fengb>
Or if you don't like that term... interface based design
<companion_cube>
if typeclasses are OOP… then mostly everything is OOP?
<fengb>
No... but you can code OOP in a functional language
<shakesoda>
to be a tool of that does not make it the thing itself
<fengb>
Except Elm (lol)
<shakesoda>
just like my kitchen knives are a tool for cooking and not murder, although i could totally stab someone with them
<companion_cube>
well if OOP is having interfaces, then, damn
<shakesoda>
and oop here is the murder, not the cooking ;)
<companion_cube>
for me OOP is more about dynamic dispatch
<fengb>
Well... Zig has OOP in comptime and allocators :P
<metaleap>
btw "offtopic" (not, but off-thread) a quick curiosity question, what linker is used by zig to turn llvm's final ir-to-object output into the final binary executable/library --- does it "bundle" an existing one (as it'd be foss C code anyway), use llvm's linker as-a-library, or call out to whatever is expected on the current local os?
<companion_cube>
comptime is OOP? wow
<shakesoda>
but neither comptime nor allocators are oop
<companion_cube>
just means "OOP" doesn't mean anything anymore fengb :p
adamkowalski has joined #zig
_Vi has quit [Ping timeout: 272 seconds]
<fengb>
It can be used for OOP yes. Like duck typed methods
<companion_cube>
it doesn't check my definition of "dynamic dispatch" tho
<companion_cube>
by far :p
<fengb>
And allocators are definitely OOP. You define an interface and implement it per instance. That's basically classical OOP in a nutshell
<shakesoda>
you're really, really conflating the "can be used for" with "is"
<fengb>
I'm not saying Zig is an OOP language. I'm saying it has facilities to enable OOP style programming
<fengb>
C doesn't... but you can still do OOP in it
<shakesoda>
you keep pretty specifically saying things are oop, which is not the same as saying you can use them _for_ oop
<shakesoda>
the semantic difference is pretty big, heh
<fengb>
Well... allocators are definitely oop. Comptime can be leveraged for oop style dispatching
<shakesoda>
anyways, i must go work, please don't make complicated designs where they aren't needed :D
<companion_cube>
glib is OOP in C, and it's a thing of horror
<adamkowalski>
what do you all mean by oop fengb. do you just mean polymorhpism?
<adamkowalski>
I feel like a lot of people associate other traits with it such as encapsulation
<companion_cube>
polymorphism is also an overloaded word :(
mahmudov has joined #zig
<adamkowalski>
and being able to substitute the child class for the parent
<adamkowalski>
I feel like if we break it apart into the constituent compoentns you all would agree
ave_ has joined #zig
<adamkowalski>
we have runtime and compile time polymorphism in zig
<fengb>
I generally refer to "oop style" with substitutable objects without breaking the contract
<adamkowalski>
but when I think of oop I specifically think of paying for a runtime dynamic dispatch
<metaleap>
oop = overload/override pragmatism =)
<adamkowalski>
if you are using templates, comptime arguments
<adamkowalski>
thats not runtime
<fengb>
But our allocator interface has runtime cost
<adamkowalski>
true
<fengb>
And it's a standard interface and shareable across most of the codebase
<companion_cube>
so you mean subtype polymorphism, ok
<adamkowalski>
allocators are using runtime polymorphism with dynamic dispach
<adamkowalski>
I'm saying you all are right
<companion_cube>
^ this is OOP indeed
<companion_cube>
comptime, not that much
<adamkowalski>
just OOP is such an overloaded word that it loses meaning
<companion_cube>
comptime is dependent static typing
<fengb>
It is... but I really want to hammer in oop != inheritance
<fengb>
Because Go's oop interface{} is structural interfaces, which has no inheritance but probably works better
<adamkowalski>
i mean we can call it what we want but allocators use something akin to inheritence
<adamkowalski>
they just store the base class as a field rather then "inherting" from it
<shakesoda>
inheritance is merely the most sinister evil created in oop's already evil name
<adamkowalski>
under the hood it's the same thing
<fengb>
Or Obj-C / Swift protocols
<adamkowalski>
the base pointer still points to the base class
<fengb>
Or Erlang actors
<metaleap>
in the end its just streams of bits we're bickering about here, if you wanna take a reductionist stance (it _sometimes_ helps)
<metaleap>
so what linker is used by zig to turn llvm's final ir-to-object output into the final binary executable/library --- does it "bundle" an existing one (as it'd be foss C code anyway), use llvm's linker as-a-library, or call out to whatever is expected on the current local os?
<fengb>
metaleap: hey no being on topic. We need more flame wars
<metaleap>
neat. i noticed how nicely self-contained zig is, it's much appreciated. no dependencies to worry about for those just diving in and exploring
<fengb>
Yeah definitely. It's really amazing to download a single binary and have it just work
<metaleap>
"even though incremental linking is a perfect fit for zig's debug builds" so this raises in me another newb question: i had the impression that zig turns all *.zig files coming into play into one giant llvm module, is this the wrong impression?
<metaleap>
because in that case it would seem to me that incremental linking would not benefit a giant-single-module approach (except when extern / C deps / lib refs come into play too)
<mikdusan>
metaleap: yes, I would think incr-builds are going to make sacrifices for it's #1 priority: freakishly fast builds
<companion_cube>
curiosity: what about builds that don't take too much ram? whenever building *on* a raspberry pi, a VPS, etc.
<companion_cube>
a lot of big C++ programs can't build at all without N GB of ram
<fengb>
Debug builds would benefit greatly from splitting up modules. It could be a flag for release builds too
<metaleap>
mikdusan: so there'd be introduces some sort of "splitting algo" of "many disparate *.zig files forming a single project, into some (lesser) number of however-still-multiple llvm-modules~=.o-files"? or is my equation there off?
<mikdusan>
companion_cube: iirc there was talk of being very flexible in that area. first, we'll take more care on free as compared to almost-dont-care-in-stage1, and second if you think about incr-builds, those atoms may be good candidates to actually have ability to _intelligently_ swap out
<companion_cube>
not relying on actual swap, I hope?
<metaleap>
or i guess every build.zig container could form the basis of an independent module/.o -- have only just now considered that possibility :D
<mikdusan>
companion_cube: exactly. by intelligent I mean not using the OS generic swap
<companion_cube>
good, cause having swap enabled is the best recipe to freeze this kind of small computer :p
<fengb>
We can't split generic functions though so it wouldn't be as simple
<mikdusan>
i probably shouldn't use the word swap. too much implication there. it's really just save an "atom" (not really a term) to disk. that could be our .o fragment. and load it when needed.
<companion_cube>
right, right.
<mikdusan>
combining this with the robust zig-cache and I imagine it will be fabulous
<companion_cube>
I think the use cases might be disjoint
<companion_cube>
one is building on a small system, once (when you install a program)
<companion_cube>
one is when you're developing, hopefully not on too small a machine, and when build time matters a lot more
<metaleap>
one thing i wonder about this whole LLD discussion (both the incremental and the mach-o topics), doesnt the whole C++ / Clang space care about this at all? or do they skip lld altogether albeit using llvm-ir still
<metaleap>
llvm has this aura of "it must be robust enough for clang & c++ inside and out" :P
<fengb>
Maybe that’ll get less true over time as Rust, Zig, etc. start pressuring it
adamkowalski has quit [Ping timeout: 256 seconds]
<companion_cube>
rust made apparent a lot of optimizer bugs in llvm, it seems
<companion_cube>
(the ones related to aliasing)
<mikdusan>
I feel like LLVM-IR lacks something (not sure what) in their model to deal with aliasing
o_O has joined #zig
o_O is now known as Guest31273
<companion_cube>
(I mean, lack of aliasing in this case)
Guest31273 has quit [Client Quit]
metaleap has quit [Ping timeout: 256 seconds]
return0__ has quit [Read error: Connection reset by peer]
<jessermeyer>
Are those flags posix permissions flags, even if I'm on Windows?
adamkowalski has quit [Ping timeout: 256 seconds]
marmotini_ has quit [Remote host closed the connection]
<jessermeyer>
What is the reason why an absolute Win32 path like "C:\\path\\to\\file.txt" results in: error: invalid character: ':'?
<alexnask>
jessermeyer, Where is this function from? (I assume os.Dir?) The API has changed in the latest commits I think
<jessermeyer>
To my second question: @embedFile
<jessermeyer>
To my first question, I think I was looking at os.file()
<jessermeyer>
Yeah I noticed a lot of FS changes on master.
<jessermeyer>
Man, @embedFile is just awesome.
<jessermeyer>
@embedFile returns a pointer to the data segment right?
<alexnask>
It returns a comptime u8 array
<jessermeyer>
But is that stored on the stack or in the data segment?
<alexnask>
It will end up in the data segment
<alexnask>
Unless yo uexplicitly copy it to a stack variable or something
<jessermeyer>
Visual Studio clued me in: unsigned char[1525]*
<jessermeyer>
So I wonder if the documentation should reflect it's really a pointer to a data segment array.
<alexnask>
This is not quite true though. Yes, assigning it to a const or a global will make the data appear in a segment array
<alexnask>
in the data segment*
<mikdusan>
it never gets to data segment if you use it only in comptime context
<alexnask>
This is just how comptime semantics work
<alexnask>
The docs are correct to just say it returns a comptime array
<jessermeyer>
Aaah
<jessermeyer>
Does comptime code execute after linking occurs? e.g, can I call a function from a linked shared library at comptime?
<alexnask>
No
<jessermeyer>
=(. That would've been magical.
<jessermeyer>
I guess the loader is the one specifying the addresses at execution time.
<alexnask>
Lexer -> parser -> comptime execution -> generated IR -> llvm IR -> object files -> linker this is a simplified pipeline I believe
<jessermeyer>
That's sort of what I figured.
<alexnask>
It would technically be possible to call functions from shared libraries at comptime but it's not supported by design
<jessermeyer>
Well, can a shared library be loaded at comptime and immediately used?
<jessermeyer>
Ha.
<jessermeyer>
By design ... why?
ur5us has joined #zig
<fengb>
Zig doesn't have an ABI so no
<jessermeyer>
I see.
<alexnask>
Its a design decision (not saying that implementing it would be easy either way)
<jessermeyer>
I guess we'll see how powerful comptime becomes come 1.0.
<mikdusan>
#1291 is open for a comptime allocator. If that gets done ... std.DynLib is your friend :)
<jessermeyer>
Obviously it's hugely powerful if you stay within Zig.
<jessermeyer>
exactly!
jjido has joined #zig
<jessermeyer>
Why is @embedFile's return type null terminated?
<fengb>
We should split that to @embedFileZ
<jessermeyer>
Agreed
<fengb>
We converted string literals into zero-terminated when we removed c-strings
mixi has quit [Quit: quit]
mixi has joined #zig
<fengb>
You and mq32 both have encountered some problems with @embedFile so maybe we should do something else
<andrewrk>
what's wrong with the type being null terminated?
<jessermeyer>
I'm about to confirm or deny the problem. I'm passing a byte array as a shader to Vulkan, and I don't think it's expecting a 0 byte hanging on the end, but it may not care.
<jessermeyer>
This byte array is really just a .spv binary blob sitting on disk.
<jessermeyer>
Is the equivalent of a reinterpret_cast in Zig @alignCast(@ptrCast())?
<andrewrk>
I don't understand, why would vulkan read past the end of the buffer?
<andrewrk>
it's either null terminated, or you're passing a length. I don't see how there can possibly be an issue
<jessermeyer>
Ok, so .len does not count the null terminator?
<andrewrk>
correct
<jessermeyer>
OK, I don't expect there to be an issue.
<andrewrk>
that's the benefit of the sentinel being in the type itself; the len can be correct
<jessermeyer>
Is the size of a null terminated type different than a non null terminated type?
<andrewrk>
the size of a pointer is always 8 bytes on 64 bit architectures, 4 bytes on 32 bit architectures
<jessermeyer>
Roger that.
marijnfs has joined #zig
<marijnfs>
is there already some serialization functionality?
<marijnfs>
with the new struct stuff it should be quite easy
<andrewrk>
I think a few people have written some stuff, as far as I recall nothing landed in std lib
<metaleap>
marijnfs: a quick grep on $ZIGDIR/lib/std on serialize shows some sort of generalized binary serialization stuff in io.zig, never tried it tho
<metaleap>
`Serializer`: "Creates a serializer that serializes types to any stream.", also has a `Deserializer` in there. and tests in std/io/test.zig
<metaleap>
(the latter likely only in the zig repo, not your zig installation)
<marijnfs>
metaleap: hmm I see the serializer, let me see
<marijnfs>
looks interesting
<marijnfs>
I there a buffer stream or something?
<marijnfs>
in fact, where is Stream defined
<fengb>
lib/std/io.zig and lib/std/io/*.zig
<marijnfs>
ah yeah, it can sometimes get pretty confusing to figure out how something is used in zig
<andrewrk>
you should be able to follow the decls in a straightforward path, unless `usingnamespace` is used, which is not the case here
<andrewrk>
you don't have to know the type of something to know where it is declared
<jessermeyer>
Getting a weird stall from attempting a kind of reinterpret cast on Windows.
<companion_cube>
andrewrk: thanks!
<jessermeyer>
if I pause execution I see I'm stalled in cmpxchgWeak in acquireSlow() from debugWarn()
<andrewrk>
yeah in this case though it's not really being used as an "interface" as daurnimator was pushing for, it's really just that all these arch files happen to want to expose the same API
<jessermeyer>
But the first time I attempt the type / align cast it succeeds just fine??
<fengb>
@alignCast does a runtime check to make sure it’s actually aligned. Maybe it was coincidentally aligned in the first invocation?
<jessermeyer>
Possible. But the debugwarn shouldn't stall out at least?
<jessermeyer>
BTW, how should I do this reinterpret_cast kind of logic in Zig?
<jessermeyer>
I'm forced to view these u8s as u32s as per the Vulkan spec.
<fengb>
You could do std.mem.bytesAsSlice
<fengb>
And possible annotate the byte array to align(4)
ur5us has quit [Ping timeout: 240 seconds]
<jessermeyer>
Like var vert_shader_bytes align(4) = @embedFile("shaders\\triangle_vert.spv"); ?
<jessermeyer>
I aligned the bytes array but that alone wasn't sufficient. I'd like to avoid reaching into the standard library for this problem. I would hope this would be possible with bare Zig.
<fengb>
Oh hmmm... those should be aligned already
<jessermeyer>
Well the return type on those are based on u8s, not u32s.
<jessermeyer>
So I think it's at least documentation to state the alignment on those up front.
<andrewrk>
so you did `var vert_shader_bytes align(4)` and then `vert_shader_bytes` wasn't aligned to 4 bytes?
<fengb>
Or maybe not. Maybe x86 compactifies the data section so you end up with misalignment
<andrewrk>
if you can confirm that then it's clearly a bug
<jessermeyer>
I'm checking that now.
<jessermeyer>
But I think vert_shader_bytes in this case is a pointer, so we're asking Zig to align the pointer, not to align the read, right?
<andrewrk>
if you're not sure what the type is and you want to be sure what the type is, give it a type
<jessermeyer>
Ok, I think I have evidence it is not aligned.
<jessermeyer>
var frag_shader_bytes align(@alignOf(u32)) = @embedFile("shaders\\triangle_frag.spv"); --> address is 0x00007ff7e3c9610d -> base10 -> 140702655275277 is odd.
<jessermeyer>
Did I make a mistake in specifying the alignment?
<fengb>
@embedFile returns a pointer
<andrewrk>
fengb, not according to the docs
<jessermeyer>
It's a comptime array, so it's complicated what it returns.
<jessermeyer>
In my case, the data is used at runtime, so it does return a pointer to the data segment.
<andrewrk>
yeah docs are wrong. I think it's good actually that it's basically the same as a string literal
<fengb>
mq32 proved it to me the other day heh
<andrewrk>
jessermeyer, slap a .* on there and call it a day
<fengb>
I think at some point it returned an array because I also thought the same thing
<andrewrk>
the docs are wrong *and* the ir.cpp code is misleading
<andrewrk>
yeah it used to return an array
<jessermeyer>
I'll try the .*, but the pointer mis-align _is_ still a Zig bug, right?
<fengb>
No, []u8 only aligns to 1 naturally. You need to convince it to align(4)
<andrewrk>
jessermeyer, do you realize that you were mistaken about the type of frag_shader_bytes? you thought it was a value but it was a pointer
<andrewrk>
s/you/we/
TheLemonMan has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<jessermeyer>
I've known it was a pointer, but I didn't quite realize how best to specify its alignment. You can see alexnask and I hashing this out earlier.
mahmudov has quit [Ping timeout: 265 seconds]
<fengb>
You can't realign pointer addresses, but you can dereference and realign the contents at comptime
<andrewrk>
you don't want the pointer itself to be aligned, you want the memory contents it points to to be aligned
<jessermeyer>
Exactly.
<andrewrk>
if you had done `var frag_shader_bytes: []align(4) u8 = @embedFile(...);` then you would have gotten a compile error
<jessermeyer>
Good lesson.
<andrewrk>
also if you were calling a zig function rather than a translated-c vulkan function, you would have gotten a compile error at the callsite
<andrewrk>
basically zig was never given enough type information to help
<jessermeyer>
Roger that. So I really was just lucky the first ptrCast succeeded.
jjido has joined #zig
<andrewrk>
or, from my opinion, unlucky :)
<jessermeyer>
I value that opinion ;)
<fengb>
Maybe we could have the compiler force worse-case-alignment in debug modes :P
slurpie has quit [Ping timeout: 256 seconds]
<jessermeyer>
Ok, one last test for understanding. Am I unlucky the following works, or have I successfully got the contents realigned?
<jessermeyer>
var frag_shader_bytes = @alignCast(@alignOf([*c]const u32), @embedFile("shaders\\triangle_frag.spv"));
<jessermeyer>
I think I'm unlucky.
jrl has quit [*.net *.split]
diginet has quit [*.net *.split]
cow-orker has quit [*.net *.split]
nickster has quit [*.net *.split]
commander has quit [*.net *.split]
wtw has quit [*.net *.split]
andrewrk has quit [*.net *.split]
jessermeyer has quit [Remote host closed the connection]
jrl has joined #zig
diginet has joined #zig
cow-orker has joined #zig
andrewrk has joined #zig
wtw has joined #zig
commander has joined #zig
nickster has joined #zig
diginet has quit [Max SendQ exceeded]
diginet has joined #zig
slurpie has joined #zig
<TheLemonMan>
BaroqueLarouche, yo, the problem is in your code
<BaroqueLarouche>
TheLemonMan: any idea what"s wrong ?
<TheLemonMan>
IndexedStorage declares a huge PaletteSize, the resulting structure overflows the stack
<TheLemonMan>
are you sure you don't want 1 << log2(bitsizeof(T)) ?
<fengb>
Hey I had the same problem earlier this week >_>
<BaroqueLarouche>
TheLemonMan: no, I really want 1 << bitsizeof(T)
<TheLemonMan>
indeed, forget what I said
<TheLemonMan>
maybe I should have named zig_probe_stack something else, if_you_see_this_you_have_a_stack_overflow
frmdstryr has quit [Remote host closed the connection]
<marijnfs>
error: expected type '[*c].cimport:10:11.struct_zmq_msg_t', found '*.cimport:8:11.struct_zmq_msg_t'
<marijnfs>
why can't it cast these pointers anymore? I believe it worked before
<BaroqueLarouche>
because it expects an array
ur5us has joined #zig
<ArtifTh>
Also, what is rationale behind not supporting line endings other than '\n'?
<ArtifTh>
>invalid carriage return, only '\n' line endings are supported
<TheLemonMan>
\r\n needs twice as many bytes, think of all the wasted bandwidth
<marijnfs>
BaroqueLarouche: I'm trying to find out why. The original c function wants a pointer it seems
<TheLemonMan>
andrewrk, where would you put a (Windows-only) function to check if we're running under Wine and query its version? I wanted that to avoid #3500 from breaking the test suite on machines with an older wine version
marijnfs_ has quit [Remote host closed the connection]
<metaleap>
"I need to get rid of the useless "referenced from here" error notes" --- they're really handy tho, but could be reduced. often in generic call sites the error is reported as occuring in say std/fmt.zig or wherever when it's really the call-site at fault. could use this heuristic for less noise: if stdlib files are involved and inner-most, drop them all and only keep the call-site-to-said-stdlib-location "referenced here" note (not the whole outer
<metaleap>
call-hierarchy)
<metaleap>
andrewrk: ^
<andrewrk>
TheLemonMan, my first preference would be to avoid checking if we're running under wine if at all possible. maybe we can let that test fail with older wine? maybe that's appropriate? but to answer your question: std.os.windows.foo
<andrewrk>
I'm ok with zig's test suite failing on older wine versions with the (not-enabled-by-default) -Denable-wine
<andrewrk>
marijnfs_: note: pointer type child '.cimport:8:11.struct_zmq_msg_t' cannot cast into pointer type child '.cimport:10:11.struct_zmq_msg_t'
<andrewrk>
that would have been really helpful to include earlier
<fengb>
That was his first post
<metaleap>
wip-lsp also wants to know from whoever knows: what "package names" legally importable (but not specified in one's build.zig) are currently autoresolved --- in addition to "std" (going to std.zig) and "builtin" (going to builtin.zig), if any?
<TheLemonMan>
andrewrk, np then, I'll try to remember not to panic when the test suite fails heh
<andrewrk>
I suggest to look at the cimport.zig file and find out why these structs are different
<metaleap>
wip-lsp also wants to know from whoever knows: what "package names" legally importable (but not specified in one's build.zig) are currently autoresolved --- in addition to "std" (going to std.zig) and "builtin" (going to builtin.zig), if any?
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
<companion_cube>
so how many LSP implementations are still active right now?
<andrewrk>
metaleap, I do not understand your question
<andrewrk>
you are asking what packages are guaranteed to be available?
<metaleap>
yeap
marijnfs has joined #zig
<metaleap>
the other day someone mentioned some undocumented one for example, sadly i forgot which
<andrewrk>
"std", "builtin", and "root"
<metaleap>
but it did work
<metaleap>
thx!
<metaleap>
companion_cube: you tell me, i'm only tracking the one i'm making
<companion_cube>
:D heh. how far along is it?
<fengb>
builtin is deprecated right? >_>
<andrewrk>
it's pending some breaking changes that will improve granularity of various build settings
<andrewrk>
e.g. specifying build mode at package scope
Akuli has quit [Quit: Leaving]
mahmudov has joined #zig
<metaleap>
companion_cube: symbols-hierarchy for current source file works 100% to my specs. resolving non-dotted idents for gotodef and hover already for local-src-file-only (incl. indefinite indirections leading to a usingnamespace), right now tackling cross-source-file resolving for this. then the dotted ones where resolving goes from left to dot-operand-in-question. also got zig-fmt (the stdlib one not the command-line-tool one) in there for lsp clients that
<metaleap>
use this, including format-on-type. also build-on-save which builds build.zig containers that directly or indirectly import the .zig file you just saved. and if you save multiple files at once of course no duplicate work is queued up. all the little details..
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 255 seconds]
<companion_cube>
and I imagine diagnostics were there from day one, hmm?
<metaleap>
for the gotodef when the identifier nodes are fully covered i'm in a good place to also tackle field-initializer and enum-lit nodes (identifiers of a different flavour)
<metaleap>
oh yeah diagnostics for build-on-save plus parse errors on the fly as you edit your file
<metaleap>
when you save a file to trigger a rebuilt, only build diags are cleared that are known to be invalidated by that particular chain of build jobs
<companion_cube>
what about completion?
<metaleap>
thats the last part in my schedule, after "references" lookups, because by then everything needed for it will be in place: except for the dangling trickiness of trying to figure out context in a currently-unparseable-ast
<metaleap>
but at least by then there will be the knowledge what names are in scope.
<metaleap>
and doc-comments etc
<metaleap>
as a stretch goal eventually i also want smart completions for example for adding new switch prongs. but thats kinda "nice to have" not "need to have"
<companion_cube>
do you know if LSIF is supposed to be there for completion/gotodef to be easier to implement for multiple files?
<companion_cube>
I couldn't really figure out what it's about
<metaleap>
oh that indexing thing? trying to see how far i can get without. probably doing half-dumb coarse index-hashmaps to reduce searches like references and workspace-wide-symbols but dont see the need for super-fancy fullblown index infra
<metaleap>
might change later when real-world zig codebases grow into vast beasts of 1000s of source files. right now i'm sort of assuming workspaces of at most 500-1000 known .zig files
<tdeo>
do you need to evaluate comptime stuff to implement some lsp features?
<metaleap>
tdeo: aim not to. all variants that are in the sources are taken as equal possibilities. so you may be multiple signatures with different arg/ret types for example. or multiple results for gotodef
ur5us has quit [Quit: Leaving]
<metaleap>
but there's some minimally-required "comptime-like" eval: for example your @import("my"++someconst++".zig") will resolve etc
<metaleap>
incl any nr of indirections there
<metaleap>
todo: need to guard eventually against circularities tho
ur5us has joined #zig
<metaleap>
multi-resolve: https://imgur.com/WB4t4aI kinda poor wip state lol. not massively eager to resolve "type(s) of thing" right now when just quoting existing sources gives 90% of the time what i wanted to know --- but eventually i might refine to that sort of smartness later on
waleee-cl has quit [Quit: Connection closed for inactivity]
<metaleap>
well that part's already working. when only string-lits are accepted it will continue to =)
doublex has quit [Read error: Connection reset by peer]
marijnfs has joined #zig
<metaleap>
when needing to take a short break from the meaty stuff, i like to add "playful goodie" mini features that occasionally do prove handy : just added bonus shots of those to the bottom of https://imgur.com/WB4t4aI =) darn those friday nights, now back to the `usingnamespace @import` decls resolvings..
waleee-cl has joined #zig
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 256 seconds]
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 260 seconds]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<wilsonk>
metaleap: are we able to install/use your lsp yet? It looks usable for small single file projects at least. I know you said it is spread across a few projects...maybe some hints on how to install :)
jjido has joined #zig
ur5us has quit [Ping timeout: 256 seconds]
<metaleap>
well you can grab from github.com/meta-leap the top 4 repos (updated in the last week). have them all side-by-side locally too. then to make, `cd langserv && zig build`
<wilsonk>
ah, ok sweet
<metaleap>
hot tip, dont hover over a string-lit with \x or \u in it.. to prevent some @panic("TODO"), i need to fix and PR sth tomorrow onto zig/lib/std/zig/parseStringLiteral.zig :D
<andrewrk>
metaleap, I've been playing with `return error.Unimplemented` rather than @panic("TODO") and been pretty happy with it
<metaleap>
andrewrk: yeah i was gonna suggest that in an issue, but then thought "finally sth i can tackle myself in a PR" so thatll be upcoming. at least for \x std.fmt.parseInt has the goods already i believe with radix spec
<metaleap>
and for \u i'll see if std.unicode is even needed (its still just hex right) and if so, if it suffices
<fengb>
Are you hiding Zig from your main account?
ur5us has joined #zig
<metaleap>
fengb: not intentionally :D hm might look that way, i just wanted a clear separate space at the start for all sorts of zig repos and tryouts and repros and forks and jazz
<fengb>
Or you're hiding your main from us
<mikdusan>
is LLVM_EXPERIMENTAL_TARGETS_TO_BUILD="AVR" still the only experimental we build for llvm-10 ?
<andrewrk>
mikdusan, yes
<andrewrk>
afaik it's still experimental in llvm 10
<metaleap>
wilsonk: curious! latest nightly? mine is a few days old
<wilsonk>
updated zig a couple minutes ago (maybe I need an older version?)
<wilsonk>
I could try with your version, if you get me the commit...if you want
<metaleap>
"stage2_panic" coming from some .cpp is probably to be reported one way or the other. my zig is at 0.5.0+7e6b68a53
<metaleap>
but will try if i get the same on latest tomorrow or on sunday
<wilsonk>
ok
<mikdusan>
yup AVR is still marked as experimental in readme
<wilsonk>
metaleap: built fine with your zig version listed above
<metaleap>
wilsonk neat, good to have pre-warning i might be hitting upon that issue on my upcoming routine sunday updates&catch-ups sequence
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 255 seconds]
<andrewrk>
fengb, your testing.allocator stuff with memory leak detection has been a boon
<fengb>
Great :D
<metaleap>
andrewrk fengb but it counts somewhat differently than testing/failing_allocator.zig (if used with usize.max of course) i noticed, right?
<metaleap>
oh wait that was quite a long while ago since i compared the 2, looks like there's been changes since
<andrewrk>
it's planned to be replaced with GeneralPurposeDebugAllocator eventually
<andrewrk>
I wonder if I can get that done before the release
<metaleap>
i'm kinda surprised i havent hit any multithreading-incurred "strange counts" yet .. last i checked counters werent atomic (and neither is my own local version of failingAlloc when i played-experimented in that space)
<fengb>
It's only designed for use in tests, which isn't threaded
<fengb>
But... there probably should be some locking mechanism
<metaleap>
i know which is why i separated out a custom version, but then i deferred "until i see it happening" :D
<wilsonk>
metaleap: lsp is looking good
<metaleap>
wilsonk if you hover over any @builtinCall and see something, it detects your stdlib location. as long as the langref html structure wont change too radically, that is :D would be curious
<metaleap>
stdlib detection should have occurred by approx. ~3 secs after start generally from what i observe. until `zig info` command is ready and shows local related paths, i'm creating in your /tmp a `zig init-lib` then `zig build` it to finally scrutinize its txt files in zig-cache lol