ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
steveno_ has quit [Remote host closed the connection]
<jab>
PokeROMdomizer
<jab>
:P
<Hejsil>
I like the ROMdomizer. The Poke in front make it weird to read :)
<jab>
yes
<jab>
ROMdomizer is generic
<jab>
but could still work
Taslem has joined #zig
<Hejsil>
The only great name I can remember calling a program releated thing, was calling an AST renderer "HPInkjet"
<Hejsil>
Sadly, the renderer never really had driver problems, so the name was missleading
bw___ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bw___ has joined #zig
<andrewrk>
neat!
<jab>
is there a std reference?
<jab>
besides webmd
<andrewrk>
no, that's blocking on auto docgen
cenomla has joined #zig
<Hejsil>
Just an index of the std would be extremely useful. Actually, that's all the documentation it'll ever need!
bw___ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Hejsil>
Hmmm... Maybe i could generate one using the zig parser in the std
<Hejsil>
andrewrk, does the self hosted parser still only parse a subset?
bw___ has joined #zig
<andrewrk>
yeah the self hosted parser isn't quite up to that task yet
<Hejsil>
Ooh well
<andrewrk>
I'm probably going to do Pointer Reform before working on it further
bw___ has quit [Client Quit]
<Hejsil>
Np. If I really need it, a parser isn't a hard thing to work one
<Hejsil>
So I might look into that
<jab>
no string functions?
<Hejsil>
std.mem should have most things you would need for strings
<Hejsil>
indexOf, dupe, copy, set
<Hejsil>
Basic things that is
<Hejsil>
eql, split, hash, trim, lessThan
<Hejsil>
I think that's all function relevant to strings in std.mem
<jab>
eql is a weird function name to me
<jab>
everything else is spelled out
<jab>
even C comprssed words like cpy is mem.copy
bw___ has joined #zig
<andrewrk>
good point. we'll probably rename that before 1.0.0
<Hejsil>
But 2 more letters :)
<jab>
lol
<andrewrk>
jab, std.mem is for byte manipulation. std lib has no string manipulation yet
<jab>
yeah substr or search or regex substitution
<jab>
reverse
sandwit has joined #zig
vec_ has joined #zig
<MajorLag>
jab, I recently thought of making a tweening library named move.zig
<MajorLag>
^ on the subject of names from an hour ago
<andrewrk>
hahahaha
bw___ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<jab>
haha
<jab>
rand.zig isn't completely generic it looks like
<jab>
its MT or nothing
<jab>
and you can reuse Rand struct if you have your own
<jab>
cant*
<andrewrk>
jab, yeah we should update Rand to follow the interface pattern
<andrewrk>
that's some of the oldest code in the std lib
<MajorLag>
also: on the subject of null terminated literal strings, if the default were to change to []null T, you could still allow the old style strings using r"" or something. I think that and being able to implicitly cast []null cont T to []const T would cover any objections, minor as they are.
<andrewrk>
the implicit cast will certainly work. using r"" for old style strings... tough sell. they buy you 1 byte of memory each
<andrewrk>
is there another reason to have that besides saving bytes?
<MajorLag>
no, I don't think so. I realize how minor a thing it is. I dunno, it just bothers me somehow.
<andrewrk>
I know what you mean
<MajorLag>
I suppose I could always write a comptime wrapper to deal with it, like my _L function for UTF16 literals.
<MajorLag>
yeah, that'd satisfy any edge cases I think.
<itsMontoya>
So this is weird
<itsMontoya>
I installed clang
<itsMontoya>
But it looks like the variable isn't being respected
<itsMontoya>
I didn't want to uninstall Clang
bw___ has joined #zig
bw___ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
sandwit has left #zig ["Leaving"]
<jab>
r"" would be...?
<jab>
not null-terminated?
<MajorLag>
yeah, but I think I talked myself out of it. The rare circumstance where I might care about the extra byte could be solved with a comptime function wrapper.
<andrewrk>
ah yeah that's a good point
<jab>
so you're moving to null-terminated strings?
<jab>
as default
<MajorLag>
andrewrk: are there tests for the syscalls? I'm wondering because if the ones I'm adding end up in the standard lib, and tests are desired for that, then I'll need to work that out. setcap in particular could be difficult.
<andrewrk>
MajorLag, not directly. the closest we have is tests for generic std lib stuff that ends up making syscalls
<andrewrk>
such as std/io_test.zig
<MajorLag>
ok, so stuff involving file io I should test, but it's ok to leave setcap and mount alone?
Hejsil has quit [Quit: Page closed]
hobomatic has quit [Remote host closed the connection]
Taslem has quit [Quit: Page closed]
<andrewrk>
MajorLag: yeah that sounds fine. I'll have a look at the pull request when you make one and double check that it looks good
itsMontoya has quit [Quit: Lost terminal]
tiehuis has joined #zig
<tiehuis>
regarding the arch issue, i've just had another look and it appears that cmake is attempting to dynamically link clang but statically link llvm which is probably the cause
<tiehuis>
i'll need a fix for the aur pkgbuild's but will see if it is a general problem
hobomatic has joined #zig
<tiehuis>
If you use this patch you should be fine to compile using the system llvm/clang on arch: https://clbin.com/gVOMl
<tiehuis>
this just disables the static-linking for release mode in favour of dynamic linking
<tiehuis>
i'm just finishing off the testing now and will update the aur package shortly
<tiehuis>
in general we could probably check in the cmake script that clang/llvm are both either static or dynamic as a mismatch will probably occur otherwise
<tiehuis>
okay, the zig and zig-git packages in the aur are now up to date, let me know if you encounter any issues
<tiehuis>
i also changed the zig-git to avoid a full retest on each update so it should be easier to use if you just want to stay on the bleeding edge feature-wise
hobomatic has quit [Quit: Leaving]
cenomla has quit [Quit: cenomla]
hobomatic has joined #zig
davr0s has joined #zig
tiehuis has quit [Quit: WeeChat 2.1]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
stud7 has joined #zig
stud7 has quit [Quit: Leaving]
hobomatic has quit [Remote host closed the connection]
davr0s has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
hellerve has joined #zig
<hellerve>
so, i just got deleteTree to work on macos
<hellerve>
but i had to add `error.AccessDenied` to the list of expected errors when we assume it’s a file, because that’s what macos will return
<hellerve>
ill have to figure out whether that breaks anything on any other system
<hellerve>
if that’s a bit too cryptic i’ll try to write it up in a more digestible way in my pr
<GitHub11>
[zig] hellerve opened pull request #864: Getting dir entries on OS X (master...wip-macos-dirent) https://git.io/vx2zP
hellerve has quit [Ping timeout: 260 seconds]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
return0e has joined #zig
davr0s has joined #zig
man213 has joined #zig
man213 has quit [Client Quit]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
MajorLag has quit [Ping timeout: 245 seconds]
steveno_ has joined #zig
<jab>
is it possible to get an integer value corresponding to a type id
<jab>
like i32.value
<jab>
so i can hash it
<jab>
also, for error messages, it doesn't combine relavent lines
<jab>
an example: /usr/local/Cellar/zig/0.2.0/lib/zig/std/hash_map.zig:12:5: note: declared here
<jab>
it's an architectural approach to game design. you have game entities composed of components which are accessible by type
<jab>
Unity has this
<jab>
you can do GetComponent<Position>(); or GetComponent<Health>()
<andrewrk>
this is just global variables
<jab>
urm
<jab>
this.GetComponent<Position>()
<andrewrk>
how is this different than a struct, with a field for each type?
<jab>
the advantage is you can add/remove at runtime
<jab>
you have systems which run on entity sets that have specific components attached
<jab>
so collision system would only iterate over entities which have Collidable, Position
<jab>
or something
<jab>
You *could* have it all in one giant struct and then have a bool to see if each one is active
<jab>
but there could be dozens of components
<andrewrk>
I see, so the difference here is in how much memory it will consume
<jab>
and separation of data access
<jab>
only see what you need
davr0s has joined #zig
<jab>
in C there is no way to do a type -> instance mapping either so the solution is to use some loosely guaraenteed mapping
<jab>
like numbers or strings
<jab>
so you would do: map.put("Position", Position{...}); and map.get("Position") as Position, but this is easier in C than zig
<jab>
since there is no void pointer in zig?
<andrewrk>
there's no way it's easier in c than zig
<jab>
ideally it would be comptime where you can get the type back exactly
<jab>
How would you do type->instance map?
<andrewrk>
to do it with status quo zig, I would have all my Component-enabled structs have a `pub const component_id = 1;` where I would make each component have a unique number instead of 1
<jab>
basically: getComponent(comptime T: type) T, where this function looks up T in a map
<andrewrk>
or maybe I would just generate a random u32
<jab>
gotcha
<jab>
yeah
<jab>
i'll write proof of concept
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<andrewrk>
std.HashMap should work fine for this
<jab>
what would be the value of hashmap?
<jab>
void *? :P
<andrewrk>
a union
<jab>
of all possible types?
<andrewrk>
yes you would have to specify the set at compile time
<andrewrk>
or you can do your void * strategy
<jab>
if you go the union strategy, a union tag type could be used at the component id
<jab>
as*
<andrewrk>
yeah that's a good idea
<andrewrk>
a hash kinda seems like overkill
<jab>
yeah
<andrewrk>
if a component is a union it would be pretty straightforward to have a list of components. if you don't have more than a dozen, a hash is not worth the overhead
<jab>
hmm, nvm, comptime: @TagType(Component) works
Ichorio has joined #zig
<jab>
should get a play.ziglang.com going :p
<GitHub191>
[zig] bnoordhuis opened pull request #865: skeleton stage 2 support for 'zig build' (master...zig-build-stage2) https://git.io/vxaGE
ccc has joined #zig
ccc is now known as Guest51962
Guest51962 has quit [Client Quit]
MajorLag2 has joined #zig
<andrewrk>
jab, we definitely should. I'm thinking about what the simplest, yet secure, way to do that is
MajorLag has quit [Ping timeout: 276 seconds]
<jab>
andrewrk: the only difficult part of these union stuff is turning it into a library. a user has to define the whole union type and how will the sepcific tagtype be passed to functions?
<jab>
the add() function takes a union instance, it shouldn't need a TagType passed a long with it since which tagtype it needs should be in the passed instance
<andrewrk>
correct
<andrewrk>
see above linked example
<jab>
the TagType instance is not known generically
<jab>
I basically tried @TagType(T)(t)
<andrewrk>
on which line?
<jab>
i erased it :P
<andrewrk>
maybe you need to deref the pointer
<jab>
hmm that works
<jab>
but now it fails in a way i don't think a workaround is possible
<jab>
i'mt trying to have the switch case be a TagType which needs to be known at compile time
<andrewrk>
you can use an if statement
<jab>
but when I add a component, it's a runtime component which could be generated. i need to look up the existing component with that TagType (if it exists) to remove it
<jab>
the problem is i can't call it at runtime, it has to be comptime
<andrewrk>
if conditions can be runtime
<jab>
TagType is a comptime knowledge, right?
<andrewrk>
the type is. the tag is runtime
<andrewrk>
you can compare 2 union(enum) instance's tags with each other at runtime, which is what you're trying to do
<andrewrk>
I wouldn't even call it ugly. what I like about this is that there is no text substitution or macro weirdness. even though it's messing with types, it's all functions and if statements and easily understandable things
<andrewrk>
you can look at any line of code and understand exactly what it does
<jab>
true
<jab>
i guess it's the interraction with the stdlib stuff
<jab>
like i have to reappend the list after changing it since i get back values not reference
<jab>
so, since structs cannot be passed by value it creates confusing interfaces: ArrayList's append has (t: &const T), but that reference is there only because the language doesn't allow passing by value
<jab>
because in the function it does *new_pos = *t; copying it by value
<andrewrk>
comps = if (self.bags.get(ent)) |item| item.value else std.ArrayList(T).init(self.allocator);
<jab>
so semantically it disconnects
<jab>
i like that
<andrewrk>
I think the type of comps should not be nullable
<andrewrk>
??x is not always wrong, but it's always a code smell
<Hejsil>
Or, well. I guess type reflection at comptime is a language feature
<MajorLag2>
jab, sadly not yet. there isn't quite enough introspection. You can examin struct/union/enum members, but not things that merely exist in the struct/union/enum namespace.
<MajorLag2>
that said, depending on your use case, you could do something like `struct { .has_foo: void, }` and in your comptime function iterate over the struct members for .has_foo. problems with that is you have to do a string compare by member name, but at least the field doesn't take up any space at runtime.
MajorLag2 is now known as MajorLag
<andrewrk>
jab, it's planned, but I don't think I made an issue for it yet
<andrewrk>
I think this @reflect function is going to be nice
<jab>
I like the potential of comptime stuff
<jab>
can build really cool stuff, but i can see it moving to c++ compile time speeds
<jab>
i can start sending pull requests once i get the build working on my mac. not sure how my libc stuff got fudged
<jab>
i blame xcode
<andrewrk>
jab, almost all comptime code execution can be cached
<jab>
heyyyy
<jab>
zig_cache/ will be sued
<jab>
used
<andrewrk>
it will!
<Hejsil>
Wuuh!
<jab>
no threading functionality?
Ichorio has quit [Ping timeout: 264 seconds]
<jab>
man "Create an OpenGL library that does not depend on libc."
<jab>
like mesa3d? that would be awesome but that's a massive project
<Hejsil>
"Unable to determine Windows SDK path." but I'm building on linux :)
<Hejsil>
This seems to happen when there is no libc_include_dir
<GitHub104>
zig/master 72ce146 Jimmi Holst Christensen: Fixed looking for windows sdk when targeting linux
<Hejsil>
Much better
steveno_ has quit [Ping timeout: 276 seconds]
steveno_ has joined #zig
Hejsil has quit [Ping timeout: 260 seconds]
<MajorLag>
appdir version of zig should now allow you to specify the C directories in your environment variables, making it slightly easier yet to use.
steveno_ has quit [Quit: Leaving]
<andrewrk>
jab, I'm working on threading in a branch