Time  Nick      Message
00:06 hecks     so what do we do about the mac CI obviously not using c++11
00:27 MTDiscord <Jordach> actually improve CMake in a proper manner
00:56 MTDiscord <josiah_wi> Is there an issue for that or could you create one?
00:56 MTDiscord <Jordach> by that i'm referring to setting CMake to force the compiler to build under CXX11
00:57 MTDiscord <josiah_wi> We... don't? head explodes
01:25 MTDiscord <josiah_wi> Question Jordach. Does Mac have static libraries installed by default and are there ever exceptions?
01:27 MTDiscord <josiah_wi> It'd be nice if the CMake had built-in support to build Minetest on Darwin, and I'd be interested in attempting this.
01:45 MTDiscord <Jordach> static
01:46 MTDiscord <josiah_wi> Why do you compile all the dependencies yourself?
01:47 MTDiscord <Jordach> hint: homebrew are idiotic developers who refuse to support multiarch
01:47 MTDiscord <Jordach> as for the next 10 years or so x64 is still likely to be supported
01:48 MTDiscord <Jordach> you can have one or the other, but not both
01:48 MTDiscord <Jordach> they also disallow/outright make it difficult to use different OS versions of a dep
01:52 MTDiscord <josiah_wi> Why did you need multiarch again? Was it because the M1 uses that?
01:52 MTDiscord <Jordach> yes, the M1 has support for unsigned binaries as x64 and signed binaries as arm64
01:54 MTDiscord <Jordach> Macs as of Big Sur allow fat binaries, ie binaries that contain both arm64 and x64 libraries and code
01:55 MTDiscord <josiah_wi> I think I have a good picture now of the situation, and I now see how dire it is. No workaround really for missing architecture support in the dependencies except what you've already done, is there.
01:55 MTDiscord <Jordach> also, if i properly wanted to micromanage the shit that is homebrew deps
01:55 MTDiscord <Jordach> it'd cost me 4 digits+ in cash to setup those mac minis for multiple configurations
01:56 MTDiscord <Jordach> not including the ebay pains of finding one that specifically runs mavericks
01:56 MTDiscord <josiah_wi> Is it really necessary to compile every dependency or do a handful support multiarch?
01:57 MTDiscord <Jordach> i hacked together working cmake lists for dependancies like libpng
01:57 MTDiscord <Jordach> as well as removing the offending ARMNEON nonsense
01:58 MTDiscord <josiah_wi> But do any work without hacking them into submission?
01:58 MTDiscord <Jordach> most dependancies already support cmake
01:58 MTDiscord <Jordach> or allow me to use the native lipo tool to construct fat libraries
01:58 MTDiscord <Jordach> libpng is the known piece of ass
01:59 MTDiscord <josiah_wi> I'm asking about when you install from homebrew.
01:59 MTDiscord <Jordach> homebrew has them precompiled for your OS version
01:59 MTDiscord <Jordach> homebrew makes it easy to make builds tailored for your machine
01:59 MTDiscord <Jordach> however, they're not that portable
02:00 MTDiscord <josiah_wi> Ahh  because of the "different OS versions of a dep" you mentioned earlier.
02:00 MTDiscord <Jordach> i could probably hack neoascetics script
02:00 MTDiscord <Jordach> and get that functional again
02:00 MTDiscord <Jordach> for mavericks+
02:00 MTDiscord <Jordach> (and yes those ran fine under Rosetta for those asking, even JIT too)
02:01 MTDiscord <Jordach> however, that is not conductive to Mac App Store or the eventual iOS version
02:01 MTDiscord <Jordach> because the Mac App Store requires a fat binary
02:01 MTDiscord <josiah_wi> Thank you for the discussion. I understand a lot more about Mac now (I did a little research on good 'ol Google too).
02:02 MTDiscord <Jordach> leave the masochism to the person that enjoys a thorough fucking over by asinine bullshit
02:04 MTDiscord <josiah_wi> Sounds good. I'll stick to PRing the C++11 requirement unless someone beats me to it.
02:04 MTDiscord <Jordach> it's two trivial lines
02:05 MTDiscord <Jordach> i'm sure it'd take 10 mins to review
02:05 MTDiscord <Jordach> and test
02:05 MTDiscord <josiah_wi> Yet it isn't there. head explodes again
02:06 MTDiscord <Jordach> you're asking the most hodgepodge of projects users and developers why shits missing
02:08 MTDiscord <josiah_wi> I wouldn't say there's any lack of s***.
12:21 hecks     someone review/approve #11498 already
12:22 ShadowBot https://github.com/minetest/minetest/issues/11498 -- Add embedded PNG texture modifier by hecktest
18:17 hecks     The GL binding is basically done
18:18 hecks     once again I face the question of what to do with the null driver
18:19 sfan5     comment it out, can be solved later
18:19 sfan5     important stuff comes first
18:20 hecks     the whole driver?
18:20 hecks     that'll break CI
18:20 hecks     you'll have to do something about minetest CI jobs that rely on it
18:20 sfan5     e.g. throw mesa in there?
18:20 hecks     yup
18:20 sfan5     okay
18:21 hecks     now technically everything will "work" without me doing anything to support null but
18:21 hecks     obviously all the pointers in GL will be 0x0
18:21 hecks     because the null driver does not have an IContextManager and does not initialize the struct
18:22 hecks     so as soon as any code is written against it (materials...) the null path will start crashing
18:23 sfan5     how soon do you think we'll have code that uses the GL stuff
18:23 hecks     #11396 already uses opengl
18:24 ShadowBot https://github.com/minetest/minetest/issues/11396 -- Shader and material system by hecktest
18:24 hecks     so basically as soon as i get irr52 merged i'm going back there and finishing that
18:24 sfan5     I see
18:25 hecks     while the longer term todo is writing the GL core irr driver
18:32 hecks     irr#52 ready for review
18:32 ShadowBot https://github.com/minetest/irrlicht/issues/52 -- Add a unified cross platform OpenGL core profile binding by hecktest
18:35 hecks     Honestly, the CI demo could actually be turned into an OpenGL demo
18:35 hecks     I should write a rotating cube for that :o
18:35 sfan5     afaik the GL context code currently doesn't use the core profile a legacy one (?), that'll have to be switched over once the new driver stuff is actually written
18:35 sfan5     ^ just remembered this
18:36 hecks     Core / legacy is like
18:36 hecks     it's just a hint for the driver that you are not allowed to use some things
18:36 hecks     legacy profile is a superset of core
18:36 sfan5     ah so it'll work without, good to know
18:36 hecks     code written for core profile will work in a legacy context
18:36 hecks     it'll still be a good idea to clean that up, it's just low priority
18:37 hecks     also, desktop GL versions before 3.3 do not have a core profile
18:38 hecks     the core profile is basically a favor done to new graphics programmers so that they do not have to learn ancient SGI OpenGL
18:38 hecks     and learn only like 200 procedures instead of a thousand
18:39 hecks     core GL is also more in line with how GPUs actually work; legacy GL is actually emulated in drivers
18:40 hecks     which is why I'm killing the fixed function path eventually, we're not actually using an ancient forgotten performance technique (GPU vendors HATE him! this man discovered one simple trick... :D)
18:40 hecks     but in fact on all hardware that we use, the fixed path incurs extra overhead from the emulation the driver has to do
18:41 hecks     and the cheaper the GPU the *less* fixed features it has because they cost more transistors on the die
18:47 sfan5     the name mangling really is the solution apple recommends? lol
18:47 hecks     hm?
18:47 hecks     like the underscore prefix?
18:47 sfan5     yes
18:48 hecks     yeah that's from their example code =]
18:48 hecks     I'm just glad that they provided *something*
18:48 hecks     unlike ios where they pretend that nobody would ever want to write any cross platform code at all
18:49 hecks     or maybe they think everyone has an army of poor interns to do it
18:51 hecks     the lack of interns or sweatshops did not stop the irrlicht people from writing their GL bindings manually though :DDDDD
18:52 sfan5     hmm mac failing on the constexprs
18:52 sfan5     why aren't those defines?
18:53 hecks     because defines are evil and can't be scoped, duh
18:53 hecks     it's not actually failing on those
18:53 hecks     just being really annoying about it
18:53 sfan5     ah the scoping
18:53 sfan5     so you'd use GL.TRIANGLES?
18:53 hecks     what it's failing on is the lack of std::unordered_set.emplace
18:53 hecks     yes
18:54 hecks     just like you no longer use the glDoThing prefix
18:54 sfan5     >	static constexpr const GLenum DEBUG_LOGGED_MESSAGES_ = 0x9145;
18:54 hecks     and you never have to add ARB or OES at the end of anything even if your card does not have the core version of a proc
18:54 sfan5     is there supposed to be a trailing _?
18:54 hecks     there isn't, let me see
18:55 hecks     it should be eating the _, let me fix this
18:55 hecks     because it was originally DEBUG_LOGGED_MESSAGES_ARB
18:56 sfan5     hope there's no DEBUG_LOGGED_MESSAGES_ARB and DEBUG_LOGGED_MESSAGES with different values
18:56 hecks     there is not
18:56 hecks     I empirically tested that not a single GL constant ever does this
18:56 hecks     and as for mismatching functions I do test for this and discard anything that doesn't agree with core
18:57 hecks     (I also discard anything that isn't KHR, ARB or OES because it makes extension checking easier and updating extensions is the driver writer's job)
18:58 hecks     you could also chime in on this little problem:
18:58 hecks     BindingGenerator.lua : 266
18:58 hecks     one of those constants is a bloody define in windows.h, this is exactly why defines are evil
18:59 hecks     my workaround is to prefix it with _ and hope that GCC helps anybody who runs into this by suggesting it
18:59 hecks     it's also a rather obscure function
19:00 sfan5     the technology wasn't there yet back then
19:01 hecks     since this has to do with threading in windows, this is probably a Windows NT define
19:01 hecks     so they just didn't care, they could have at least tried using a prefix
19:02 sfan5     as for mac try this http://sprunge.us/r8zZ9S
19:03 hecks     thanks :o i hope this doesn't break mingw64 like my previous attempt did
19:03 sfan5     I'd be surprised if it did
19:03 sfan5     we'll see
19:04 sfan5     I guess I could compile-test the thing on Android
19:05 hecks     let's see if I can build with this
19:05 hecks     thing is that I was running into really obscure mingw gremlins with std=c++11
19:05 hecks     suddenly dllexporting "GL" stopped working
19:06 hecks     but uhh I guess I was tired, I kinda know what to check this time
19:06 hecks     should have actually opened the dll and seen what it produced, maybe I need an extern "C" somewhere
19:07 hecks     okay it didn't break
19:07 hecks     maybe cause uhh I didn't have to do this DISABLE_STRICT_ANSI thing which i don't even understand
19:07 hecks     but which irrlicht _supposedly_ requires for c++11
19:09 sfan5     compiles fine for android
19:10 pgimeno   hecks: about #11498, "Looks good" counts as an approval (but please ask a core dev to be sure)
19:10 ShadowBot https://github.com/minetest/minetest/issues/11498 -- Add embedded PNG texture modifier by hecktest
19:11 hecks     i am a core dev....
19:11 hecks     :DDDD
19:11 hecks     this isn't the first time c55 forgot to actually click approve
19:11 pgimeno   yeah but a new one :) I implied to ask an _experienced_ core dev
19:12 hecks     well as soon as someone actually clicks approve i am allowed to merge it
19:12 hecks     i've been running that pr since it was made too, everything works
19:12 hecks     i think my gl-test branch is accidentally based on it
19:12 hecks     so i guess i tricked everyone else into testing it too
19:13 pgimeno   well, all I tested is that it didn't break starting a game, because I didn't really use the feature (AFAIK) and I did very little more than starting a game
19:14 hecks     wow CI passed and i managed to build it too
19:14 hecks     i guess osx is fixed, just gotta get Jordach to run it
19:14 hecks     probably works though
19:14 hecks     pgimeno: just starting devtest will test it
19:15 hecks     the mandelbrots will be rendered as soon as you receive the tile definitions
19:15 pgimeno   [OT] you can explicitly ping Discord users by adding @ before their names, or that's how I think it works
19:15 hecks     @Jordach we fixed irr#52 building on mac, you can test it now
19:16 ShadowBot https://github.com/minetest/irrlicht/issues/52 -- Add a unified cross platform OpenGL core profile binding by hecktest
19:16 hecks     okay now let me fix the trailing underscore
19:17 MTDiscord <Jonathon> fyi the ping worked
19:18 hecks     ok this is silly, it should be eating the underscore
19:19 hecks     oh duh i just forgot to use my extra arg
19:20 hecks     pushed, it actually removed some duplicates too
19:20 hecks     I think we're good to ship now?
19:22 hecks     i'll just go through the review
19:22 hecks     oh ffs
19:22 hecks     DIFFERENCE is also a #defined constant somewhere?
19:23 hecks     let me guess it's more windows clownery
19:33 hecks     sfan5 about the MINETEST_CLIENT define
19:33 hecks     okay so it should probably just be a MINETEST define though we only use GL on clients anyway
19:34 hecks     but anyway its purpose is to switch (dllexport) to (dllimport) on the same header if it is included by downstream code
19:34 hecks     on the same symbol (the GL struct)
19:34 sfan5     I get that
19:34 hecks     so why would we need to invert it?
19:34 hecks     are you suggesting that MT should spawn the GL object?
19:35 sfan5     no
19:35 sfan5     I mean turning 'ifdef MINETEST_CLIENT' into 'ifndef CURRENTLY_BUILDING_IRRLICHT'
19:35 hecks     just #ifndef IRRLICHT?
19:35 hecks     ah ok
19:35 sfan5     but actually
19:35 sfan5     just use this? https://github.com/minetest/irrlicht/blob/7709e1e5f8d8429308ae20d366171fdf6e64bee8/include/IrrCompileConfig.h#L500-L508
19:36 hecks     this is never ever included in minetest right?
19:36 hecks     (why is it in /include/...)
19:36 sfan5     what do you mean?
19:36 sfan5     irrcompileconfig is included by just about every irrlicht header
19:36 sfan5     existing APIs use this to work in DLLs
19:37 hecks     oh there's IRRLICHT_API
19:37 hecks     ok
19:42 hecks     all resolved, just waiting for CI
19:43 hecks     sfan5: all good?
19:43 sfan5     i'll take another look
19:46 sfan5     just one thing
19:46 sfan5     void* GetProcAddress();
19:46 sfan5     this in the header, does that do anything?
19:47 hecks     it seems that it no longer does, i'll delete it
19:49 hecks     deleted and regenerated
19:52 sfan5     shall I click the button?
19:52 hecks     merge? do it :o
19:53 sfan5     or did you want to wait for mac testing?
19:53 hecks     oh uhhhhhh
19:54 hecks     well it'll compile anyway
19:55 hecks     we're not actually using this yet so we can get jordach to test it as soon as he's available
19:55 hecks     it shouldn't make anyone's copy blow up, no code in minetest includes mt_opengl.h yet
19:55 hecks     except i guess the opengl driver...
19:56 sfan5     okay then
19:56 hecks     mac CI doesn't run the auto example does it
19:56 sfan5     nah
19:56 hecks     would it be hard to make it?
19:56 hecks     that would solve this question
19:56 sfan5     I don't know if the CI runs headless or whatever
19:56 sfan5     and you can't just throw Mesa at it like on Linux
19:56 hecks     aaaaaaa
19:58 hecks     well this is a dev branch, we're allowed to take some risks aren't we
19:58 sfan5     ye
19:58 hecks     we do have a stable branch in irrlicht don't we....
19:58 sfan5     there's tags for that
19:59 hecks     well that should be enough
19:59 sfan5     for example all CI builds on minetest/minetest pull the most recent tag
19:59 hecks     okay then merge it
19:59 sfan5     I did minutes ago
20:00 sfan5     (conversely this also forces us to switch to newer tagged versions to make use of features added into irrmt without breaking CI...)
20:00 hecks     explain this to me actually
20:01 hecks     is it possible for me to run CI on the materials branch against *this* commit specifically?
20:01 hecks     is there something you can toggle for this
20:02 sfan5     there's a version defined in util/ci/common.sh and the buildbot*.sh's but those work for tags where someone uploaded prebuilt releases (you could do this actually)
20:02 sfan5     perhaps easier is to edit the CI scripts a bit to pull irrlicht master into lib/irrlichtmt
20:03 hecks     so we make a new tag on irrmt
20:03 sfan5     https://github.com/minetest/irrlicht/releases/tag/1.9.0mt2 <- the prebuilt libs in case you haven't seen them
20:04 hecks     okay so we make a new one, it emits some files and we make CI use those?
20:04 hecks     let me read the script
20:05 hecks     oh i guess i just change the wget url
20:05 sfan5     ...if you have a tag that is
20:06 sfan5     for the tag you have to upload the prebuilt libs manually, the linux one is just the one from ci (convenient) windows is from scripts/ci-build-mingw.sh plus some packaging around it
20:06 sfan5     I once planned to write down how the irrmt packaging and related stuff is supposed to work but never got around to it
20:06 hecks     so the release can't be auto made from CI artifacts?
20:06 sfan5     no
20:06 sfan5     would be possible if desired
20:06 hecks     shucks
20:07 hecks     of course it would be desired to not have to do this manually
20:07 sfan5     but like I said if you really just want to test any revision the the clone to lib/irrlichtmt thing works
20:07 hecks     i guess so
20:08 hecks     and cmake will prefer that one?
20:08 sfan5     yes
20:08 hecks     what about the mingw issues
20:09 hecks     didn't building irr in this way confuse mingw last time
20:09 sfan5     idk what you're referring to
20:11 hecks     remember when we changed that target thing and people had problems building mt against irrlicht, myself included
20:11 hecks     and the lib/irrlichtmt trick specifically did not work for me
20:12 hecks     i just hope it doesn't mess up CI too, we'll see
20:12 sfan5     ¯\_(ツ)_/¯
20:13 hecks     oh and how do you prevent the CI changes from polluting master, manual squash while merging?
20:13 sfan5     revert the commit before merge
20:13 hecks     works
20:13 sfan5     or what you said
20:52 hecks     oh gee wiz i sure hope nobody notices me making those last minute fixes!
20:53 hecks     and man I really hate #defines