ur5us has quit [Remote host closed the connection]
ur5us has joined #zig
ur5us has quit [Read error: Connection reset by peer]
<andrewrk>
hmm did std.fmt.format lose the ability to format 0-padded hex numbers?
<andrewrk>
I expected ("{x:02}", .{0x07}) to produce "07" but it produces " 7"
<andrewrk>
ok, got it with {x:0>2}
darithorn has quit [Remote host closed the connection]
darithorn has joined #zig
<jwmerrill>
Does C have any equivalent of @fieldParentPtr, or would you just do pointer arithmetic based on known layout for that kind of thing?
<foobles>
It does, I belive
<foobles>
but its a macro
<foobles>
jwmerrill its a `offsetof`
<foobles>
however, it doesn't work on arbitrary comptime strings like I think it does in Zig
nephele_ has quit [Ping timeout: 246 seconds]
xackus has quit [Read error: Connection reset by peer]
nephele has joined #zig
xackus has joined #zig
SimonNaa has joined #zig
SimonN has quit [Ping timeout: 240 seconds]
epmills has joined #zig
epmills has quit [Client Quit]
_Vi has quit [Ping timeout: 272 seconds]
<daurnimator>
yeah __builtin_offsetof; make sure you don't use the undefined version!
<daurnimator>
you also have the traditional `container_of` macro
<oats>
I haven't really looked at the compiler internals; does the comptime stuff work by having a zig interpreter of some kind? Could it be used to make a repl for the language?
<pixelherodev>
Do you know what IR is?
<pixelherodev>
Basically, it interprets the IR
<oats>
intermediate representation?
<pixelherodev>
Yeah
<oats>
like llvm ir?
<pixelherodev>
Yeah
<pixelherodev>
Zig generates its own IR, executes the comptime bits, translates the rest to LLVM IR and has LLVM generate binaries
<oats>
huh, ok
<foobles>
its very cool. im actually working on that kind of thing right now
<foobles>
basically, as it's analyzing the IR, it checks "is the stuff I've already analyzed marked as comptime? and if so, am I able to evaluate myself right here and now?"
<foobles>
like when you say `if (x == null)`
<pixelherodev>
if X is comptime known, the whole branch just disintegrates, right?
<mikdusan>
sure if the cond is false
<oats>
right, if x isn't null
<pixelherodev>
But it also applies to any else branch
<foobles>
im just saying the comparison itself is replaced with a boolean node directly
<foobles>
control flow is a little more advanced, im not quite sure how that works
<foobles>
since control flow is all determined at pass 1
<mikdusan>
I'd like to remedy that :)
<StateOff>
Can I nest two switch expressions that handle an enum(union) somehow? I seem to get: values of type '(enum literal)' must be compile time known.
xackus_ has joined #zig
<pixelherodev>
Paste code?
xackus has quit [Ping timeout: 264 seconds]
<StateOff>
Was a typo. Sorry for the noise - figured it out while recreating in godbolt.
<pixelherodev>
That is, if I have a `fn(op: var)` which switches on @TypeOf(op) and has `else=>unreachable`, giving it invalid types becomes a compile error, right?
<mikdusan>
yes
<pixelherodev>
Perfect
<pixelherodev>
Documenting my low-level emitter :)
<pixelherodev>
"If you attempt an invalid operation, the emitter will fail at compile-time."
<pixelherodev>
:D
klltkr has quit [Ping timeout: 250 seconds]
<mikdusan>
oh. unreachable might not do the trick. but @compileError is your friend
<pixelherodev>
Ah right
<pixelherodev>
unreachable probably should work for debug mode
<pixelherodev>
but compileError is definitely the way to go
<pixelherodev>
thanks
<pixelherodev>
Heh, switching some unimplementeds to unreachable results in a ~0.04% speed boost. How impressive.
<pixelherodev>
Good to know that returning errors has negligible overhead :)
<pixelherodev>
Well, in the non-error path
waleee-cl has quit [Quit: Connection closed for inactivity]
darithorn has quit [Quit: Leaving]
foobles has quit [Remote host closed the connection]
xackus_ has quit [Ping timeout: 240 seconds]
<pixelherodev>
So today I learned that there's a JS -> LuaJIT compiler
<pixelherodev>
I don't think it works though :P
kenaryn has joined #zig
<pixelherodev>
Hasn't been updated in six years and was a hack even then
<kenaryn>
Hello, I have a very simple question: is Zig higher level than C? If so, is it because Zig compiler is a layer built on top of Clang?
<daurnimator>
no and no; but also sort of yes
<daurnimator>
zig is same level as C in terms of programming
<daurnimator>
but zig also builds on top of clang: but only for compatibility for importing C headers
<kenaryn>
Allright, thank you.
ur5us has joined #zig
kenaryn has left #zig ["WeeChat 2.3"]
dddddd has quit [Ping timeout: 256 seconds]
ur5us has quit [Ping timeout: 252 seconds]
ur5us has joined #zig
ur5us has quit [Ping timeout: 265 seconds]
haliucinas has quit [Remote host closed the connection]
haliucinas has joined #zig
cole-h has quit [Ping timeout: 250 seconds]
dermetfan has joined #zig
Xavi92 has joined #zig
Xavi92 has left #zig [#zig]
wootehfoot has joined #zig
_Vi has joined #zig
sanaris has quit [Quit: Lost terminal]
squeek_ has joined #zig
squeek502_ has quit [Ping timeout: 250 seconds]
_Vi has quit [Ping timeout: 272 seconds]
StateOff has quit [Ping timeout: 256 seconds]
TheLemonMan has joined #zig
<TheLemonMan>
Snektron, pong
<Snektron>
Ah, morning
<Snektron>
I was wondering if you know whats up with arm in gcc/clang
<TheLemonMan>
hm? what's up with ARM?
<Snektron>
So for example i have a chip with v7e-m, which has a dsp extension
<Snektron>
Both gcc and clang cant generate code for this, as you can only enable dsp when targetting v8
<Snektron>
But Zig (and by extension i presume llvm) can generate code for that feature?
<Snektron>
Why doesn't clang 'just' let you enable that specific feature?
<Snektron>
(its not important or anything, i just got confused when i looked it up)
<TheLemonMan>
hmm, is __ARM_FEATURE_DSP defined in your C code?
<Snektron>
Not that i know of, but i would expect that to just enable library intrinsic implementation of functions
<Snektron>
I was rather thinking of something like autovectorization as use case, although im not sure how well that would work on arm
<TheLemonMan>
that's a flag defined by the compiler whenever it detects the dsp extensions
<Snektron>
Oh, right
<TheLemonMan>
if the flag is defined for gcc/clang and you're passing the correct mcpu/march then the problem may be with their choice of LLVM passes/C constraints/LLVM optimizations
<TheLemonMan>
when in doubt always check the LLVM IR
<Snektron>
I just checked, it does define __ARM_FEATURE_DSP
<Snektron>
(Thats with gcc)
<Snektron>
So maybe dsp is just core and is always enabled?
<Snektron>
Anyway, thanks for helping
<TheLemonMan>
the compiler is aware the target supports DSP instructions, maybe the vectorizer doesn't kick in
<TheLemonMan>
reading the IR (don't know if GCC has any way to dump that) will tell you more
<TheLemonMan>
if the code is similar between clang and zig the problem may be later in the pipeline
<Snektron>
I suspect dsp might just be a core part of the processor, instead of an optional extension
<Snektron>
(cortex m4)
<TheLemonMan>
nah, +dsp refers to the DSP instruction set
<ifreund>
been using the zig 0.6.0 package daurnimator made for my personal use
<r4pr0n>
the weird thing is that this happens with both the self-built llvm (which worked fine before) and the system llvm (which was updated to 10 recently)
Akuli has joined #zig
moo has joined #zig
wootehfoot has quit [Ping timeout: 240 seconds]
marijnfs_ has joined #zig
joey152 has joined #zig
gpanders has quit [Ping timeout: 258 seconds]
gpanders has joined #zig
antaoiseach has quit [Quit: leaving]
wootehfoot has joined #zig
moo has quit [Ping timeout: 250 seconds]
Xavi92 has joined #zig
moo has joined #zig
wootehfoot has quit [Ping timeout: 256 seconds]
<Snektron>
I finally got my zig environment set up again
<Snektron>
r4pr0n: works for me on void
<Snektron>
self-compiler llvm and zig
<Snektron>
s/r/d
<r4pr0n>
i guess it's an arch problem then
<pixelherodev>
`./src/dynarec.zig:41:46: error: TODO: type coercion of anon struct literal to struct` :(
<pixelherodev>
oh well
r4pr0n has quit [Quit: r4pr0n]
<andrewrk>
you can work around this by surrounding the anon struct literal with @as(T, ...)
<pixelherodev>
Or just `T{}`
<pixelherodev>
Which is what I'm doing for now
<GreaseMonkey>
> dynarec.zig
<GreaseMonkey>
sounds like someone's having fun
<pixelherodev>
Yeah :)
<GreaseMonkey>
i'm having a similar kind of "fun", i'm getting X11 working via Xlib
<GreaseMonkey>
i'm currently using C to wrap the interface though because the X11 headers are something @cInclude has a hard time with
<pixelherodev>
This is *actually* fun though :P
<GreaseMonkey>
i've got a window open that i don't draw to, and i can handle key press and release and actually know the keysym used
<GreaseMonkey>
i've got work soon so i'll get some basic drawing happening after work
<pixelherodev>
Writing a JIT for ikskuh to prove a point :P
dermetfan has quit [Ping timeout: 265 seconds]
<GreaseMonkey>
which point is that?
<pixelherodev>
IIRC, they said something to the effect of "I don't think a JIT would be *that* much faster given the nature of my CPU"
<pixelherodev>
and I took it as a challenge :P
<GreaseMonkey>
yeah that's a fun challenge
<GreaseMonkey>
...also hot damn, i had a look to see what syntax highlighting there was for VIM for Zig... the highlighter in the official repo was surprisingly easy to set up even w/o pathogen or any of that
<oats>
pixelherodev: ooh, what are you writing a JIT for?
<ikskuh>
oats,
<ikskuh>
the spu mark ii
<ikskuh>
a cpu i've developed and for which i'm currently creating a computer
<foobles>
looks like the error should be pointing to the other line
<foobles>
right?
<foobles>
the one returning u8 explicitly
<ikskuh>
no
<ikskuh>
the function returns u16
<ikskuh>
but somehow the compiler thinks it will return u8
<foobles>
oh i see
<foobles>
the `@as(u8, 0xFF)` should afterwards coerce to a u16 anyway
<Xavi92>
Does it probably get "confused" because of the @as above?
<ikskuh>
foobles: yep
<ikskuh>
Xavi92: nope. that'S just to enforce a type there
<ikskuh>
my actual code is somewhat more complex
<Xavi92>
Hm it's kinda curious this wasn't spotted before
<fengb>
Seems like it’s doing peer resolution instead of result location resolution
akflcar has joined #zig
<akflcar>
hey
<ikskuh>
Xavi92: because people don't use zig! people need to use zig more! :D
<akflcar>
zig is not as small as C? i am a zig newbie
<akflcar>
when was zig created?
<akflcar>
2015
<ikskuh>
what do you mean by "as small"?
<ikskuh>
zig has more features than C
<ikskuh>
but it has less footguns
<fengb>
The Zig “spec” is a lot more well defined, once it’s written at least. A lot of C tends to hand wave edge cases away
<fengb>
Things that are undefined behavior in C usually has some checks around it and possibly well defined alternatives
<fengb>
So in that sense, it’s “bigger”
<fengb>
Plus comptime can be considered a bigger implementation detail, but the usage is much nicer than the preprocessor
<hazeycode>
I turned on UBSAN on a 17 C++ year old project the other day for a joke... wasn't funny actually
<hazeycode>
*17 year old, C++ project
<hazeycode>
can't type straight anymore
<fengb>
C++ year is a new unit
<fengb>
Translates to about 10 regular years, since that’s how many years you’ll age for using it 🙃
<hazeycode>
how old are you? in c++ years
<hazeycode>
lol
<akflcar>
how was optimization implemented in zig, as it's the hardest battle?
<companion_cube>
time to turn that 17y C++ code into C++17!
<companion_cube>
akflcar: it's done by llvm
<foobles>
what would yall think if `?T == T` short circuited? Like if the lhs is null, it doesnt evaluate the right hand side at all and just returns false?
<foobles>
that seems like a bad idea to me
<foobles>
but its an interesting idea I think
<akflcar>
companion_cube: ?? but how does llvm know the "new" language?
<companion_cube>
well the zig compiler produces LLVM IR
<companion_cube>
llvm doesn't care about where its IR comes fro
<ikskuh>
foobles: nah, bad idea
<companion_cube>
from*
<ikskuh>
i would not expect that
<fengb>
I don't like it because I don't think I would translate it in my head
<ikskuh>
how can i set a signal handler in zig?
<hazeycode>
foobles: I can't think of why it's a bad idea, but it feels like one
<fengb>
foo == bar() looks like an immediate compare, not a short circuiting thing
<foobles>
LLVM IR is an intermediate representation generated by a lot of languages. LLVM itself uses that to generate machine-specific assembly
<akflcar>
what does IR stand for?
<akflcar>
ok foobles
<hazeycode>
on that note: are there any plans to ditch llvm? :(
<foobles>
are you against llvm?
<akflcar>
can gcc too do those things, as some use gcc as well.
<foobles>
eeh, I dont think its nearly as easy with GCC
<fengb>
Yes but it's harder because GCC traditionally doesn't have a frontend interface
<fengb>
LLVM IR was designed to be pluggable. GCC wasn't and I'm not sure they've changed their stance
<foobles>
hazeycode why do you ask?
<hazeycode>
I'm neither for nor against llvm particularly at this moment
<fengb>
LLVM was always intended to be an implementation detail... so yes there are plans
<fengb>
But it'll also probably be the main optimizing backend for the foreseeable future
<foobles>
I dont really see a reason to ditch it
<foobles>
unless there is some issue with it that i am unaware of
<foobles>
it seems super well supported and reliable
<fengb>
We've been having issues keeping it stable
<fengb>
LLVM 10 release broke a lot of things
<fengb>
Er... keeping the build stable
<fengb>
In the near term, there's plans to have alternative backends to at least speed up debug builds. I think andrewrk might have mentioned a stable Zig IR that we can start to leverage
layneson has joined #zig
foobles has quit [Remote host closed the connection]
<hazeycode>
fengb: thanks for the heads up, that's interesting
marijnfs2 has joined #zig
Akuli has quit [Quit: Leaving]
<pixelherodev>
GCC wasn't not designed to be pluggable
<pixelherodev>
It was explicitly designed to not be pluggable
<pixelherodev>
For "ethical" reasons
<companion_cube>
they could have been llvm but didn't want ti
<companion_cube>
to*
<fengb>
Right, I just don't remember if they've considered changing their stance
<companion_cube>
cause the GPL isn't contaminating through compilation :D
<fengb>
The spat happened a few years ago now so maybe it could have gotten better
<hazeycode>
really!? :O
<pixelherodev>
Basically, they didn't want corporations benefiting from GCC without contributing their changes upstream
<pixelherodev>
They deliberately avoided exposing an API for GIMPLE
<companion_cube>
they didn't want anyone to write compilers based on gcc without the compiler being GPL
<companion_cube>
which, ugh
<fengb>
Pretty classical GNU vs BSD. Purity vs practicality
<companion_cube>
self-sabotage, in this case
<fengb>
It was also at a time when GCC had terrible diagnostics
<companion_cube>
well it did bring some competition
<hazeycode>
do you guys have any advice for dealing with `error: unable to translate function` ?
tane has quit [Quit: Leaving]
Xavi92 has quit [Remote host closed the connection]
<pixelherodev>
Not going to lie, I do somewhat agree with Stallman's points there
<companion_cube>
that llvm has been used for a lot of compilers by his "adversaries"?
akflcar has quit [Ping timeout: 264 seconds]
<pixelherodev>
not quite
<pixelherodev>
That software freedom is important
<pixelherodev>
I use GPL in some of my own projects (MIT in others)
<companion_cube>
sure, but I don't like his definition of "freedom"
<fengb>
Clang/LLVM is just big agenda pushed by Apple
<companion_cube>
big apple agenda
<pixelherodev>
That I don't agree with
<shakesoda>
fengb: the slow compilation agenda
<fengb>
Clang used to have faster compilation... 🙃
<companion_cube>
the babel tower of new languages agenda
<pixelherodev>
I also think any solution that revolves around licenses is bound to fail eventually
<pixelherodev>
Whether from a replacement project with a different license (e.g. Clang), people ignoring the license (likely happens all the time; GPL isn't enforceable for most), or some other factor
<hazeycode>
I don't understand why opening up gcc has anything to do with copyleft. Seems to be an excuse for design oversight to me
<fengb>
They intentionally don't want to make it easy to make a frontend because they can't propagate GPL through a nice IR
<pixelherodev>
They don't want people using it to make non-copyleft compilers
<fengb>
If LLVM was GPL, you can still make a proprietary frontend to it
<hazeycode>
But you enforce that with the license, not usability right ?
<fengb>
In order to prevent this, they intentionally made it harder to interface with
marijnfs2 has quit [Ping timeout: 250 seconds]
<fengb>
I mean a better design means they cannot enforce the license since there would be a boundary
marijnfs1 has quit [Ping timeout: 258 seconds]
<fengb>
So they intentionally held back on the design to prevent that from happening
marijnfs1 has joined #zig
marijnfs2 has joined #zig
* pixelherodev
shrugs
<pixelherodev>
I don't really think it's worth thinking about. They did a dumb, it's over.
<pixelherodev>
Zig is the future anyways, why worry about C compilers?
<companion_cube>
you seem a bit early in celebrating the victory :D
<fengb>
Well... I wish we could use GCC as a backend :P
<hazeycode>
I don't see much difference between give copyleft program standard defined source code get proprietary program out vs give copyleft program copyleft defined IR and get proprietary program out
<companion_cube>
how about tcc? it's LGPL
<companion_cube>
and it compiles fast!!
<hazeycode>
I'm going to sleep on it.... good night from England
hazeycode has quit [Remote host closed the connection]
ur5us has quit [Remote host closed the connection]
ur5us has joined #zig
<fengb>
Good night
<StateOff>
No Idea how to get a Windows build with SDL2 out of zig.
shinzo has left #zig [#zig]
marijnfs2 has quit [Ping timeout: 256 seconds]
marijnfs2 has joined #zig
<fengb>
thejoshwolfe is like silent bob. He’s barely around but when he pipes up it’s always insightful :P