00:10:09  * madewokherdjoined
00:36:06  * [[zzz]]joined
00:39:34  * [[zz]]quit (Ping timeout: 252 seconds)
02:43:00  * theshadowquit (Quit: theshadow)
06:31:51  * drdanzjoined
06:38:42  * ender`joined
07:35:34  * auroraeosrosequit (Read error: Connection reset by peer)
07:39:26  * madewokherdquit (Remote host closed the connection)
08:14:44  * mloskotjoined
11:04:08  * auroraeosrosejoined
11:04:28  * auroraeosrosequit (Changing host)
11:04:28  * auroraeosrosejoined
15:01:21  * virmitiojoined
15:08:49  * drdanzquit (Remote host closed the connection)
15:41:50  * mloskotquit (Quit: Leaving)
16:12:58  * theshadowjoined
16:40:18  * bherilajoined
16:40:21  * bherilapart
16:58:46  * drdanzjoined
17:06:05  * bherila_joined
17:45:14  * madewokherdjoined
17:45:30  * drdanzquit (Ping timeout: 245 seconds)
17:59:25  <madewokherd>virmitio: it might be worth checking if SDL_image still works
17:59:31  * TReKiEquit (Ping timeout: 264 seconds)
17:59:37  <madewokherd>since the libjpeg update
18:00:25  <virmitio>madewokherd: file a bug and assign it to me, if you would
18:00:46  <madewokherd>then I'd have to go check myself
18:01:02  <madewokherd>because I don't know if it's broken or not
18:01:02  <virmitio>no, just file the bug saying "remember to check this"
18:01:41  * madewokherdquit (Remote host closed the connection)
18:01:46  <virmitio>I've got another dozen packages in my head right now and that way I'll at least remember it something this week
18:04:06  * GarrettS-MSFTjoined
18:04:06  * GarrettS-MSFTquit (Changing host)
18:04:07  * GarrettS-MSFTjoined
18:04:07  * FearTheCowboyquit (Disconnected by services)
18:04:56  * auroraeosrose1joined
18:06:46  * TReKiEjoined
18:07:05  * bherilajoined
18:07:55  * auroraeosrosequit (Ping timeout: 252 seconds)
18:08:30  * bherila_quit (Ping timeout: 264 seconds)
18:09:25  * madewokherdjoined
18:09:46  <madewokherd>figured I might as well just test it
18:10:07  <madewokherd>it looks like if I install SDL_image I still get libjpeg 8 as a dep
18:10:54  <virmitio>if you swap out for the 9a dll, does it still run ok?
18:11:20  <virmitio>it looked like 8 and 9 would be bin compat (though I didn't look too hard, to be honest)
18:11:39  <madewokherd>yes, it still works
18:12:04  <madewokherd>although I'm annoyed that I don't understand how dependencies work, or what we should do when there is a binary-incompatible upgrade
18:12:36  <madewokherd>is nuget avoiding the update because the major version changed?
18:13:02  <madewokherd>(I can actually install version 9 in the nuget project alongside SDL_image, but I have to do it manually
18:13:08  <virmitio>nuget does not assume major version changes to be bin-compat (though it also does insist that they not be)
18:13:26  <virmitio>wait
18:13:38  <virmitio>*also does NOT insist
18:14:17  <madewokherd>I think we might have to put the binary version (if it ever breaks) in the dll and package name :/
18:15:29  <virmitio>possibly, but at the immediate moment I'm willing to leave that be until either it happens or we have more time to look at it closer
18:16:15  <madewokherd>well, my thought is what if I updated libtiff (which depends on libjpeg) to use a new binary-incompatibile version
18:16:37  <madewokherd>SDL_image uses both libjpeg and libtiff
18:16:51  <madewokherd>so the only way to resolve that is to have both dll's in the package at once
18:17:37  * ender1joined
18:18:18  <madewokherd>all this assumes that libtiff doesn't use types from libjpeg; if it did, a binary-incompatible update to libjpeg would also make an update to libtiff using the new libjpeg incompatible
18:19:17  <virmitio>I think I see your concern, but I'm not sure my head's coherent enough right now to hold an intelligent discussion about it. Would you be willing to throw all of this into an issue on github for the coapp powershell tools repo?
18:19:58  * ender`quit (Ping timeout: 256 seconds)
18:22:04  <madewokherd>wait a minute
18:22:19  <madewokherd>this is exactly the same as libc
18:23:08  <madewokherd>and it's only really a problem if you have a library that makes frequent binary-incompatible updates, which afaik we've never encountered
18:23:22  <madewokherd>(except for libc)
18:24:44  <madewokherd>mfc I guess...
18:24:46  * auroraeosrose1quit (Ping timeout: 276 seconds)
18:28:47  <madewokherd>writing an issue
18:30:45  * ln-quit (Ping timeout: 256 seconds)
18:30:59  * ln-joined
18:38:21  * auroraeosrosejoined
18:38:21  * auroraeosrosequit (Excess Flood)
18:38:50  <madewokherd>arg, the requirement that libraries know which updates of their dependencies are binary-compatible is just broken\
18:39:16  <virmitio>I'll agree with that
18:45:40  <madewokherd>I don't think I can do anything without a real scenario
18:46:11  <madewokherd>well
18:47:02  <madewokherd>I think we have two likely scenarios: frequent, predictable binary-incompatible updates, and rare ones
18:47:25  <madewokherd>for the rare ones we can make separate packages
18:48:45  <madewokherd>so there's a gtk2 package and a gtk3 package; problem solved
18:49:01  * cH40z-Lordquit (*.net *.split)
18:49:15  * cH40z-Lordjoined
18:49:30  <virmitio>why are we needing separate packages? nuget packages have the means for specifying dependency package allowable version ranges
18:49:39  * auroraeosrosejoined
18:49:55  <madewokherd>well, I guess that depends
18:50:17  <madewokherd>if it makes sense to install more than one version of a dll at the same time, you need separate packages
18:50:58  <madewokherd>for libpng 1.2 and 1.4 you might want to do something like that; for gtk it doesn't make sense
18:51:33  <virmitio>are we talking 'install to the system' or 'install for building my software'?
18:51:48  <madewokherd>install for building software
18:52:22  <madewokherd>or, would you ever want to load both versions in one process?
18:52:29  <virmitio>then I think I need an example of when you'd need multiple versions of a dep library for building another library before I'll understand
18:52:47  <madewokherd>libjpeg is a possible example
18:52:52  <virmitio>or for building an end application for that matter
18:52:58  <madewokherd>say 9 did break it
18:53:19  <madewokherd>SDL_image and libtiff are both built to depend on version 8
18:53:42  <madewokherd>libtiff may update its dependency to version 9 before SDL_image does
18:54:54  <madewokherd>SDL_image depends on libtiff (which brings in libjpeg 9) and libjpeg (which it needs to be version 8)
18:55:38  <madewokherd>none of these api's expose their use of libjpeg, so it doesn't matter whether they're using the same instance
18:56:23  <virmitio>ok, I can see how that could happen, but it would result in a library conflict regardless unless one or the other (sdl or tiff) decided to include jpeg as static to itself
18:57:02  <madewokherd>not if the new libjpeg is in a different package with a different dll filename
18:57:12  <virmitio>otherwise they'll both require a libjpeg.dll in the same dir, and both will expect their (mutually exclusive) versions
18:57:31  <virmitio>I'm first trying to look at it under the existing model
18:57:54  <virmitio>and by existing, I mean what everyone has been putting up with for the past decade or two
18:58:07  <virmitio>how has this been resolved in the past?
18:58:20  <madewokherd>put the binary version in the filename
18:58:28  <madewokherd>that's what linux does, at least
18:58:38  <madewokherd>also sxs would work
18:59:00  <virmitio>ok
18:59:09  <madewokherd>so we could just say that because our ultimate goal is sxs and we can make that work fine, we don't care very much about this
19:00:06  * auroraeosrose1joined
19:00:13  <madewokherd>gentoo has a thing called revdep-rebuild
19:00:17  <virmitio>I'll have a chat with GarrettS-MSFT and we'll see if we can raise an issue with the nuget folks. As I'm not sure they currently support having multiple versions installed local to a project/solution side by side
19:00:38  <madewokherd>well, I don't think they need to
19:00:49  <madewokherd>or should
19:01:29  <madewokherd>actually, one thing you could do is put the binary version in the .dll filename and the name of the redist package
19:01:42  <madewokherd>that would solve it IF we were depending on redist packages when we only needed the binaries
19:01:53  <madewokherd>but the problem with that is our redists don't ever depend on other redists
19:02:08  <virmitio>for this scenario, the packages would either need to be named differently (not a preference, as it fractures the library landscape) or they need to be installable side by side
19:02:26  <virmitio>and we really can't make the redists depend only on other redists
19:02:32  <madewokherd>well
19:02:39  <virmitio>or rather, we can't make a full dev lib depend only on redists
19:03:03  <virmitio>redist -> redist would probably be quite possible
19:03:09  <madewokherd>why do we split out the redist packages anyway?
19:03:52  <madewokherd>I thought I understood, but based on how they actually work it seems I don't
19:04:09  <virmitio>anymore? I think it's just because we haven't revisited it in a while. originally it was to avoid needing to always dep on the full dev lib. (which isn't really an option anymore)
19:05:17  <madewokherd>my thought was that if I have a library that depends on another dll, but a consumer of my library doesn't need that dll's headers or .lib (just the .dll), I could use redists to just bring in the dll
19:05:23  <virmitio>we would likely be better served to roll them back together at some point, but we've been a bit overbusy to have time for sitting down and looking at it for a bit
19:05:34  <madewokherd>which is actually perfect for solving this scenario
19:05:38  * auroraeosrosequit (Ping timeout: 245 seconds)
19:05:45  * cH40z-Lordquit (Ping timeout: 245 seconds)
19:06:09  <virmitio>which is all well and good, as long as you are not also distributing static libs in your nuget package
19:06:37  <madewokherd>did we ever decide how static libs were going to work?
19:08:22  <virmitio>sortof? the problem we've run into is that there's genuinely no 'good' way to deal with them, and a wide variety of simply abhorrent ways to handle the issue (which are really hard to differentiate from the merely mediocre options that are the best choices available)
19:08:47  <madewokherd>right
19:09:55  <madewokherd>if you're packing all of a lib's deps into its static .lib, this isn't a problem
19:10:17  <virmitio>to be honest, the root of the problem from my understanding is that VC has 4 separate, mutually link-time incompatible runtime libraries that can be linked against. And the selection of which to use MUST be made at compile-time.
19:10:54  <madewokherd>don't we have the same problem with dynamic libs?
19:11:07  <madewokherd>oh, no
19:11:24  <madewokherd>because we don't know if the final image will use the static or dynamic libc
19:11:29  <madewokherd>right
19:11:33  <virmitio>because unless we're passing file handles around, we don't care what runtime a dll links to
19:12:04  <virmitio>that's its problem, not an issue to the calling lib/app
19:12:17  <virmitio>static libs are a horse of another color
19:13:09  * auroraeosrosejoined
19:13:24  <virmitio>so, as an example, if you statically use zlib then it doesn't matter what else you may want, you MUST link against the same runtime that it was originally compiled for.
19:14:06  <virmitio>which gets really ugly if you try linking to multiple static libs that are compiled against different runtimes
19:14:19  <madewokherd>you'd need a static lib for each runtime
19:14:38  <virmitio>and by 'ugly' I mean 'there is no way to successfully complete linking it'
19:14:42  * auroraeosrose1quit (*.net *.split)
19:15:22  <virmitio>that's one of the options, and we seriously considered it (and may do so again in the future, I don't know)
19:15:34  <madewokherd>incidentally, it'd be really cool if we could use some sort of delta compression on our packages :p
19:15:59  <madewokherd>honestly, I'm inclined to just drop this now
19:16:11  <virmitio>the other vaguely survivable option that we've gone with for the time being is to forcibly assign the runtime being built against if you link to a static lib
19:16:13  <madewokherd>because I want us to not waste time on it and just move on to sxs, which we can do right
19:16:58  <virmitio>legacy, embedded, core system, etc.
19:17:29  <virmitio>we feel it a 'bad idea' to abandon these groups of developers
19:17:58  <madewokherd>sure, but we can settle for an imperfect solution
19:18:05  <virmitio>and I'm pretty sure we need to solve this anyway for internal usage
19:18:09  <madewokherd>my instinct is to always go for the perfect solution
19:18:23  <madewokherd>and it's hard for me to back off from that
19:19:27  <madewokherd>so maybe it breaks temporarily when you have these complex dependency trees with an incompatible update in there
19:19:50  <madewokherd>and you have to go back and get an exact version of a package
19:20:25  <madewokherd>hopefully that'll be a rare occurance anyway
19:20:50  <madewokherd>and if/when I know I'm linking a library that updates frequently, I can think about it more carefully
19:21:02  <madewokherd>*breaks frequently
19:22:56  * ender`joined
19:23:58  * madewokherdquit (Read error: Connection reset by peer)
19:24:01  * ender1quit (Read error: Operation timed out)
19:26:11  * madewokherdjoined
19:27:43  * mloskotjoined
19:38:15  * mloskotpart ("Leaving")
19:39:17  * cH40z-Lordjoined
20:29:33  * auroraeosrosequit (Read error: Connection reset by peer)
20:30:16  * auroraeosrosejoined
20:40:32  * virmitioquit (Quit: Leaving.)
21:02:06  * bherila__joined
21:05:17  * bherilaquit (Ping timeout: 256 seconds)
21:48:06  * theshadowquit (Ping timeout: 264 seconds)
21:48:31  * drdanzjoined
21:53:23  * ender`quit (Quit: sweater, n a garment worn by children when their mother is cold)
22:08:37  * drdanzquit (Ping timeout: 256 seconds)
22:15:46  * drdanzjoined
22:28:07  * theshadowjoined
22:29:16  * bherilajoined
22:30:44  * drdanzquit (Ping timeout: 256 seconds)
22:32:01  * bherila__quit (Ping timeout: 248 seconds)
23:55:35  * drdanzjoined