ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
davr0s has joined #zig
davr0s has quit [Read error: Connection reset by peer]
wink_ has joined #zig
wink_ has left #zig [#zig]
wink_ has joined #zig
<unique_id>
Creating a vk.xml => vulkan.zig parser now. It's easy, but ugly code.
<wink_>
An Actor has a "fn processMessage(self: *Self: msg: *Message)" and I want to be able to create various types of Actors and dispatch messages to them from an ActorDispatcher.
<wink_>
An ActorDispatcher has an array of "actors: [maxActors]ActorPtr" my problem is I don't know how to properly create an ActorPtr so it can be cast or typed properly and invoke "actor.processMessage"
<wink_>
Of course, this may be the totally wrong approach, so any help appreciated.
<MajorLag>
Pretty sure you're going to need to use the interface pattern. Your array will have to be intrusive, pointing into the various structs at some common member (see allocator in std for how this works). In your case, it may just be an array of pointers to ProcessMessage fns.
<MajorLag>
er... actually it'd have to point to a member that's a pointer to the struct's ProcessMessage, and ProcessMessage would have to use @fieldParentPointer to get the parent struct.
<MajorLag>
This is because there's no way at runtime to know what type the array of pointers points to in any given index, so you don't know where its fields are and can't safely access it. But if you point to a member of the struct that is the same type in all of them, and that member in turn points to a function that is specific to the parent type, then that function knows where the member is relative to the parent and can
<MajorLag>
e parent and work with the fields.
tyler569 has quit [Ping timeout: 268 seconds]
<MajorLag>
I suppose another alternative is to make ActorPtr a struct { actor: @OpaqueType(), processMessage: fn(...), }. so it points to the actor and the actor's processMessage(). I haven't worked with OpaqueType much, but I think processMessage would need to take @OpaqueType for self and cast it to the appropriate type. Of course there's no way for the compiler to type check this, so if you mismatch the two in ActorPtr it
<MajorLag>
.
<MajorLag>
*oopsies.
bheads_ has joined #zig
bheads_ has quit [Ping timeout: 252 seconds]
tyler569 has joined #zig
qazo has joined #zig
qazo has quit [Ping timeout: 244 seconds]
tiehuis has joined #zig
<tiehuis>
Dirkson: I need to review the benchmarks games examples as currently i had only been making sure they compiled with latest
<tiehuis>
when I initially wrote them we didn't have threading support or anything so i figured i'd hold off until we get that (and maybe simd)
<Dirkson>
tiehuis: I didn't have any issues with zig. Oddly enough, it was most of the C stuff that wouldn't compile properly :D
<tiehuis>
i might clean it up a bit over the weekend however
<tiehuis>
i'll review the c reference code i picked and correct those if they aren't working
<andrewrk>
tiehuis, I'll prioritize SIMD in 0.4.0
<tiehuis>
i'm actually getting segfaults on all of them too as well
<Dirkson>
It'd surprise me if they weren't. It's more likely to be something funky with the copy of linux I'm compiling on top of - I've not done much compilation on that machine.
<Dirkson>
tiehuis: Oh. Well, color me surprised then :D
<tiehuis>
i'm only running regular arch for reference
<Dirkson>
I'm on a recent install of musl-based void. I've also got a plain debian machine sitting around, but it objected when I tried to shove zig onto it, and I gave up pretty quick.
<andrewrk>
Dirkson, even the static CI build?
<andrewrk>
that should run everywhere
<Dirkson>
andrewrk: I think I was missing xz, and apt-get install was Randomly Borked when I attempted to install it. Given that that copy of debian's Only Job is to run Unity, I decided that not messing with it was the right call.
<andrewrk>
oh wow, failed due to the xz dependency
<Dirkson>
I know, right? :D
<andrewrk>
noted
<andrewrk>
defaults are extremely powerful
<Dirkson>
I feel like that's a very reasonable dependency. The Right Answer to "I don't have xz" on linux really is "install it"
<tiehuis>
oh right, that's dumb all the c programs take a command-line argument
<tiehuis>
there isn't any error checking in them though so it just atoi's random memory otherwise and crashes
<Dirkson>
tiehuis: Ooooh
<Dirkson>
Yup, that'd explain some things alright.
<tiehuis>
i'll make a helper script to run them with the standard arguments when i clean everything up
<Dirkson>
I was extremely impressed by the poetic nature of my zig/C comparison test. Zig time: 7s. C time: Segfault. It wasn't the answer I was looking for, but it's an important answer to hear nonetheless.
<andrewrk>
tiehuis is single-handedly going to get us up to the github linguist quota of zig repositories :)
<andrewrk>
hi kristate
<tiehuis>
might be a good place to look if anyone is interested in writing some zig but doesn't want to do anything too large
<andrewrk>
yep late night for me
<kristate>
Hi -- let me push what I've got so far so you can review it
<andrewrk>
ok
<tiehuis>
that's actually part of the reason i have been making a fair few different repos/projects
<tiehuis>
also got the ryu float printing algorithm implemented and works alright as far as i can see
<andrewrk>
exciting!
<tiehuis>
i must say, when porting c code it always irks me how much implicit casting is occurring everywhere
<andrewrk>
one might even call it "hidden control flow"
<andrewrk>
nah, it's just data. but it's hidden data manipulation
<andrewrk>
I just added std.AutoHashMap where you only have to supply K, V
<andrewrk>
because zig can use reflection to figure out a hash function
<tiehuis>
that'd be handy, how do you perform equality comparison? is it just defaulted to '=='?
<andrewrk>
it's a big switch statement on the type. a lot of them are ==. a lot of them are @compileError("TODO")
<Dirkson>
Ah, does zig not have implicit casts? That'd be swell.
<tiehuis>
right, that makes sense i suppose the only thing it doesn't work is when your equality is on only a subset of the type passed but in that case HashMap is fine
<andrewrk>
my plan is for single-item pointer to structs, if you define "equal" and/or "hash" then the auto hash function calls that, otherwise recurses on the fields
<andrewrk>
it's a little hidden magic, but you're kinda asking for that with "Auto"
<andrewrk>
here is a comprehensive list of implicit casts that zig has
<andrewrk>
s/comprehensive/complete/
<Dirkson>
Cool. Thanks!
<kristate>
pushing
<kristate>
ah, let me rebase
<wink_>
MajorLag: txs for the help, I did get something working, http://bit.ly/2MfyL1o . Any other suggestions or observations from anyone are welcome!
<kristate>
rebased
<kristate>
andrewrk: I am shadowing _ and initing the variable without name
<andrewrk>
kristate, I finished reviewing - are you ready for me to merge it?
<kristate>
andrewrk: I don't have else |_| { } done
<kristate>
andrewrk: wondering what the best way to go about that is
<andrewrk>
oh, is it not the same sort of thing as for and while?
<kristate>
andrewrk: its similar, but there are a few edge cases that I might not be aware of
<andrewrk>
the first thing I would do is try what you did with shadowable and then see if the tests pass
<andrewrk>
btw another place besides for and while, is `if`
<andrewrk>
maybe we should put the logic inside ir_create_var
<kristate>
andrewrk: yes, I wanted to do that, but I couldn't figure out how to get the context
<andrewrk>
which context?
<kristate>
that is if I could test for node->type == NodeTypeForExpr or node->type == NodeTypeWhileExpr
<andrewrk>
I don't think you need to do that test
<andrewrk>
ir_create_var is called from if, while, for, switch, catch with non-null name, which is exactly all the places we need this logic
<kristate>
andrewrk: hmm, so if we have an underscore, then we should automatically shadow it etc?
<andrewrk>
yes, it's a special name
<kristate>
andrewrk: okay, I will ignore bool is_shadowable and Buf *name in the event that name == "_"
<andrewrk>
I think that should work
<kristate>
ok
<kristate>
seems to be working so far
<kristate>
testing
<kristate>
test seem to pass
<kristate>
pushing
<andrewrk>
hmm I don't see the changes
<kristate>
andrewrk: pushed
<kristate>
andrewrk: btw, when will the documentation on the website be refreshed with master ?
<andrewrk>
oh, I have to do that manually currently
<andrewrk>
I'll do it now
<kristate>
cool
<andrewrk>
kristate, merged, and the docs are updated
<andrewrk>
thanks for that fix!
<kristate>
andrewrk: yes!
<kristate>
andrew, it sounds corny, but I think zig is something great and if we put some more polish into it, it would be around for a long time
<andrewrk>
I'm happy that you think that way
<andrewrk>
I for one have made a vow to exclusively use zig for my own open source projects
<andrewrk>
so at least it will be around for as long as I'm alive
<kristate>
andrewrk: I am actually trying to reinvent the Internet from Japan
<kristate>
I built a completely new layer 3 built on secure primatives
<andrewrk>
oh wow
<kristate>
and we have a lot of devices to cover
<kristate>
I am working on it at the university of tokyo
<andrewrk>
that's hardware, right?
<andrewrk>
layer 3 is hardware?
very-mediocre has joined #zig
<kristate>
long story short, CPUs were really slow in the 1980s, so vint cerf and others came up with a neat hack: the 32bit IP address
<andrewrk>
I'm about to go to sleep - but I want to hear about your project sometime
<kristate>
but, because the protocol requires engineers to calculate all of the routes and populate routers -- its all memory backed
<kristate>
we use the CPU to calculate the routes in realtime
<kristate>
so, no need for big routers
<andrewrk>
ah interesting
<andrewrk>
that seems less buggy too
<kristate>
it's really cool
<andrewrk>
good night
<kristate>
andrewrk: g:night! thanks for another productive day
zolk3ri has joined #zig
geocar has joined #zig
kristate has quit [Ping timeout: 256 seconds]
<unique_id>
speaking of SIMD, I don't know how popular this will become but there's a kind of shader language for the CPU called ispc (from Intel). The cool thing is that you just write your code in a c-like language from a single SIMD lane point of view and the compiler automatically compiles it for AVX or whatever you like. And it actually achieves super good speedups. For if statements it uses masks. The output is just a .o which you link
<unique_id>
with the rest of your program. Conclusion: ispc allows you to write much larger programs that take full adavantage of SIMD and the greater the line count of SIMD code that you wish to write, the greater the chance that a shader like language like ispc is the right approach for that section of code.
<unique_id>
It's made by Matt Pharr (author of Physically Based Rendering), he has blog entries on "The story of ispc". I just think it's good to be aware of how SIMD-heavy functions might be written in the future, even if this info isn't actionable for us.
<MajorLag>
wink_: Just an FYI, `var self = @intToPtr(*Self, @ptrToInt(aiPtr) - aiPtr.actor_offset)`, the idiomatic zig way to say this is `var self = @fieldParentPtr(Self, "interface", aiPtr)`. It does the identical operation, but without the need to store the offset.
return0e_ has joined #zig
return0e has quit [Ping timeout: 264 seconds]
qazo has joined #zig
tiehuis has quit [Quit: WeeChat 2.2]
qazo has quit [Ping timeout: 260 seconds]
bheads has quit [Ping timeout: 264 seconds]
bheads has joined #zig
ofelas has joined #zig
ofelas has quit [Client Quit]
ofelas has joined #zig
ofelas has quit [Client Quit]
ofelas has joined #zig
ofelas has quit [Quit: Yaaic - Yet another Android IRC client - http://www.yaaic.org]
<wink_>
MajorLag: It's always great to delete LoC, http://bit.ly/2Mk16Us thanks, much cleaner.
<andrewrk>
unique_id, I'll have a look at that
ofelas has joined #zig
<MajorLag>
wink_: on another note, I'd never considered creating Actors by wrapping them in a comptime fn returning a new type. I think that might actually be a better approach. I'm going to consider that technique when I next go to update my animation Actor/Action code.
<wink_>
MajorLag: Is it possible to look at your code, maybe I'm re-inventing the wheel?
<wink_>
Is there a succinct word or pharse for a generic function that returns a struct, maybe a "Type Constructor"?
<unique_id>
the problem is that you have to learn the language. It's not the easiest thing in the world. I'll be using this language for some of my simd stuff. It's probably best used for larger programs, anything that Disney/Pixar does, ray tracing, etc
<MajorLag>
wink_: I haven't put that code anywhere yet because I'm not happy enough with it, but it doesn't do message passing so I don't think you're duplicating effort. It queues and applies interpolations and sequences to members of actor structs over time. It's somewhat based on LibGDX's Actor/Action model.
<wink_>
MajorLag: let me know if/when you do. You say you don't pass messages, but you say "queues interpolations" that seems like a message to me? Note: no nothing about libGDX, but will investigate today.
<MajorLag>
Actions directly manipulate the actor's members. My current actor implementation keeps a list of actions applied to it, and runs each action every frame until the action reports it has completed. Some actions are compound actions, like sequences, which are themselves lists of actions. Most of them are just applying interpolations. you can see the result: http://zig.tgschultz.com/wip/move.zig.example.gif
<MajorLag>
I should also note for readability, `const MemberList = []const []const u8;`, so actions.MemberList is an array literal. This is because varargs don't work at comptime currently.
<MajorLag>
Oh boy, it's been so long since I've worked on this code that it still uses SDL.
<unique_id>
I'm 700 lines into my vk.xml => vulkan.zig converter, it's going great.
<unique_id>
looking forward to perfect vulkan bindings for vulkan
<andrewrk>
:)
<unique_id>
zig*
<andrewrk>
unique_id, do you have a generic xml tokenizer?
<andrewrk>
that might be nice to have in the std lib
<andrewrk>
full parsing is probably out of scope, but tokenization is nice and simple and unchanging
<unique_id>
nope, I made a small parser (without tokenization) that's adequate for vk.xml. We could learn from: https://dev.yorhel.nl/yxml for tokenization/parsing
<unique_id>
mit licensed
<MajorLag>
wink_, andrewrk: Yes, that SDL. I've converted most of my projects to straight win32 api calls and OpenGL right now (though just to dump a framebuffer to screen). When I start doing something more serious on the gamedev front I'll probably write my own proper platform layer in pure zig.
<bheads>
I think a ZDL would be another good killer app project for zig
<MajorLag>
andrewrk, possibly. It would depend on the API. From what I've seen of how zig's std lib is structured, with abstractions that you can bypass when need be, I think I probably would. I'd be interested in contributing to some kind of "ZDL" project.
<MajorLag>
I switched from SDL not due to any real difficulty, it was more out of a desire to be completely free of C. Oh, and I didn't want the dll dependency.
<andrewrk>
yeah, that's a really nice benefit on windows
<andrewrk>
I got your installation process right here. it's an exe file. just run it
<andrewrk>
I mean, the exe file is the app. there is no install process
<bheads>
and 5gigs of assets
<andrewrk>
those can go in the exe
<bheads>
lol
<bheads>
how do you update anything?
<bheads>
or install mods!
<andrewrk>
yeah it's a bad idea. you got me :)
<MajorLag>
Yeah, I really dig that. I'm a fan of AppBundles, AppDirs, static exe-only programs, and AppImage.
<bheads>
need to get flatpaks to run on windows and osx
<MajorLag>
bheads: updates are binary diffs. That's how AppImage does it.
<bheads>
binary diffs scar me
<MajorLag>
flatpak an snap are vastly overengineered in my opinion.
<MajorLag>
If your game is mod-friendly though, you do probably want more of an AppDir than a single-exe.
<bheads>
I do like app bundles but there is a ton of file dup
<bheads>
I use to work on a back up product. We found so much duplication accross machines
<unique_id>
For as long as double clicking an AppImage brings up a Disk Writer tool (until you tick the executable bit), AppImage will remain yet useless for the average computer user
<bheads>
which we only backed up once and charged for every instance
<MajorLag>
Not to get into an offtopic argument about it, but that duplication is a good idea in my opinion because it means there will never be any conflicts. Share base system libs, but nothing else.
<wink_>
MajorLag: as an FYI I'm attempting to implement Actor Model (https://en.wikipedia.org/wiki/Actor_model) in zig. On the libGDX web site has quite a bit of documention, can you point me to what you've found to be a good "overview" of it's actor/action model?
<bheads>
snaps and flatpaks can handle to duplication in a better way
<bheads>
ie: base image + llvm6 image + zig 0.2 image = zig 0.2 pak
<bheads>
Why have 50 copes in the app bundle of the same dynamic libs
<andrewrk>
why have dynamic libs
<bheads>
:D
<MajorLag>
wink_: I really like the way LibGDX structured their API. It's all in layers that you're free to choose where you want to interact with it. It's base is straight OpenGL, upon which are Textures => TextureRegions => Sprites => Actors => Widgets => GUI elements => Scene graph.
<bheads>
andrewrk: 100% aggree
<MajorLag>
bheads: again, not to get into an argument about it, but suffice it to say I disagree about the value of that deduplication compared to the disadvantages of overengineering the solution.
<bheads>
MajorLag, so you can get paid 100k a year in devops :)
qazo has joined #zig
<MajorLag>
wink_: I wrote two games in LibGDX and several prototypes and only stopped because I got sick of Java's BS.
qazo has quit [Ping timeout: 260 seconds]
<wink_>
Which part of Java was most offensive?
<wink_>
(Actually, that's probably some what off topic, so never mind)
ofelas has joined #zig
ofelas has quit [Ping timeout: 248 seconds]
davr0s has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]