<plumm>
same with function arguments; if there is an argument mismatch can't the compiler show me the signature so I don't have to jump to the source to know which place things go?
dimenus has joined #zig
<stratact>
daurnimator: I'm working on it, thank you for the lua source too. Earlier I just didn't have the confidence and I felt inspired by andrewrk when he made it contributor friendly to learn it more. I also got that book for reference/learning
<daurnimator>
stratact: `man tzfile` is all you need :)
<stratact>
I see what you did there. Thank you :)
<protty>
andrewrk: do you remember how you recorded time spent in functions using `perf`?
<daurnimator>
protty: `perf record`?
<protty>
am getting perf.data and trying to open it with perf report but it doesnt seem to display anything noteworthy
<daurnimator>
protty: -g ?
<daurnimator>
protty: may also want -F 99
protty has quit [Ping timeout: 260 seconds]
reductum has quit [Quit: WeeChat 2.6]
qbradley has quit [Remote host closed the connection]
waleee-cl has quit [Quit: Connection closed for inactivity]
<Flaminator>
Is there any specific reason why the `address of` operator is a prefix operator instead of a postfix operator like .* is?
<daurnimator>
Flaminator: I've actually been asking that question myself lately. I think its because a postfix *operates* on the result; but address of isn't really that.
<daurnimator>
Flaminator: e.g. &foo.bar -> it's not getting bar and taking the address of it; it's changing the "." operator for the current expression
<Flaminator>
Isn't &foo.bar actually foo.bar.&?
<Flaminator>
So you get the address of bar and not foo.
<daurnimator>
Flaminator: but foo.bar might load bar into a register. or make a copy on the stack
<Flaminator>
But wouldn't the end result be the same? a.b has a higher precedence than & has.
<daurnimator>
Flaminator: no. imagine if `foo.bar` made a copy of bar on the stack
<daurnimator>
--> then `foo.bar.&` would be a stack address.
<daurnimator>
rather than the location of `bar` inside of `foo`
<daurnimator>
likewise `&foo.bar.qux` -> the & operator essentially changes the semantics of `.` for the expression.
<shachaf>
lvalues are the weird thing here, not &
<shachaf>
Assignment also "changes the semantics" because x.y = 5 doesn't read the value of x.y.
<shachaf>
The difference, I guess, is that in a.*, a is used an rvalue (i.e. just a value). In &a, a is used as an lvalue (which is really more like a memory location).
<adamkowalski>
Huh it's literarly the syntax I posted? I wonder why it wasn't working for me. I'll try again
<adamkowalski>
Also if I have a struct with a compile time parameter how do I get get access to it from outside of that struct?
<plumm>
Foo.bar
<plumm>
compile time parameter being... sorry if i misunderstood
<adamkowalski>
fn Foo(comptime T: type) type {
<adamkowalski>
return struct {
<adamkowalski>
bar: type = T,
<plumm>
ok, wdym outside?
<adamkowalski>
}
<adamkowalski>
}
<plumm>
@typeOf(Foo(usize).bar) ?
<adamkowalski>
bar is a type
<adamkowalski>
it's not a value
<plumm>
ok, so then just access bar directly
<plumm>
you can also use the above if bar's type is computed based on T
<adamkowalski>
Okay I'll post some code on pastebin, because I tried that and it doens't work
<adamkowalski>
Actually I want to do the oposite. I have a graph and it will contain elements of type T. I want to write a free function which takes a graph and a value as long as value can be converted to the element type of the graph
<adamkowalski>
traviss: sorry I didn't reply to that earlier. But I am not a fan of that solution. I think it's interesting, however constant is still now a privleged function
<adamkowalski>
People who want to add new functions that modify the graph will not be able to leverage that as the struct is in a library presumably
<traviss>
ok just making sure you saw it
<adamkowalski>
I am not a fan of member functions in general since you cannot crack open the struct and add new ones
<daurnimator>
adamkowalski: you probably want: `const elementType = T;`
<adamkowalski>
So I want what you posted but only using free functions haha
<adamkowalski>
daurnimator: awesome, thanks!!
<daurnimator>
adamkowalski: fields of type `type` need to be comptime known; which means they have to be const; or inside a comptime-only struct.
<adamkowalski>
I was trying the comptime keyword instead of const haha
<adamkowalski>
Man everything in Zig ends up being so clean and simple. Sometimes I feel like I overcomplicate things and the right solution ends up being the obvious thing to try haha
<adamkowalski>
I got it to compile. Is this how you all would approach writing that function? There is some repition with the type deduction: https://pastebin.com/b2QgdBnE
<mq32>
i programmed that machine a bit (literally the thing on the photo)
<mq32>
it's a quite cool architecture to code, but the machine we (i'm a bit with the computer museum) have has some glitch that will make the core memory lose its contents :(
<mq32>
also, if you ever come to stuttgart: visit the computer museum!
<FireFox317>
Owh, that's a nasty glitch indeed XD But the computer looks so cool tho!
<mq32>
yeah that's why i wanted to hack some stuff with it :D
<mq32>
but i failed at a "better" bootloader
<FireFox317>
Yes! I'm only 6 hours from stuttgart, so will probably be there some time :)