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 quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
mnoronha has joined #zig
davr0s has joined #zig
reductum has joined #zig
mnoronha has quit [Ping timeout: 272 seconds]
fsateler has quit [Read error: Connection reset by peer]
fsateler has joined #zig
mnoronha has joined #zig
mnoronha has quit [Ping timeout: 252 seconds]
mnoronha has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
wink_ has quit [Remote host closed the connection]
Graznarak has quit [Ping timeout: 256 seconds]
m4ge123 has joined #zig
very-mediocre has joined #zig
davr0s has joined #zig
pskocik has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
tiehuis has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
jjido has joined #zig
unique_id has joined #zig
pskocik has quit [Remote host closed the connection]
<tiehuis>
updated the zig aur packages `zig`, `zig-git`, sorry it took a few days there
<tiehuis>
also, see the `zig-static` package too if you don't really want to compile from source, these just take the automatically built static binaries and package them up
<tiehuis>
will likely be up to date much quicker than the others since they don't rely on the system LLVM
tiehuis has quit [Quit: WeeChat 2.2]
MajorLag has quit [Ping timeout: 240 seconds]
wink_ has joined #zig
renatorabelo has quit [Ping timeout: 240 seconds]
SyrupThinker has joined #zig
jjido has quit [Ping timeout: 245 seconds]
m4ge123 has quit [Ping timeout: 252 seconds]
m4ge123 has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
utzig has joined #zig
very-mediocre has quit [Ping timeout: 256 seconds]
davr0s has joined #zig
bheads has joined #zig
<bheads>
Morning all!
<andrewrk>
morning bheads
<bheads>
I was wondering if any updates/work has been done on the interface / inheritence side of things
<andrewrk>
nope, none at all
<bheads>
The code I messing with needs widgets what has child widgets
<andrewrk>
aha
<andrewrk>
the classic OOP use case
<bheads>
I ended up with a Widget struct that have some base properties and function pointers
<bheads>
the parent structs have a widget member and replace the fn pointers, I use @fieldParentPtr to find the parent in the overloads
<bheads>
it works but is a little clunky
<bheads>
also fn pointers dont pass the calling struct point, ie: self.widget.click(self.widget, event_data); // have to pass the widget
<bheads>
@andrewk also congrates on 0.3
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<bheads>
I was trying to think over ofer ways to avoid this oop pattern, but I code in java all day, I think it has rotten my brain
<andrewrk>
I think for widgets at least, this oop pattern makes a lot of sense
<bheads>
I thought about a tagged union on the widget, but then the widget has to know all possible widget types
<bheads>
so its not extendable
<andrewrk>
right
<bheads>
anonymous structs would help
<andrewrk>
I have a plan for that
<andrewrk>
the main problem is initializing them, right?
<bheads>
no difference the a member struct, just one less .name = Foo {}...
<andrewrk>
oh, I see - "including" a structs fields into another one, aka inheritance
<bheads>
what is trickey is how do you get the anonymous struct type out of the parent
<andrewrk>
I believe it even says in that issue "implement a widget based UI framework before closing"
<bheads>
yep I do remember read some of these issues, was just wondering if I was doing this correctly for the time being or if there was a better way
<andrewrk>
yeah this looks like the best thing to do, at least for now
davr0s has joined #zig
<bheads>
okay cool, I was also reading the ticket on 'use'. I was starting to get tired of typing sdl.SDL_xxxxx. Never though of aliasing all the sdl functions, or use 'use' on the import.
<bheads>
a translate-c option to remove funtion prefixes like this would be nice
<andrewrk>
I think there's no shame in using `use` when it comes to c imports
<andrewrk>
and I agree that would be nice. the alternative is manually redeclaring every export
<bheads>
I really dont like polluting the name space
tom1998 has joined #zig
halosghost has joined #zig
davr0s has quit [Ping timeout: 252 seconds]
davr0s has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<euantor>
I'm not quite sure how to resolve that - FreeBSD does have the ability to have a `procfs`, but it's disabled by default so it can't really be relied on
<andrewrk>
it's a rather important component
<euantor>
I believe the usual way to get the full path to the executable is to use `realpath(argv[0])`
<andrewrk>
does freebsd have a stable syscall ABI? or is it a system where you use libc to make syscalls?
<euantor>
There are quite a few conditions that only cover Windows, Mac and Linux
<andrewrk>
if freebsd relies on libc for syscalls, that means it depends on a dynamic linker, which probably has a way to figure out the exe's own path
<andrewrk>
maybe it exposes an api
<euantor>
I believe it's fairly stable, but I'm not entirely sure
<andrewrk>
what about sysctl CTL_KERN KERN_PROC KERN_PROC_PATHNAME -1
<euantor>
that could work, I've never seen that one before
<Hejsil>
Makes me feel the same as writing insane macros in C
<Hejsil>
Love it
<andrewrk>
haha
<andrewrk>
I just finished a major ir.cpp refactor, 1713 insertions(+), 2125 deletions(-)
<andrewrk>
do you think the tests will pass first try?
<Hejsil>
Going pretty good so far
<Hejsil>
I think it'll fail at the compiler error tests
<andrewrk>
err, I meant mine. but yours too :)
<Hejsil>
Thoses that have code in string literals
<Hejsil>
Aaah
<Hejsil>
No way
<andrewrk>
hahahah you have no faith
<andrewrk>
Segmentation fault
<andrewrk>
argghh
<Hejsil>
That was fast
<Hejsil>
RwLock takes a long time to complete
<Hejsil>
std.event.RwLock test that is
<Hejsil>
Aah, i branched at the "std.Mutex: implement blocking mutexes on linux"
<halosghost>
andrewrk: phew
<halosghost>
andrewrk: that's quite a rewrite
<halosghost>
and in Cxx, no less
return0xe has quit [Remote host closed the connection]
return0e has joined #zig
<Hejsil>
andrewrk, seems that "translate_c.zig" doesn't get recompiled when I change it
<Hejsil>
Oooh wait!
<andrewrk>
hmmmm
<Hejsil>
I have two zig folders right now
<Hejsil>
Sec, Im stupid
<andrewrk>
I was gonna say, I was reeeeeally careful with the cache invalidation
<Hejsil>
Yep, cache is smarter than me
<Hejsil>
Don't worry
mnoronha has joined #zig
<halosghost>
andrewrk: how does isCompTime() work?
<halosghost>
andrewrk: something about when `t` gets its value?
<andrewrk>
a static if will not analyze the branch not taken, so you get the type directly. a runtime if will invoke peer type resolution and the result will have the type of the larger int
<halosghost>
ahh
<halosghost>
I see
mnoronha has quit [Ping timeout: 252 seconds]
<halosghost>
so, eventhough that code always takes the first branch, the type resolution will cause the u7 to be up-cast to a u8 if at runtime
<halosghost>
interesting
<Hejsil>
The dark arts of Zig
jjman has quit [Quit: WeeChat 1.6]
<halosghost>
andrewrk: am I right in my reading of the docs that though structs can have member functions, there is no special syntax to offer methods (i.e., functions that take a reference to the caller)?
<andrewrk>
halosghost, that's right, methods are not special, other than that you can call them with foo.bar() syntax
<andrewrk>
foo.bar() is syntactic sugar for @typeOf(foo).bar(foo)
<halosghost>
oh
<halosghost>
hmm
<halosghost>
yeah, that makes ense
<halosghost>
andrewrk: any plans for something like lua's : method sugar? (if you're not familiar with it, I'll be happy to explain it)
<halosghost>
wait
<andrewrk>
no plans for that
<andrewrk>
zig is not a very sugary language
<halosghost>
hmm
<halosghost>
oh, wait
<halosghost>
nevermind
<halosghost>
it sounds like what you said above means you already have it
<halosghost>
yeah
<halosghost>
nevermind :)
<andrewrk>
ok Hejsil to be fair this segfault happens in master branch if you add a very reasonable assert in ir_get_var_is_comptime. this doesn't count!
<halosghost>
lol
<Hejsil>
Yes yes
<Hejsil>
Fixing up tests after changing syntax is kinda painful :/
<andrewrk>
maybe it would be worth transitioning to a test framework that lets zig fmt help with syntax changes
<andrewrk>
on the other hand, syntax changes are rare if you consider the entire lifetime of the project
<andrewrk>
at some point there are simply no more syntax changes
<Hejsil>
Indeed, so It might be fine
<andrewrk>
zig isn't going to be like java or go, there's going to be a point where it's done and won't get any bigger. (apart from basic maintenance such as keeping up with new hardware intrinsics)
<Hejsil>
This is not a "sed"able syntax change :(
<andrewrk>
maybe it's vim macro-able
<halosghost>
hehe
<andrewrk>
you can do a lot with vim macroable
<andrewrk>
*with vim macros
Ichorio has joined #zig
<Hejsil>
Im fixing up compile-error, and sometimes the line:column wont match anymore
<Hejsil>
Can your vim-macros handle that :)
<andrewrk>
good point
<andrewrk>
it's going to get even trickier when we try to have the same test cases passing for stage1 and stage2
<Hejsil>
vim-macros 0 - 1 real life
<Hejsil>
Indeed
<Hejsil>
Maybe we need a way to skip first N tests
<andrewrk>
I'm fine with that if you want to add it. there's also -Dtest-filter="aoeu"
<andrewrk>
(need to double check the --help menu, both of my zig directories have WIP changes that are blocking me from doing that)
<Hejsil>
Well, skipping N tests is more useful in this case, as compile-error tests don't have a lot in commen in terms of tests
<Hejsil>
And yes, the build system of the zig repo does expose Dtest-filter
<andrewrk>
I'm pretty happy with `zig build` being cached now
<andrewrk>
that was a bit of a downer before
<Hejsil>
Oooh yeeeah. I can use -Drelease-skip
<Hejsil>
-Dskip-release*
<Hejsil>
Hmmm. vscode seems to have a max of 10000 cursors at the same time
<andrewrk>
lol
<Hejsil>
complier_rt has a ton of array literals :)
mnoronha has joined #zig
<Hejsil>
I guess i should really use "find/replace"
<andrewrk>
Hejsil, I just pushed that big refactor. I think it should generally not conflict with any of your stuff
DutchGh0st has joined #zig
<DutchGh0st>
hi, how do I create a slice from a ptr and a length?
<DutchGh0st>
Im trying to call Zig from Rust
<andrewrk>
ptr[0..len]
<DutchGh0st>
error: slice of single-item pointer
<DutchGh0st>
var s = buf[0..len];
<andrewrk>
you probably want to declare buf like this: buf: [*]u8
<andrewrk>
that means you're expecting a pointer to an unknown number of contiguous items
<halosghost>
I haven't properly described how awesome it is that Zig now differentiates between pointer-to-single-time and pointer-to-buffer
<DutchGh0st>
but then you still need to provide the length, right?
<DutchGh0st>
rust str's dont have a null byte at the end...
<halosghost>
well, if you declare it as a pointer-to-buffer, then presumably, 0..len will now work
<halosghost>
(speaking as someone who hasn't tried yet :P)
<DutchGh0st>
well, here's the funny thing
<andrewrk>
DutchGh0st, what exactly are you getting from Rust? can I see the full function?
<DutchGh0st>
imma make this a github repo ^^, 2 seconds
<andrewrk>
use --no-rosegment when compiling your zig thing to work around a valgrind bug, then `valgrind ./yourprogram`
<DutchGh0st>
but I dont have valgrind installed...
<Hejsil>
andrewrk, is there a way of having docs not delete the docgen_tmp folder?
<andrewrk>
Hejsil, I don't think so, other than commenting out the `defer deleteTree()`
<Hejsil>
I guess I'll just comment out the defer os.deleteTree(allocator, tmp_dir_name) catch {};
<Hejsil>
Right
<andrewrk>
troubleshooting?
<Hejsil>
Well, docs should use the new syntax too
<Hejsil>
And it's easier to inspect the output files
<andrewrk>
yeah. I thought I made the error message show a line number in langref.html.in though
<andrewrk>
I'm pretty sure it does
<Hejsil>
Oooh yeeeah
<Hejsil>
It does do that
<Hejsil>
The giant squigle line distracted me
<Hejsil>
Hmm, it only points to the block, not the code that fails
<andrewrk>
yeah, you'd have to copy-paste it out of there
<andrewrk>
but since it's not html, you can cut/paste verbatim, no & or anything
<andrewrk>
DutchGh0st, the bottom line is that mismatched function declarations is undefined behavior, and that means anything can happen - including it magically working sometimes
<DutchGh0st>
I see
<DutchGh0st>
I guess the string was not big enough to crash
<DutchGh0st>
but I've updated it now :)
<DutchGh0st>
it *should* be all safe now
<DutchGh0st>
its kinda cool really
<andrewrk>
DutchGh0st, does "cargo build" build the zig code? where does it execute build-lib?
<DutchGh0st>
it does not build the zig code, sadly
<DutchGh0st>
still need to do that manually
<DutchGh0st>
but 'zig.exe' is not in my path variable, so can't really do that yet
<DutchGh0st>
unless I use some paths
<andrewrk>
I wonder if it would make sense to have a cargo crate that contains static zig 0.3.0, and then you can depend on it like a rust crate, and it provides the zig binary
<andrewrk>
you could make it work for windows, mac, linux, then depending on this rust crate would give you cross platform zig in your path, for rust projects, that has no system dependencies
<DutchGh0st>
mhh yeahh
<DutchGh0st>
hehe
<DutchGh0st>
you could do some really fun things I suppose haha
<andrewrk>
the point would simply be ability to depend on zig code in rust projects without requiring zig installed globally
<andrewrk>
that might be a really compelling use case for nodejs projects actually, since it can be a pain to depend on node modules on windows that need to compile native extensions
<andrewrk>
static compiler + liberation from libc opens up some opportunities
<DutchGh0st>
andd
<DutchGh0st>
I dont know much of a pleasure it is to compile Zig to wasm?
<DutchGh0st>
or is that just an LLVM thing?
<andrewrk>
I think it works now in the static builds
<DutchGh0st>
I do know there is a whole team that focussus on being able to write Rust, and then compile to wasm
<DutchGh0st>
it'd be interesting to see a bunch of languages combined together :)
<andrewrk>
rust has multiplicative complexity, which requires a large team to tackle
davr0s has joined #zig
<andrewrk>
zig's simplicity allows it to be developed and maintained by a small team
<DutchGh0st>
yeah :)
<Hejsil>
I'd be fun to try to make a small Zig compiler, like people do with C all the time
<DutchGh0st>
how I should go the other way around
<DutchGh0st>
call into Rust from Zig
<andrewrk>
DutchGh0st, it's the same as calling into Rust from C
<andrewrk>
from zig's perspective it's the same as calling into C
<DutchGh0st>
this is interesting
<DutchGh0st>
if I change my directory to the /zig directory, and call 'cargo run', it runs
<DutchGh0st>
if I go inside the projects main folder, and call `cargo run`, it does not exit succesfully
<DutchGh0st>
(exit code: 3221225781)
<andrewrk>
that sounds like an issue with the cargo build system
<DutchGh0st>
now I am using a String, which does heap alloc
<DutchGh0st>
that'd be bad andrewrk
<DutchGh0st>
oh, it seems to have compiled as dll or something?
<Hejsil>
It's done!
<andrewrk>
brilliant
<Hejsil>
+90,171 −90,187
<andrewrk>
meanwhile, macos build is broken because of the bad macho linker code again :(
<Hejsil>
compile_rt really gives code to the diff
<Hejsil>
:/
<andrewrk>
oh you had to edit the big compiler_rt test
<Hejsil>
Yep
<andrewrk>
great work
<Hejsil>
That's get me above 100.000+ lines of code added to zig :)
<andrewrk>
hahaha
<andrewrk>
well you did write most of zig fmt
<Hejsil>
Well, the render part was rewritten
<halosghost>
andrewrk: I seem to remember your writing something about a hypothetical big-int library for Zig; did that ever get finished / included in the standard library?
<Hejsil>
And parsing is probably gonna be rewritten again :)