[10:37:57] Dominus: Marzo, I have no idea how my commits of last week were screwed to be accepted in the repository but not show my name as usual. Something I did wrong on that macbook I used :(
[11:03:25] jasonaowen: looks like missing email address, and different name than you usually use
[11:03:32] jasonaowen: you can set it on that macbook: https://git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup#_your_identity
[11:05:21] jasonaowen: fixing the history is possible but slightly difficult to do: https://stackoverflow.com/a/16218264/
[11:13:54] jasonaowen: happy to help in ~12 hours if you want :) but for now I'm going to bed
[11:14:27] Dominus: Thanks! I'll look into it and see if it is worth fixing
[11:26:38] Dominus: grrr, and the munt guy reverted my pkg-config file making it useless https://github.com/munt/munt/commit/5a44b4dc575b03b0bb8b1fb15c803d9405c3805a
[11:49:36] Marzo: FYI, fixing history is only ever a good thing to do before you push, or if you pushed something that you really should not have (such as private keys, passwords, etc)
[11:50:02] Marzo: Or if it is a mostly private repository that only you are likely to be using anyway, such as most forks for pull requests
[11:53:14] Marzo: Oh, and I have been looking at Newton Dragonś GM patches
[11:53:27] Marzo: And there is a good chance we won need them for Exult after all
[11:53:58] Marzo: We have a lot of code for GM/GS conversion, and it seems to me that this code basically replicates what his patches do
[11:58:02] Dominus: then no fixing required. Need to pay attention if I ever switch machines again. ugly :)
[11:58:36] Dominus: Newton Dragon patches, so we probably would just need to do proper documentation on our conversion stuff
[12:06:03] Marzo: Just confirmed it: music sounds identical using Newton Dragonś patches, or using Exult with a generic midi driver with GM/GS/GS127 conversion
[12:06:59] Marzo: It seems that the major difference between GM and the others is on midi SFX support
[12:08:59] Marzo: In any case, mt32emu sound is MUCH better
[12:09:26] Marzo: I also had some fluidsynth soundfonts that made midi music sound nearly identical to MT32
[12:09:33] Marzo: I have no idea what I did with them
[12:10:03] Dominus: that may have been on your linuy machine.
[12:10:20] Marzo: It was, yes; but it was on the N-1 machine
[12:10:31] Dominus: I remember you telling about this when you implemented the stacking fluidsynth soundfonts
[12:10:33] Marzo: I don think I ever copied it to my last Linux machine
[12:13:29] Dominus: I'm really struggling to see how adding the pkg-config file for munt will break projects that use the #include mt32emu/mt32emu.h: unless they specifically query the new pkg-config file but didn't change their include...
[13:54:40] Dominus: but finally I understand the problem
[14:06:10] Marzo: More importantly, do you see a way to fix it?
[17:25:53] Marzo: @Dominus: out of curiosity, our snapshots are still uploaded to SF webspace?
[18:13:00] Dominus: Marzo, yes
[18:13:59] Dominus: And Sergm of munt is proposing (or rather di already) add a mt32emu.h stub to the include dir that will point to the mt32emu subfolder mt32emu.h
[18:15:20] Dominus: problem is that the files that munt puts there are not really well named and might cause conflict with other projects or library files (starting with config.h and synth.h etc...)
[18:15:43] Dominus: I'll test later if the stub works and will report back to him how that is working pout
[20:35:32] Dominus: interesting committ messages :)
[20:54:03] Dominus: this Windows snapshot setup looks really really nice
[20:54:31] Dominus: with the gimp plugin *and* the mods...
[20:55:05] Marzo: Just have to see if it will work
[20:55:16] Marzo: I should have added a manual trigger for it
[20:55:46] Dominus: probably not on first run :) There is always something small making it stuck
[20:55:53] Marzo: As is, it will run everyday at midnight, and require at least one commit in the previous 24 hours
[20:57:38] Dominus: so our download page needs to point at a new location :)
[20:58:35] Dominus: (if you touch that... our actual homepage is atm no longer in sync with the web github repository - something I wanted to fix this week :))
[20:58:36] Marzo: I am also thinking of a way to upload directly to SF space
[20:58:51] Marzo: But I want to make sure it will work first
[21:03:13] Marzo: It finally worked on OSX
[21:04:24] Dominus: sorry for being a nuisance :)
[21:04:53] Marzo: That isn´t your fault, it is Apple´s
[21:05:01] Dominus: :)
[21:05:12] Dominus: I'm really not a fan of brew though
[21:05:30] Marzo: They are the ones that have decided to ship ancient versions of bison, flex, zlib, libxml2, and others
[21:05:46] Marzo: From what I have seen, MacPorts suffers from the same issue
[21:06:18] Dominus: they (brew) take a rather hard approach to the whole package manager thing.
[21:06:45] Dominus: for my builds I'm using xcode's bison and flex, btw.
[21:06:58] Dominus: which is probably the source of being outdated
[21:07:20] Marzo: In XCode you are building as c++14, right?
[21:07:59] Dominus: I think that's what configure figures out, I'm not telling it explicitly
[21:09:03] Marzo: Hm. The issue is that configure tries c++17 before trying c++14; and the build was failing on OSX because the ancient version of Bison it has emits code with the ´register´ keyword
[21:09:21] Dominus: xcode provides bison 3.6 and flex 2.6, while macports provides bison 3.7.5 and flex 2.6.4
[21:09:29] Marzo: Once upon a time, this keyword used to ensure that a variable was placed in a register
[21:09:54] Dominus: hmm, odd since it's been a while since I needed to do anything in regards to that
[21:09:56] Marzo: For a long time now, it has had the same semantics as white-space
[21:10:17] Marzo: So much so that it was removed from the language in c++17
[21:11:25] Marzo: But yeah, XCode has a newer version than the system-wide installed one
[21:12:13] Marzo: And MacPorts also had the issue that I faced with homebrew -- I know this because the Travis build does not build UCC or the mods
[21:13:48] Dominus: and I was wrong... my gtk+3 prefix had the newer bison/flex
[21:14:18] Dominus: xcode comes with bison 2.3 and flex 2.5.35 (apple flex-32)
[21:14:35] Marzo: Hah, so it was working by luck?
[21:14:49] Marzo: Interesting
[21:14:55] Marzo: Time to update the docs :_)
[21:15:15] Dominus: but if you had macports (or brew I guess) install bison and flex you should be good as these versions are much newer
[21:15:46] Dominus: yes, likely working by sheer luck
[21:16:04] Dominus: I'll take a note to install these for macports as well
[21:16:15] Marzo: It is working now that I have finally got the correct paths in the correct places
[21:16:36] Dominus: :)
[22:17:43] Dominus: he he he... "Fixing copy/paste errors on badges" <- I was wondering why stuff in the readme.md has *anything* to do with baRges... only on third read did I see my misreading
[22:18:06] Marzo: :)
[22:30:56] Dominus: ok, looked at my prefix again and apparently I've added flex to my prefix back at the end of2019. So flex 2.6.4 with old bison 2.3 (provided by Apple/xcode) seems to work fine for building. Problems you face when you don't know what you did why to your prefix :)
[22:43:02] Dominus: btw, the reason not to use the github actions for macos builds is the codesigning and more importantly these days, notarization (which is based on codesigning)
[22:44:59] Dominus: (though it seems people have done that, too)
[22:46:41] Dominus: via repository secrets. but no, I'm not going this way :)
[22:58:40] Marzo: Why not? :)