ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
PV_ has joined #zig
cenomla has joined #zig
<ltr_> i keep getting that error
<ltr_> damn i dont know
cenomla has quit [Quit: cenomla]
cenomla has joined #zig
<ltr_> LLVM_ABI_BREAKING_CHECKS=FORCE_OFF now im compiling llvm with that option
jfo has quit [Ping timeout: 248 seconds]
<PV_> I have question about structs - whether they can be used as "poor man's objects".
<PV_> 1. With all access to struct internals is only through struct methods.
<PV_> 2. All members are hidden, invisible, inaccessible, seen only as byte array.
<PV_> 3. struct can be instantiated as value (on stack, in other struct), w/o need to @import anything related to members.
<PV_> In C one could import header with struct description, but this brings in all internal details. Or one can hide the struct behind pointer to the struct, but this has performance implications and requires lifetime management. I am asking if there's third way, ability to hide internals but w/o need to use pointers.
dimenus2 has joined #zig
dimenus2 has quit [Client Quit]
<andrewrk> ltr_, that's really strange, I don't get that error when I build from source. Did you use the configuration parameters from https://github.com/zig-lang/zig/wiki/How-to-build-LLVM%2C-libclang%2C-and-liblld-from-source ?
cenomla has quit [Quit: cenomla]
_whitelogger has joined #zig
benq has joined #zig
PV_ has quit [Ping timeout: 260 seconds]
arBmind has joined #zig
arBmind has quit [Quit: Leaving.]
benq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
benq has joined #zig
jfo has joined #zig
alpha has joined #zig
alpha has quit [Client Quit]
benq has quit [Quit: Textual IRC Client: www.textualapp.com]
jfo has quit [Quit: Lost terminal]
sparris has joined #zig
<sparris> I tried to print floats and noticed that there where no formatting options for floats that I could find. It would be nice to use the zig standard library for formatted float printing (not libc), would adding somthing like Go's formatting (https://golang.org/pkg/fmt/) be interesting+
<sparris> (I meant the above as a question: ... be interesting?)
dimenus_ has joined #zig
dimenus_ has quit [Client Quit]
jfo has joined #zig
dimenus is now known as Guest12636
Guest12636 has quit [Killed (leguin.freenode.net (Nickname regained by services))]
dimenus has joined #zig
Guest12636 has joined #zig
hasen_judy has joined #zig
<hasen_judy> I see there are now functions to get struct members :)
<hasen_judy> this is awesome
<jfo> I wonder if it would be useful to anyone else to have a dedicated test command that simply runs the last test present in the file. I'm using `zig test` as a little runner and I'm falling into some TDD patterns and I don't need to run all the tests every try. right now I'm doing it this way https://github.com/jfo/vim-runners/blob/master/plugin/runners.vim#L62
<jfo> `zig test --last-only` or something.
<ltr_> jfo: i think you can filter the test, or modify the build.zig file to run test acording a custom criteria
<andrewrk> sparris: agreed. That's planned. what's needed to do that is 1. Some more userland code in std/fmt.zig and then 2. Documentation
<andrewrk> jfo: have you tried --test-filter combined with giving your test unique names?
<jfo> yes, that's what I'm doing now
<jfo> it's working fine for me but I wonder if a dedicated "run only the final test" command would help with iteration. This is a "hey this would help me in my personal workflow but maybe not everyone else would get benefit" musing
hasen_judy has quit [Quit: hasen_judy]
<jfo> ltr_: I need to learn the build system but the docs are TODO-y rn :)
<ltr_> the build.zig that comes with the source code could help you
<dimenus> andrewrk, i found the bug in #603 and others https://github.com/zig-lang/zig/issues/603 that is causing issues with cImports
<dimenus> the hash table for typedefs (and possibly others) isn't returning items that should exist in the table
<dimenus> so zig generates another pub const item again and again every time it sees the typedef
<dimenus> didn't you introduce hash tables somewhat recently on decls?
<sparris> andrewrk: Nice, maybe I will playaround with adding some formatting options in fmt.zig for learning myself.
<andrewrk> sparris, that would be most welcome
<andrewrk> dimenus, you are referring to this commit: c1642355f0b05f182c0b6d81d294d12be79ad0a8
<andrewrk> I suspect that the bug is independent of that commit
<andrewrk> nice find btw
<dimenus> andrewrk, yep commit does not look related
<dimenus> i just vaguely remembered you implementing hash tables recently-ish :)
arBmind has joined #zig
<dimenus> andrewrk, i actually think we're just misundestanding ASTUnit::visitLocalTopLevelDecls
<dimenus> it gets called once for all typedefs, not per typedef
<dimenus> sorry, it calls our function once for all typedefs in a module
<dimenus> not for each one
jfo has quit [Ping timeout: 240 seconds]
jfo has joined #zig
<ltr_> andrewrk: i was able to compile llvm with debug symbols, 5 hours and 400Gb of trying, zig compiles w/o those errors i mentioned, i just had to define LLVM_ABI_BREAKING_CHECKS=FORCE_OFF, i dont know why
<andrewrk> ltr_, very strangeu
<andrewrk> dimenus, sounds like we can put the pointer address in a hash table to uniqueify them?
<andrewrk> I think we do that for some other top level decls
<dimenus> my first guess was wrong, it might not be the hash function
<dimenus> if i create a dummy header file with multiple typedefs in it, that function only gets called once
<dimenus> so my thought is that the clang function is meant to resolve ALL typedefs in a module not one typedef
<ltr_> andrewrk: what can i use to display messages in the compiler's code? emit_warning?
<ltr_> i cant debug certain lines of parsec, the debuger just exit the function without passing for any return
<ltr_> the default flags for debug are -O0?
jfo has quit [Ping timeout: 264 seconds]
<ltr_> no, hehe without optimizations it debugs correctly
<dimenus> are you working on the typedef/struct issue with cImports ltr_?
jfo has joined #zig
steveno has joined #zig
<ltr_> yes
<ltr_> trying to
<andrewrk> ltr_, fprintf(stderr, "blah\n");
<andrewrk> emit_warning is for --verbose, to explain why we couldn't translate a given C definition to zig
<dimenus> andrewrk, i have a question when you havea minute
<andrewrk> dimenus, go for it
<dimenus> so i sort of figured out what's going on here with the issue I mentioned earlier
<dimenus> the TypedefnameDecl points have different values each time they're passed into the function
<dimenus> so we can't store those directly, but we can store the names of the typedefs
<dimenus> that worked for my simple example, but fails with glfw3.h for instance or windows.h
<dimenus> still outputting a lot of the same typedefs over and over
<dimenus> so I'm trying to find where we print out all of the values in the c->decl_table table
<andrewrk> maybe we need to call some function such as GetCanonicalDeclaration
<andrewrk> to get a unique pointer
<andrewrk> I think decl_table is just for de-duping. The part where we actually add a zig declaration is add_top_level_decl
<dimenus> andrewrk, nice that did indeed give us a unique ptr for typedefs
<dimenus> now its on to enums, which already call getCanonicalDecl() but are still being duplicated
steveno has quit [Ping timeout: 250 seconds]
steveno has joined #zig
jfo has quit [Ping timeout: 240 seconds]
jfo has joined #zig
<andrewrk> dimenus, hmm that is curious
steveno has quit [Remote host closed the connection]
<ltr_> i cant debug parsec.cpp file, i can see what dimenus is saying about the table, but i cant debug that part from line 2610 to 2611 it just exit the function, im using a -O0 build
<dimenus> i've got most of it working already
<dimenus> compiler still doesn't like typedef interface
<dimenus> but that's about it
<dimenus> trying to get a glfw app running on windows now
<ltr_> no problem , im just curious why the debuger does not continue to the next line
<ltr_> when it should do the put in the table
<dimenus> o
<dimenus> *i'm not sure what you mean
<dimenus> i'm also using msvc though, not gnu tools
<andrewrk> I believe ltr_ is using gdb on linux and dimenus is using msvc debugger on windows
<andrewrk> they likely have different behavior in this situation
<ltr_> yes
<ltr_> i have a BP in the line 2611, the first time it stops for the first declaration i cant go to the next line with continue, it just exit the function
<ltr_> from 2610 -> 2611
<andrewrk> ltr_, what distro are you using?
<ltr_> ubuntu 17.10
<ltr_> zig is compiled with debug and -O0
<ltr_> llvm5 compiled with debug symbols too
<ltr_> the second time, i cant continue normally
<ltr_> sorry i CAN continue
<ltr_> lol:
<dimenus> 2610 on my version of zig is a return statement
cgag has quit [Ping timeout: 255 seconds]
andrewrk has quit [Ping timeout: 255 seconds]
<ltr_> (gdb) print trans_qual_type(c, child_qt, typedef_decl->getLocation())
<ltr_> /build/gdb-sBS5Fz/gdb-7.12.50.20170314/gdb/infcall.c:836: internal-error: value* call_function_by_hand_dummy(value*, int, value**, void (*)(void*, int), void*): Assertion `sp >= lastval_addr' failed.
<ltr_> A problem internal to GDB has been detected,
<ltr_> further debugging may prove unreliable.
<dimenus> andrewrk, does zig have block comments yet?
andrewrk has joined #zig
<dimenus> 7.12 is a little old for gdb, ltr_
<ltr_> upgrading...
<ltr_> 2610 parsec? let me check, im sure im with the last commit of master
<dimenus> andrewrk, was print deprecated in stdout?
<ltr_> zig std?, yes, i think andrewrk just went offline
<ltr_> oh no, he is here i have the part quit messages filtered out
<andrewrk> dimenus, are you talking about io.stdout.print?
<andrewrk> I changed all the io API
<dimenus> yep
<andrewrk> usually you want std.debug.warn
<andrewrk> if you want to print to stdout, use io.getStdOut(), which gives you a io.File
<dimenus> i want to print fmt though
<andrewrk> then you can use file.write, or make a io.FileOutStream so you can use the io.OutStream API (which has formatted print)
<andrewrk> or you can even go crazy, and wrap that in a io.BufferedOutStream, which has the same io.OutStream API but is buffered
<andrewrk> this commit has some examples in the tests: 4543413491078c53d24115c5229989cda05cb1a5
<andrewrk> oh and in the commit message
<andrewrk> dimenus, oh, and std.debug.warn supports formatted printing
<dimenus> i have most of the cimports workign btw
<dimenus> i can actually call glfw functions on windows and they work
<andrewrk> cool
<dimenus> can't include windows.h because zig chokes on typedef interface though
<andrewrk> do the existing parseh tests pass?
<andrewrk> zig build --build-file path-to-zig-src/build.zig test-parsec
<andrewrk> we have some typedef tests in there
<andrewrk> dimenus, do you have a reduced test case that shows the typedef problem?
<dimenus> hmmm, debug.warn worked but FileOutStream print crashed
<dimenus> andrewrk, i'll build one this evening most likely
<andrewrk> thejoshwolfe and I are going to do some pair programming tonight over the phone, working on adding more automatic c-to-zig translation
<dimenus> nice
arBmind has quit [Quit: Leaving.]
<dimenus> andrewrk, parsec tests all pass
<andrewrk> good
<GitHub21> [zig] dimenus opened pull request #610: Fixed duplicate decl detection for typedefs/enums (master...parsec) https://git.io/vFKzm
<andrewrk> dimenus, nice, I'll have a look in a couple hours
<dimenus> andrewrk, is it possible to do pointer math with c pointers?
<dimenus> scenario is that in glfw, monitors are returned as GLFWMonitors**
arBmind has joined #zig
<andrewrk> have a look at std/cstr.zig
<andrewrk> in short: use foo[index]
<dimenus> yeah i was using that, i think zig might have the type confused here though
<dimenus> '?&?&struct_GLFWmonitor'
<andrewrk> it's because each thing can be null
<andrewrk> so you'll have to null unwrap the double pointer, then for each iteration null unwrap the inner pointer
<andrewrk> dimenus, https://clbin.com/p5WJY
<andrewrk> (I'm assuming that the monitors array is terminated by null)
<dimenus> it's not, i have a count in this case
<andrewrk> in this case you want to slice the result
<andrewrk> const monitors = @ptrCast(&&GlfwMonitor, glfwGetMonitors())[0..monitor_count];
<dimenus> your example got me where I needed to be though
<dimenus> thanks
<andrewrk> I think that cast should work
<dimenus> interesting
<andrewrk> it's a little dangerous. you could be more safe by not casting, and doing this:
<andrewrk> const monitors = (??glfwGetMonitors())[0..monitor_count] // and then `??` before accessing monitors[index]
<dimenus> is the type namespaced?
<andrewrk> which type?
<dimenus> &&struct_GLFWmonitor
<andrewrk> it's in the @cImport namespace
<dimenus> yep
<andrewrk> so if you did `const c = @cImport(...);` then it's `c.struct_GLFWmonitor`
<dimenus> i was confusing myself, so i did a parsec
<dimenus> this is very close: var monitors = @ptrCast(&&glfw.GLFWmonitor, glfw.glfwGetMonitors(&monitor_count))[0..monitor_count];
<dimenus> need to just convert the c_int to usize somehow
hasen_judy has joined #zig
hasen_judy has quit [Client Quit]
<andrewrk> usize(value)
<dimenus> i didn't realize conventional casting was a thing in zig
<dimenus> sorry about that lol
<andrewrk> this asserts that the value is positive
<andrewrk> lol no worries
<andrewrk> e.g. your program will crash if you do usize(c_int(-1))
<andrewrk> (in the above trivial case the compiler will catch it, but you get the idea)
<dimenus> here i am trying to find a compile time function to do it
<dimenus> when its just straight forward
<dimenus> that's cool that it asserts
<dimenus> i should really implement some of glfw in zig
<dimenus> so we don't need to do fancy pointer handling
<dimenus> we can just return array of known length
<andrewrk> that would be neat
<andrewrk> I was planning on doing that at some point
<andrewrk> we could even have the library expose a C interface
<andrewrk> so you can use it with either zig or C, and it can compete directly with GLFW
<dimenus> do you have thoughts on a 'using' so you can ignore namespacing temporarily
<dimenus> like over a block scope for instance
<andrewrk> we have that
<andrewrk> `use foo;`
* jfo ++glfw
<andrewrk> `use @import("foo.zig");`
<andrewrk> oh, over a block scope
<andrewrk> that might be interesting
<dimenus> like it shows intent rather than a global use
<dimenus> and you're less likely to have ambiguous names
<andrewrk> yeah
<jfo> how often do you use `use`?
<dimenus> not often yet
<dimenus> lol
<dimenus> but prefixing everythign with 'glfw' is high friction
<andrewrk> jfo, it's recommended generally to avoid `use`.
<jfo> sorry I meant more generally in earnest
<andrewrk> it's useful when trying to make public something you're importing, e.g. `pub use foo;`
<andrewrk> `use` slows down the compiler
<dimenus> ok, avoid it I will
<dimenus> with intellisense i guess that friction goes away anyway
<jfo> block scope use reminds me of php closures
dimenus has quit [Read error: Connection reset by peer]
dimenus has joined #zig
dimenus has quit [Remote host closed the connection]
arBmind has quit [Quit: Leaving.]
cgag has joined #zig
achamb has quit [Quit: leaving]