| 10 Jan 2021 |
 kvark | I think I'm going to tag the next version after https://github.com/gfx-rs/naga/pull/351 is merged and get it to wgpu | 02:01:23 |
| kvark | unless you folks have other things pending? | 02:01:33 |
| kvark | ah, I think https://github.com/gfx-rs/naga/issues/350 is also needed | 02:08:39 |
 napokue | No I haven't something pending, been busy with work, holidays, other side projects recently. Hopefully soon I can contribute some more :) | 02:26:00 |
| 11 Jan 2021 |
| *  pjoe always has pending ideas, but nothing currently in progress, so tagging is fine with me too | 06:23:31 |
| 12 Jan 2021 |
| * pjoe added handling of function calls to glsl-in: https://github.com/gfx-rs/naga/pull/354 | 08:27:21 |
| kvark | anybody wants to peek at https://github.com/gfx-rs/naga/pull/355 ? | 21:17:49 |
| kvark | should be fairly trivial | 21:17:54 |
| kvark | pjoe: would you want to fix https://github.com/gfx-rs/naga/pull/354, or want it landed as is? | 22:48:33 |
| 13 Jan 2021 |
| pjoe | fixed, found one more place in same file that could use flat_map. seems like I have merge rights, want me to do it (asuming squash and merge is what we do?) | 07:04:48 |
| pjoe | * fixed, found one more place in same file that could use flat_map. seems like I have merge rights, want me to do it (asuming squash and merge is what we do?) | 07:05:01 |
| kvark | sure thing! | 07:05:38 |
| pjoe | or is it 'rebase and merge' ? | 07:06:21 |
| kvark | it depends on what you want to do. If there are individual commit-steps, all checked by CI, and all progressing towards a goal, then rebase is what we do | 07:06:53 |
| kvark | otherwise, if it's just fixes and back-and-forth, we squash | 07:07:04 |
| pjoe | ok, think squash would be fine in this case then :) | 07:07:20 |
| kvark | yep | 07:07:25 |
| pjoe | done :) | 07:08:00 |
| * pjoe uses 'merge commits' at day job ... but there we are using gitflow like branching | 07:08:59 |
| kvark | thank you! | 07:09:18 |
| pjoe | btw. I noticed an issue with the casting implemented earlier: vec4(1) now becomes a cast instead of a compose | 07:09:59 |
| * pjoe trying to remember why I added the cast for type ctors with one param 🤔 | 07:10:37 |
| pjoe | ahh think it was from handling the float casting ... need to add some more check on output type | 07:18:59 |
| pjoe | I suppose vec4(1.0) should be a compose, while vec4(ivec4(1)) should be a cast 🤔 | 07:32:14 |
| pjoe | should vec4(1) actually be first a cast to float and then a compose 🤔 .. guess this type stuff isn't quite so simple | 07:44:48 |
| kvark | Ugh, glsl | 13:33:09 |
| kvark | Much implicit | 13:33:27 |
| pjoe | indeed ... ugh | 14:12:59 |
| kvark | I think GLSL ES doesn't allow that, fwiw | 14:23:07 |
| 19 Jan 2021 |
|  cryvosh joined the room. | 19:14:46 |
