ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
<mreiland>
here's the error: error: invalid token: '*' pub fn init(x:f32,y:f32, c: *const Color) Point {
<darithorn>
do you have the most recent version of zig?
<mreiland>
I just checked, it was master I downloaded
<mreiland>
but it was a few days ago
<darithorn>
yeah, redownload the master and it'll compile fine with what you have now
<andrewrk>
pointer syntax changed yesterday
<mreiland>
the link is still colored, has an update been pushed for it?
<mreiland>
and does it change the URL?
<darithorn>
it doesn't change urls
<mreiland>
oh ok
<mreiland>
zig-linux-x86_64-0.2.0.717ac85a is what I downloaded, I'll redownload and compare build id's
<mreiland>
thanks
<darithorn>
the downloads for "Master" are automatically built every day or so iirc
<mreiland>
how often does syntax like that change?
<darithorn>
not very often. that pointer syntax change has been planned for a while though
<mreiland>
I'm wondering if maybe I should work against the 0.2.0 release
<mreiland>
alright, sounds like it was just wonderful timing on my part then :)
<mreiland>
actually it looks like I have the latest version, I'm guessing the binaries haven't caught up with the documentation yet
<mreiland>
I'll just work off the 0.2.0 docs you linked me until that happens, thanks for the help
king_button has quit [Remote host closed the connection]
king_button has joined #zig
<dbandstra>
would it make sense to have an attribute called something like "fixed" for struct fields, which creates a compile error if you try to copy that field out of the struct? then only allow @fieldParentPtr to work on "fixed" fields?
<dbandstra>
i just spent time tracking down some undefined runtime behaviour because i copied `random` out of the Xoroshiro object, instead of using a pointer
king_button has quit [Remote host closed the connection]
<dbandstra>
maybe i'm missing somethign though, i just discovered @fieldParentPtr 5 minutes ago
cenomla has joined #zig
<andrewrk>
dbandstra, oh that's an interesting idea
<andrewrk>
mreiland, looks like the latest link redirects to zig-linux-x86_64-0.2.0.b85b68a7.tar.xz
<andrewrk>
that's the newest master branch commit
<mreiland>
I'm probably doing something silly, but I'm looking at the following download page: https://ziglang.org/download/
<mreiland>
and I'm pulling down the 2nd link (linux) named 'zig-linux-x86_64-master.tar.xz', but it still appears to be pulling down the file 'zig-linux-x86_64-0.2.0.717ac85a.tar.xz'
<mreiland>
am I looking in the wrong place perhaps?
<dbandstra>
try right clicking on the zig-linux-x86_64-master.tar.xz link in a private window
<dbandstra>
opening in a private window *
<dbandstra>
i think it's a browser cache thing
<MajorLag2>
yeah, it sounds like browser caching
<MajorLag2>
but... I can't think of why a browser would think it made sense to cache a download
<mreiland>
yep, that's what it was
nicolaslekoala has quit [Read error: Connection reset by peer]
<mreiland>
I tried it in a private window and saw the correct download
<MajorLag2>
Yeah, I just pulled it and got /zig-linux-x86_64-0.2.0.b85b68a7.tar.xz
<mreiland>
yeah, mystery solved, thanks guys
<MajorLag2>
sounds like the browser might need a bug report
<mreiland>
I hate how aggressive ff and chrome get with caching sometimes, there's no reason for them to be caching that page
<dbandstra>
there's some kind of redirect or url rewrite going on
<MajorLag2>
it's a 301
<MajorLag2>
...which to be fair is 'moved permanently'
<mreiland>
yeah, I was just diving in to look at that
<mreiland>
the last modified date is also 5/23
<MajorLag2>
so maybe that's something that needs to be changed on our end...
<mreiland>
yeah, I definitely don't think following a link from your frontpage should hit a page that returns a 301, lol
<mreiland>
and I would bet the last modified being out of date has something to do with amazon
<mreiland>
just a guess though
cenomla has quit [Ping timeout: 268 seconds]
<mreiland>
Is there good documentation on the standard library and the memory model used by zig? I don't seem to be finding what I'm looking for in the documentation
quc has joined #zig
<mreiland>
I'll take that as a no so I'll just start asking questions here.
<mreiland>
basically, I'm trying to wrap my head around memory management in zig
<mreiland>
it seems you're not able to copy structs and must always pass them by val
<mreiland>
but they do copy when you return the val from a function?
<dbandstra>
heh you are in the same spot as me
<dbandstra>
i think i was asking that question 2 days ago
<mreiland>
did you get a good answer?
<dbandstra>
yeah that's what the compiler allows, and returning does a memcpy (possibly optimized away in the future)
<mreiland>
my guess is that it does either copy or if the optimizer knows it's safe simply places it where it will ultimately end up in the stack? I know zig is big on making sure the stack is predictable so you cannot bust it
<mreiland>
ok, so if that's the case then if you do something like so MyStruct.init(MyOtherStruct.init(5,5))
<mreiland>
and MyStruct uses a pointer (since I think that's required by the language), that's a problem waiting to happen? or does the language do somethign to make that safe?
<mreiland>
to be clear MyStruct contains a MyOtherStruct pointer
<mreiland>
it's the equivalent of passing around a pointer to a local in C or C++, correct?
<dbandstra>
your MyStruct.init function has to take a `&const MyOtherStruct`
<mreiland>
yes
<dbandstra>
and then the compiler will automatically send a reference
<mreiland>
my concern is that the member in MyStruct must also be a pointer
<dbandstra>
(there's an issue i can't find where this feature might removed)
<mreiland>
unless I'm wrong on that, I'm still learning the language
<mreiland>
you mean it uses a reference to avoid the pointer copy?
<dbandstra>
i mean if a function takes a const poitner to something, and you call it with a value, it will be the same as calling it with &value
<mreiland>
let me get a more complete example, I think I'm not communicating well
<alpha>
I know zig is still in alpha stage and I don't have any problem with not having html docs. But even the stdlib source code has no doc comments.
<andrewrk>
you're suggesting that best practice is to write the docs at the same time as the function definitions
alpha has quit [Quit: Page closed]
<andrewrk>
there is an argument to be made there. however, given that the language itself isn't even stable yet, the stdlib is changing rapidly. once the language is more stable then we can start stabilizing the std lib
<dbandstra>
andrewrk, is there a way for me to build zig without having to build llvm (which i tried before, but ran out of disk space, it seems to require 100GB)
<andrewrk>
what os
<dbandstra>
i'm on linux
<andrewrk>
how about the static builds automatically built from master?
cenomla has joined #zig
<dbandstra>
i've been using that but i'd like to be able to mess around with the compiler (also i found a crash in the compiler that i wouldn't mind debugging myself)
<andrewrk>
ah wonderful
<dbandstra>
it's ok if the answer is no.. i should probably repartition or something and give my linux boot more than 100GB
<andrewrk>
be sure to use -DCMAKE_BUILD_TYPE=Release for clang and llvm
<andrewrk>
that should keep the size down
tiehuis has joined #zig
<andrewrk>
also debug builds are way slow
<tiehuis>
what distro are you running?
<dbandstra>
me? ubuntu 18
<andrewrk>
oh, you should be able to use llvm/clang from apt-get
<tiehuis>
because I compile against the package llvm from ubuntu with no issue on 16.04
<dbandstra>
ok
<tiehuis>
i use https://apt.llvm.org/ repositories on 16.04, but not sure what 18.04 is up to
<dbandstra>
i need llvm 6?
<tiehuis>
yes
<tiehuis>
looks okay on 18.04, give it a try with the system version and it should work, else just say if not
<dbandstra>
without adding any repositories i see llvm-5.0-dev but only 6 thing is llvm-6.0-tools
<dbandstra>
oh wait
<dbandstra>
it's not sorted :P
alpha has joined #zig
<alpha>
zig master builds do not contain zig fmt?
<andrewrk>
alpha, currently you need to build stage2 to get that
<andrewrk>
but we're probably going to do a temporary solution to get it into master builds until the self hosted compiler is done
<alpha>
Okay, thank you
alpha has quit [Client Quit]
<andrewrk>
alpha, to answer your question about passing allocators around, there was one proposal that I've been meaning to type up
<andrewrk>
a quick summary would be: ability to bind a parameter name to a value within a scope
alpha has joined #zig
<andrewrk>
but it's a tough argument to make, adding complexity to the language when a little bit of boilerplate will get the job done
<alpha>
tiehuis: Also, it gives the same error whether a source file is present or not
<tiehuis>
what is your `zig version` produce?
<alpha>
so to replicate, simple create a new directory and in it, `zig build --init` followed by `zig build`
<alpha>
tiehuis: latest master branch downloaded 2-3 hours ago
<tiehuis>
yeah, i did that and the issue (for the latest master) is failure to open the default 'src/main.zig' file
<alpha>
zig version => 0.2.0.b85b68a7
<alpha>
Hmm... even if i have src/main.zig, i get the same error though
<tiehuis>
can you make your main.zig have the content: `pub fn main() void {}`
<alpha>
tried it. same issue.
<tiehuis>
what does `zig build --verbose --verbose-link` print?
<alpha>
zig build-exe C:\Users\alpha\Desktop\s\src\main.zig --verbose-link --cache-dir C:\Users\alpha\Desktop\s\zig-cache --output C:\Users\alpha\Desktop\s\zig-cache\YOUR_NAME_HERE.exe --name YOUR_NAME_HERE reached unreachable code Unable to dump stack trace: Unable to open debug info: TodoSupportCoffDebugInfo Build failed. The following command failed: .\zig-cache\build zig . .\zig-cache --verbose --verbose-link
<tiehuis>
not really sure at this point sorry, does a normal `zig build-exe src/main.zig` work fine?
<alpha>
yes, I am able to use build-exe
<alpha>
Another question. I have main.zig which has a @cInclude. The `.h` file is in the same dir. But compiling the main.zig file, I get error that it is unable to find the .h file.
<alpha>
^ C:\Users\alpha\AppData\Local\Temp\sWZd7kMK.h:1:10: note: 'mpc.h' file not found #include <mpc.h> ^
<tiehuis>
add `-isystem /path/to/dir`
<tiehuis>
cInclude doesn't do local header resolution by default and only searches system headers
<alpha>
Okay. Thank you.
<alpha>
Is there any plan for local header resolution?
<tiehuis>
hasn't been asked as far as I'm aware
<tiehuis>
I think it depends on how common a use-case it will come to be and whether the existing solution has shortcomings otherwise
<alpha>
Okay, I will create a Github issue for both these things.
<tiehuis>
great, thanks
dbandstra has quit [Quit: Leaving]
dbandstra has joined #zig
<GitHub9>
[zig] tiehuis opened pull request #1039: Add context to zig_unreachable calls (master...context-for-unreachable) https://git.io/vhWNl
<tiehuis>
I pushed a pr that should add some context to all unreachable calls which should help here
<tiehuis>
when that builds try downloading that artifact if you want to pinpoint the issue
<tiehuis>
just a somewhat temporary measure until those backtraces are implemented
<alpha>
tiehuis: Thank you!
<dbandstra>
has anyone used vscode on linux to debug zig?
<tiehuis>
i think Hejsil uses vscode with debugging, i think on linux, would need to check
<dbandstra>
do you know if i should be using gdb or lldb?
<dbandstra>
sorry for all the questions, i used to do c/c++ stuff on windows
<tiehuis>
i uses gdb because i have a good script for it, but lldb has worked fine for me as well
<tiehuis>
no problem
<dbandstra>
i'm just fighting with vscode
<tiehuis>
i'm not familiar with debugging in vscode unfortunately so can't provide much assistance
<dbandstra>
neither am i :)
<dbandstra>
thanks to you i got zig built though
<tiehuis>
great, that's good to hear
<dbandstra>
ci/travis_linux_install is a good reference for apt getting stuff
alpha has quit [Quit: Page closed]
<dbandstra>
ahh i'm cooking with gas now
<dbandstra>
is it ever useful to use the `object.*.field` syntax?
<tiehuis>
only unless object was a double pointer which is not common, i think . only implicitly dereferences at most once?
<tiehuis>
would need to double check that
<dbandstra>
looks like . dereferences all the way
<dbandstra>
whoops i'm wrong, it does only once (my typo when testing it out)
qazo has quit [Read error: Connection reset by peer]
quc has quit [Ping timeout: 260 seconds]
nicolaslekoala has joined #zig
spazzpp2 has joined #zig
<spazzpp2>
hi
<spazzpp2>
just listening to "andy"s talk at recurse.com
<spazzpp2>
Do you agree that zig looks really promising (compared to slower rust)?
quc has joined #zig
isaachier has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<isaachier>
i doubt rust is slower by much... just allocates more
davr0s has joined #zig
isaachier has quit [Quit: Page closed]
clownpriest has joined #zig
clownpriest has quit [Client Quit]
clownpriest has joined #zig
darithorn has joined #zig
<spazzpp2>
I wrote a really simple char replacing parser and the result was slower than c
Ichorio_ has joined #zig
Ichorio has quit [Ping timeout: 276 seconds]
return0e has quit [Ping timeout: 248 seconds]
spazzpp2 has quit [Quit: Konversation terminated!]
spazzpp2 has joined #zig
return0e has joined #zig
isaachier has joined #zig
<isaachier>
spazzpp2 i'd compare rust with c++ speed (using clang compiler)
nicolaslekoala has quit [Ping timeout: 256 seconds]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
clownpriest has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
clownpriest has joined #zig
isaachier has quit [Quit: Page closed]
<andrewrk>
isaachier, yes any problems with empty structs are bugs
<andrewrk>
spazzpp2, I don't remember claiming that rust is slower
<andrewrk>
rust is a really solid project. the places where I think zig competes with rust are: robust error handling, writing inherently unsafe code, and simplicity
<spazzpp2>
andrewrk, no, I claimed rust was slower than C. Watching your talk was just context.
clownpriest has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
return0e has quit [Ping timeout: 245 seconds]
Sahnvour has joined #zig
<Sahnvour>
andrewrk: slowly making progress on the .pdb thing, I'm able to locate and read its format, but still need to determine how to get address/line information
<andrewrk>
Sahnvour, ah, excellent
<andrewrk>
that's related to what tiehuis and alpha were dealing with earlier
<Sahnvour>
hope I'm not duplicating work ?
spazzpp2 has quit [Quit: Leaving]
return0e has joined #zig
<adrusi>
based on the documentation it looks like there isn't really a good way to define a function in C and call it from zig, short of distributing the C code as a separate library, is that right?
<adrusi>
like if my project directory has the files main.zig, my_proc.c, my_proc.h, and I define my_proc in my_proc.c, there isn't a good way of calling my_proc from main.zig
<adrusi>
@cInclude adds a #include <...> to the C buffer, but there's no way to add a #include "..."
<adrusi>
I'm trying to get an error message from a c function that sets errno, but when I @cInclude("errno.h"), zig doesn't recognize c.errno (which doesn't surprise me since errno is declared in a strange way by glibc)
<adrusi>
so my first try at a workaround was to define char const *errorstring() { return strerror(errno); } in C and call that function from zig, but it looks like that doesn't work
<adrusi>
There should probably be a @cIncludeLocal builtin, or similar
<adrusi>
if @andrewrk thinks that makes sense I can make a PR, seems like a simple addition
clownpriest has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<andrewrk>
Sahnvour, I believe you are the only one working on windows stack traces
<andrewrk>
adrusi, the zig build system is only a proof of concept right now, but you can use it to build .c and .zig files and put them together
<adrusi>
yeah, I've been looking at this example, but it's different because it shows C calling Zig functions rather than Zig calling C Functions
<andrewrk>
adrusi, for errno, try this: @import("std").c._errno()
<andrewrk>
std.c is not complete but it's intended that for libc you can use it instead of @cImport
<adrusi>
however, I'm now thinking that it would be better to use build options configuring C_INCLUDE_PATH rather than having a separate @cIncludeLocal builtin
<adrusi>
I tried implementing @cIncludeLocal, but it doesn't work because the @cImport makes a file in /tmp, and so #include "..." searches for headers relative to there, which is probably what it should be doing
clownpriest has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<andrewrk>
do you have a conflicting .h file name and you need to decide how to resolve the conflict in the @cImport block?
Ichorio_ has quit [Ping timeout: 260 seconds]
<adrusi>
no, that was not the issue
<adrusi>
the issue was that @cInclude(...) was not resolving header files in the PWD
<adrusi>
because @cImport places the generated header file in /tmp, so the preprocessor thinks /tmp is PWD (I think?)
<andrewrk>
why not put the pwd in the include path explicitly?
<adrusi>
yeah, I think that's the right move now
donpdonp has quit [Ping timeout: 240 seconds]
clownpriest has joined #zig
clownpriest has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
alpha has joined #zig
<alpha>
adrusi: I have proposed cInclude to search local directory here https://github.com/ziglang/zig/issues/1040 It would be really good for single header libraries which are now quite common in C
<andrewrk>
that's a compelling reason
quc has quit [Ping timeout: 248 seconds]
alpha has quit [Ping timeout: 260 seconds]
<andrewrk>
if it's a single file header, that would be heavily relying on translate-c
<andrewrk>
for the function bodies and such
<andrewrk>
it would probably be better to handle this use case by porting the single file C code into zig and cleaning it up a bit
<GitHub85>
[zig] isaachier opened pull request #1045: Fixes for zero-sized allocation (master...minor-cpp-improvements) https://git.io/vhlaF