<gustav_o>
at first I thought it could only log compile-time strings, which would have been quite useless :)
kristoff_it has quit [Ping timeout: 248 seconds]
porky11 has quit [Quit: Leaving]
jjido has quit [Quit: Connection closed for inactivity]
marijnfs has quit [Ping timeout: 252 seconds]
marijnfs has joined #zig
gustav_o has quit [Quit: gustav_o]
gustav_o has joined #zig
gustav_o has quit [Client Quit]
wootehfoot has quit [Read error: Connection reset by peer]
curtisf has quit [Quit: Page closed]
SamTebbs33 has quit [Quit: Lost terminal]
cameris has quit [Quit: leaving]
mbarkhau has quit [Ping timeout: 258 seconds]
andrewrk has quit [Ping timeout: 244 seconds]
andrewrk has joined #zig
<marler8997>
Hey Andrew, it's been a couple years but I think I'm coming back
<marler8997>
Looks like you've got prebuilt windows binaries now. Very nice. I've got a project to port to zig and it's been going very well. The port has alot of benefits of the D version I've been noticing
terinjokes has joined #zig
<scientes>
yeah i was just looking at D
<scientes>
I was interested in adding the switch() on strings that D has
<scientes>
but i think it really belongs in llvm, and I would want to do it properly, unlike D (but the syntax is fine)
<marler8997>
I believe D can switch on any type that supports "opEquals"
<scientes>
well, zig will not support operator overloading
<scientes>
and that would be equilivent to a if() which makes it kinda redundant
<marler8997>
it's not necessarily operator overloading
<marler8997>
in D, the '=' operator reduces to opEquals
<marler8997>
but you obviously wouldn't want to do that in zig
<marler8997>
the equivalent would probably just be, any type that has an "equals" method
<scientes>
^^ it would be the same as if() performance -wise
<scientes>
making it kinda dumb
<marler8997>
similar to how D does foreach
<marler8997>
any type that has the 'empty'/'front'/'popFront' methods, can be used to foreach
<marler8997>
foreach (foo; bar) gets rewritten to for(; !bar.empty; bar.popFront) { auto foo = bar.front; ... }
<scientes>
nononono, that is not zig-like at all
<scientes>
no operator overloading
<marler8997>
well I'm not proposing it in zig, just explaining what D does
<marler8997>
and which operator is being overloaded here?
<scientes>
I've seen too much code in C++ that gets everything wrong because of operator overloading
<scientes>
it is very common, even in supposedly high-quality code like LLVM
<marler8997>
again, which operator is being overloaded?
<scientes>
the zig rule is "no hidden control flow"
<scientes>
i guess that makes the rule clearer
<scientes>
the point is that you always know what algorithms and data structures are being used, unless you call a function
<marler8997>
right...meaning the control flow has to be apart of the language
<scientes>
meaning that no operators ever call functions
<marler8997>
so I guess your point was, you don't want language constructs to implicitly call functions on types
<scientes>
EXCEPT the call operator
<marler8997>
gotcha
<marler8997>
and I definitely see the reason for that
<scientes>
well there is a tiny exception, which is that llvm generates calls to some c functions like memcpy() that can be implicitely created
<scientes>
but that won't bite you
<marler8997>
you have to start somewhere
<marler8997>
the language constructs themselves break the rules of zig
<marler8997>
the point is, you want those powerful features to be in a small subset that everyone can understand
<marler8997>
bringing us back to your switch feature, I suppose that's reason not to do it the same way as D does, by supporting it on any type that as a specific function
<scientes>
yeah but D also supports switches on strings
<scientes>
and I want to support that, because it can be very performant
<scientes>
VERY
<marler8997>
right, because strings support opEquals
<marler8997>
very performant?
<scientes>
yeah but they did it a VERY slow way
<marler8997>
like, indexing a table from the length or...how does switch make it fast?
<scientes>
perfect hash function basically, but there are two algorithms I see being implemented
<marler8997>
ah
<marler8997>
so these would be comptim strings only?
<scientes>
you can also use a bloom filter to go to the default case faster
<scientes>
yes, only strings, not []u8
<scientes>
well, yeah comptime []u8
<marler8997>
interesting
<marler8997>
have you gotten it working as a library yet?
<scientes>
but making it merge-ready is a bunch more work
<marler8997>
cool stuff
_whitelogger has joined #zig
marmotini has joined #zig
<tgschultz>
with const comptime-known strings , can't you just switch on the addresses being equal?
<tgschultz>
or... no wait, I'm too tired for thinking. you're comparing comptime known strings to runtime known strings with a perfect hash.
<andrewrk>
hey welcome back marler8997
hio has joined #zig
_whitelogger has joined #zig
<marler8997>
Thanks Andrew, zig seems to be in a much better place than it was a few years ago. I've been testing the waters by porting my audio synthesizer to it...very impressed by it
<marler8997>
I'm using a few dozen windows functions that aren't in std, I'll probably make a PR to submit them at some point
<andrewrk>
sounds good
<emekankurumeh[m]>
we should probably add a complete windows api wrapper at some time
<emekankurumeh[m]>
like winapi for rust
husho has joined #zig
cameris has joined #zig
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 248 seconds]
Sahnvour has joined #zig
kristoff_it has joined #zig
_whitelogger has joined #zig
samtebbs33 has joined #zig
gustav_o has joined #zig
marmotini has quit [Ping timeout: 272 seconds]
Ichorio has joined #zig
gustav_o has quit [Quit: gustav_o]
marmotini has joined #zig
wootehfoot has joined #zig
_whitelogger has joined #zig
gustav_o has joined #zig
_whitelogger has joined #zig
<tgschultz>
I autogenerated one, and further refined it with a lot of scripting and reorg. Extern function declarations alone are ~5k lines. rewriting all of them to be more zig like would take a while.
Akuli has joined #zig
gustav_o has quit [Quit: gustav_o]
Ichorio has quit [Ping timeout: 252 seconds]
_whitelogger has joined #zig
avoidr has quit [Quit: leaving]
gustav_o has joined #zig
<scientes>
I felt that way about the zig_llvm stuff
<scientes>
it should change functions to be methods, but you can't do that with @opaqueType s
curtisf has joined #zig
kristoff_it has quit [Ping timeout: 268 seconds]
<andrewrk>
scientes, re: json stuff from #musl - I don't think removing json until it's fully conformant is the best approach for the zig project. the main goal of the std lib until 1.0 is to act as a test bed for the language
<scientes>
its not hard to fix, i just didn't want to change the byte-at-a-time approach
<scientes>
but i think you have a point with "test-bed"
<scientes>
that is the real focus
<andrewrk>
yeah. json might not even be part of the std lib if the package manager is good enough and it's not needed for any self-hosted compiler thing. that's all to be determined
<scientes>
cause its easy to be overwhelmed with ideas
<scientes>
and vaporware
<andrewrk>
yes
<scientes>
anyways, happy that copy-elision is coming along
<andrewrk>
apologies for the images rather than text
<scientes>
I was working on getting that to work with vectors
<andrewrk>
ah, yeah I haven't tested that yet
<scientes>
I really want to generic vector programming in zig
<scientes>
but there is lots to be done
<scientes>
but that is something that C does very poorely
<andrewrk>
by generic you mean portable yeah?
<scientes>
yep
<andrewrk>
it's incredible to me how less brittle this third attempt is than my second one. ugh what a mess that was
<scientes>
that's exactly what you have to do however
<andrewrk>
it felt like pouring buckets of water out of a leaky boat
<scientes>
and if you are struggling with something, doing something else for a day usually does wonders
<andrewrk>
yeah and sleep
<scientes>
but looking at portable vector programming, supporting the C ABI is a lot of tedius error-prone work, and LLVM should really provide helpers for that, as almost every language wants it
Ichorio has joined #zig
<curtisf>
Yesterday while playing with generic programming in Zig I was a little disappointed (and reminded a lot of an annoyance of C++ templates) that Zig offers no diagnostics on comptime code that isn't run. Might that ever change?
<curtisf>
It seems more possible than in C++ because there's no operator overloading and implicit constructors/destructors, but things like OS specific branches might be trouble
<Akuli>
i guess this doesn't answer your question, but there is @compileLog
<andrewrk>
curtisf, I haven't typed up the issue for this yet, but for documentation generation purposes there is already a need for building a set of targets rather than just one. this will enable a few things that zig cannot yet do
<andrewrk>
for example, unused variable / function errors and unreachable code errors.
<scientes>
it is more difficult in zig to do this
<curtisf>
would that apply to un-run comptime functions, though? e.g. ```pub fn garbage(comptime t: type) void { var y: u9 = comptime std.io.getStdOut().write("hi" / 0); }```
<andrewrk>
yes if they were not referenced in any of the builds and if they were not part of the public API of a package
<curtisf>
oh, you're saying you'd get an unused function warning, which would at least tell me to test it
<andrewrk>
it is a difficult problem. not only does the isssue with generic programming you pointed out exist, but the issue applies additionally to every function in zig
<andrewrk>
generic or not
<andrewrk>
you'd get an unused function error, yes, so you would be forced to delete it or reference it (perhaps even as simple as `_ = foo;` to create an intentional reference to it)
<andrewrk>
this would only be reasonable if one could build the entire set of targets
<andrewrk>
this would also be applicable for refactoring features of IDEs
<andrewrk>
the reason java has the best refactoring tools is that there is only ever one target. no conditional compilation
<andrewrk>
this is one reason cross compilation is taken so seriously
<andrewrk>
it's an important piece of the puzzle
<andrewrk>
I do want to solve this problem with zig. I want refactoring to feel safe and reliable. comptime isn't going away; and the halting problem means that we're not really left with a choice other than multi-target builds to solve this problem
<andrewrk>
multi-target builds is sort of a way to get "compilation coverage" of all your code
<andrewrk>
think test coverage but comptime
<andrewrk>
anyway that's not something I'm tackling soon, but it's on my metaphorical radar
<scientes>
when will zig get a llvm-9 branch?
<scientes>
I can work with llvm-8, just wondering if there is a method to this
<andrewrk>
if I felt like I had more time I'd do it today. but I will make it a priority once upstream creates the 9 branch
<scientes>
well it might change, so it might make sense to wait as you say
marmotini_ has joined #zig
marmotini has quit [Ping timeout: 246 seconds]
gustav_o has quit [Quit: gustav_o]
gustav_o has joined #zig
<andrewrk>
someone in #musl brought up an interesting project idea
<andrewrk>
a self-contained binary you can ship along with your application to do UI stuff. as an alternative to UI-as-a-library
<scientes>
I don't get it
<gustav_o>
how would you communicate with it?
<samtebbs33>
Communication via IPC I suppose
<samtebbs33>
Perhaps it could let the user decide between a tty interface or gui
<gustav_o>
to ease cross platform deployment?
<andrewrk>
hmm I'm having second thoughts now. the idea struck me at first because it side-steps the "now you have to use the language the ui lib is written in" problem
<scientes>
that that is a significant problem
<scientes>
and even GTK+ has problems with it, because it isn't really C, it is gobject
<andrewrk>
right
<andrewrk>
I'd rather use an IPC protocal than gobject
<scientes>
html is actually a pretty decent GUI language
<andrewrk>
*protocol. same with C++ classes
<scientes>
which for how much it sucks, is really saying something
<scientes>
but anyways, I don't do guis
<andrewrk>
but I guess a UI C library is actually just kinda the same thing or better
<gustav_o>
I’m a big fan of the immediate mode guis a là imgui etc
<gustav_o>
yea, or one could argue that a ui-binary would be better because it could update itself independently from the application etc, but then that’s not really a good thing :)
<scientes>
qt is basically the only C++ library that has succeeded in being binary backwards compatible
<scientes>
as that is something that is extremely difficult
<tgschultz>
I disagere about HTML being a good GUI language. Wasn't NEWS basically what's being described?
<scientes>
tgschultz, my point was that everything else sucks too
<scientes>
but this isn't my area of expertise (and never will be)
marmotini has joined #zig
hendi has joined #zig
hendi has quit [Client Quit]
marmotini_ has quit [Ping timeout: 245 seconds]
<gustav_o>
I’m reading through the docs and wow, zig seems great :) the printf() example is so nice
<gustav_o>
Could one do something like that for pretty printing variables for debugging? like var p = Point(x,y); warn(“{}”, p); could produce “Point { 3.2, 3.1 }”?
<gustav_o>
(e.g can I reflect types other than functions?)
return0e_ has joined #zig
knebulae has quit [Read error: Connection reset by peer]
return0e has quit [Read error: Connection reset by peer]
<tgschultz>
gustav_o: already that will work. structs are printed more or less as you describe by default. However, if you have a more complicated type you can create your own `format` function in its namespace and the formatter will defer to it.
<gustav_o>
so I’ve been writing my new game framework in C for simplicity/portability but after researching zig a bit it definitely seems to be superior for this kind of project. do you know anyone using it for a bigger game yet?
knebulae has joined #zig
<scientes>
gustav_o, you will need to get involved in zig development for any significantly sized project
gamester has joined #zig
<marijnfs>
i'm trying to make a minimal example of the sort error i got yesterday, but it's hard
<gamester>
scientes: Why? Everything pretty much just works already except convenience things like automatic interfacing with c libraries. A large project is just more of the same. The only thing is you'll need to pay attention to Zig changes.
<gamester>
gustav_o: I'm working on a game (among other things unfortunately), it's bigger than hackathon stuff, smaller than what small teams produce (but more fun). That's all I know.
Akuli has quit [Quit: Leaving]
<gustav_o>
gamester: have you encountered any big problems yet?
<scientes>
yeah go ahead. that is a primary use-case
<gamester>
gustav_o: I have not. Andrew knows what he's doing.
<scientes>
and if it is open source we would like to have more tests
<gustav_o>
scientes: mm I can imagine that given that it’s early.. but core language features? if I avoid coroutines etc. I got some problems compiling with frameworks on OSX but I’m thinking I can create a library with the core framework in zig and then compile and link with platform specific tools?
<scientes>
gustav_o, yeah, the core language is feeling alot stabler than it did 6 months ago
<gustav_o>
basically use zig for all my own logic and some “call into c-libs” stuff
<gustav_o>
cool
<scientes>
but it is not fully implemented. there are lots of panic("TODO") in the compiler
<gamester>
scientes: there are?
<gamester>
I mean you can write really dumb code that shouldn't compile and instead you'll crash the compiler
<gamester>
But when writing normal code, I don't hit TODO
<scientes>
I've only run into it when doing rarer things, like excercising error unions
<scientes>
and yes, please help with those bugs
<gamester>
gustav_o: all I can say is that Zig moves fast. The current compiler does have unimplemented edge cases that won't be ironed out because the stage 2 comiler (written in Zig) will be the real compiler
<scientes>
well we still want to have the stage1 compiler be able to bootstrap stage2
<scientes>
because bootstrapping is a pain, and a security problem
<scientes>
not sure that will actually happen
<scientes>
but that is the plan
<gustav_o>
I’m ok with running into the odd bug here and there and helping out when I do, but if it happens constantly I would say that it’s too early to base a project on it.. but I’ll start and see :)
<scientes>
Hopefully zig adds enough that it will attrach the work to make it stabler
<scientes>
*attract
<gustav_o>
you don’t think the 3 stage thing will pan out? The main difficulty I see is maintaining two codebases (but there must be 1000s of other difficulties :)
<gamester>
I'm not sure why even one person wouldn't be able to make the compiler stable. Jon Blow's Jai compiler has gone through fuzz testing, finding nothing. Zig's comiler1 isn't going through that because it would be a waste of time (I assume)
<scientes>
nothing against any type of testing
<gamester>
huh?
<scientes>
any help with zig is appreciated
<gamester>
I'm saying Andrew is intentionally not doing fuzz testing on Zig's stage 1 because the point is to move to stage 2 fairly quickly
<scientes>
fuzz testing is overrated
<scientes>
and it certainly is not ready for it
<scientes>
doing fuzz testing well is almost the same as just writing tests
<scientes>
those are much more productive at this time
<scientes>
tests are not just preventing breaking, they are also a form of documentation
porky11 has joined #zig
porky11 has quit [Client Quit]
<gamester>
fuzz testing helps you find the tests that you should write
<scientes>
fuzz testing is when you run out of bugs
<scientes>
zig is no-where near there
<scientes>
but someone else can do it, no objection
<gamester>
I don't know what we're discussing at this point. I'm in full agreement with not doing fuzz testing as it would be a clear waste of time.
<scientes>
yeah
<scientes>
i'm also hacking at the same time, so not really paying attention to this conversation
mbarkhau has joined #zig
<mbarkhau>
hi, I'm trying to debug a program that ends with segfault
<mbarkhau>
i've isolated the line that causes it, but don't quite see what the issue is
<scientes>
paste
<hryx>
hi mbarkhau. scientes is asking if you can provide a link to a pastebin with your code
<mbarkhau>
my feeling is that andrewrk is more amenable to arguments around language adoption
<scientes>
seriously, these are unimportant things
<mbarkhau>
"all the hip cool languages are dropping semicolons mom"
<scientes>
zig has radically improved compiler errors by having strings not allowed to span newlines
<scientes>
and this is the same thing
<scientes>
zig can almost always spot a syntax error on the line it occured
<curtisf>
The more similar Zig is to C, the more likely it can begin replacing it before I die, so I am willing to accept whatever ugliness semicolons might possibly carry
<mbarkhau>
idk. how many people in the go and python communities are clammoring to have semicolons pout back in?
<mbarkhau>
*put
<scientes>
python syntax is super funky
<scientes>
and its actually really bad for code review
<scientes>
because a one-line change becomes a 30-line change
<mbarkhau>
because of semicolons O_o?
<scientes>
because of implicit blocks
<tgschultz>
I hated golang's asi, it drove me insane
<scientes>
asi?
<tgschultz>
automaic semicolon insertion
<scientes>
tgschultz, well yeah because you put the semicolon on the next line :)
<scientes>
devil :P
<companion_cube>
the python syntax is the worst, I'd avoid listening to them
<tgschultz>
No, I put braces on the next line, and go put a semicolon before it becuse f*** me I guess
<scientes>
yeah i meant brace
<tgschultz>
either whitespace is significant or it isn't. Python went one way, other languages go the other, go decided it wanted the worst of both
<tgschultz>
that's my opinion anyway
<scientes>
i still think it is because you couldn't put the brace on the next line
<scientes>
but yeah i think zig should keep the semicolon
<tgschultz>
well yeah, but why not? It's the way I grew up coding, it's what I'm used to, and my opinion is that it is more readable.
<scientes>
as i am coming from C I will end up putting semicolons in any language i work with
<scientes>
and whitespace IS significant in Zig
<scientes>
and i think it makes sense
<scientes>
to have newlines be significant
<tgschultz>
where is whitespace significant in zig?
<scientes>
strings cannot contain literal "\n"
<scientes>
for damn good reason
<scientes>
it keeps the formatting sane
<mbarkhau>
coming from python, semicolons feel like make work. anywho, I'm almost sorry I brought it up
<scientes>
yeah I don't really care
<scientes>
the go thing would be fine with me
<tgschultz>
do you mean \r?
<marijnfs>
is there a numeric for loop? i see it was proposed but docs don't mention it?
<scientes>
we could still use a sort that is optimized for highly sorted stuff (python has that)
<scientes>
along with a hint that you can provide to sort to make it use that
<hryx>
Specifically, that EvalResult contains an APValue, which is currently opaque. I'm struggling to find a good solution
<scientes>
you could use uintptr, but that is ugly
<scientes>
you can't store opaque types on the stack, only pointers to them
<hryx>
Should clang::APvalue be fully defined in zig_clang.h so that it's not opaque? I guess they could be allocated from the C++, but I assume that's not ideal
<hryx>
scientes: exactly, that's my problem
<andrewrk>
hryx, in this case we can promote APValue to something where we know the size of it, look at ZigClangSourceLocation, ZigClangQualType, and ZigClangAPValueLValueBase
<andrewrk>
you can follow that pattern - be sure to set up the bitcasts in zig_clang.cpp and the static_asserts to detect if the size changes
<hryx>
andrewrk: that seems ideal, although APValue looks maybe more complex than those types. Maybe classes just scare me more than structs though
<hryx>
oh yeah, static asserts are a good idea. Thanks, I'll try that
<scientes>
hryx, if it is anything like APInt it isn't that bad
<scientes>
but it will store information on the heap via malloc()
<andrewrk>
in theory it should be ok as long as the sizes are the same, and the actual logic is done in the .cpp file with the correct type
<scientes>
i think that is the way APInt works
<scientes>
LLVM's SmallVector also does that
<andrewrk>
scientes, this is about putting a C API on top of a C++ API
<scientes>
yes I see
<scientes>
why don't we actually expand the c api with what we need?
<scientes>
at least some of it
<scientes>
is llvm that unfriendly?
<andrewrk>
this is the clang API
<andrewrk>
I started with trying to use the clang C API but it's basically Monopoly Jr
<marijnfs>
andrewrk: yeah I tried to make some 'fuzz test' case that creates this situation, but can't figure out how to reproduce it
<hryx>
andrewrk: One more question somewhat related to translate-c. stage1 seems to be able to build an AST with no token references, and ast_render.cpp just uses string literals when rendering. However the stage2 version of render heavily refers to the original tokens. Is this new approach specifically intentional?
<hryx>
The reason why I ask is that building tokens and AST at the same time is pretty cumbersome
<andrewrk>
first of all I agree it's cumbersome
<andrewrk>
there are 2 factors going into this: (1) stage2 has zig fmt - the ability to render AST while retaining information such as comments and other formatting. stage1 doesn't have that functionality (2) in stage2 I want more control about the range that compile errors point to
<andrewrk>
I was hoping that we'd be able to abstract the cumbersome properties of this design away once and then not really have to think about it
<andrewrk>
but yeah it's pretty bothersome to have to mark revert points and go back and stuff
<hryx>
super true, I understand. I think the only actual annoying part is that the order of tokens matters
<andrewrk>
I think we can relax that restriction
<hryx>
that would be cool. At first glance it looks like this is currently just an expectation that render.zig has in some places
<andrewrk>
yeah
<andrewrk>
btw, incoming breaking change to master branch
<hryx>
saw that [_]i32{} change, pretty cool :>
<andrewrk>
also `const` no longer allowed there, that was confusing people
<hryx>
Ok, so for now I will live with the existing way of building tokens & AST in translate-c. Then later I'll look at how norms in render.zig could be relaxed to make the builing order more flexible
<hryx>
and the above advice on making APValue non-opaque will unblock me. thankz!
<andrewrk>
hryx, thank you!
<andrewrk>
also no hard feelings if you get bored with translate-c :)
Ichorio has quit [Ping timeout: 248 seconds]
<hryx>
nah man, at this point I'm too invested haha
<hryx>
it has been a very good learning experience
<scientes>
ugghg, how do i check a LLVMTypeRef for null
<scientes>
it keeps optimizing out my checks
<scientes>
ahh finially
<emekankurumeh[m]>
andrewrk don't forget to close issue 568