<zfoo>
does zig have an equivalent to 'if_nametoindex' in C?
dec05eba has joined #zig
<lunamn>
zfoo: maybe std.net.if_nametoindex could be made public
<zfoo>
would be convenient
<dec05eba>
my 30 bytes packed struct gets padded automatically to 36 bytes. Is there a way to prevent that? the doc for packed struct only mentions that there is no padding between fields
<dec05eba>
also why would it get padded to 36 bytes, not 32?
<daurnimator>
dec05eba: packed structs are quite broken
<dec05eba>
oh no..
<pixelherodev>
Yeah :(
xackus has joined #zig
ifreund has quit [Ping timeout: 256 seconds]
nephele_ has joined #zig
nephele has quit [Ping timeout: 256 seconds]
nephele_ is now known as nephele
satchmo has quit [Ping timeout: 246 seconds]
dingenskirchen1 has joined #zig
dingenskirchen has quit [Ping timeout: 252 seconds]
dingenskirchen1 is now known as dingenskirchen
<ttmrichter>
daurnimator: Really? That presents a bit of a bind for my use case.
<daurnimator>
ttmrichter: if you pad everything to byte boundaries then you can get by for now
<ttmrichter>
Well, since the peripherals are all basically a bunch of 32-bit integers with bit fields, that doesn't sound so bad. One thing I couldn't see immediately, however, was how to define a field that's 3 bits wide or the like. Or is that using "u3" as a type?
<shakesoda>
yeah, that would be u3
<shakesoda>
zig has arbitrary integer sizes
<leeward>
hah
satchmo has joined #zig
<ttmrichter>
OK, that's nice to have.
<leeward>
So I'm trying to make the case for "uword" or similar types, and I figured I'd take a look at some aarch64 disassembly to see how it handles 32-bit overflow. My first attempt had it popping and pushing the value inside the loop to the stack. Ok, -O0 is stupid. Of course, I remembered why I used -O0 when -O1 emmitted the hard coded result and just skipped the loop entirely. I guess I do have to play this game. Oh look, making it volatile
<leeward>
goes back to pushing and popping from the stack.
<ttmrichter>
Especially if it's actually defined to be packed in order, etc.
<leeward>
And...if I use -O3, it partially unrolls the loop but still fiddles with the stack.
<ttmrichter>
The next question I haven't found an immediate answer for: can I coerce an arbitrary integer into a pointer to a specific struct?
<ttmrichter>
For instance I have five USARTs. They're all structured (almost) identically in ways that I can capture as a struct. Can I then say "0x40013e00" is a pointer to that struct?
<daurnimator>
ttmrichter: `@intToPtr`
<ttmrichter>
Ah, nice! It's a function, not an operator. That's where I missed.
<daurnimator>
ttmrichter: its not a function either; its a builtin
<ttmrichter>
Builtin isn't short for "builtin function" a.k.a. BIF?
<daurnimator>
nope
<ttmrichter>
OK. I'll dig into the distinction there then.
<daurnimator>
builtins can do things functions can't do; e.g. `@field(somestruct, "somefield") = blah;`
<leeward>
Note how the C version uses a 32-bit value because it's a single instruction.
<daurnimator>
leeward: you need %+
<leeward>
daurnimator: I don't.
<leeward>
+% would get the same behavior in debug as release-small and release-fast. What I want is for it to emit faster code, like in the C example (PRIuFAST16 is a uint32) in release-fast and release-small.
<leeward>
Of course, I don't want it so bad that I want to make a stink about it. It's just a thing that exists in C that I use sometimes.
<leeward>
Probably not worth the cost to add to a language like Zig.
<leeward>
Better off making a library with a bunch of switches based on architecture and `const ufast16 = u32` and the like.
<leeward>
Sometimes having types as values is convenient.
<daurnimator>
leeward: ah right. just because zig currently picks u16 doesn't mean it *has* to.
<ttmrichter>
leeward: Having types as values is one of the things that has me interested in Zig.
<daurnimator>
leeward: instead of printing 0, a different optimization in zig may make it print 65536
<leeward>
right
<leeward>
I guess that's not so much a language issue as an optimization issue.
<leeward>
Which is way down at the bottom of the list.
<daurnimator>
leeward: what makes you think the optimization C does is better anyway?
<daurnimator>
leeward: they both entirely compute it at compile time :P
<pixelherodev>
Or have it check `if (32_fastest && size < 32) {} else if (64_fastest)` etc
<pixelherodev>
Heck, here's an idea
<pixelherodev>
Have it modify *writes* to the higher size
<pixelherodev>
But leave *reads* alone
<pixelherodev>
That should allow for better optimizations, and make e.g. debugging / printing it give the right value even if it silently wraps
waleee-cl has quit [Quit: Connection closed for inactivity]
<hspak>
Is there a way for "fs.cwd().openFile()" to create the file if it doesn't exist?
<daurnimator>
hspak: use `createFile` instead
<hspak>
Oops, must've missed that while reading through the source, thanks daurnimator!
swills has joined #zig
leeward has quit [Ping timeout: 264 seconds]
leeward has joined #zig
keegans has quit [Quit: WeeChat 2.7]
<leeward>
hooray, new router
<pixelherodev>
Nice
ur5us has quit [Ping timeout: 260 seconds]
dermetfan has joined #zig
st4ll1 has joined #zig
st4ll1 has quit [Quit: WeeChat 2.8]
ur5us has joined #zig
cole-h has quit [Quit: Goodbye]
dddddd has quit [Ping timeout: 260 seconds]
gpanders has quit [Ping timeout: 264 seconds]
ur5us has quit [Ping timeout: 260 seconds]
wootehfoot has joined #zig
gpanders has joined #zig
ur5us has joined #zig
_Vi has joined #zig
Snetry- has quit [Ping timeout: 246 seconds]
FireFox317 has joined #zig
Snetry has joined #zig
dermetfan has quit [Quit: WeeChat 2.7.1]
dermetfan has joined #zig
hermier has quit [Ping timeout: 256 seconds]
Tharro has joined #zig
Kingsquee has quit [Quit: Konversation terminated!]
ifreund has joined #zig
hermier has joined #zig
squeek502_ has joined #zig
ave_1 has joined #zig
ave_1 has quit [Client Quit]
ave_5 has joined #zig
gpanders has quit [Ping timeout: 265 seconds]
Syrup has joined #zig
zfoo has quit [Ping timeout: 265 seconds]
fraktor has quit [Ping timeout: 265 seconds]
Syrup is now known as SyrupThinker
SyrupThinker has quit [Ping timeout: 265 seconds]
ave_ has quit [Ping timeout: 265 seconds]
squeek502 has quit [Ping timeout: 265 seconds]
ave_5 is now known as ave_
gpanders has joined #zig
bbrittain has quit [Ping timeout: 246 seconds]
bbrittain has joined #zig
rappet has quit [Ping timeout: 246 seconds]
rappet has joined #zig
ur5us has quit [Ping timeout: 260 seconds]
craigo has quit [Ping timeout: 265 seconds]
dddddd has joined #zig
mgxm_ has joined #zig
redj_ has joined #zig
ifreund has quit [Ping timeout: 246 seconds]
hspak has quit [Ping timeout: 246 seconds]
jwmerrill has quit [Ping timeout: 246 seconds]
mgxm has quit [Ping timeout: 246 seconds]
mgxm_ is now known as mgxm
ifreund1 has joined #zig
bkleiner has quit [Ping timeout: 264 seconds]
so has quit [Ping timeout: 264 seconds]
niftynei has quit [Ping timeout: 264 seconds]
Amun_Ra has quit [Ping timeout: 264 seconds]
redj has quit [Ping timeout: 264 seconds]
lohengrin has quit [Ping timeout: 264 seconds]
hspak6 has joined #zig
so has joined #zig
lohengrin has joined #zig
niftynei has joined #zig
Amun_Ra has joined #zig
neceve_ has joined #zig
swills has quit [Ping timeout: 256 seconds]
swills has joined #zig
swills has quit [Ping timeout: 265 seconds]
swills_ has joined #zig
frmdstryr has joined #zig
dermetfan has quit [Ping timeout: 260 seconds]
redj_ is now known as redj
waleee-cl has joined #zig
ifreund1 is now known as ifreund
wootehfoot has quit [Quit: Leaving]
salotz has joined #zig
doublex has quit [Remote host closed the connection]
doublex has joined #zig
sarmonsiill has quit [Ping timeout: 240 seconds]
Akuli has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
doublex has quit [Ping timeout: 240 seconds]
<scientes>
generating a new function from stage1 is not easy
<scientes>
*function call
<scientes>
not an actual function
doublex has joined #zig
<scientes>
I can do this in LLVM
Xavi92 has joined #zig
<Xavi92>
is it guaranteed by zig enums start from zero by default, as in C?
<scientes>
Xavi92, no
<Xavi92>
scientes: are they still ordered sequentially?
<scientes>
no
<scientes>
I mean, they are, but no guarantees
<Xavi92>
scientes: okay, thanks!
<pixelherodev>
Currently, they are
<pixelherodev>
If you need that behavior guaranteed, use an extern enum
<pixelherodev>
IIRC
<pixelherodev>
Hmm
<ikskuh>
extern enum or explicit assignment
<pixelherodev>
Zig linter idea: detect enums where @enumToInt / @intToEnum is used without explicitly defined values
<ikskuh>
well, this still is a legal behaviour
<ikskuh>
for serialization/deserialization
<pixelherodev>
Yes, *but*
<ikskuh>
but not a future proof one
<pixelherodev>
^
<pixelherodev>
that, and a linter isn't meant to be "YOUR CODE IS BADDDDD"
<pixelherodev>
It's meant to be a "Hey, you might want to verify this"
<pixelherodev>
It's a tool to help the user, not to make decisions for you.
<Xavi92>
thanks for your tips! Not that I need to interface C ABI, but feeling lazy to define a set of constants with explicit values
SimonNa has quit [Remote host closed the connection]
<Xavi92>
@compileLog is returning 5 for `@sizeOf(Gp1)`, but was expecting 4. Why is that? https://bpa.st/XGRQ
<pixelherodev>
GP1?
<pixelherodev>
Ahh linked
<pixelherodev>
Xavi92: bug
<pixelherodev>
Known bug :(
<pixelherodev>
Packed structs are largely broken
<Xavi92>
Oh :(
<pixelherodev>
Yeah.
<pixelherodev>
It sucks :(
<Xavi92>
pixelherodev: packed structs are a tough problem to solve I guess
<Xavi92>
pixelherodev: I'll stick to manual bit masks for the time being, thanks anyway!
SimonNa has joined #zig
<scientes>
uggh, it is a PITA to split a slice in stage1
<scientes>
into ptr and len
<scientes>
but I don't think the C ABI is nice to slice structs
<pixelherodev>
scientes: you mean internally, within the compiler?
<scientes>
yes
<pixelherodev>
Gotcha
<scientes>
especially in codegen.cpp
<scientes>
probably have to do so in ir.ccp first
<pixelherodev>
How are `.ptr` / `.len` implemented for slices?
<scientes>
basically i have to call those
<pixelherodev>
That's the pain?
<pixelherodev>
What are you trying to do?
<pixelherodev>
What's the endgame, rather
<scientes>
I've got a algorithm for doing switch on []u8
<pixelherodev>
Passing slices to C callconv functions as ptr + len?
<pixelherodev>
Huh
<scientes>
but it needs a run-time interpreter
<FireFox317>
Xavi92, if you replace the packed's with extern it will work I think. reserved might need to be split into two fields, a u8 and a u16
<fengb>
Packed would work if you split reserved into u8 and u16
<Xavi92>
FireFox317: as in here? https://bpa.st/JVZA That causes @sizeOf(Gp1) == 6 because of alignment requirements
<Xavi92>
fengb: that worked!
<fengb>
Let’s do the rain dance of making the compiler work :P
<FireFox317>
Xavi92, hmm what about 4 u8's? :D
<FireFox317>
oh lol did not read fengb's sugestion
cole-h has joined #zig
* Xavi92
dances
<fengb>
I think anything bigger than u8 has “natural” sizes and packed doesn’t properly ignore them
<fengb>
So if they don’t line up, it gets really confused
<pixelherodev>
Hmm
<pixelherodev>
Nah, I'm focusing on stage2
<pixelherodev>
Gonig to finish the error_tests changes today
<FireFox317>
Good job pixelherodev
<pixelherodev>
:P
<pixelherodev>
Next Zig task is a refactoring tool :)
<pixelherodev>
I started on one months ago but
<pixelherodev>
well
<pixelherodev>
I forgot to save it when I wiped my PC
<pixelherodev>
So I lost motivation entirely :P
<pixelherodev>
:(
<companion_cube>
refactoring tool -> you mean zls, right? :p
<FireFox317>
Well a refactoring tool is basically zls
<pixelherodev>
No
<FireFox317>
lol
craigo has joined #zig
<pixelherodev>
Refactoring as in `zrf package.struct.function.local package.struct.field` should move a local var and update references to it
<ikskuh>
yeah that's job of a language server
<pixelherodev>
Boo.
<companion_cube>
that's definitely the job of LSP
<pixelherodev>
:(
<pixelherodev>
Everyone's a critic.
<companion_cube>
cause instead of typing the whole field (if it even has a name)
<companion_cube>
you just say "do this where my cursor is"
<fengb>
Cursor? That's heresy
<companion_cube>
do you write code with ed? :p
<ikskuh>
language server style is
<ikskuh>
"hover a field with the cursor, press F2, enter a new name, press enter, have all references renamed"
<companion_cube>
^
<ikskuh>
one refactoring which i think would be absolutely awesome is "extract method/function"
<ikskuh>
select a piece of code, tell your refactoring tool that it should separate this into a function and replace the selected code with a function call
<companion_cube>
like java IDEs do…
<ikskuh>
if we get such power to zls, it would be really awesome
<pixelherodev>
:(
<pixelherodev>
fine. I'll stick to stage2. I see how it is.
<pixelherodev>
(joking, joking)
<pixelherodev>
(you're probably right :)
<companion_cube>
you can make the refactoring tool into a library that zls might use :p
<companion_cube>
or any other frontend
* pixelherodev
shrugs
<pixelherodev>
no point
<pixelherodev>
it would be worse
<pixelherodev>
ZLS uses its own parsing
<pixelherodev>
Using a library for refactoring would be inefficient
<pixelherodev>
A library for general usage isn't a bad idea though
<pixelherodev>
But it'd make more sense to do it the other way around
<pixelherodev>
Add the functionality to ZLS, make a ZLS library
<pixelherodev>
So you can import ZLS from Zig code and use its tools natively
<pixelherodev>
Without needing an actual LSP client
<ikskuh>
afaik ZLS uses stage2 parser
<pixelherodev>
It does
<pixelherodev>
But I mean, it caches data
<pixelherodev>
So there's no point in *re* parsing everything for refactoring
<fengb>
"The licensing cost was steep—estimates were as high as $500,000—but Broussard reasoned that it would **save time** used to write a new engine."
* pixelherodev
bursts into laughter
<pixelherodev>
Alrighty, fixed the problems mentioned on 5422, just need to finish the impl :)
satchmo has left #zig ["WeeChat 2.8"]
<ifreund>
does using orelse on a [*c] pointer not work?
<leeward>
Is it ![*c]?
<leeward>
They can be cast to optional types, right?
<ifreund>
it's just [*c]
<ifreund>
i think the orelse might actually be working but something werid is definitely going on here
<leeward>
easy enough to find out
<ifreund>
ok, no it looks like I'm doing something wrong. The error message led me a little astry
<pixelherodev>
Alrighty, transformation updates are good now :)
FireFox317 has quit [Ping timeout: 260 seconds]
<leeward>
ifreund: Confirmed: a [*c] with value 0 will trip an orelse.
<ifreund>
leeward: thanks for testing that
<ifreund>
It seems I have indeed screwed up something else
<leeward>
no problem
ur5us has joined #zig
Akuli has quit [Quit: Leaving]
neceve_ has quit [Ping timeout: 265 seconds]
xackus has quit [Ping timeout: 258 seconds]
kushalp has quit [Ping timeout: 260 seconds]
tracernz has quit [Ping timeout: 256 seconds]
waleee-cl has quit [Ping timeout: 246 seconds]
rzezeski has quit [Ping timeout: 246 seconds]
wjlroe has quit [Ping timeout: 272 seconds]
yrashk has quit [Ping timeout: 272 seconds]
dch has quit [Ping timeout: 260 seconds]
utzig has quit [Ping timeout: 260 seconds]
eddyb[legacy] has quit [Ping timeout: 260 seconds]