<pixelherodev>
Best part is that this time, support won't be just whatever random features were needed short term
<fengb>
I feel like I should learn this so I could generate LLVM directly
<pixelherodev>
It's not *that* bad, but if definitely takes some getting used to though
<pixelherodev>
s/though//
<AndroidKitKat>
pixelherodev: do you use cool retro term unironically?
<AndroidKitKat>
not trying to flame jw
<pixelherodev>
Yeah, but only with minimal settings
<pixelherodev>
And like 2FPS
<pixelherodev>
Mostly just for the glow honestly
<pixelherodev>
Literally, all I really have active are 43% bloom, tiny screen curvature, and either 1/3 or full transparency depending on what the term is for
<pixelherodev>
Each window averages maybe 2% CPU, which is so low as to not affect battery life at idle, and to not seriously slow down e.g. compilation
<AndroidKitKat>
w/e floats ur boat tbh
<jaredmm>
I won't disagree with that. Digging through the dark magic of these headers trying to figure out why a variable name stops populating. 4 cases when you import Windows.h.
<pixelherodev>
To be fair, 2% CPU is actually *absurd*, but it's not *quite* annoying enough to motivate me to profile it and work on optimizing it, nor to replace it with something more... practical?
<pixelherodev>
... mundane?
<jaredmm>
I'm pretty sure the issue is that the name of the value is a #define that evaluates to nothing, which I'm sure there's a reason for.
<jaredmm>
So I guess by that logic, translate-c is correct that it doesn't have a name, but if it doesn't have a name would the idiomatic Zig code be to use the name of the define as the member name? Is there a better way to represent that Windows-or-C-ism in Zig?
<pixelherodev>
If it's defined to nothing, it's usually for `#ifdef`s
<jaredmm>
/ For compilers that don't support nameless unions/structs
<jaredmm>
Basically that. I guess that anonymous unions aren't a thing in C99 and that's why the define exists.
waleee-cl has quit [Quit: Connection closed for inactivity]
<pixelherodev>
C11 or GNU extension to C99, yeah
<pixelherodev>
Though I've seen a claim (I haven't verified this) that the original 1974 compiler supported them
<pixelherodev>
(where Original means Dennis Ritchie's)
<frmdstryr>
Was @typeId removed?
<fengb>
Yes, @typeInfo does everything you need
Sahnvour has quit [Ping timeout: 240 seconds]
Sahnvour has joined #zig
<frmdstryr>
fengb: Thanks
<frmdstryr>
andrewrk: Using llvm10 works for the @intToFloat thing
<andrewrk>
frmdstryr, interesting. that probably means the difference earlier was 9.0.0 -> 9.0.1
dimenus has quit [Ping timeout: 240 seconds]
<frmdstryr>
the size is almost 4x bigger though?
<frmdstryr>
the llvm 9 debug build was 109kb, the llvm 10 build is 387kb
<andrewrk>
debug builds are allowed to be big. is that new size a problem? how about the size of your release build?
<pixelherodev>
That concerns me more if it scales
<andrewrk>
by what scale factor?
<pixelherodev>
Would e.g. a build that's 10MB in 9 be 40MB in 10? Or would it be 10.3MB?
<pixelherodev>
Does it shift a build size graph up linearly or proportionally to existing size?
<frmdstryr>
The release build is 334k
<frmdstryr>
before the release build was around 35k if I remember correctly
<pixelherodev>
*That*'s a much bigger deal than debug builds...
<pixelherodev>
release-fast or release-small I assume?
<frmdstryr>
release-safe
<pixelherodev>
Ah
<pixelherodev>
As long as release-fast and release-small aren't overly affected I'm not terribly concerned
<pixelherodev>
... suddenly the fact I'm going to need to extend the parser to support LLVM 10 feels more real :(
<andrewrk>
pixelherodev, maybe you should develop against the llvm10 branch
<pixelherodev>
Eh, it's fine for now
<pixelherodev>
As I mentioned earlier, I'm maybe an hour or two of work away from working codegen
<pixelherodev>
As my free time is limited, I'd rather get this working on nine and then add moving to ten to the TODO list for after more important work
<fengb>
If it’s anything like my estimates, that’s another 2 weeks >_>
<pixelherodev>
I bet you ten internet points that I get it done *tonight* then :)
<fengb>
@field(Type, name) can get you the actual function
<BaroqueLarouche>
ohhh
mmx870 has quit [Ping timeout: 248 seconds]
mmx870 has joined #zig
ur5us has quit [Ping timeout: 240 seconds]
<pixelherodev>
Part of the fun of writing this parser is finding bugs in the upstream LLVM parser
<pixelherodev>
While I don't doubt mine is incorrect in far far more places than upstream, I can now name at least one spot in which it's *more* correct according to the spec :P
<pixelherodev>
Or maybe I should do more testing before getting excited: it's the regex in the spec that's wrong, not the parser :P
<pixelherodev>
s/wrong/misleading
<pixelherodev>
InitializerConstant is optional lexically, but not semantically in the context where I thought it was
<andrewrk>
i'm still amazed when I modify thousands of lines of zig code, fix the compile errors, and then everything actually works
<daurnimator>
andrewrk: whenever I try that I get compiler segfaults ;)
_Vi has joined #zig
euandreh has joined #zig
drp has quit [Remote host closed the connection]
drp has joined #zig
dddddd has quit [Ping timeout: 272 seconds]
_Vi has quit [Ping timeout: 240 seconds]
ur5us has joined #zig
ScentedFern has quit [Remote host closed the connection]
<Snektron>
<BaroqueLarouche "andrewrk: Is there a way to call"> If you use the length of std.meta.declarations(AllImageFormat) you have an upper bound for the result array size
<Snektron>
Besides, i think the break statement adds a bug, since youre exiting a scope with a pointer to a local variable
ur5us has quit [Ping timeout: 240 seconds]
mikdusan has joined #zig
lunamn has quit [Ping timeout: 255 seconds]
student069 has joined #zig
marmotini_ has joined #zig
marmotini_ has quit [Ping timeout: 272 seconds]
lunamn has joined #zig
alexnask has joined #zig
_Vi has joined #zig
marmotini_ has joined #zig
_whitelogger has joined #zig
rappet has joined #zig
drp has quit [Remote host closed the connection]
waleee-cl has joined #zig
<BaroqueLarouche>
Snektron: the break statement works because it is inside a comptime block, also thanks for the suggestion :)
<Snektron>
Im not quite familiar with lifetime of comptime variables, but i'd guess that they should be similar to runtime lifetimes
<alexnask>
Afaik comptime values don't have a lifetime, they are always valid, so you can leak pointers (at least with current stage1 compiler)
<alexnask>
Iirc the plan for stage2 (self hosting compiler) is to implement a garbage collector for comptime values
marmotini_ has quit [Remote host closed the connection]
marmotini_ has joined #zig
marmotini_ has quit [Ping timeout: 272 seconds]
alexnask has quit [Ping timeout: 255 seconds]
alexnask has joined #zig
alexnask_ has joined #zig
alexnask__ has joined #zig
alexnask has quit [Ping timeout: 272 seconds]
alexnask_ has quit [Ping timeout: 255 seconds]
LER0ever has joined #zig
<fengb>
They have permanent lifetime ;)
<alexnask__>
Sure, good point
alexnask__ is now known as alexnask
dddddd has joined #zig
dingenskirchen has quit [Read error: Connection reset by peer]
dingenskirchen1 has joined #zig
dimenus has joined #zig
dingenskirchen1 is now known as dingenskirchen
waleee-cl has quit [Quit: Connection closed for inactivity]
metaleap has joined #zig
<fengb>
Really weird idea: can I lookup a runtime pointer value at comptime? It's in a globally static array
<fengb>
I suppose I can lookup the offset
<fengb>
... this is so much better than sorting at comptime
<fengb>
Sometimes it's just better to do the simple thing :/
frmdstryr has quit [Ping timeout: 260 seconds]
frmdstryr has joined #zig
frmdstryr has left #zig [#zig]
frmdstryr has joined #zig
marmotini_ has joined #zig
marmotini_ has quit [Ping timeout: 260 seconds]
waleee-cl has joined #zig
<andrewrk>
alexnask, fengb: they have the same lifetime as any value in a garbage collected language
<andrewrk>
e.g. if you use a comptime value only inside a comptime function call to produce a different value, the intermediate values can be freed
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
LER0ever has quit [Remote host closed the connection]
LER0ever has joined #zig
Akuli has joined #zig
nepugia has joined #zig
<betawaffle>
is there some way to determine if the *value* of a `var` argument is comptime-known?
<andrewrk>
why do you need to know?
<betawaffle>
maybe to switch between returning an array pointer or slice?
<betawaffle>
not that important, i suppose
<andrewrk>
wouldn't it be better to always return a slice, since that works for both cases?
metaleap has quit [Quit: Leaving]
<betawaffle>
i'm writing a minecraft server, and i'm trying to design a really nice interface for parsing the protocol
<andrewrk>
I see
<betawaffle>
so i'm trying different ideas
<pixelherodev>
Comptime is nice, but until performance is improved (or some optimizations are implemented) I'm being very hesitant with how much work I shift to comptime
<pixelherodev>
If there was e.g. a builtin for string comparison, that would majorly improve the biggest issue I had
<pixelherodev>
A comptime function that does a lot of `std.mem.eql(u8,`s will massively inflate compile times :(
<pixelherodev>
The problem with a builtin though is that it increases language complexity, whereas detecting std.mem.eql(u8 calls and replacing them leave the language simpler and complicate the compiler
TheLemonMan has joined #zig
<TheLemonMan>
andrewrk, picking a thumb1 only architecture as default for the ARM target isn't a wise move IMO
<TheLemonMan>
I mean, you picked a -m variant without ARM instructions
frmdstryr has quit [Ping timeout: 240 seconds]
LER0ever has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<fengb>
pixelherodev: yeah I noticed; was sorting on strings at comptime and it was really slow :(
<pixelherodev>
I'd try to optimize it but I honestly don't want to touch the C++ any more than I already have
<andrewrk>
it should probably be an 'a' variant right?
<andrewrk>
how about v7a?
<TheLemonMan>
yeah that's much better
<andrewrk>
ok pushing to master
<TheLemonMan>
the m variants are badly supported by the stdlib, we should add some checks for noarm feature here and there
<andrewrk>
TheLemonMan, btw why do we have arm and thumb architectures? could we possibly remove the thumb arch and rely on detecting whether "thumb_mode" cpu feature is enabled?
<andrewrk>
that has always confused me
<TheLemonMan>
the feature means thumb is supported iirc, it doesn't change the instruction set being used
<andrewrk>
note that dwarf.zig and elf.zig are not forced to have these annotations; those files remain agnostic. it's debug.zig which is trying to create a "seam" for the purpose of stack trace printing
<TheLemonMan>
hmm, I remember trying to run the tests with that flag
_Vi has joined #zig
<andrewrk>
the interesting changes in the above commit are in std.fs
metaleap has joined #zig
<andrewrk>
btw what should be the convention? (1) `openAtC` (2) `openAtZ` (3) `openAt0`
<frmdstryr>
andrewrk & TheLemonMan thanks for all the help yesterday, finally got it all working
<andrewrk>
frmdstryr, so it was a bug fix in llvm then?
<BaroqueLarouche>
my vote for 1, since null-terminated sentinel as used when interracting with C
<BaroqueLarouche>
*are
<TheLemonMan>
frmdstryr, awesome!
<frmdstryr>
Yes, Seems like it, with 9.0.0 at least
wootehfoot has joined #zig
<andrewrk>
BaroqueLarouche, I veto the C one because it's not only for C related things. when you compile for windows with no libc or linux with no libc, the OS still has a bunch of ABIs that use null terminated strings
<andrewrk>
one day C will be dead and zig lives on, there should be no functions with "C" in their name, referring to C programming language
<BaroqueLarouche>
andrewrk: I see! 2 then
<BaroqueLarouche>
"one day C will be dead and zig lives on, there should be no functions with "C" in their name, referring to C programming language" this is the way
<mikdusan>
mando!
<BaroqueLarouche>
haha yes!
<andrewrk>
TheLemonMan, damn, even with that new debug info improvements, stage1 stack traces not working for me in debug builds: https://clbin.com/EaAOG
<andrewrk>
this regressed for me about a month ago
<andrewrk>
(this is my wip branch rebased on master)
<TheLemonMan>
uh that's weird
<TheLemonMan>
can you fax me the zig binary?
<andrewrk>
sure, what's your phone number
<shakesoda>
for null terminators I like the Z suffix
<mikdusan>
if using .(enum literal) syntax that is
<pixelherodev>
that's brilliant :)
<Snektron>
too bad you cant make use of enum literal syntax with that
<andrewrk>
I don't think it's too bad, I think it makes perfect sense
<alexnask>
Is 'error: function with inferred error set must return at least one possible error' expeced behavior when try-ing a function with an explicit empty error set return value in the body?
<alexnask>
I know this sounds stupid
<andrewrk>
alexnask, that error is planned to be removed. you will be able to not return any errors from an inferred error set function. the inferred error set will be error{}
<alexnask>
But there is no way to check the return error set of functions that take var arguments before calling them, so I'm trying to use empty error sets as a workaround
<andrewrk>
as a workaround you can explicitly put error{}
<pixelherodev>
Seconded
<pixelherodev>
That not being able to use enum literal makes sense
<pixelherodev>
In my case for instance, if A is default, I should be comparing against A, not default
<alexnask>
andrewrk, my current usecase is finding the error set of a method of a given type and attaching it to the return type of a function, so I can't just pass error {} atm.
<andrewrk>
we don't ship binaries with debug info on the download page, but one of the benefits of stage1 being a hybrid of c++ and zig is that we get stack traces even in c++
<andrewrk>
it could be an interesting open source project to make "libdebuginfo" or something like this, which is intended to be used by C/C++ and provide stack traces
<andrewrk>
all it would do is export some C ABI functions that are backed by zig std lib
marmotini_ has joined #zig
<fengb>
So backporting Zig into C?
<fengb>
The more I think about the bootstrap process, the more circular it sounds >_>
<andrewrk>
the crazy thing is that zig's bootstrap process is significantly less circular than most other langs
<alexnask>
I used to maintain a compiler that just shipped generated C sources and there was no non-self hosted implementation at all
<andrewrk>
yeah. that creates work for maintainers though, every time you introduce a bootstrapping stepping stone
<alexnask>
(Well obviously there was one at the very beginning)