ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
relatingdata has joined #zig
zolk3ri_ has joined #zig
zolk3ri has quit [*.net *.split]
minus has quit [*.net *.split]
zolk3ri_ has quit [Remote host closed the connection]
minus has joined #zig
pixeljoelson has quit [Remote host closed the connection]
isd has quit [Ping timeout: 265 seconds]
steveno_ has quit [Quit: Leaving]
Braedon has joined #zig
<Braedon>
I may be wrong but I felt that you could run functions on generic objects
<Braedon>
Like; fn Foo(T: type, T obj) { obj.RunX() }?
<andrewrk>
this is duck typing
<andrewrk>
if T has a RunX method then it will compile
<Braedon>
Yeh that's what I thought
<Braedon>
Assertion failed: (payload_type->di_type), function get_error_union_type
<Braedon>
Which probably means that I'm passing some error union somewhere and not handling it
hobomatic has quit [Quit: WeeChat 1.4]
<Braedon>
Oh never mind I did !type in my main generic function
<andrewrk>
if you get an assertion failure, that's a compiler bug
<Braedon>
Nah it was me
<Braedon>
The compiler should have given a better warning to be fair
<Braedon>
But it was me sticking an '!' onto a type that it didn't belong too
<Braedon>
Almost done locale basics
isd has joined #zig
return0e has joined #zig
return0e has quit []
heakins has quit [Ping timeout: 260 seconds]
isd has quit [Quit: Leaving.]
return0e has joined #zig
relatingdata has quit [Quit: Page closed]
Braedon has quit [Ping timeout: 260 seconds]
uptown has joined #zig
uptown has quit [Client Quit]
hryx has joined #zig
bbrittain has quit [Ping timeout: 264 seconds]
dtz has quit [Ping timeout: 248 seconds]
epsyloN has quit [Ping timeout: 264 seconds]
m6w6 has quit [Ping timeout: 264 seconds]
jab_ has quit [Ping timeout: 256 seconds]
jab has joined #zig
bbrittain has joined #zig
tridactyla has quit [Remote host closed the connection]
epsyloN has joined #zig
m6w6 has joined #zig
hoppetosse has joined #zig
hryx has quit [Ping timeout: 260 seconds]
dtz has joined #zig
raytracer[m] has quit [Ping timeout: 245 seconds]
kammd[m] has quit [Ping timeout: 260 seconds]
jab has quit [Ping timeout: 240 seconds]
jab has joined #zig
raytracer[m] has joined #zig
hoppetosse has quit [Ping timeout: 276 seconds]
kammd[m] has joined #zig
hoppetosse has joined #zig
Hejsil has joined #zig
zolk3ri has joined #zig
hoppetosse has quit [Remote host closed the connection]
hoppetosse has joined #zig
hoppetosse has quit [Ping timeout: 276 seconds]
Braedon has joined #zig
<Braedon>
Do I have to cast enums to use bitwise?
<Hejsil>
Yep
<Hejsil>
Braedon, what do you need the bitwise operators on enums for?
<MajorLag>
but can you do this with that?: `var window = sdl.CreateWindow("test", 0, 0, 640, 480, sdl.SDL_WINDOW_FULLSCREEN | sdl.SDL_WINDOW_OPENGL); ?
<MajorLag>
with a packed struct of bools, you'd either have to initialize the entire thing: Id{flag0 = false, flag1 = false, ...}, or create an intance undefined, memset it to 0, then set the flags you want to true...
<Hejsil>
takeFlags(5) is allowed if you just use numbers
hoppetosse has quit [Ping timeout: 264 seconds]
hoppetosse has joined #zig
<Hejsil>
Not saying using pub const fields is wrong. It has the nice bitwise or thing
<MajorLag>
your way can't do this: var to_check = Flag1 | Flag2 | Flag5; var chk = flags & to_chk; if(chk == to_chk)....
<Braedon>
Mhmm interesting I like that
hopppetosse has quit [Ping timeout: 264 seconds]
<Hejsil>
You could define a function that does this
<MajorLag>
it's a common enough pattern that I wonder if zig shouldn't have an enum type for this behavior. Then again, it's easy enough to do with an empty struct, so it is kind of unneeded.
<Braedon>
Again yeh but maybe?
<Braedon>
Also I found a bit of validation haha, I found a comment that says '// TODO ASCII is wrong, we actually need full unicode support to compare paths.'
<MajorLag>
though typing in the numbers by hand instead of an autoincrement is a bit tedious, but also kinda necessary if you intend to expose it.
<Braedon>
And I just finished my string invaraiant way to split strings
<Braedon>
It kinda is though something like iota could be useful?
<MajorLag>
iota is weird. I think it should act like enum and auto increment except where specified if we're going to do that.
<Braedon>
Yeh something like it but not exactly it cause its weird as hell
<MajorLag>
Braedon: In windows, even unicode is wrong. Windows file paths can encode surrogate halves in UTF-16.
<Braedon>
Yep mine does utf16 :)
<Braedon>
And utf22
<Braedon>
And every variant you want
<Braedon>
Just need to give it a way to view and iterate through them and its happy
<MajorLag>
right, but what I'm saying is, if you follow the unicode standard, windows file paths aren't necessarily valid unicode because it explicitly forbids encoding surrogate halves.
<Braedon>
Yah that's what I'm saying
<MajorLag>
*unpaired
<Braedon>
You call it like this; `var it = split(unicode.Utf8View, unicode.Utf8Iterator, []const u8).init("Cat, Mat, Bat", ",");` and so for Utf16 you would just create a view and iterator for Utf16 with those special rules
<MajorLag>
ah, I see.
<Braedon>
Now commonly there are shortcuts to do stuff like `stringUtils.asciiSplit_it.init("Cat, Mat, Bat", ",")`
<MajorLag>
You don't care about unicode, just as long as an iterator returns codepoints
<Braedon>
Yep
<Braedon>
Or not even codepoints
<Braedon>
It could return anything
<Braedon>
All you need is a way to slice your view, compare views, create iterators from views, and iterate through that, as well as reset iterator
<Braedon>
Then you can do 'anything'
<Braedon>
This will work for EVERY 'memory' function, they said they wanted something that could work with anything and I knew how annoying Windows is so i made sure it was done right
noonien has joined #zig
steveno_ has joined #zig
aiwakura has quit [Quit: Ping timeout (120 seconds)]
aiwakura has joined #zig
aiwakura has quit [Quit: Ping timeout (120 seconds)]
aiwakura has joined #zig
Braedon has quit [Ping timeout: 260 seconds]
aiwakura has quit [Quit: Ping timeout (120 seconds)]
Hejsil has quit [Quit: Page closed]
aiwakura has joined #zig
<MajorLag>
Hejsil, the bitflags thing with an empty struct could be made safe, if there were a way to mark a type alias such that it wouldn't implicitly cast to what it is aliased to and would be considered a new type instead. Something like: `const MyFlag = @noImplicitCast(u8); const MySet = struct { pub const FLAG0 = MyFlag(0b00000001); pub const FLAG0 = MyFlag(0b00000010); ... };` the the compiler would throw an error when
<MajorLag>
1);` instead of `funcTakingFlags(MySet.FLAG0);`
<MajorLag>
Actually andrewrk, what do you think about that in general? Being able to 'divorce' a type alias from the type it aliases so that you have to explicit cast between them?
Ichorio has joined #zig
zesterer has joined #zig
<andrewrk>
MajorLag, I think you can accomplish that by putting a type in a struct
alexnask has joined #zig
<alexnask>
Hi
<andrewrk>
hi
<alexnask>
Sorry for flooding the issues tracker :P
<alexnask>
I'm just testing things out
<alexnask>
Is there any way to check if the Child type of a Pointer type is const?
<alexnask>
I've looked at this issue, in fact I think I will be trying to implement a subset of that proposal
<alexnask>
My motivation is e.g. building a function that gets the i'th field of any struct.
<alexnask>
It should return a const pointer if the reference passed in is const
<andrewrk>
related, there is a problem with @fieldParentPtr where it returns a ptr with the same const-ness as the field ptr, but that's incorrect. the two are unrelated. so you would have to provide the const-ness as an argument to @fieldParentPtr for it to be correct
<alexnask>
I guess what I'm asking is wether the const-ness of a type part of the type itself, or an attribute of the pointer type?
<alexnask>
For example, is "const i32" a type?
<andrewrk>
it's an attribute of the pointer type
<andrewrk>
alexnask, it's planned to add @field which does field access syntax but with a comptime []const u8 field name instead of an identifier
<alexnask>
Ah, cool, I'll go ahead and close that issue then
<MajorLag>
andrewrk, I suppose so, it's a hairier to set up for the usecase I mentioned though. I suppose it is preferable to adding a new builtin function.
<andrewrk>
this is for the SDL flags use case, right?
<MajorLag>
well not just SDL, bitflags in general.
<andrewrk>
for bit flags in general, what's the downside of Hejsil's suggestion?
sandwit has quit [Remote host closed the connection]
sandwit has joined #zig
<MajorLag>
You can't do bitwise operations on them: var to_check = Flag1 | Flag2 | Flag5; var chk = flags & to_chk; if(chk == to_chk)....
<MajorLag>
so passing a set of flags into a function becomes a chore too
<andrewrk>
I feel like normal u32 or whatever is pretty ok for this use case
<andrewrk>
It seems like bugs with flags like this are rare
<hinst>
need to terminate statements with ; character ?
<andrewrk>
hinst, correct
<MajorLag>
yeah, I generally agree andrewrk, I was just considering how one would make it strict if one were so inclined.
steveno_ has quit [Ping timeout: 245 seconds]
steveno_ has joined #zig
sandwit has left #zig ["Leaving"]
<andrewrk>
MajorLag, that's fair. I think we could come up with a use-case-specific solution, but then we would want to weigh that against introducing another way to do things and adding complexity to the language
zesterer has quit [Read error: Connection reset by peer]
zesterer has joined #zig
<MajorLag>
andrewrk: I've been testing a possible saftey improvement to the interface pattern, but I can't seem to get it to break in a case where it should... I might just be missing something stupid here: https://paste.ubuntu.com/p/shxjkzK6SM/
zesterer has quit [Client Quit]
zesterer has joined #zig
<alexnask>
@MajorLag it fails for me fwiw
<MajorLag>
odd. I even tried throwing extra garbage on the stack before using he interface, and using @noInlineCall to get it. I'll try it in linux
<alexnask>
I tried on WSL (linux on windows)
<alexnask>
So I assume it will work on linux, odd one for sure
<MajorLag>
yeah, it breaks (that is, breaks in the intended way) on linux. so what magic makes it work on win32 I wonder?
<alexnask>
let me try on win64 too
<alexnask>
perhaps LLVM removed the extra variables you initialized and it is a case of the interface still being on the bottom of the stack or smth?
<alexnask>
yup, it works on win64 for me too... hmmm
<MajorLag>
that's what I thought, but I threw extra variables on the stack intentionally and then warn'ed them out to be sure they were being used. When that didn't work I made one of the variables a []u32{0}**1024, still worked.
<MajorLag>
Is windows doing escape analysis and allocation behind my back?
<alexnask>
Nah that would be too much magic I think :P
<alexnask>
I assume returning the interface by value from getInterfaceForThing breaks?
<alexnask>
seems so, so the interface stays in the stack for some reason
hoppetosse has quit [Ping timeout: 265 seconds]
hoppetosse has joined #zig
<andrewrk>
MajorLag, type expressions are implicitly comptime
<andrewrk>
MajorLag, perhaps this can be incorporated into the language. E.g. if you use @fieldParentPtr on a given struct (and the struct is not extern or packed) then it will add a hidden "sig" field and do this check
hoppetosse has quit [Read error: Connection reset by peer]
<MajorLag>
that's what I was thinking. there are probably some cases where it will still break (trying to read from deallocated memory comes to mind).
<MajorLag>
also, whatever the hell is going on in win32 here.
<raytracer[m]>
Hey there. Can somebody give me any tipps when it comes to analyzing the difference in behavior in debug vs release mode? I have ported a small C++ program (https://github.com/raytracer/zig-smallpt) to zig and it runs just fine in debug, but not in release-safe or release-fast where some optimization seems to lead to the wrong result (a black image in this case).
<andrewrk>
hi raytracer[m]
<andrewrk>
that's a high priority compiler bug you found there
steveno_ has quit [Quit: Leaving]
<raytracer[m]>
Ah should I open a Github Issue or is it an already known bug?
<andrewrk>
I would appreciate a github issue
<andrewrk>
raytracer[m], oh, one thing to consider
<MajorLag>
...so related note: that thing that should fail but doesn't in windows? breaks in release-fast and release-safe, just not in debug.
<MajorLag>
or tests.
<raytracer[m]>
Thanks for the tip. I already tried to set the Float Mode to strict mode. I will try come up with a minimal working example and open an Issue.
<andrewrk>
thanks. I'll have a look right away
noonien has quit [Quit: Connection closed for inactivity]
<andrewrk>
raytracer[m], when I run smallpt in valgrind I see a bunch of invalid reads
<andrewrk>
even in debug mode
<andrewrk>
for some reason valgrind is not picking up the debug info though
<andrewrk>
raytracer[m], also I recommend to use BufferdOutStream for your use case
<raytracer[m]>
Hmm interesting, thank you for your effort. I will take a further look at it tomorrow, precompiled valgrind does not seem to be available for Mac OS High Sierra and compiling it from source currently fails on my system.
<raytracer[m]>
Btw. https://github.com/zig-lang/zig/issues/669 makes it currently a bit hard to print the intermediate results of the computations in release mode, maybe I have to think of something else to look at the computations.
<andrewrk>
raytracer[m], you're linking against libc for malloc - you can also use printf from C
<andrewrk>
providing a full standard library competing with libc is a big effort and is not complete yet. apologies for the incompleteness (specifically with regards to floating point printing)
<raytracer[m]>
Oh you are right, I will try that
<andrewrk>
I can reproduce the missing debug symbols in valgrind with just clang
hoppetosse has joined #zig
zolk3ri has quit [Remote host closed the connection]
<raytracer[m]>
Oh no problem at all @ standard library. Porting smallpt to zig was just a small weekend project, unfortunately the original authors intent was to produce a C++ version in less than 100 lines so the readability is less than ideal. So the code has probably to go through quite a few iterations before it becomes readable (currently it is basically an almost literal translation)
zesterer has quit [Quit: zesterer]
zesterer has joined #zig
zesterer has quit [Client Quit]
zesterer has joined #zig
<GitHub49>
[zig] bnoordhuis opened pull request #897: fix use-after-free in BufMap.set() (master...fix879) https://git.io/vxSWg
<andrewrk>
raytracer[m], I got valgrind debug info working. here's a sample output on smallpt: https://clbin.com/kfMVW
steveno_ has joined #zig
steveno_ has quit [Client Quit]
<raytracer[m]>
Thank you very much, now I know where to look. I will probably continue to work on it on the weekend, good night for now (currently midnight here).
<GitHub119>
[zig] bnoordhuis opened pull request #899: fix llvm assert on version string with git sha (master...fix898) https://git.io/vxS0F
zesterer has quit [Quit: zesterer]
<GitHub92>
[zig] andrewrk closed pull request #899: fix llvm assert on version string with git sha (master...fix898) https://git.io/vxS0F