02:06:17  * gixquit (Ping timeout: 246 seconds)
02:11:53  * gixjoined
05:14:43  * madewokherdquit (Remote host closed the connection)
06:54:10  * HamishCjoined
07:47:42  * ender`joined
09:38:08  * HamishCquit (Ping timeout: 260 seconds)
09:52:44  * ssam2joined
10:10:32  * HamishCjoined
12:22:20  * auroraeosrosejoined
12:25:51  * sfbpart
14:18:10  * virmitiojoined
14:45:22  * Virmitio1joined
14:55:20  * Virmitio1quit (Quit: Leaving.)
14:56:31  * vpovirkjoined
15:35:09  * wwahammyjoined
15:38:17  <auroraeosrose>FearTheCowboy: git is live
15:38:21  <auroraeosrose>fork in progress
15:38:35  <auroraeosrose>perhaps, if I can make it work ;)
15:38:36  <virmitio>woot!
15:39:01  * auroraeosroseputters off
15:39:09  <auroraeosrose>I wonder how many forks of it there will be in an hour
15:40:09  <virmitio>likely not more than a few hundred
15:40:18  <virmitio>takes time for everyone to actually get to it
15:40:43  <auroraeosrose>we'll see
15:40:54  <auroraeosrose>ugh, I'm going to need two checkouts - bah humbug
15:41:00  <auroraeosrose>one for php on the "real" git
15:41:04  <auroraeosrose>and one for github
15:41:14  * auroraeosrosemumbles about why just not move entirely to github
15:50:45  <FearTheCowboy>No Idea.
15:51:45  <auroraeosrose>FearTheCowboy: actually I think eventually that will happen
15:51:49  <auroraeosrose>for now it's "baby steps"
15:51:56  <FearTheCowboy>LOL
15:52:36  <auroraeosrose>seriously
15:53:25  <auroraeosrose>I should write this down as I do it
15:53:47  <auroraeosrose>since we have no step by step "there's a project on github I want to fork and package" docs
15:55:10  <FearTheCowboy>Indeed.
15:55:36  <FearTheCowboy>you should fork based on a tag or release, mark that as the upstream
15:55:51  <FearTheCowboy>and then add in the CoApp magic.
15:56:24  <auroraeosrose>so - I want to fork a specific branch instead of the whole repo?
15:56:30  <vpovirk>the problem is it gets complicated when you have multiple branches
15:57:04  <FearTheCowboy>I defer to vpovirk on this; I've not done any multiple-branched ones
15:57:09  <vpovirk>so if you have tags on different branches, you have to make a different coapp branch and a different upstream branch and you have to do a rebase to get your changes over
15:57:32  <vpovirk>or a merge if you planned ahead so that will work or you know it's safe
15:57:33  <FearTheCowboy>however with PHP, I think we need to make mutliple forks (or support multiple branches for 5.3 / 5.4 ...)
15:58:03  <vpovirk>multiple forks don't gain you anything except the ability to name your branches 'master' and 'upstream'
15:59:08  <auroraeosrose>well, issue is each fork is going to be it's own package too though
15:59:16  <auroraeosrose>thoughts vpovirk?
15:59:26  <auroraeosrose>was waiting until today to do the php fork since I knew this git move was coming
16:00:01  * FearTheCowboywonders where virmitio is ...
16:00:10  <vpovirk>how much has php changed between 5.3 and 5.4 ?
16:00:25  <vpovirk>i.e. are you going to want to share your work between them?
16:00:29  <FearTheCowboy>vpovirk -> it's like Python 2.x and Python 3.x
16:00:45  <FearTheCowboy>well, maybe not *quite* that bad, but ... some
16:00:57  <vpovirk>even the ability to cherry-pick is worth having one repo, I think
16:01:58  <vpovirk>that's probably the way to do it; make a coapp-5.4 branch and an upstream-5.4 branch (or better naming if you have it), and do your work there
16:02:01  <virmitio>I heard my name?
16:02:26  <vpovirk>then when you want to do 5.3, make a coapp-5.3 and upstream 5.3, and if there's work in -5.4 that you can use, cherry-pick it
16:03:02  <vpovirk>merge/rebase is too complicated to explain quickly
16:06:06  <auroraeosrose>vpovirk: they're are a CRAPLOAD of differences
16:06:13  <auroraeosrose>branches are usually quite different
16:06:27  <auroraeosrose>and packaging stuff will need to go to all branches
16:06:34  <auroraeosrose>and we'll need TRUNK, 5.3 and 5.4
16:06:51  <auroraeosrose>shouldn't need more then three - when 5.5 is branched 5.3 will be killed
16:07:07  <FearTheCowboy>I'd go with three forks personally...
16:07:43  <auroraeosrose>three forks? sigh - yeah I can do that
16:08:00  <auroraeosrose>how do I handle the fact that each fork will be at LEAST 4 packages
16:08:06  * auroraeosrosemumbles
16:08:16  <FearTheCowboy>this is where virmitio steps in and explains the secret sauce.
16:09:12  <auroraeosrose>cause yeah
16:09:17  <auroraeosrose>this thing is going to be a mess ;)
16:09:33  <FearTheCowboy>a given fork often produces multiple packages
16:09:56  <auroraeosrose>FearTheCowboy: sure but do any of the others dep on a package from the same fork yet ;)
16:10:03  <auroraeosrose>cause this sucker will
16:10:04  <FearTheCowboy>(potentially mutliple flavors * multiple platofrms * serveral individual pcakages)
16:10:06  <FearTheCowboy>Yep
16:10:11  <auroraeosrose>sweet
16:10:24  <FearTheCowboy>zlib-dev depends on zlib-dev-common and zlib
16:10:25  <vpovirk>I really think that if they have one repo, you should too
16:10:47  <vpovirk>I don't see what you gain by having more than one
16:11:13  <FearTheCowboy>vpovirk the trick is; we've got build automation thats based on per-repo right now, not multiple branches per repo ...
16:11:50  <auroraeosrose>and virmitio doesnt' want to rewrite the automation I assume
16:11:52  <FearTheCowboy>if virmitio is up to making multiple branches build, I don't really mind, but we're just swamped with so much at once
16:12:24  <auroraeosrose>yup
16:12:32  * auroraeosrosepokes virmitio
16:12:38  <auroraeosrose>I can do it either way - your call
16:20:03  <FearTheCowboy>maybe virmitio needs a cookie
16:20:34  <virmitio>well, the honest truth is that, if I need to, I can swap out just part of the automation process for a specific project/package without affecting the other packages or remaining automation
16:21:03  <virmitio>so if the right answer is to do one fork with lots of branches and tags that all need built, I can do that
16:21:22  <virmitio>just please don't do that with every package we want to publish in-house
16:21:27  <virmitio>it would make me cry
16:21:47  <auroraeosrose>hehehe
16:21:58  <auroraeosrose>the languages are probably going to be the only weird ones like that
16:22:03  <auroraeosrose>well, maybe not
16:22:10  <vpovirk>lots of projects have stable branches
16:22:24  <vpovirk>but we probably won't have a reason to build old versions of most of them
16:22:39  <vpovirk>well, except for gnome 2/gnome 3, but I doubt I'll get around to that any time soon
16:24:22  <virmitio>the present front-to-back automation will build whatever is in HEAD for each repo in coapp-packages, so if we're only concerned with the "current stable" version for a given package, just make sure HEAD points to that branch of our fork
16:24:50  <auroraeosrose>so the issue here is multiple stable versions then
16:24:53  <auroraeosrose>how is that handled?
16:25:07  <auroraeosrose>because although most only have one, other items may have multiple
16:25:08  <virmitio>otherwise, as I said, I can decouple a particular package from the full automation to have it build multiple branches when needed
16:27:08  <vpovirk>it'll probably be mostly 2 branches, in cases where 1 isn't enough
16:27:20  <virmitio>in the case of multiple stable versions being maintained, I'd suggest keeping a 'coapp-<version>' branch that has the various coapp build and packaging files for each maintained version and I'll just keep the list of branches being built up to date by hand for now
16:27:54  <auroraeosrose>perhaps a file that you can grab that out of would help?
16:30:18  <virmitio>I can think of a number of ways off hand that would enable multi-branch automation "out-of-the-box" in the future, but I'd rather handle it case by case for a little while while I mull over the options
16:31:25  <auroraeosrose>ok
16:31:42  <auroraeosrose>so your vote is - one repo fork and automation is "special" for now?
16:31:46  <virmitio>auroraeosrose: a file in HEAD that I check before doing anything else seems a reasonable way to go, but would also mean rebuilding the automation again. While I'm not opposed to doing that, I'm hesitant to try it before I've thought all the way through it first
16:31:57  <virmitio>for the time being, yes
16:32:05  <auroraeosrose>all righty
16:33:33  <vpovirk>how about a file in HEAD that documents this but doesn't automate it?\
16:34:02  <vpovirk>or is that no more useful than telling virmitio?
16:34:44  <auroraeosrose>hehehe
16:34:50  <auroraeosrose>might help keep his memory straight
16:35:09  <virmitio>vpovirk: aside from the benefit to the forker that they could effectively "leave me a message" in the file instead of sending me a notice via email or irc, I see no real benefit to that right now
16:36:33  <virmitio>auroraeosrose: maybe, but that's why I keep lots of notepads and post-its on my desk
16:46:54  <FearTheCowboy>grsh. these variations on options at install time are gonna kill me...
16:47:21  <auroraeosrose>variations on options at install time?
16:48:16  <FearTheCowboy>the checkbox "Install latest version..." is being changed to a comobobox that holds a couple/few options depending on the current state of the package that is being installed
16:48:40  <auroraeosrose>ahhhh
16:50:30  <FearTheCowboy>and depending on whats' installed, and what's available, the contents change somewhat
16:51:37  <virmitio>ah, the many subtle variations in what one can do with a package file...
17:04:14  * Scotisis no longer away : Gone for 2 days 14 hrs 47 mins 57 secs
17:19:36  * Scotisis set as away : Reason(breakfast)
17:44:17  <vpovirk>solution: stop giving people options
17:44:28  <FearTheCowboy>I'm trying really hard!
17:44:46  <virmitio>vpovirk: I'm not sure you'd like that decision
17:45:07  * Scotisis no longer away : Gone for 25 mins 31 secs
17:45:50  <vpovirk>I can't think of an option I'd want besides which packages I choose to install or not
17:45:58  <auroraeosrose>convention over configuration! my way or the highway!
17:46:44  <vpovirk>and I'm OK with using an interface other than double-clicking the msi to set them
17:53:59  * ender`quit (Quit: A new scientific truth does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die, and a new generation grows up that is familiar with it. -- Max Planck)
17:57:35  * ender`joined
17:58:37  <FearTheCowboy>Well, the question is, when you double click a package, do you want the: (a) latest version, (b) latest compatible version, (c) this version ... it's one question, and the answer most of the time is the default value (which depends on the context.. )
18:00:53  <auroraeosrose>double click a package where ;)_
18:01:24  <vpovirk>I don't think I understand what "compatible" means
18:01:36  <vpovirk>is firefox 4.0 compatible with firefox 3.0 ?
18:01:50  <FearTheCowboy>possibly.
18:01:56  <FearTheCowboy>"binary compatible" ...
18:01:58  <auroraeosrose>yeah - that question is also going to be different based on app vs. library
18:02:54  <FearTheCowboy>I'd say that apps are 'binary compatible' when it works as an inplace upgrade without changing the configuration.
18:03:15  <vpovirk>but what if I have a package for an extension that relies on a specific firefox version?
18:03:56  <FearTheCowboy>if firefox is making binary incompatible changes, then they should be marking their packages as so.
18:04:18  <FearTheCowboy>Firefox is really a crappy example, as they've got a really terrible 'compatibility' scheme
18:04:28  <vpovirk>that's why I chose it
18:04:39  <FearTheCowboy>And they make no attempt at inter-version compatibility.
18:04:57  <FearTheCowboy>I highly doubt that we can manage FireFox extensions compatibility at all with CoApp
18:05:33  <vpovirk>unless "OR" dependencies are possible in the extensions..
18:05:42  <vpovirk>I don't think that requires a solver
18:05:58  <FearTheCowboy>not until we have soft/feature dependencies
18:06:00  <vpovirk>at least not any worse than features
18:16:04  * ssam2quit (Read error: Connection reset by peer)
18:19:58  * cH40z-Lordquit (Read error: Operation timed out)
18:20:17  * cH40z-Lordjoined
18:24:46  * HamishCquit (Quit: Going offline, see ya! (www.adiirc.com))
20:09:03  * mloskotjoined
20:09:04  * mloskotquit (Changing host)
20:09:04  * mloskotjoined
20:11:05  * remy_ojoined
20:32:34  * mloskotquit (Quit: mloskot)
20:32:51  * auroraeosrose1joined
20:34:18  * auroraeosrosequit (Disconnected by services)
20:34:23  * auroraeosrose1changed nick to auroraeosrose
20:34:30  * auroraeosrosequit (Changing host)
20:34:30  * auroraeosrosejoined
20:44:28  * mloskotjoined
20:44:28  * mloskotquit (Changing host)
20:44:28  * mloskotjoined
20:47:47  * virmitiopokes ender|
20:47:53  <ender`>yes?
20:48:04  <ender`>http://www.downloadmoreram.com/
20:48:26  <auroraeosrose>W T F
20:49:00  <virmitio>ender`: any chance you could write up a dependency tree for gimp?
20:49:20  <ender`>probably
20:49:42  <saivert>ender`: don't do it. it is a trap
20:49:52  <saivert>;)
20:50:05  <auroraeosrose>virmitio: where do you want dep tree of the evil language?
20:50:11  <virmitio>of course it's a trap! it's me asking
20:50:35  <virmitio>auroraeosrose: preferably burning in a trashcan far away from me
20:50:36  <ender`>i should probably start with this: http://p.0au.de/721 (this is the list of packages i get off the SuSE build service)
20:50:52  <virmitio>auroraeosrose: failing that, shooting me an email with it would work too
20:52:43  <ender`>virmitio: some of these are optional - should i mark them?
20:53:02  <auroraeosrose>yeah, I'm wondering that too
20:53:08  <auroraeosrose>or extension dependant
20:54:59  <virmitio>well, ideally we'd like to have a "base" package for extensible things, which would have only the minimum dependencies to have it run. Then we'd have various "extension" packages which would add features and would depend on the base package plus any extra deps the extension needs.
20:55:43  <ender`>the slight problem here is that without the dependency, that feature won't build (eg. without webkit, the help plugin isn't built)
20:55:49  <virmitio>going that route, it would be easy to build an "all-features" package that just depends on all the extension packages
20:56:35  <auroraeosrose>with PHP there's usually a set that"s built and shipped, but not necessarily enabled
20:56:39  <auroraeosrose>which makes it even nastier
20:57:05  <virmitio>ender`: can the feature be built/shipped separately from the core?
20:57:28  <auroraeosrose>although theoretically we can rip out as many as possible and package them separately
20:57:32  <auroraeosrose>that might be nice
20:57:36  <ender`>shipped, yes. built no
20:57:37  <auroraeosrose>although - oy the package madness
20:57:43  <virmitio>to be honest, I don't mind if there's a huge difference between the deps to build and the deps to install
20:57:46  <ender`>(the plugins are separate executables)
20:57:49  <auroraeosrose>virmitio: same here - shipped yes built no
20:57:58  <virmitio>ok
20:58:42  <virmitio>answer for you both, then: I'll need two lists. one of the deps to build everything, and another of the deps for installing a core binary package
20:58:50  <ender`>eg. in the 2.7.5 installer, i have the postscript plugin as a separate component, since it requires ghostscript (which uses around 25MB)
20:59:22  <virmitio>if I need to do a monolithic build and then package it up piecemeal, we can arrange that
20:59:37  <auroraeosrose>hmmmm - this is where it gets even nastier.... if I break it into SAPIs then you'd have the core php library (php5.dll) and then cli, cgi, etc - but yes it must be done as monolithic build of doom
20:59:38  <ender`>and to make the matters slightly worse: by default, i install 32bit TWAIN plugin with 64bit GIMP, because there's almost no 64bit TWAIN datasources :)
20:59:56  * auroraeosroselistens to virmitio cry
21:00:18  <FearTheCowboy>auroraeosrose -> this is as I've expected all along.
21:00:29  <FearTheCowboy>one monolithic build, a brazillian packages
21:00:31  <ender`>(somebody made 64bit twain work - but the only thing it can connect to on my computer is the testing twain datasource)
21:01:29  <virmitio>auroraeosrose: I'm not the one who's going to be crying. I just need to take a working building repo (with dependency references), build it, and put the results into various boxes. YOU, on the other hand, actually need to make it build happily.
21:01:49  <auroraeosrose>as long as I can get my evil libraries that never wanna build
21:01:52  <auroraeosrose>I'm good!
21:01:57  <virmitio>I've got a meeting to run off to, but I'll be back in a few minutes. brb
21:01:58  <auroraeosrose>the extensions are the easy part
21:02:43  <ender|>i wish i knew enough python to make this script spit out the dependencies for me
21:02:59  <FearTheCowboy>Yeah, extension will be "easy" ... once I get the MysticalAutoMagicLoadLibrary stuff done.
21:03:43  <auroraeosrose>yeah, the fun part might be the PHP configure system too
21:07:18  <ender`>how do you want me to format the dependencies?
21:07:43  <FearTheCowboy>ender` => virmitio stepped out... he'll be back in a few
21:09:28  <ender`>if i'm not around, here's the almost complete list of GIMP dependencies: http://p.0au.de/722 (only missing are babl and gegl, since they're too old on SuSE)
21:16:36  * virmitiois back
21:25:08  <Scotis>FearTheCowboy -> gotten any feedback on the packages list? any immediate needs?
21:25:39  <FearTheCowboy>It's pretty nice; a few people have commented that it's much improved :)
21:25:56  <FearTheCowboy>A couple things that I'd like off the top of my head:
21:26:13  <FearTheCowboy>- suppress the coapp.toolkit in the dependencies (since everything has that)
21:26:40  <Scotis>ok - that's fairly easy :)
21:26:41  <FearTheCowboy>- if dependencies are empty or previous versions are empty, don't show the tabs for those
21:27:02  <FearTheCowboy>- don't show the current version in the other versions tab...
21:27:14  <Scotis>hmm that should already be happening for the dependencies tab...
21:27:23  <Scotis>i'll check on it though
21:27:27  <Scotis>ok yeah that makes sense
21:28:00  <Scotis>i also want to clean up the modified date/time format - it is very verbose
21:28:03  <FearTheCowboy>Well, there always is a dependency on CoApp.toolkit, so it's always showing
21:28:04  <FearTheCowboy>yeah
21:28:57  <FearTheCowboy>I probably will have a few more ideas in a few days (after I get the next build out)
21:29:18  <Scotis>cool
21:29:28  <FearTheCowboy>The simple UI is getting some much needed tweaking, and update/trim are going to work right :)
21:29:39  <Scotis>nice!
21:29:53  <virmitio>FearTheCowboy: we get the "must be admin" issue fixed?
21:30:01  <FearTheCowboy>That's going to be in here too
21:30:12  <Scotis>i saw there was some discussion on making the flavors actual metadata?
21:30:41  <FearTheCowboy>yeaaaaah. We're likely going to add in a bit of metadata about the flavor so that the developer-libraries roles work right
21:30:56  <FearTheCowboy>...we'll discuss it more later this week...
21:31:01  <Scotis>ok
21:32:41  <Scotis>i think i am also going to play around with how i display packages that have multiple flavors - maybe put each one on a separate line - because right now it would get a little ridiculous if there is more than 2
21:32:59  <FearTheCowboy>ok
21:34:59  <Scotis>and make the '+ details' links a little less distracting - if you want to know more details - you'll be looking for it
21:35:50  <FearTheCowboy>Yeah; perhaps a little graphical + or something... I dunno
21:37:31  <Scotis>would it make any sense to try an combine the '-dev' and '-dev-common' and then base package into one listing w/ sub listings?
21:37:49  <FearTheCowboy>Yeah, that would be nice
21:38:18  <Scotis>are those going to be pretty standard naming conventions?
21:38:35  <Scotis>are there any other ones like that?
21:39:11  <virmitio>well, everything that I'm publishing is going to follow that standard
21:39:22  <virmitio>if it doesn't yet, it will before long
21:39:27  <Scotis>ok
21:39:29  <FearTheCowboy>So far, that's what we've got. I suspect that everything will follow those conventions
21:40:16  <auroraeosrose>might as well just have a "soft conventions" page and dump that into the wiki
21:40:22  <Scotis>is there a name for those distinctions? those are different ____ of the same package?
21:41:54  <Scotis>like how 'flavors' refers to 'vc10', 'vc8', 'vc9', etc...
21:41:55  <ender`>virmitio: seen the list?
21:42:24  <FearTheCowboy>not really coined a word for that... related variations?
21:43:15  <vpovirk>I'm anticipating -core variations of some things
21:43:29  <ender`>working on trimmed down list at the moment
21:43:29  <virmitio>ender`: I glanced at it briefly. I don't suppose there's any easy way to see it in more of a tree format (A depends on B, which depends on C, D, and E, etc.)?
21:43:40  <ender`>hm
21:43:42  * mloskotquit (Quit: mloskot)
22:15:22  * FearTheCowboyquit (Ping timeout: 246 seconds)
22:20:54  <virmitio>y'know, we could push out these packages so much faster if we didn't need to test them first...
22:26:00  <vpovirk>yeah, whose idea was that..
22:26:23  <virmitio>I dunno, but when I find out, I'm gonna smack that guy.
22:27:22  <vpovirk>testing is what users are for
22:27:47  <auroraeosrose>exactly!
22:27:53  <auroraeosrose>testing in production is the only true way
22:31:01  <vpovirk>msi is black magic
22:32:21  <ender`>virmitio: http://eternallybored.org/misc/imgs/gimp-deps.png
22:32:27  <vpovirk>just to build a thing that installs a tree of files I have to do some crazy things
22:32:56  * FearTheCowboyjoined
22:32:56  * FearTheCowboyquit (Changing host)
22:32:56  * FearTheCowboyjoined
22:33:04  <virmitio>welcome back FearTheCowboy
22:33:11  <FearTheCowboy>lol
22:33:22  <FearTheCowboy>I had a reboot
22:33:38  <virmitio>ender`: that is much more understandable, even if it does make my eyes bleed a bit
22:35:27  <ender`>anything that appears to be stand-alone is a gimp dependency (but opensuse only has gimp 2.6, which doesn't have those dependencies)
22:35:35  <virmitio>ender`: you depend on win_iconv? not libiconv?
22:36:02  <ender`>i really have no need for the full libiconv
22:37:00  <ender`>the win_iconv dll has the same ABI as libiconv anyway
22:38:08  <auroraeosrose>virmitio: as long as you don't use some weird edge case libiconv and win_iconv are quite interchangeable
22:38:12  * saivertchanged nick to lazydog
22:38:26  <virmitio>just struck me as odd, that's all
22:38:30  * mgdmjoined
22:38:39  <auroraeosrose>virmitio: it was designed that way ;)
22:38:53  <auroraeosrose>" can I drop this in and get basically the same functionality with windows apis
22:38:54  <ender`>it mattered more with gimp 2.6 - with 2.8 i'll apparently be shipping everything but the kitchen sink
22:39:08  * mgdmmakes a libkitchensink.so
22:39:15  <ender`>oh, and i completely forgot about python (and pygtk, pygobject and pycairo)
22:39:28  * lazydogchanged nick to saivert
22:39:51  <auroraeosrose>that's a gimp dep?
22:39:52  <auroraeosrose>oy
22:40:33  <ender`>pygimp
22:43:28  <auroraeosrose>FearTheCowboy: WTF?
22:43:32  <auroraeosrose>she needs her tubes tied
22:43:38  <FearTheCowboy>LOL
22:44:28  <auroraeosrose>my ten year old just rolled his eyes "she's stupid"
22:45:12  <mgdm>who dat?
22:45:24  <FearTheCowboy>I'm not sayin' she's dumb, but ... http://t.co/L2luhDRD She ain't no rocket scientist...
22:46:56  <auroraeosrose>my five year old figured it out in about one minute
22:46:58  <auroraeosrose>LOL
22:47:26  <virmitio>...
22:47:45  <virmitio>I... um... wait... wha... huh?!?
22:48:07  <FearTheCowboy>She's the kind of person who would see jigsaw puzzle, notice that the box says 2-4 years, and be proud she did it in 1.
22:49:25  <auroraeosrose>I was talking to my husband - and he said (without seeing the video) "how blonde is she"
22:49:46  <virmitio>it makes me sad to realize that I've known people like this
22:49:48  <ender|>haha
22:50:16  <FearTheCowboy>What's really scary, is their vote counts the same as yours!
22:50:29  <auroraeosrose>yeah
22:50:34  <auroraeosrose>universal birth control!
22:55:07  <ender|>it's too late for that!
22:55:25  <mgdm>https://twitter.com/old_sound/status/181875760011812864 is somewhat applicable
22:55:56  <auroraeosrose>IZ TRU
22:55:57  <mgdm>I just realised that might be rather insulting, I didn't mean that :-)
22:56:58  <auroraeosrose>LOL
22:57:05  <auroraeosrose>bah humbug
22:58:01  <virmitio>I think I'm going to need to half-rewrite an nmake file to get the test tools for apr
22:58:12  * virmitiois now grumpy
22:58:32  <vpovirk>at least you're not writing bourne shell scripts that generate msi tables
22:58:32  <auroraeosrose>would you like a cookie?
22:58:39  <auroraeosrose>WTF
22:59:03  <mgdm>I wrote some SQL recently that generated PHP, do i win?
22:59:17  <virmitio>vpovirk: I have to agree wiht auroraeosrose on this one. Why would you be doing that?
22:59:39  <vpovirk>because the only tool that I have available to build the msi is a program that imports tables/streams
22:59:48  <vpovirk>oh and a cab archiver
23:00:19  <virmitio>mgdm: unfortunately not. I'm pretty sure that you have to jump through at least three layers of code generation before we can consider you for an award
23:01:06  * mgdmwill endeavour to be even more convoluted, then
23:02:54  <vpovirk>anything else would require either an MS component or the very thing I am trying to build
23:03:37  <virmitio>yeah... coapp is approaching that point
23:04:25  <auroraeosrose>three layers of code generation?
23:04:26  <auroraeosrose>sweet
23:04:39  <auroraeosrose>we're writing code to generate code to generate code to generate code?
23:04:48  <vpovirk>none of my files are installing because they're "not scheduled to install"
23:04:52  <vpovirk>I don't even know what that means
23:06:28  * remy_oquit (Quit: WeeChat 0.3.7)
23:06:32  <virmitio>auroraeosrose: was more meaning the point of "you need it to build it"
23:07:03  <virmitio>though I don't think it's far from the first bit, either
23:09:24  <vpovirk>so, an nmake file is code to generate code...
23:09:34  <vpovirk>so if we write code to generate an nmake file that's two layers
23:10:18  <vpovirk>I don't think that works
23:16:12  * vpovirkquit (Quit: urk IRC v0.-1.cvs - http://urk.sf.net/)
23:18:03  * stalledquit (Ping timeout: 244 seconds)
23:21:20  * Scotisis set as away : Reason(food)
23:22:08  * mgdmmutters about auto-away messages being cack
23:22:08  <mgdm>:)
23:23:11  * virmitiois not away. Instead, he is watching you...
23:32:22  * saivertquit (Ping timeout: 246 seconds)
23:36:04  * stalledjoined
23:36:57  * Scotisis no longer away : Gone for 15 mins 36 secs
23:39:30  * saivertjoined
23:40:30  * virmitioquit (Quit: Leaving.)
23:40:48  * cH40z-Lordquit (Read error: Connection reset by peer)
23:41:33  * cH40z-Lordjoined
23:45:12  * madewokherdjoined
23:53:49  * ender`quit (Quit: There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare)