doublex has quit [Read error: Connection reset by peer]
doublex_ has quit [Read error: Connection reset by peer]
doublex has joined #zig
doublex has quit [Read error: Connection reset by peer]
doublex has joined #zig
doublex has quit [Read error: Connection reset by peer]
doublex has joined #zig
doublex has quit [Read error: Connection reset by peer]
doublex has joined #zig
doublex has quit [Read error: Connection reset by peer]
doublex has joined #zig
doublex has quit [Read error: Connection reset by peer]
doublex_ has joined #zig
doublex_ has quit [Read error: Connection reset by peer]
doublex has joined #zig
doublex has quit [Read error: Connection reset by peer]
doublex has joined #zig
doublex has quit [Read error: Connection reset by peer]
doublex_ has joined #zig
doublex_ has quit [Read error: Connection reset by peer]
doublex has joined #zig
doublex has quit [Read error: Connection reset by peer]
doublex has joined #zig
emekoi has joined #zig
nephele_ has joined #zig
nephele_ is now known as nephele
emekoi has quit [Quit: Leaving]
doublex has quit [Ping timeout: 260 seconds]
mikdusan has joined #zig
doublex has joined #zig
dddddd has quit [Ping timeout: 256 seconds]
stripedpajamas has quit [Quit: sleeping...]
<pixelherodev>
leeward: :)
stripedpajamas has joined #zig
craigo has quit [Ping timeout: 264 seconds]
B4s1l3 is now known as opDispatch
waleee-cl has quit [Quit: Connection closed for inactivity]
slowtype1 has joined #zig
<marler8997>
easy way to turn a comptime_int into a string at comptime?
stripedpajamas has quit [Quit: sleeping...]
opDispatch has quit [Quit: Konversation terminated!]
<fengb>
I usually create a "comptime var buf: [100]u8" and run bufPrint
<fengb>
Change 100 to a smaller number :P
<marler8997>
yeah that's what I ended up doing
<marler8997>
ah new allocator found bug in std.fs.path.zig
stripedpajamas has joined #zig
ur5us has quit [Ping timeout: 240 seconds]
<ttmrichter>
The introduction says, "Note that you can leave off the ! from the return type because warn cannot fail." It really should say "must leave off" because I just got a run-time error with the ! in place in the second Hello program.
antaoiseach has joined #zig
<daurnimator>
ttmrichter: which intro? and care to send a PR? :)
<scientes>
i was doing a [4]u64. switched it to a u256 and it just worked
<scientes>
nice
<scientes>
compilers do so much for us
<pixelherodev>
Eh
<pixelherodev>
I hate LLVM
<scientes>
I don't like C++
<pixelherodev>
Well, yeah
<pixelherodev>
I also hate LLVM in general
<pixelherodev>
The design
<pixelherodev>
ugh
<pixelherodev>
We talked about how comptime performance isn't a thing they care about
<pixelherodev>
here, earlier, I mean
<pixelherodev>
They only recently started even paying attention to it
<pixelherodev>
(comptime performance == time to compile, not Zig comptime)
<torque>
"it compiles slowly" seems like a strange hill to want to die on re: llvm being bad I guess
hermier has joined #zig
<pixelherodev>
It compiles *unnecessarily* slowly
<pixelherodev>
torque: it's *inefficient*
<pixelherodev>
It isn't about absolute speed to me, not really
<pixelherodev>
It's that it's possible to have the same thing but significantly faster
<pixelherodev>
but they *explicitly did not care*
<pixelherodev>
until it got to here
stripedpajamas has quit [Quit: sleeping...]
<torque>
that doesn't seem like a design flaw but rather a matter of priorities, though?
<scientes>
pixelherodev, I am sure the most efficient way to fix that is to rewrite the whole thing /sarcasm
<scientes>
Like I really doubt the backends are slow
<scientes>
you could just skip the middle end entirely
<pixelherodev>
scientes: heh
<pixelherodev>
heh heh
<pixelherodev>
I mean
<pixelherodev>
I'm definitely not rewriting
<pixelherodev>
it*
<pixelherodev>
what are you talking about
<pixelherodev>
no idea
<pixelherodev>
torque: call it poor priority selection then, if you want
<torque>
I haven't ever looked at the llvm codebase, but I'd much rather have a good abstraction 99% of the time than raw speed. I realize the two are not necessarily mutually exclusive
<torque>
but there are a finite number of hours in the day
<pixelherodev>
Sure
<pixelherodev>
my goal is to have both
<pixelherodev>
I'm of the opinion libLLVM has exactly neither of those
<torque>
when it comes down to it, compiling code doesn't usually have hard requirements for realtime performance, unlike, say, video decoding, so it makes sense their priorities would lie elsewhere
<hermier>
there are no such thing as a good abstraction unless you can predict the future
<pixelherodev>
Ehh
<pixelherodev>
torque: it's not about performance though, it's about efficiency
<pixelherodev>
If you can do a task in ten seconds, or in sixty seconds, and get the same results
<torque>
since most software gets distributed as pre-compiled binaries, I'd wager you actually save many computer-cycles of computation even if you slow compilation down an order of magnitude to speed up runtime by 1%
<pixelherodev>
and you *deliberately choose the latter for short-term convenience*?
<pixelherodev>
Right, but that's what I'm saying
<torque>
is it "deliberate" if you don't do the comparison
<pixelherodev>
It's not about "trading comptime for run-time"
<pixelherodev>
It's *inefficienct*
<pixelherodev>
I'm saying it could produce equally well optimized code in much less time if the implementation was more well-designed
<torque>
given the scope of the project, I'm not necessarily convinced that is true
<torque>
but again, I'm considering the practical realities of the problems the developers are interested in and have time to solve
<scientes>
its more a trade-off
* pixelherodev
shrugs
<torque>
I mean I could say I hate zig for being inefficient
<torque>
but there are bigger fish to fry, as it were
<scientes>
^^
<hermier>
inefficiency is only the visible direct cost, if you add reusability/maintenance/practicallity costs in the ballance, inefficiency starts to be a smaller fish
<pixelherodev>
Right but
<pixelherodev>
I'm saying that it doesn't have those either.
<pixelherodev>
I simply do not think the design has any real advantages (but I've only spent a few hours in the source so)
<scientes>
> (but I've only spent a few hours in the source so)
<torque>
that claim seems patently untrue given that multiple languages have been implemented using llvm as a backend
<torque>
(which lends itself to the claim of it being reusable/practical. hard to talk about maintainable given it is written in c++)
<hermier>
if language is the problem, then it is not the real problem
<hermier>
it would be nice to have everything in the same language, but even in C one needs to throw assembly into the mix from time to time
<scientes>
hermier, verdad? Entonces tú puede hablar en Español?
<hermier>
so the language issue is a falcy
<hermier>
scientes: nope, french here
<hermier>
scientes: the fact I can't speek, doesn't mean I can't understand and tune to my needs
<hermier>
it is true it would be niecer to unify a whole pipeline into a unified langage, for the sake of the completeness, but then you need to have a new maintenance cost to deal with
<torque>
well, I wouldn't miss an opportunity to take an oblique jab at c++, but generally I'd claim that language choice absolutely affects code maintainability, by providing more or less constructs that can be used to produce ridiculous messes
<torque>
lord knows I've committed more than my fair share of crimes in python in ways that I wouldn't be able to in e.g. C
<daurnimator>
not to mention the "newspeak" effect
<scientes>
hermier, that language is the C ABI
<scientes>
and LLVM is designed to be modular
<marler8997>
found an ownership bug deep in rational.zig...what a headache
<hermier>
C ABI is the worse excuse ever, there are more efficients ways to deals with the stack than the C ABI. And lets not speak about the mangling mess that it imposed to C++ symbols. But tradeoff were settled once and you have to deal with it *forever*
<pixelherodev>
lol
<pixelherodev>
The C++ mangling issue isn't C's fault
<pixelherodev>
I don't recall C demanding that C++ use their ABI
<pixelherodev>
C++ chose to
<pixelherodev>
*Then* decided to make language decisions that would require mangling
<daurnimator>
hermier: there have been new C ABIs throughout the ages
<pixelherodev>
That's not a particularly bright combination
<pixelherodev>
That too
<pixelherodev>
C ABI != POSIX SystemV ABI
<pixelherodev>
C ABI for x64 != C ABI either
<daurnimator>
if you *can* think of a better one.... people would probably adopt it
<pixelherodev>
Spoiler alert: you probably can't, because it's really not that bad.
<pixelherodev>
And mangling isn't an ABI issue.
<pixelherodev>
It's a naming one
<pixelherodev>
That's a separate issue from ABI
<pixelherodev>
Technically, I think you can use anything as a name
<pixelherodev>
Yeah
<pixelherodev>
Which I know because Andrew demoed using emoji
<daurnimator>
pixelherodev: mangling is part of the ABI though....
<pixelherodev>
C++ could've just injected function sigs as the mangling
<pixelherodev>
daurnimator: what? Huh?
<pixelherodev>
I don't recalling seeing that in the spec
<pixelherodev>
recall*
<pixelherodev>
It's not impossible that I missed it though
<pixelherodev>
Going to take anohter look
<pixelherodev>
another*
<hermier>
it is required because of tooling issue and practicality
<daurnimator>
pixelherodev: is it stdcall that has the stack space required as part of the symbol?
<pixelherodev>
daurnimator: ... uh...
<pixelherodev>
I'm looking at the C ABI right now
<pixelherodev>
Fun fact:
<pixelherodev>
C++ doesn't use the C ABI
<daurnimator>
> STDCALL functions are name-decorated with a leading underscore, followed by an @, and then the number (in bytes) of arguments passed on the stack.
<pixelherodev>
That's not the C ABI
<pixelherodev>
STDCALL != C ABI
<hermier>
if you remove the mangling, then you have to change every tools in existance from assembly to compilers
<pixelherodev>
Sure
<pixelherodev>
But
<pixelherodev>
They never had to add it
<hermier>
anyway that is not the point of the orignal subject
<pixelherodev>
They could've used something smarter from the beginning
<daurnimator>
pixelherodev: it's the default ABI used by some C compilers. That's a C ABI
<pixelherodev>
What compilers?
<daurnimator>
pixelherodev: most things that grew up on windows
<hermier>
every compiler in existance
<pixelherodev>
(But yeah, x64 SystemV C ABI explicitly states that C++ has its own ABI and links to it)
<pixelherodev>
hermier: lol
<pixelherodev>
no
<pixelherodev>
daurnimator: Windows doesn't have an official C compiler.
<pixelherodev>
MSVC is officially speaking *not* a C compiler.
<daurnimator>
some parts of visual studio; borland IIRC.... turbo C?
<pixelherodev>
MSVC explicitly states "Do not ever compile in the deprecated C mode"
<daurnimator>
pixelherodev: MSVC *is* a C compiler for some versions
<pixelherodev>
It can compile C.
<pixelherodev>
Yes.
<pixelherodev>
But the official docs claim that you should never use it as one
<pixelherodev>
I'll take them at their word.
<daurnimator>
It was a C compiler; then it was a C/C++ compiler; then it was a C++ compiler; then it was a C/C++ compiler
<pixelherodev>
Sure, practically
<pixelherodev>
but
<pixelherodev>
officially, it's C++ only
<pixelherodev>
Again, if MS wants to tell me not to use it as a C compiler, fine
<pixelherodev>
I won't.
<pixelherodev>
Bye, Windows.
<daurnimator>
officially from 2014-2018 or so. before that it was officially a C compiler. and more recently too
<hermier>
anyway
<pixelherodev>
It's still officially C++, unless they changed it in the last month or so
<pixelherodev>
s/C++/C++ only
<pixelherodev>
Point is
<pixelherodev>
stdcall is not, despite the name, a standard callconv *on sane systems*
<pixelherodev>
And Windows doesn't use it anymore either IIRC
<pixelherodev>
msbuild ABI or something?
<pixelherodev>
I think it's offered as an attribute
<pixelherodev>
but not by default anymore
<pixelherodev>
I could easily be wrong though
<pixelherodev>
it's 3 AM, I took multiple sleeping pills, and I don't care enough about Windows to remember *any* details
<pixelherodev>
let alone obscure ones
<pixelherodev>
anyways
<pixelherodev>
I'm avoiding chat for the next few days
<pixelherodev>
I waste way too much time in rants that I'm only half serious about
<pixelherodev>
I really couldn't care less if you call MSVC a C++ compiler
<pixelherodev>
I'm still just pissed that they don't properly support C99
<pixelherodev>
The 2-decade-old standard.
<pixelherodev>
That was probably the final straw that had me wipe Windows entirely.
<pixelherodev>
daurnimator: more seriously though, to the best of my knowledge, stdcall is non-standard on every platform
<pixelherodev>
I could be wrong though
<hermier>
it is normal, they deal with their own mess and sometimes you can't never achieve to be conformant to some standards
<pixelherodev>
Actually, about that
<pixelherodev>
It got closer to conformant with the 2016 upgrade IIRC
<pixelherodev>
as someone put it, they probably have some ninja coders secretly fixing C support
<hermier>
if you look at every compiler they are always conformant to a certain degree
<pixelherodev>
Officially unsupported though
<pixelherodev>
:P
<pixelherodev>
Ehh
<pixelherodev>
GCC for instance can be made to be truly conformant
<pixelherodev>
maybe not 100%, but at least 95% easily
<pixelherodev>
MSVC isn't just non-conformant
<pixelherodev>
It explicitly doesn't support like, half the language
<pixelherodev>
Honestly though, I couldn't care less at this point
<pixelherodev>
Windows is an atrocious platform, for anything, but especially for dev
<hermier>
until spec designers become implementors, and provides a solid reference implementation that you could ship in your project, that beeing conformant is a futile joke
<pixelherodev>
The compiler situation is a mess, it's hell to get everything building properly, and even if you can get it building, proper debugging is a pain
* pixelherodev
shrugs
<pixelherodev>
I simply don't care anymore
<pixelherodev>
SEP field is activated
<pixelherodev>
and ugh
<pixelherodev>
I've been a downer for like
<pixelherodev>
20 minutes now, at least
<pixelherodev>
ugh
<pixelherodev>
better topic
<pixelherodev>
... so how bout that stage2? :P
<pixelherodev>
hermier: that's a solid point
<pixelherodev>
It's one reason I like RISC-V
<pixelherodev>
Spec authors have an official conformance testing suite
<pixelherodev>
Honestly, RISC-V = <3
<pixelherodev>
Can't wait for a RISC-V laptop lol :P
<pixelherodev>
That would be awesome
<ikskuh>
heh
<pixelherodev>
oh wait
<pixelherodev>
there go the sleepies
<ikskuh>
i think we have to wait some time still for that
<pixelherodev>
nights
<pixelherodev>
Years, for sure
<pixelherodev>
Hopefully within 5-10 though
<pixelherodev>
An actual open chip implementation, with fully open hardware?
<pixelherodev>
Would be a dream
<pixelherodev>
Especially if it was like that
<pixelherodev>
uh
<pixelherodev>
what was it?
<pixelherodev>
wait no sleepies
<daurnimator>
IIRC VS2019 is going to even add _Generic support
<pixelherodev>
Not losing those
<pixelherodev>
night
<pixelherodev>
daurnimator: whoa, really?
<pixelherodev>
huh
<pixelherodev>
Good job ninjas!
<pixelherodev>
You too `ninja`
<pixelherodev>
you're awesome
dermetfan has joined #zig
<pixelherodev>
keep being awesome
<ikskuh>
/kick pixelherodev "Go to sleep"
<pixelherodev>
Sorry about the ugh conversations. Going to sleep now. I'm going to feel awful about this in the morning, if that's any consolation :P
<hermier>
well x86 and its PCXX specifications has way too much lugage, it is true that risc V is more fresh
<shakesoda>
i definitely want more non-x86 laptops
<shakesoda>
keeps things interesting
<hermier>
laptop or not does not matter, but yes there is a need for a new platform to iterate from
mondra has joined #zig
<shakesoda>
oh, i just want laptop shape so i don't have to switch the plugs so much on all my displays and keyboards and such
<shakesoda>
i'm totally fine with boxes
<shakesoda>
on a deeply related note, i've got a new pi 4 (8gb) showing up today
<shakesoda>
excited to play with that, it's quite an upgrade over the ones i've been using
<hermier>
have a pi4 4gb, and it is quite nice, but I struggle with the available distro/software :/
dermetfan has quit [Ping timeout: 246 seconds]
dermetfan has joined #zig
<shakesoda>
i mostly just develop stuff on mine, and pretty much everything i'm interested in works fine on arm
<shakesoda>
been using pi zero and 3's for years
nrdmn has quit [Ping timeout: 256 seconds]
ur5us has joined #zig
<ttmrichter>
For purposes of defining peripherals, I'm assuming, from a once-over here, that a packed struct would be the way to go to ensure that something like usart1.input_data_register gets the right place?
<gonz_>
shakesoda: Are you booting into your own stuff directly or compiling for linux-arm?
<gonz_>
For the Pi, I mean.
<ttmrichter>
I'm investigating Zig for small embedded systems, so very low level.
<shakesoda>
gonz_: usually linux, but i boot my own stuff directly on zero when i'm in the mood to work on that
<shakesoda>
note that i've been working in c on these things, the zig compiler works fine but takes too long
<gonz_>
ttmrichter: If it still compiles or not I don't know, but you might want to take a look at https://github.com/AndreaOrru/zen
<ttmrichter>
That's orders of magnitude higher level than what I'm aiming for.
<shakesoda>
was it you asking about the cortex m series support
<ttmrichter>
And it doesn't seem to have memory-mapped peripherals in it.
<ttmrichter>
Yes.
<gonz_>
ASM is orders of magnitudes higher level than what you're doing?
<gonz_>
What upside do you see to writing raw machine code, because I guess that's what you're doing in that case...?
<ttmrichter>
If I have to access that by manually flipping bits and doing the equivalent of "peek" and "poke" this is a non-starter of a project.
<ttmrichter>
What I'd do in C, C++, Modula-2, Modula-3, FreePascal, etc. is have a struct defined in some way so I can access the USART_SR by name from a pointer.
<shakesoda>
eh, a couple functions doing bit twiddling isn't so bad if you have the need
<shakesoda>
but if you can map it to a struct in c, you can in zig
<ttmrichter>
And in the better languages of that list (i.e. not C) individual bits or bit collections by name.
<shakesoda>
c lets you define bit widths in structs
<ttmrichter>
This isn't "a couple of functions". In a SMALL MCU we're talking hundreds of these.
<shakesoda>
the syntax is pretty uncommonly used though
<ttmrichter>
It's also undefined as to what the layout is.
<ttmrichter>
Nobody sane uses bit fields for that.
<shakesoda>
i have certainly known people to do exactly that, but i won't call them sane :)
<ttmrichter>
Anyway, leaving the office. I'll have to dig through the manual.
<shakesoda>
packed structs probably do what you want.
<hermier>
packed struct the most horrible necessary language hack in every language when you need to conform to some low level bit requirements...
<drp>
what's the difference between zig0(stage1) and zig(stage2)? speed? features?
<shakesoda>
hermier: struct packing is also really useful for binary files and otherwise serializing stuff
<shakesoda>
you just want to avoid it in the general case
<tdeo>
drp: some parts of the compiler are implemented in zig
<tdeo>
zig0 does not include them because there is no zig compiler to compile them with
<tdeo>
translate-c is implemented in zig
<tdeo>
so it won't work in zig0
<hermier>
drp: stages corresponds to the degree of autonomy the compiler depends on its host system, you want stage 2 (full self hosted) to be has full featured has possible, other stages are throw away necesities to reach stage2
_Vi has joined #zig
<drp>
Thank you!
<hermier>
to explain it more simply, stage0 is compiled on host, stage 1 is proof that stage 0 is able to compile the compiler, and stage 2 is proof that a compiler is able to compile itself
dddddd has joined #zig
drp has quit [Read error: Connection reset by peer]
drp has joined #zig
sacredbirdman has joined #zig
ifreund has joined #zig
ur5us has quit [Ping timeout: 260 seconds]
sacredbirdman has quit [Remote host closed the connection]
mondra has quit [Remote host closed the connection]
<ttmrichter>
hermier: That's one of the best, succinct descriptions of that I've ever heard.
<hermier>
ttmrichter: Details are complicated, but concept are usually simple to explains when really understood.
<ttmrichter>
Right, the devil is in the details.
<ttmrichter>
But often when people get compiler bootstrapping explained to them they're given all the details.
<ifreund>
if i ignore the risk and continue it seems to work fine
<FireFox317>
well firefox is not letting me :D "eenode.irclog.whitequark.org has a security policy called HTTP Strict Transport Security (HSTS), which means that Firefox can only connect to it securely. You can’t add an exception to visit this site.
<FireFox317>
companion_cube, thanks, I DM'ed the person
<companion_cube>
✔
<FireFox317>
its already fixed!
<pmwhite>
It would be interesting, once the self-hosted compiler is written, to test it by computing it's fixed-point; that is, compiling itself via itself ad infinitum. How quickly, if ever, would we reach an executable that produces a byte-identical version of itself.
<ifreund>
I've always kinda assumed that's something most people wrting compilers try
<ifreund>
never read about any results though
<fengb>
I think it's been said that stage 3+ should be identical
sacredbirdman has quit [Remote host closed the connection]
FireFox317 has quit [Remote host closed the connection]
FireFox317 has joined #zig
sacredbirdman has joined #zig
dermetfan has joined #zig
FireFox317 has quit [Remote host closed the connection]
FireFox317 has joined #zig
xackus has joined #zig
stripedpajamas has joined #zig
oats has quit [Quit: until later, my friends]
oats has joined #zig
sacredbirdman has quit [Ping timeout: 245 seconds]
stripedpajamas has quit [Ping timeout: 240 seconds]
<FireFox317>
Hey demizer, welcome to Zig! Unfortunately C++ does not have a stable ABI, which means that we can't call C++ code from Zig. Only C has a stable ABI and thus you have to use `extern "c"` in the C++ header to make sure that it uses the C ABI. The webview header you are using does this correctly, so you should be able to @cImport this header. I'm not sure if you have a compiled version of the webview library, but if you don't, then you
<FireFox317>
need to compile this with `g++` or `zig c++`
<FireFox317>
You can than link this library with the zig code and it should work
<leeward>
I keep forgetting to put my changes in branches for PRs.
reductum has joined #zig
<FireFox317>
demizer, I'm not available for the next 1,5 hours, but probably other people in here can help you for sure!
<leeward>
demizer: I think you may have some misconceptions about how header files work. There's no need to compile webview.h to work in zig; you just have to @cImport it like FireFox317 suggested.
<leeward>
You know what? I'll put something in reddit.
Aransentin has joined #zig
<demizer>
FireFox317: thanks for the response. In the reddit post I show the "zig c++" command, and was successful with that. But not sure how I go about converting webview.h into a library that zig can use. The C++ implementation code is also contained in webview.h. Also, do I have to call "zig c++" from build.zig over cli, or is there an api I can use?
<demizer>
leeward: thanks for the response!
<leeward>
demizer: reddit post incoming
<demizer>
👍
<leeward>
Hopefully that's helpful. Let us know if you need help getting the library to link; the build system is not super well documented yet.
Akuli has joined #zig
rappet has quit [Quit: -]
<demizer>
leeward: thank you. I will try building a library and linking against it. I've done the latter before in zig. Not sure yet how to turn webview.h into a library yet though as it also contains the C++ implementation of the classes
rappet has joined #zig
<leeward>
Oh goodness, looking at their actual code and...hmm
<leeward>
so webview.cc is just #include "webview.h"
<leeward>
Way to go, C++.
<ifreund>
the easiet way to do this is likely to wrap in simple C bindings
<ifreund>
i'm already doing this for a few C functions that can't be automatically translated yet
<leeward>
The header does export C bindings. I think what you want to do is build webview.o from webview.cc.
<ifreund>
but you can't @cImport this header right?
<leeward>
Is that the problem?
<ifreund>
idk, maybe I'm lost
<leeward>
I think the problem is trying to `zig c++ webview.h`
<demizer>
correct
<demizer>
zig c++ main.cc works
<leeward>
Have you tried `zig c++ webview.cc`?
<ifreund>
i don't think compiling the header is a thing you do
<leeward>
Yeah, that's where I was going.
<ifreund>
you compile the .cc and @cImport the header
<demizer>
i am going to try creating webview.cc on lunch break
<ifreund>
lol, webview.cc is one line
<ifreund>
what is this spaghetti
<leeward>
Yeah.
<ifreund>
why is all the code in the header
<torque>
single! header! library!
<leeward>
Short answer: C++
<demizer>
yeehaw
<demizer>
:D
<ifreund>
but yeah what you need to do afaik is compile and link agains `webview.cc`
<torque>
the most c++ solution to having no package management infrastructure
<ifreund>
and @cImport the header which will hopefully work
<demizer>
thanks guys, I will try that. Appreciate the help!
<ifreund>
if translate C fails, then you can always wrap a subset in C and translate that
FireFox317 has quit [Ping timeout: 256 seconds]
<pixelherodev>
ikskuh: thanks for the kick ;)
sacredbirdman has quit [Ping timeout: 245 seconds]
<pixelherodev>
daurnimator, hermier, sorry about being snappy and, dare I say, antagonistic last night. I should be in a a Snickers-esque commerical: "You're not you when you're exhausted. Take a goddamn nap."
<pixelherodev>
"And now, back to your regular pleasant programming"
<leeward>
pixelherodev: I'm a third of the way through your stream from yesterday. You should really consider naming the videos in twitch.
<leeward>
When there are more than 2, it will matter.
<pixelherodev>
I will. Probably.
<pixelherodev>
leeward: I put them up on diode.zone anyways
<pixelherodev>
Which reminds me
<pixelherodev>
Need to split yesterday's stream in half and post those
<leeward>
mmm, P/N junctions...
<pixelherodev>
P/N?
<leeward>
diodes
<leeward>
are made of P and N type semiconductors. Where the two meet is where the diode magic happens.
<pixelherodev>
Ahh gotcha
<leeward>
(positive, negative)
<pixelherodev>
Still waking up :P
* leeward
goes off to implement JavaTranslator.
* pixelherodev
sobs
<pixelherodev>
What have I wrought onto this world?!
<leeward>
Reminds me of a famous telegram: WHAT HAVE PIXELHERODEV WROUGHT
<leeward>
wow, fail
<leeward>
Hath?
<leeward>
s/HAVE/HATH/
slice has joined #zig
slice has quit [Client Quit]
FireFox317 has joined #zig
<pixelherodev>
andrewrk: is there a way to retrigger a specific CI without pushing? Alternately, what's a good way to debug a CI failure on an OS I don't have?
<andrewrk>
get access to the OS
<andrewrk>
somehow
craigo has joined #zig
<pixelherodev>
:P
Xavi92 has joined #zig
<leeward>
pixelherodev: Lots of CI setups will have a way to remotely connect to a session. Which CI is failing?
<euantor>
If using sr.ht, you can SSH into a build VM and run tests there
<pixelherodev>
Or
<pixelherodev>
other option
<pixelherodev>
figure out what platform-specific changes I made :P
<leeward>
Sure, if you're a member of the "guru meditation" school of debugging.
<pixelherodev>
It's not that big.
<pixelherodev>
~50 lines maybe
<pixelherodev>
Platform specific should be miniscule
<leeward>
I'm not saying there's something inherently wrong with *think think* as a method of debugging. It works sometimes.
<leeward>
Not my style though. I like to watch it fail.
<pixelherodev>
THat would require installing Windows
<pixelherodev>
Which would be a pain
<pixelherodev>
Take forever
<pixelherodev>
and probably be harder than just reading the code
<leeward>
Or using remote desktop to connect to a windows VM hosted by the CI people...
<pixelherodev>
I don't think that's possible lol
<pixelherodev>
and I think I found the problem anyways
<leeward>
I don't know what the gentoo incantation is, but rdesktop is a thing that runs on Linux.
<pixelherodev>
right but
<pixelherodev>
I don't think CI offers that ?
<pixelherodev>
and
<leeward>
Which CI?
<leeward>
I know that some do.
<pixelherodev>
I don't think it'd be easier than this anyways
<leeward>
For your 50 lines where you've already found the problem? Probably not. For the future? It's a good tool to have in the belt.
<pixelherodev>
That depends on a single assumption
<pixelherodev>
I'm ever going to touch Windows code in a way that's more than this :P
<leeward>
True!
<pixelherodev>
I'd have to be either very desperate or receive a loooot of zeroes to consider that lol
<pixelherodev>
and the latter probably wouldn't work either TBH
<leeward>
Personally, I've only ever had 1 project where I cared enough about Windows to build CI for it. That actually targeted cygwin, which made life a bit easier.
<pixelherodev>
I don't have much use for a lot of zeros
<pixelherodev>
I have a lot of motivation to avoid Windows
<leeward>
It's that 1 before them that helps.
<pixelherodev>
You know what I mean :)
<pixelherodev>
I'm not interested in e.g. being a millionaire. Money is only worth what it can buy, and frankly, my total material desires probably amount to a rounding error most people that rich :P
<leeward>
Zig is a good example of a reason to care about Windows code though. If you write something and you want lots of people to use it, Windows support is somewhere between "must" and "probably should."
<pixelherodev>
Good laptop, comfy place to nap, good wifi. That's it.
<pixelherodev>
:P
<leeward>
Spoken like someone who grew up comfortable.
<pixelherodev>
Nah
<pixelherodev>
Not remotely
<pixelherodev>
More than many, sure
<pixelherodev>
But my parents were... not something I'm discussing on here :P
<pixelherodev>
To put it better: relative to Americans, no.
<pixelherodev>
I still recognize how fortunate I am relative to many parts of the world
<leeward>
You have time. Young, single, and broke is a fine place to be.
<pixelherodev>
That's the hope
rappet has quit [Ping timeout: 272 seconds]
<leeward>
I don't want to get into the wonders of having money. They're not much of a reason to compromise principles.
sacredbirdman has joined #zig
rappet has joined #zig
<leeward>
Making your stuff useful to the most people possible, though, that's all the wedge windows needs. These days, anyway.
<pixelherodev>
Not for me.
<pixelherodev>
I agree with you, principles are vastly more important than money to me
<pixelherodev>
I disagree on the WIndows thing
<pixelherodev>
I've officially dropped Windows support in most of my stuff
<pixelherodev>
I don't go out of my way to not support it, but if it's broken, *I* won't be the one patching it
<pixelherodev>
If someone wants Windows support, and they send a patch, I'd merge it, but I won't waste my time supporting a platform I consider unethical
<leeward>
Would you accept patches that fail the Windows CI?
<pixelherodev>
I wouldn't *have* such CI set up lol
<leeward>
After that hypothetical person's patch is merged, obviously.
<leeward>
Because they're thorough and they included it.
<pixelherodev>
Ah, then no.
<pixelherodev>
I wouldn't allow patches that break any platform - I just won't be the one to support it.
<pixelherodev>
If there's enough support for someone to add that CI, then they've done what I'd consider the reasonable minimum, and I'm not going to spite them by doing that.
<Xavi92>
if using gdb, how could I read a memory address with an arbitrary size? In C, I'd use e.g.: `p *(int *)0x80010000`
<leeward>
It's the same as C.
<leeward>
Oh, you mean instead of p?
<Xavi92>
leeward: so it's still using the C data types?
<leeward>
x /72xb 0x80010000
<leeward>
In gdb it is.
<Xavi92>
leeward: thanks!
<sacredbirdman>
pixelherodev: would you have time to help me with the compiler crashing?
<sacredbirdman>
or should I just post the problem somewhere
<pixelherodev>
sacredbirdman: what's the issue?
<pixelherodev>
Segfault?
<pixelherodev>
Ehh, post it to GitHub Issues
<sacredbirdman>
not segfault.. it just says it quit unexpectedly
<pixelherodev>
I'll take a look if I have time, but it means anyone else can too :)
<sacredbirdman>
at some point I'd be interested in knowing how to drill down on issues like this
<pixelherodev>
Anyone know if the leak checker for the stdlib applies to stage1, too?
<sacredbirdman>
but I'll post it to github
<sacredbirdman>
I got a minimal non-working example =)
<leeward>
Wow, I just discovered that the thing I told Xavi92 was kinda wrong. You can cast to a u64 or a usize or whatever in gdb too.
<leeward>
Fun times.
ur5us has joined #zig
Akuli has quit [Quit: Leaving]
FireFox317 has quit [Remote host closed the connection]
FireFox317 has joined #zig
shcv has joined #zig
reductum has quit [Quit: WeeChat 2.8]
satchmo has joined #zig
wootehfoot has quit [Read error: Connection reset by peer]
<shcv>
does anyone have examples of UDP networking, or documentation references? Based on looking at the std.os source it looks pretty similar to C, but I'm not sure if there are differences I should be aware of
<lunamn>
you can look at std.net as well, it isn't complete, but it could help
st4ll1 has quit [Ping timeout: 256 seconds]
st4ll1 has joined #zig
<FireFox317>
shcv, jup std.net is supposed to be a high level networking api IIRC. However currently only linux has quite okay support i think
<FireFox317>
high-level cross-platform i should say
<pixelherodev>
std.net is the long-term API, but short-term, std.os is the way to go
<pixelherodev>
Or, you can build up std.net ;_
<pixelherodev>
;)
<pixelherodev>
*
st4ll1 has quit [Ping timeout: 256 seconds]
sacredbirdman has quit [Remote host closed the connection]
_Vi has quit [Ping timeout: 260 seconds]
<FireFox317>
daurnimator, while implementing the complete (without vector stuff) systemV ABI for x86_64, I looked at the Clang source code and found where they handle bitfields. I think this might be relevant for your 'Linux kernel module project' and PR #4165 that you submitted. The relevant Clang code is in https://github.com/llvm/llvm-project/blob/master/clang/lib/CodeGen/TargetInfo.cpp#L2893-L3011 . This is in a classify function that chooses
<FireFox317>
which type a paramater should be passed in (stack, register etc). The Zig code that does this classifying is currently in analyze.cpp:7951 -> function `type_system_V_abi_x86_64_class`.
<FireFox317>
Maybe I should have added this to the relevant issue/PR tho
* ikskuh
pokes shcv into the direction of zig-network
<pixelherodev>
FireFox317: what parts of the ABI did you implement? This is for stage1?
<ikskuh>
shcv, https://github.com/MasterQ32/zig-network, implements UDP/TCP for windows/posix, no async atm, but provides crossplatform polling/waiting abstractions
<ikskuh>
pixelherodev: did you forget about me and kristoff?
<pixelherodev>
ikskuh: busy with IRL stuff for a bit, sorry
<ikskuh>
oh, okay
<pixelherodev>
Give me an hour or so :(
<ikskuh>
we already talked our stuff, i'm going to bed now
<ikskuh>
:D
* pixelherodev
waves
<pixelherodev>
night :)
<ikskuh>
await ikskuh.sleep();
<FireFox317>
pixelherodev, yes stage1 indeed. passing c types as paramaters and returning them too. Basically complete support for all structs/unions, but also arrays. basically issue #1481 and then all the x86_64 points
<pixelherodev>
Ahh, nice :)
<pixelherodev>
I still only have integers for my stuff :P
<pixelherodev>
Well, INTEGERs
<pixelherodev>
I'm sure *you* know what I mean :D
<FireFox317>
:D
<FireFox317>
definitely
<shcv>
ikskuh: thanks, I'll look at it
<ikskuh>
it's even tested! :D
<shcv>
pixelherodev: I don't mind contributing to std.net, though I don't know what the plan is for the API
<FireFox317>
but luckily (?) we have llvm in stage1, so i dont have to look at all the small details (which register etc)
<pixelherodev>
shcv: I think the API is already largely decided
<pixelherodev>
If you implement stuff platform-specific in your own project, it should be relatively simple to port it later
<ikskuh>
pixelherodev: not really
<ikskuh>
windows sockets are different enough from linux to require a special care for async
<pixelherodev>
Ugh, really? Dammit
<pixelherodev>
There I go making assumptions about sanity again :)
<FireFox317>
shcv, pixelherodev I dont think it is. andrewrk just added it for his needs (i think?). The API can definitely still change
<FireFox317>
lol ikskuh fast
<pixelherodev>
Ahh
<pixelherodev>
Good o know
<pixelherodev>
to*
<pixelherodev>
I'll stick to stage2, thanks :)
<ikskuh>
zig-network actually will support async soon for windows
<ikskuh>
it should work in theory for linux, but seems like the real world is a bit different
<ikskuh>
will look into this soon. if it's "good enough", we can merge the lib into zag
<ikskuh>
and have actual networking code in there!
<leeward>
zag?
<shcv>
yay
<ikskuh>
zig std
<shcv>
also http looks a bit sparse...
<ikskuh>
yeah, sadly
<shcv>
so I might look into helping out with that a bit too
<ikskuh>
h11 is there, but not really good :(
<ikskuh>
both API vise and quality of implementation :(
<satchmo>
I think they just moved the function to target.zig, that's where I found ptrBitWidth
<pixelherodev>
leeward: never mind then :(
<pixelherodev>
maybe I imagined it
* pixelherodev
shrugs
<pixelherodev>
I do remmeber a discussion on the matter
<pixelherodev>
Might have been a comment in an unrelated thread though
<leeward>
ifreund: That is certainly relevant, and full of good points.
Aransentin has quit [Remote host closed the connection]
arekishi has joined #zig
<arekishi>
How do i cast a pointer (to a struct) to a []const u8? im trying to send a serialized struct over an unix socket with the File.writeAll function
<satchmo>
mem.asBytes?
<ifreund>
@ptrCast([]const u8, ptr) really
<fengb>
asBytes is safer as it adds some size checks
<ifreund>
oh on, use asBytes if you don't want things to go bad
<arekishi>
thanks, i thought i tried that but i guess i didn't
<ifreund>
*oh no
<fengb>
But... regular structs don’t have well defined memory layout so be warned
<ifreund>
yeah this doesn't seem like a thing you really want to do tbh
<satchmo>
would using packed structs help for serialization or nah
<arekishi>
hmm @ptrCast doesn't work in that way but mem.asBytes works for me. ` error: expected pointer, found '[]const u8'`
<arekishi>
and here is the code: `@ptrCast([]const u8, &buffer)`
<arekishi>
im making a zig version of xcb, lots of structs and fields. It cleaned to use as struct than manually copying each field with arithmetic and memcpy
daex_ has quit [Ping timeout: 265 seconds]
<arekishi>
cleaner*
<leeward>
That last bullet concerns me. "Non-ABI-aligned fields are packed into the smallest possible ABI-aligned integers in accordance with the target endianness."
<leeward>
Does that mean that SPARC can't have fields smaller than u32 even in packed structs?
<leeward>
Or is it saying that there will be padding if I try to put a u32 after a bool?
reductum has quit [Quit: WeeChat 2.8]
<leeward>
Oh, never mind. I misread it. It's saying that 16 bools make 2 bytes if bytes are allowed.
ur5us has quit [Ping timeout: 260 seconds]
FireFox317 has quit [Ping timeout: 272 seconds]
Snetry has quit [Ping timeout: 272 seconds]
Snetry has joined #zig
<daurnimator>
arekishi: if you have a pointer type you slice it: `@ptrCast([*]u8, ptr)[0..@sizeOf(ptr)]`
<daurnimator>
arekishi: though note we have helpers for this: `std.mem.toBytes` I think?