Perl 6 - the future is here, just unevenly distributed

IRC log for #pogl, 2017-01-21

| Channels | #pogl index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
09:49 Mithaldu chm: didn't have time to make the branch?
09:52 Mithaldu chm: also it would be nice if you could comment on some of the other PRs i made so i can try to increase the non-critical code quality instead of letting the bitrot set in further
16:48 chm joined #pogl
16:51 chm Mithaldu: no, didn't have time to make a branch but I see you were able to test it out yourself.
16:52 chm Mithaldu: I've given feedback for discussion on your PRs
16:52 Mithaldu chm: kinda unhappy i have to repeat both my summary AND the code in answer to the mfpl noise question :P
16:52 chm Mithaldu: Thanks for the timing information and the #pogl comments.
16:52 Mithaldu cheers
16:53 chm I have a bettern understanding of where I wasn't understanding your concerns.
16:53 Mithaldu excellent
16:53 chm First, there was ambiguity of "array" which I took as a perl @array but you seem to use as OpenGL::Array sometimes.
16:53 chm There are a number of times I'm still not clear.
16:54 Mithaldu i use both whenever it is more convenient
16:54 Mithaldu particularly
16:54 chm Yes, but it makes a difference in the XS bindings.
16:54 Mithaldu glUniform4f
16:54 Mithaldu i'd love to be able to throw an array at that one and friends
16:55 chm Unfortunately, Bob used _p for some perl bindings and when convenient used the same for OGA bindings.
16:55 Mithaldu but that rewards me with a compile time error, so i must unpack the array manually
16:55 chm Regarding glUniform4f and @arrays, the place the binding should be is glUniform4fv_p I think.
16:56 chm That said, those have not been implemented.
16:56 Mithaldu yep
16:56 Mithaldu that's why i have them in helpers right now
16:56 chm I would definitely put in an issue for feature request that perl versions of glUniform#X take @args as well
16:57 Mithaldu chm: https://github.com/devel-chm/OpenGL-Modern/pull/12/files#issuecomment-274273581
16:57 Mithaldu alright, making an issue
16:58 chm I don't understand where \r or \n or \r\n is not whitespace.
16:58 Mithaldu in git
16:59 Mithaldu if i run mfpl on windows i end up with a 65k+ lines changed file, and it is invariably at the top for git gui when trying to make a commit
17:00 Mithaldu that's utter crap
17:01 chm Mithaldu:  I'm not sure I think having automatically generated files under version control makes sense.
17:02 chm Corian did that but it has been an annoyance for me as well since I couldn't tell from the stats
17:02 chm if the changes were significant or not.
17:02 Mithaldu are those files supposed to change based on the system?
17:02 Mithaldu if not, then they're fine to keep, as they're based on other files in the repo
17:02 Mithaldu and having them under git also means it's easy to check changes happening to them
17:03 chm Those files should be completely generated from the build process.
17:04 Mithaldu auto-xs.inc as well?
17:04 chm For releases, we should have a version that is built for the distribution.
17:04 Mithaldu if so i'll just make a commit to cut them out
17:04 Mithaldu that happens automatically due to the build process relying on mfpl
17:05 Mithaldu ok, i'd need to create a call to generate-XS.pl
17:05 chm What is mfpl?
17:05 Mithaldu makefile.pl
17:05 chm ok
17:06 Mithaldu 18:04:07 (Mithaldu) auto-xs.inc as well? </n
17:06 Mithaldu err
17:06 Mithaldu y/n
17:06 chm I think the analogy is like META.yml and MYMETA.yml
17:06 chm Yes, auto-xs.inc as well.
17:07 Mithaldu ok, making an appropiate commit then
17:07 chm If things are working then the generated files should be the same in content but maybe not \r\n
17:07 Mithaldu tbh, the \r\n / \n thing makes me wanna stab people, as it's *nix-only devs being lazy as heck
17:07 chm I also like the fact that some of the constant duplication you had pointed out
17:08 Mithaldu yeah, writing the response to that one right now
17:08 chm could be addressed in the generation process more cleanly.  Not that it is that way at the moment.
17:09 Mithaldu https://github.com/devel-chm/OpenGL-Modern/pull/13#issuecomment-274274273
17:10 chm Mithaldu: another thought, since the current bindings use the same calling from perl as C
17:10 chm Maybe the bindings could be the _c varients to avoid confusion.
17:11 Mithaldu tbh i'm fine with leaving them as the canonical opengl names
17:11 chm That would seem to represent the current implementations and avoid collisions with _p and others going forward
17:11 Mithaldu but really, whatever you decide is fine
17:11 Mithaldu i have no opinion on how i'm supposed to call them
17:11 chm Ok, not critical to decide until we do the official release.
17:12 chm Thanks for the thoughts.  Let me get back to OM and get a push out with some API progress.
17:12 Mithaldu alright
17:13 Mithaldu and again
17:13 Mithaldu please push as often as possible
17:13 Mithaldu even work in progress stuff is valuable as it informs everyone else on the direction
17:13 Mithaldu you can just push it as a chm_dev branch or whatever if it's not ready for master
17:19 Mithaldu chm: in general, do you have any issue with me adding non-frivolous dependencies?
17:20 Mithaldu e.g. toolchain-like things that cut down on code repetition and wheel reinvention
17:27 chm Mithaldu: I prefer to keep things as simple as possible.  For example, I'm not a fan of Filter::signatures
17:27 Mithaldu me neither
17:27 Mithaldu but i'm talking about dead-simple things
17:27 Mithaldu io::all, capture::tiny
17:27 Mithaldu as i said
17:27 chm It is not supported for earlier perl versions, it is experimental, and, as you see, it breaks
17:27 Mithaldu toolchain level things
17:27 Mithaldu not shiny beads
17:29 Mithaldu or put in other words
17:30 Mithaldu if we're making modern opengl i'd like the thing to also be modern perl (which is not experimental perl before you comment on that) and right now the dist is a pile of idiosyncrasies
17:30 chm I wasn't familiar with IO::All but it seems reasonable
17:30 Mithaldu \o/
17:31 Mithaldu it's ingy-ware, but the only questionable thing in it are the operator overrides
17:31 Mithaldu which nobody sane is gonna use anyhow
17:31 chm Capture::Tiny seems reasonable as well since I expect we need to have some smarter XS/code/file generation tools
17:31 Mithaldu excellent
17:31 Mithaldu i also intend to make the xs gen thing a module at some point
17:33 chm I'm sure we'll have some discussion about the modern perl thing.
17:33 Mithaldu yeah, i'll make it piece by piece
17:33 Mithaldu just mentioned it as an overall goal
17:34 chm I'm all for clean, consistent and best practices.  There is definitely some cruft to go around.
17:34 Mithaldu :)
17:34 Mithaldu i'm mostly afraid of such things like reimplementing slurp
17:34 chm However, given that OpenGL::Modern is for folks to use _OpenGL_ I don't what folks
17:34 chm using older versions of perl to be out of luck
17:34 Mithaldu noted
17:35 Mithaldu definitely most of the stuff i bring in should be fine, except for like, 5.6
17:35 chm If you've seen some of my plans for PDL::NextGen the idea was to have an OO based on Moo[se]
17:35 Mithaldu \o/
17:35 Mithaldu note on that
17:35 Mithaldu start with Moo
17:35 Mithaldu only go with Moose if Moo turns out too little
17:35 chm And with a C-FFI support for OO as well.  Currently looking at the C Object System for that.
17:36 Mithaldu best of luck with that, that's way out my experience
17:36 chm Interestingly, the COS supports multimethods which would really help to make a nice, friendly API
17:36 Mithaldu that does sound interesting
17:36 Mithaldu might be some kind of solution for the 4 values vs array thing?
17:37 chm If you have any experience with perl6, I would like OpenGL::Modern to be able to work with that as well.
17:37 chm I don't know if that would make sense but it would be nice for perl6 not to have to re-roll this work
17:37 Mithaldu no experience
17:37 Mithaldu perl6 is a completely different language
17:38 Mithaldu possibly froggs, the SDL dude might have some interest
17:38 chm Yes, but I'm sure folks using perl6 could use OpenGL bindings (maybe they already have them)
17:38 Mithaldu if you google perl 6 opengl you'll find a few results
17:39 chm Re Moo[se], starting with Moo was the idea.  I wanted simple and compatible if only upwardly
17:39 Mithaldu aight
17:39 chm Later
17:40 Mithaldu chm: https://github.com/devel-chm/OpenGL-Modern/pull/19
17:40 Mithaldu ah crap
17:40 Mithaldu made a mistake
17:40 Mithaldu look again in a minute
17:41 Mithaldu actually nevermind, go ahead
17:41 Mithaldu chm: the error i was seeing was just incomplete travis stuff
17:42 Mithaldu #19 should be fine to pull in immediately and as is
20:17 Mithaldu chm: your comment here is a really fucking good way to stop me from giving any further shits: https://github.com/devel-chm/OpenGL-Modern/pull/13#issuecomment-274274839
20:17 Mithaldu seriously, holy fucking what
20:18 Mithaldu it is not fucking difficult to actually look at the commits i made in a nice atomic and logical order so you can tell what i did
20:18 Mithaldu fuckl
20:19 Mithaldu even if you're scared of deduplicating for some reason
20:19 Mithaldu extracting the lists is a complete and absolute utter nobrainer in every possible respect
20:21 Mithaldu in any case, let me know when you've actually read the commits
20:21 Mithaldu otherwise just tell me if this is how it's gonna be so i can go and learn unity
20:24 Mithaldu and to be really clear on why i'm upset and what "how it's gonna be" is:
20:25 Mithaldu you have now in two tickets very clearly not inspected the code or commits of the PRs. i put very general descriptions in the ticket comments and the bulk of the brain into the code. if you're gonna ignore the actual code where i put the real work, then any further work from me is nothing but a huge waste of time
20:26 Mithaldu (and i think as the maintainer of PPI who's had to read hundreds of commits and their assorted tests to not break a parser, i get to gripe about this)
21:23 chm Mithaldu: Actually, it may be "not f*** difficult" for you to look at the commits.
21:23 chm That is not the case for me.  Please stop taking offense at different coding/software/programming ability on my part.
21:24 chm If I had time/ability to easily review the commits I would have.
21:24 chm I asked you to split them into separate issues to help me which you did not wish to do.
21:25 chm Had you split out the issues I could have made more progess in seeing the changes.
21:25 chm As is, looking at the github diffs, it was not clear the details.
21:25 chm Regarding the constants, I'm not going to get into that until I understand it myself.
21:26 chm My priorities are to get the API and bindings working....not code beautiful or even perl beautiful.
21:27 chm I'm making progrress there but it is slow going.
21:27 chm Our discussions from earlier helped to clear up some issues I was debating.
21:27 chm That is where my time is planned for the rest of the weekend.
21:29 chm I'm sorry if this is a show stopper for you (Is unity really that good?)
21:30 chm I'll continue to push forward and hope that you can consider helping out.  Please do be assured that I don't intend offense.

| Channels | #pogl index | Today | | Search | Google Search | Plain-Text | summary