ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
realtingdata has joined #zig
vegecode has joined #zig
zolk3ri has quit [Remote host closed the connection]
alexnask has quit [Ping timeout: 264 seconds]
<vegecode>
I've found something interesting when compiling Zig for msp430. I'm not 100% sure if it's a bug per se, but it is not allowing me to use a call to std.mem.set during my _start nakedcc entry point.
<vegecode>
I'm also not sure if the mistake is my fault, or Zig
<vegecode>
I am using nakedcc to avoid generating a prologue because the stack hasn't been set up yet. Maybe it just isn't possible to use auto variables in a nakedcc function? Assembly only. It seems like it should be possible.
<vegecode>
Or is there another function attribute or something like that that I can use to decrement the stack pointer myself with assembly?
<vegecode>
Now that I typed that out, it makes sense that you can't have auto variables in a nakedcc function, but I'm still surprised that the call to mem.set was inlined (I think)
<vegecode>
Is there a way to declare a function call as no-inline?
<vegecode>
I might just be trying to get something to work that can be easily stepped around by just calling a function to do the non-assembly initialization within _start
<vegecode>
Well nevermind, I think I found my own answer. I need to get a rubber duck to talk to.
realtingdata has quit [Ping timeout: 260 seconds]
bheads has quit [Remote host closed the connection]
bheads has joined #zig
<GitHub140>
[zig] tiehuis opened pull request #1139: Add floating-point internal bit representation to TypeInfo (master...float-typeinfo) https://git.io/fYMqh
dbandstra has joined #zig
<andrewrk>
vegecode, I think sadly we are in far different timezones
<andrewrk>
I'll be around later
<vegecode>
I'm in Missouri. I'm making great progress again now though. I thought about it all day, apparently all I needed was to type it out in here to figure out my issue. Didn't even need an answer!
<vegecode>
I have noticed that llvm replaced my call to mem.set with a call to libc's memset when I added the flag --release-fast.
<vegecode>
I am really loving Zig so far! Have a great night!
vegecode has left #zig [#zig]
lqd has quit [Ping timeout: 256 seconds]
odc has quit [Ping timeout: 256 seconds]
l1x has quit [Ping timeout: 276 seconds]
cgag has quit [Ping timeout: 256 seconds]
strmpnk has quit [Ping timeout: 256 seconds]
monteslu has quit [Ping timeout: 256 seconds]
jzelinskie has quit [Ping timeout: 260 seconds]
ragge has quit [Ping timeout: 260 seconds]
saolsen has quit [Ping timeout: 276 seconds]
chandlore_ has quit [Ping timeout: 276 seconds]
geocar has quit [Ping timeout: 276 seconds]
rayman22201 has joined #zig
JinShil has joined #zig
saolsen has joined #zig
l1x has joined #zig
lqd has joined #zig
monteslu has joined #zig
dbandstra has quit [Quit: Leaving]
geocar has joined #zig
odc has joined #zig
strmpnk has joined #zig
jzelinskie has joined #zig
chandlore_ has joined #zig
xtreak has joined #zig
cgag has joined #zig
saolsen has quit [Ping timeout: 256 seconds]
chandlore_ has quit [Ping timeout: 276 seconds]
l1x has quit [Ping timeout: 256 seconds]
geocar has quit [Ping timeout: 256 seconds]
lqd has quit [Ping timeout: 256 seconds]
strmpnk has quit [Ping timeout: 276 seconds]
odc has quit [Ping timeout: 265 seconds]
cgag has quit [Ping timeout: 248 seconds]
monteslu has quit [Ping timeout: 276 seconds]
jzelinskie has quit [Ping timeout: 276 seconds]
very-mediocre has joined #zig
chandlore_ has joined #zig
saolsen has joined #zig
cgag has joined #zig
geocar has joined #zig
lqd has joined #zig
l1x has joined #zig
strmpnk has joined #zig
jzelinskie has joined #zig
xtreak_ has joined #zig
<very-mediocre>
that's a *lot* of people joining o_o
l1x has quit [Max SendQ exceeded]
monteslu has joined #zig
l1x has joined #zig
xtreak has quit [Ping timeout: 256 seconds]
odc has joined #zig
Hejsil has joined #zig
ragge has joined #zig
_nipc has joined #zig
xtreak has joined #zig
kristate has joined #zig
xtreak_ has quit [Ping timeout: 256 seconds]
_nipc has quit [Quit: _nipc]
alexnask has joined #zig
kristate has quit [Ping timeout: 245 seconds]
xtreak has quit [Remote host closed the connection]
xtreak has joined #zig
quc has joined #zig
JinShil has quit [Quit: Leaving]
zolk3ri has joined #zig
noonien has joined #zig
xtreak has quit [Remote host closed the connection]
<alexnask>
@kristate This looks like it should be fixed
<alexnask>
The issue was probably that @typeOf(init) would be *const T instead of T, looks like the code expects the naked type (T) so it should work fine
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
<alexnask>
@reify is going well btw, just aggregate types left
<andrewrk>
kristate: thanks for reminding me, I was looking forward to fixing that after #733
<kristate>
I am working on a PR right now
<kristate>
andrewrk: please check it over, should be ready in 5 minutes
<andrewrk>
Sounds good
<andrewrk>
I'll have a look
<andrewrk>
alexnask: exciting
<Hejsil>
@reify is to much power for me to use resposively
<Hejsil>
And I can't stop myself!
Hejsil has quit [Quit: Page closed]
<kristate>
going through tests
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
return0e has quit [Remote host closed the connection]
<very-mediocre>
isn't there a worry that every library will roll its own dialect of zig?
<very-mediocre>
or is that a desired property?
<very-mediocre>
metaprogramming is admittedly quite exciting though :)
return0e has joined #zig
<alexnask>
Right it's pretty good as is
<alexnask>
The only extra thing that @reify will enable that isn't achieavable now is generating aggregate types with an arbitrary amount of fields
<alexnask>
Right now, a type function can only fake such functionality by having an upper limit of fields and disabling some by defining them as void
<alexnask>
which I would argue is more messy than generating fields with iterative code
<very-mediocre>
been peeking at the repo on github, your work here is awesome btw :)
<alexnask>
I've only messed with @typeInfo stuff though, I want to work on other parts of the compiler after my finals are over
<very-mediocre>
still need to properly look into what can be done at comptime
<very-mediocre>
haven't had time unfortunately
<very-mediocre>
my exposure to metaprogramming is quite limited
<alexnask>
Everything that doesn't involve inline assembly and pointer arithmetic, pretty much
<alexnask>
+ working with types as values
<very-mediocre>
The gears in my head are spinning a bit
<very-mediocre>
Thinking of generating a perfect hashing function for a set of data at comptime
<very-mediocre>
that sort of thing
rayman258 has joined #zig
<very-mediocre>
but it's all very vague in my mind
<alexnask>
If you've used C++ constexpr you can think of comptime as a superset of that (but also kinda templates at the same time)
<very-mediocre>
I've used old school C++ prior to constexpr being a thing
<very-mediocre>
I get how it's templates
<alexnask>
Right, one usecase I can think of is generating sine/cosine tables
<alexnask>
This is something I bet C++ programmers would love to do but afaik constexpr doesn support floating point operations
<very-mediocre>
yeah that's pretty common
rayman22201 has quit [Ping timeout: 256 seconds]
<alexnask>
Basically comptime is used to generate any type of data at compile time and types just happen to be a type of data in that context
<very-mediocre>
also i guess it replaces the preprocessor
<very-mediocre>
i.e. conditional compilation
<very-mediocre>
still need to do a deep dive though
<alexnask>
So another example is vtables, you can use comptime to generate a unique vtable for each implementation type of an interface and store it in static memory
<very-mediocre>
right
<very-mediocre>
that's pretty cool
<very-mediocre>
I wonder if slightly improved OOP would be standard
<very-mediocre>
or if several paradigms could be imported
<very-mediocre>
metaprogramming brings lots of openness, it's scary
<very-mediocre>
probably unfounded fears i guess
<very-mediocre>
thinking of how JavaScript is disastrously without paradigms yet it works
<very-mediocre>
so surely zig is better than that even with metaprogramming
<alexnask>
I think as long as the standard library provides useful abstractions built on top of the metaprogramming features people will probably tend to use those
<alexnask>
Ofc the same thing is true if those are language features in the first place
<very-mediocre>
that's really it, like where do we draw the line
btbytes has joined #zig
<very-mediocre>
should vtables be a thing you import?
<very-mediocre>
I'm sure andrewrk has firm ideas about these things of course
<very-mediocre>
just when seen from outside these questions come up
<alexnask>
Right, attaching general information about the type in TypeInfo makes sense
<alexnask>
Ofc, Type: type would have to be omitted if we were to use it for @reify
<alexnask>
Unless the user had to manually set type=TypeInfo.SelfType or something similar
<MajorLag1>
Either that or @reify could override whatever it is set to. Omitting .Type shouldn't be a big deal because you had to have that to get the TypeInfo, but if you pass a TypeInfo around for some reason then there's no way to get the type back out of it.
isd has joined #zig
very-mediocre has quit [Ping timeout: 260 seconds]
noonien has quit [Quit: Connection closed for inactivity]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<andi3>
Hello, could someone give me an update on the current status interfaces? I kind of read the two issues "vtable abstraction" and "Proposal Interfaces" but am left with the impression that I=one is supposed to hack together his own script or use some 3rd party lib? Don' you think such an essential feature should be part of the standard?
<andi3>
also, saying "out meta programming can do this" somehow makes me afraid, because if I read ruby code it's always extremely bogus and there are all kind of crazy things going on under the hood of some code and I fear the same for zig with too much meta magic required to t=do a basic job.
<andrewrk>
andi3, my official stance on OOP / interfaces, is that there is an open issue to investigate whether such features are necessary: https://github.com/ziglang/zig/issues/130
<andrewrk>
I also have experience with ruby and have the same concerns as you
<andi3>
on the other hand golang code has yet been by far the most readable code in my experience ever, there has yet to come something I do not understand at all, it's just really easy to read for me
bheads_ has joined #zig
davr0s has joined #zig
<andrewrk>
the lack of features is a feature
bheads__ has quit [Ping timeout: 245 seconds]
<andi3>
I mean, that's only really true as long as it does not require strange workarounds, otherwise brainf*** would have an amazing "feature", rest assured, strange workarounds very much depend on the point of view
<andi3>
For me gelang interfaces are nice to work with, compared to java, and the only thing I miss, is the option to explicitly implement an interface and get compile time errors if I mess up. in go this can be done by using var _ SomeInterface = SomeStruct{} but this does not feel right, but is's okay to work with
<andi3>
(I miss this in some cases, not all the time)