| --- Log opened Thu Sep 03 00:00:29 2015 |
| 00:06 | | Checkmate [Z@Nightstar-r9lk5l.cust.comxnet.dk] has joined #code |
| 00:06 | | mode/#code [+o Checkmate] by ChanServ |
| 00:25 | | Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has joined #code |
| 00:25 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
| 00:45 | | Alek [Alek@Nightstar-03ja8q.il.comcast.net] has quit [Ping timeout: 121 seconds] |
| 00:56 | <@macdjord> | * McMartin types Shift-Insert into a cmd.exe window and it fucking works, after 20 years |
| 00:57 | <@macdjord> | Way back in highschool, I had one CS class where we worked in Pascal using this ancient IDE that only recognised the 'classic' editing shortcuts - [modifier]-Insert for cut, copy, and paste, etc.. |
| 00:57 | <@macdjord> | For some reason, one of them, Ctrl-Shift-Z for 'Redo' (rather than Ctrl-Y) stuck with me, and I keep getting annoyed by modern programs that don't recognise it (or, worse, use it for something else). |
| 01:03 | <@celticminstrel> | Some modern programs still recognize that though... |
| 01:08 | | Reiv [NSwebIRC@Nightstar-q8avec.kinect.net.nz] has joined #code |
| 01:09 | | Netsplit *.net <-> *.split quits: abudhabi, tripflag, Xires, @Derakon[AFK], grindhold, @Vornicus, @macdjord, @jerith, wowaname, @Tamber |
| 01:10 | | mode/#code [+o Reiv] by ChanServ |
| 01:10 | | Netsplit over, joins: @Tamber, &jerith, &Derakon[AFK], ~Vornicus, @macdjord, Xires, grindhold, tripflag, wowaname, abudhabi |
| 01:16 | | himi [fow035@Nightstar-dm0.2ni.203.150.IP] has joined #code |
| 01:16 | | mode/#code [+o himi] by ChanServ |
| 01:27 | | Alek [Alek@Nightstar-03ja8q.il.comcast.net] has joined #code |
| 01:27 | | mode/#code [+o Alek] by ChanServ |
| 01:48 | < [R]> | " For example on my first day I found that X was running what was supposedly largest VAXcluster remaining in the world, for doing their production builds. Yes, dozens of VAXen running VMS, working as a cross-compile farm, producing x86 code. You might wonder a bit about the viability of the VAX as computing platform in the year 2005. Especially for something as cpu-bound as compiling. But don't worry, one of my new coworkers had as their current task evaluating |
| 01:48 | < [R]> | whether this should be migrated to VMS/Alpha or to VMS/VAX running under a VAX emulator on x86-64!" |
| 01:49 | < [R]> | https://www.snellman.net/blog/archive/2015-09-01-the-most-obsolete-infrastructur e-money-could-buy/ |
| 01:49 | | Meatyhandbag [sebastianfe@Nightstar-ee1.oh7.224.136.IP] has quit [Client exited] |
| 02:12 | | thalass [thalass@Nightstar-m49.o7s.158.104.IP] has joined #code |
| 02:12 | | mode/#code [+o thalass] by ChanServ |
| 02:19 | | mac [macdjord@Nightstar-r9vt2h.mc.videotron.ca] has joined #code |
| 02:19 | | mode/#code [+o mac] by ChanServ |
| 02:21 | | macdjord [macdjord@Nightstar-r9vt2h.mc.videotron.ca] has quit [Ping timeout: 121 seconds] |
| 03:24 | | catadroid` [catalyst@Nightstar-amtka2.dab.02.net] has joined #code |
| 03:27 | | catadroid [catalyst@Nightstar-pcp6ei.dab.02.net] has quit [Ping timeout: 121 seconds] |
| 03:46 | | Meatyhandbag [sebastianfe@Nightstar-ee1.oh7.224.136.IP] has joined #code |
| 03:52 | | thalass [thalass@Nightstar-m49.o7s.158.104.IP] has quit [Ping timeout: 121 seconds] |
| 04:18 | | Meatyhandbag [sebastianfe@Nightstar-ee1.oh7.224.136.IP] has quit [Client exited] |
| 04:31 | | Turaiel is now known as Turaiel[Offline] |
| 04:41 | | catadroid` [catalyst@Nightstar-amtka2.dab.02.net] has quit [The TLS connection was non-properly terminated.] |
| 04:41 | | catadroid [catalyst@Nightstar-20rmth.dab.02.net] has joined #code |
| 04:47 | | Checkmate [Z@Nightstar-r9lk5l.cust.comxnet.dk] has quit [Ping timeout: 121 seconds] |
| 04:55 | < [R]> | How do I force ld to look at a 64bit library? |
| 04:55 | < [R]> | It's repeatedly bitching about 32bit libraries not being compatable with the 64bit one I'm compiling, when 64bit versions exist. |
| 05:01 | | mac [macdjord@Nightstar-r9vt2h.mc.videotron.ca] has quit [[NS] Quit: Remeber, you two, be smart. And if you can't be smart, be safe. And if you can't be safe, /name it after me/.] |
| 05:13 | <&McMartin> | Make sure your library path is properly set, I imagine |
| 05:14 | <&McMartin> | Also, that talk catadroid linked earlier today/yesterday is fantastic |
| 05:14 | | * McMartin is only about a half-hour in, but yeah, this kind of thing is *exactly* the level of stuff he was looking for. |
| 05:15 | <@Reiv> | What's this, McM? |
| 05:16 | <&McMartin> | 13:26 < catalyst> https://www.youtube.com/watch?v=xnqTKD8uD64 might be handy, I don't know if it's pitched at a decent level for you or not |
| 05:16 | <&McMartin> | It's pitched at experts that have forgotten what problems with C++98 were, in fact, problems in the first place that C++11/14/17 were trying to solve, and how the terrifyingly general solutions produced thereby *were* solved |
| 05:17 | <&McMartin> | Which is to say, it's targeted almost directly at me, especially since I'll probably have to train half the company in C++ at some point in the foreseeable future and it's also talking about *that* as well as "these are the best practices you implement with these tools" |
| 05:24 | <@Reiv> | McMartin: Hunh |
| 05:24 | <@Reiv> | So you're pretty much going to use that as an educational video?~ |
| 05:29 | <~Vornicus> | there's this bit - he's talking early on about defaults. they're really, super, stupid important. like |
| 05:30 | <~Vornicus> | For twelve years I did not know that objects were *already* hashable in python. |
| 05:31 | <~Vornicus> | and I needed that so damn often |
| 05:35 | <~Vornicus> | and if I'd known that that was the default, I'd have had to write a lot less code. |
| 05:36 | <&McMartin> | Reiv: I'm giving the main one to the CTO |
| 05:37 | <&McMartin> | The other bit is to get that 180-page "here's what you really need to know" book, devour it, and make sure that what I design can be *used* by people who know just that. |
| 05:37 | <&McMartin> | Noting that what can be *used by* and what can be *written by* are two very different things |
| 05:43 | <~Vornicus> | this c++ thing is |
| 05:43 | <~Vornicus> | C++ does not look anything like I thought it did |
| 05:45 | <&McMartin> | I've been saying for some time that C++11 may as well be an entirely new language... |
| 05:45 | <&McMartin> | ... I was not attempting hyperbole |
| 05:53 | <~Vornicus> | I'm getting that impression! |
| 05:53 | | VirusJTG [VirusJTG@Nightstar-6i5vf7.sta.comporium.net] has quit [Connection reset by peer] |
| 05:53 | <~Vornicus> | A lot of this talk is over my head because I haven't done anything in C++ in a long time |
| 05:53 | <&McMartin> | A wag might also add "and if you did it right, that language would be Rust" |
| 05:53 | <&McMartin> | Yeah, this is in no way a beginner's guide |
| 05:54 | <&McMartin> | I've been coding in C++11 for 3 months now almost exclusively, and that was with several months of experimenting with Rust as it evolved, and thus getting used to messing with object lifetime as a core thing to worry about and deal with |
| 05:54 | <&McMartin> | So it's kind of like going to a statically typed language where I have to declare all my casts after a decade of nothing but JavaScript and Perl >_> |
| 05:56 | <@Reiv> | Do you prefer either? |
| 06:10 | <&McMartin> | C++11 is an actual production language that everything has a compiler for. Rust... is still in its infancy, but it has a good chance of being important later. |
| 06:11 | <~Vornicus> | the whole concept of move constructors blows up my head |
| 06:15 | <&McMartin> | Yeah, Rust is "move semantics *fucking everywhere*" and I think that gave me a better grounding to make proper use of C++11's madness. |
| 06:15 | <&McMartin> | Also, in Rust, when you fuck it up, it is a compiler error instead of runtime heap corruption =P |
| 06:17 | <~Vornicus> | I do pine for the days where shit don't build when I fuck it up that way |
| 06:17 | <~Vornicus> | but I work in fuckin' javascript |
| 06:17 | <~Vornicus> | gnah, slep |
| 06:19 | | Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has quit [Connection closed] |
| 07:17 | | himi [fow035@Nightstar-dm0.2ni.203.150.IP] has quit [Ping timeout: 121 seconds] |
| 07:27 | < catadroid> | If there's one thing in the world I am an expert in, it's C++ |
| 07:39 | | Kindamoody[zZz] is now known as Kindamoody |
| 08:02 | | celticminstrel [celticminst@Nightstar-r3r7al.dsl.bell.ca] has quit [[NS] Quit: And lo! The computer falls into a deep sleep, to awake again some other day!] |
| 08:36 | | kourbou [kourbou@Nightstar-deqg8j.fbx.proxad.net] has joined #code |
| 08:53 | | Kindamoody is now known as Kindamoody|afk |
| 09:04 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has joined #code |
| 09:04 | | mode/#code [+o himi] by ChanServ |
| 09:39 | | kourbou [kourbou@Nightstar-deqg8j.fbx.proxad.net] has quit [[NS] Quit: Off to school I go] |
| 09:54 | | catadroid` [catalyst@Nightstar-n67l13.dab.02.net] has joined #code |
| 09:56 | | catadroid [catalyst@Nightstar-20rmth.dab.02.net] has quit [Ping timeout: 121 seconds] |
| 10:05 | | catadroid` is now known as catadroid |
| 10:36 | <@TheWatcher> | Ugh, it should not be faster to write your own godsdamned API client module that to modify an existing one to do one simple bloody thing |
| 10:37 | <@TheWatcher> | *than to |
| 10:50 | | You're now known as TheWatcher[d00m] |
| 10:55 | | thalass [thalass@Nightstar-m49.o7s.158.104.IP] has joined #code |
| 10:55 | | mode/#code [+o thalass] by ChanServ |
| 10:56 | < catadroid> | Maybe? depends what the API is |
| 11:06 | | Netsplit *.net <-> *.split quits: catadroid |
| 11:08 | | PinkFreud [WhyNot@Pinkfreud.is.really.fuckin.lame.nightstar.net] has quit [Ping timeout: 121 seconds] |
| 11:08 | | thalass [thalass@Nightstar-m49.o7s.158.104.IP] has quit [[NS] Quit: Leaving] |
| 11:09 | | PinkFreud [WhyNot@Pinkfreud.is.really.fuckin.lame.nightstar.net] has joined #code |
| 11:09 | | mode/#code [+o PinkFreud] by ChanServ |
| 11:09 | | Netsplit over, joins: catadroid |
| 11:13 | | VirusJTG [VirusJTG@Nightstar-6i5vf7.sta.comporium.net] has joined #code |
| 11:17 | <@TheWatcher[d00m]> | catadroid: the GitLab API. |
| 11:17 | <@TheWatcher[d00m]> | Being used from perl |
| 11:17 | <@TheWatcher[d00m]> | So in theory Gitlab::API::v3 should do the job, except the author either forgot to add the sudo facility, or ran into the problem I'm having with it. |
| 11:19 | < catadroid> | oh, I see |
| 11:19 | <@TheWatcher[d00m]> | (added irritating: that module uses Moo, and hence has some - IMO - horrible syntax and great fun with field initialisation in object creation. |
| 11:19 | <@TheWatcher[d00m]> | ) |
| 11:20 | | You're now known as TheWatcher |
| 11:25 | | gnolam_ [lenin@Nightstar-t1tbf0.cust.bahnhof.se] has joined #code |
| 11:28 | | gnolam [lenin@Nightstar-t1tbf0.cust.bahnhof.se] has quit [Ping timeout: 121 seconds] |
| 12:06 | | * TheWatcher args at people that don't M-x delete-trailing-whitespace |
| 12:10 | < abudhabi> | Why do you hate trailing whitespace? |
| 12:11 | | Checkmate [Z@Nightstar-r9lk5l.cust.comxnet.dk] has joined #code |
| 12:11 | | mode/#code [+o Checkmate] by ChanServ |
| 12:13 | <@TheWatcher> | I have "(add-hook 'before-save-hook 'delete-trailing-whitespace)" in my .emacs, and if I'm working on code written by someone who doesn't strip trailing whitespace, I get my changes plus a bunch of changes caused by stripped whitespace |
| 12:14 | <@TheWatcher> | Which is Irritating |
| 12:28 | | * TheWatcher eyes '$Rev: 273 $' |
| 12:29 | <@TheWatcher> | Y halo that, CVS substitution marker. It's been a while since I last saw you. |
| 12:29 | <@TheWatcher> | *thar |
| 12:31 | < catadroid> | :o |
| 12:31 | < catadroid> | CVS substitution marker? |
| 12:35 | <@TheWatcher> | CVS let you put keywords like $Date: $, $Log: $ and other thins in your code and, each time you commited, it would substitute the appropriate values there - so you'd get $Date: 2015/09/03 12:35:05 $ and so on. Although now I think, I believe it was $Revision: $ rather than just $Rev: $ |
| 12:39 | <@TheWatcher> | Kinda broke with subversion, altough I seem to remember that there was a way to do it in there too. It makes no sense at all to do something like that with git/etc though, of course. |
| 13:00 | < catadroid> | ah I see |
| 13:00 | < catadroid> | I really should learn how to use git and Co |
| 13:21 | | Meatyhandbag [sebastianfe@Nightstar-ee1.oh7.224.136.IP] has joined #code |
| 13:44 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has quit [Ping timeout: 121 seconds] |
| 13:52 | | gnolam_ is now known as gnolam |
| 13:52 | | mode/#code [+o gnolam] by ChanServ |
| 13:57 | < [R]> | I'm getting the following error: undefined reference to `imlib_free_image', header: http://nobl.ca/Imlib2.h source: http://nobl.ca/test.c (Yes, I know I'm calling it wrong, trying to figgure out why it can't see the prototype) |
| 13:59 | <@TheWatcher> | You're linking with -lImlib2 ? |
| 14:04 | < [R]> | \o/ |
| 14:04 | < [R]> | Thank you, that worked. |
| 14:04 | <@TheWatcher> | Wewt. |
| 14:08 | | * gnolam sighs. |
| 14:09 | <@gnolam> | Yet another spectro... |
| 14:14 | <@gnolam> | I'm going to have to build some sort of shelf for my desk. I'm out of room. |
| 14:59 | | gnolam [lenin@Nightstar-t1tbf0.cust.bahnhof.se] has quit [Connection closed] |
| 14:59 | | gnolam [lenin@Nightstar-t1tbf0.cust.bahnhof.se] has joined #code |
| 14:59 | | mode/#code [+o gnolam] by ChanServ |
| 16:17 | | kourbou [kourbou@Nightstar-deqg8j.fbx.proxad.net] has joined #code |
| 16:24 | | catadroid` [catalyst@Nightstar-pnednl.dab.02.net] has joined #code |
| 16:24 | | Meatyhandbag [sebastianfe@Nightstar-ee1.oh7.224.136.IP] has quit [Client exited] |
| 16:27 | | catadroid [catalyst@Nightstar-n67l13.dab.02.net] has quit [Ping timeout: 121 seconds] |
| 16:33 | | celticminstrel [celticminst@Nightstar-r3r7al.dsl.bell.ca] has joined #code |
| 16:33 | | mode/#code [+o celticminstrel] by ChanServ |
| 16:42 | | catadroid [catalyst@Nightstar-spe22l.dab.02.net] has joined #code |
| 16:42 | | catadroid` [catalyst@Nightstar-pnednl.dab.02.net] has quit [A TLS packet with unexpected length was received.] |
| 16:46 | | GreenGuy [Gnomino@Nightstar-fik25i.gnomino.eu] has joined #code |
| 16:57 | | gizmore [kvirc@Nightstar-grreaf.dip0.t-ipconnect.de] has joined #code |
| 17:03 | | catadroid [catalyst@Nightstar-spe22l.dab.02.net] has quit [[NS] Quit: Bye] |
| 17:06 | | Meatyhandbag [sebastianfe@Nightstar-ee1.oh7.224.136.IP] has joined #code |
| 17:10 | | catadroid [catalyst@Nightstar-spe22l.dab.02.net] has joined #code |
| 17:24 | | Checkmate [Z@Nightstar-r9lk5l.cust.comxnet.dk] has quit [[NS] Quit: If I had a world of my own, everything would be nonsense. Nothing would be what it is because everything would be what it isn't. And contrary-wise; what it is it wouldn't be, and what it wouldn't be, it would. You see?] |
| 17:51 | | Meatyhandbag [sebastianfe@Nightstar-ee1.oh7.224.136.IP] has quit [Client exited] |
| 17:52 | | Meatyhandbag [sebastianfe@Nightstar-ee1.oh7.224.136.IP] has joined #code |
| 17:53 | | Meatyhandbag [sebastianfe@Nightstar-ee1.oh7.224.136.IP] has quit [Client exited] |
| 17:57 | | Meatyhandbag [sebastianfe@Nightstar-0fv.1a3.224.136.IP] has joined #code |
| 18:12 | <@gnolam> | Gah. Blue bloody LEDs. |
| 18:14 | <@gnolam> | Why would anyone need those on a bloody /label printer/? |
| 18:14 | <@Tamber> | Because bloo is futuristic!1 |
| 18:15 | <@Tamber> | (Fuck blue indicator LEDs on anything.) |
| 18:16 | | kourbou [kourbou@Nightstar-deqg8j.fbx.proxad.net] has quit [[NS] Quit: Iām not a psychopath. Iām a high-functioning sociopath. Do your research.] |
| 18:29 | <@Alek> | they're pretty bright in the dark XD |
| 18:30 | | * Alek has a blue led power indicator on his box. and a green HD-activity led. |
| 18:31 | <@Alek> | blame the TRON reboot. :P |
| 18:31 | <@Alek> | um. not reboot. sequel. -_- |
| 18:40 | | VirusJTG [VirusJTG@Nightstar-6i5vf7.sta.comporium.net] has quit [Ping timeout: 121 seconds] |
| 19:02 | | Kindamoody|afk is now known as Kindamoody |
| 19:10 | | GreenGuy [Gnomino@Nightstar-fik25i.gnomino.eu] has quit [Connection closed] |
| 19:45 | | Kindamoody is now known as Kindamoody[zZz] |
| 19:54 | <&McMartin> | 04:39 <@TheWatcher> Kinda broke with subversion, altough I seem to remember that there was a way to do it in there too. It makes no sense at all to do something like that with git/etc though, of course. |
| 19:55 | <&McMartin> | Is there actually a mechanism for git or git-like systems for "this header file includes a string/etc that indicates the provenance of the code"? |
| 19:55 | <&McMartin> | I suppose "generate at build time from contents of git log" but |
| 19:56 | | Meatyhandbag [sebastianfe@Nightstar-0fv.1a3.224.136.IP] has quit [Client exited] |
| 19:56 | <&jerith> | McMartin: You're supposed to do that yourself by looking at repository metadata, I think. |
| 19:59 | <&McMartin> | Oh right |
| 19:59 | | * McMartin forgot this was OSS, where shipped software does not exist |
| 19:59 | <&McMartin> | Or exists only under the most grudging of duress |
| 19:59 | <&jerith> | https://github.com/warner/python-versioneer |
| 20:00 | <&McMartin> | Ooh. |
| 20:00 | <&jerith> | That does something clever, although I don't recall the details. |
| 20:00 | <&McMartin> | Yes, I want this for Ophis, even though I think literally nobody uses the distutils version |
| 20:01 | <&jerith> | I used versioneer a while ago and there were some issues with it, but I don't recall the details. |
| 20:02 | <&McMartin> | Which probably means I don't want it for Ophis, because I really should be tying a bow on Ophis 2 and putting it into formal hibernation/completed status |
| 20:02 | <&McMartin> | It's been mature for over seven years |
| 20:02 | <&jerith> | Anyway, I meant you do the VCS metadata thing at build or packaging time. |
| 20:03 | <&McMartin> | And then use an ISO date code for last commit as your monotonically increasing integer that on SVN you'd use the revision number for, I imagine |
| 20:04 | <&jerith> | Do you need monotonically increasing integers for dev builds? |
| 20:04 | | GreenGuy [uid85383@Nightstar-om40rg.irccloud.com] has joined #code |
| 20:05 | <&jerith> | Actually, versioneer seems to do it by counting the commits since the last tag. |
| 20:06 | | VirusJTG [VirusJTG@Nightstar-6i5vf7.sta.comporium.net] has joined #code |
| 20:06 | <&McMartin> | "Do you need monotonically increasing integers for dev builds?" -> "Do you have any notion of autoupdate in your product and need to be able to tell whether the next available is truly an upgrade or not?" |
| 20:06 | <&McMartin> | "If yes, do you ever test this functionality before release?" |
| 20:06 | <&jerith> | McMartin: Those should be release builds, not dev builds. |
| 20:06 | <&McMartin> | Commits since last tag seems like a more human-friendly mechanism. |
| 20:07 | <&jerith> | And as such, they get tagged. |
| 20:07 | <@Tamber> | Pah! Autoupdate is for *spit* closed-source software~ ;) |
| 20:07 | <&McMartin> | jerith: Yeah, that wasn't how we were organized at the last place |
| 20:07 | <&jerith> | Tamber: `apt-get update && apt-get upgrade` in a cron job. ;-) |
| 20:07 | <&McMartin> | Essentially any commit could be turned into a "release" for QA by the build bot with no effort on any human's part. |
| 20:08 | <@Tamber> | jerith, perhaps I should have put that as "built-in autoupdate" instead, then. :p |
| 20:08 | <&McMartin> | That was actually pretty nice, and SVN gave us that for basically free by including an appropriate call to svnversion in the buildscripts |
| 20:09 | <&McMartin> | Versioneer sounds like it could do that with commitcounting and the "you're shipping .debs" tradition appears to be "use an ISO date as the 'patch level'" |
| 20:10 | <&jerith> | McMartin: `git tag <version>; git push --tags` and have your CI system build a release package. ;-) |
| 20:10 | <&McMartin> | Yes |
| 20:10 | <&McMartin> | Now you need to make sure that your "version"s are monotonically increasing across all your devs, etc |
| 20:10 | <&McMartin> | That is strictly a step down |
| 20:10 | <&jerith> | I don't follow. |
| 20:11 | <&McMartin> | If I "git tag <version>", I need to be in communication with every other dev to make sure it's an atomic increment. |
| 20:11 | | gizmore [kvirc@Nightstar-grreaf.dip0.t-ipconnect.de] has quit [[NS] Quit: KVIrc 4.3.1 Aria http://www.kvirc.net/] |
| 20:11 | <&McMartin> | If I use something based on date or commitcount, I push. |
| 20:12 | <&McMartin> | The latter workflow is significantly more robust. |
| 20:13 | <&jerith> | `git tag` shows you the existing tags and you can just pick the next one. |
| 20:13 | <&jerith> | Or you make <version> date-based. |
| 20:13 | <&McMartin> | The failcase for that is when two developers are preparing releases for QA on the same codebase |
| 20:14 | <&McMartin> | Which means either you explicitly embrace the notion of partial order |
| 20:14 | <&McMartin> | Or you let the build system handle it all |
| 20:14 | <&McMartin> | This is adding a manual step that shits up your taglist and ANAICT buys you literally nothing, so I'm still struggling to see why one would do it |
| 20:15 | <&jerith> | Oh, I actually meant the build bot does that. |
| 20:15 | <&jerith> | When it decides "this commit should be a release", it tags the commit with the version and rebuilds or whatever. |
| 20:16 | <&jerith> | It does mean you have to manage the release versions explicitly rather than relying on a full ordering of all commits. |
| 20:17 | <&McMartin> | Right, though anything that makes it out to customers would need that anyway for the "real" revision jumps |
| 20:17 | <&McMartin> | But it's nice to have anything the CI spits out be able to coexist |
| 20:18 | <&jerith> | Yeah. |
| 20:18 | <&jerith> | How does your system handle branch builds? |
| 20:18 | <&McMartin> | Past tense, as the company folded for non-tech related reasons, but... |
| 20:18 | <&McMartin> | It was a lexicographical compare on major.minor.patch.revision |
| 20:19 | <&McMartin> | So a branch from an earlier release is an update to that release but not any later release |
| 20:19 | <&McMartin> | Two branches from the same release would "fight" for the latest-revision slot |
| 20:19 | <&jerith> | I know, but I'm talking about the design of the system rather than the actual usage thereof. :-) |
| 20:19 | <&McMartin> | The nature of the product was such that downgrades were nonfeasible |
| 20:19 | <&McMartin> | Yeah, the design was "lexicographical comapre on major.minor.path.revision" because it was SVN based |
| 20:20 | | * jerith nods. |
| 20:20 | | Checkmate [Z@Nightstar-ev6.6um.94.83.IP] has joined #code |
| 20:20 | | mode/#code [+o Checkmate] by ChanServ |
| 20:20 | <&McMartin> | There were plans to switch to git, that never really materialized because git is shit at blobs and we needed decent blob support, and the on-paper plan was to replace "revision" with a count of builds made by the CI system. |
| 20:20 | <&McMartin> | Which was not my choice; I argued for ISO date. |
| 20:21 | <&jerith> | The commits-since-last-tag-followed-by-hash gives you something similar to the SVN thing, except the branch with more commits always wins. |
| 20:21 | <&jerith> | Having the CI system count sounds like a horrible idea. |
| 20:22 | <&McMartin> | "The branch with more commits always wins" sounds like an outright design failure |
| 20:22 | <&McMartin> | Given the nature of the system and what we used it to enforce, date directly represented that as the final disambiguator |
| 20:22 | <&jerith> | I don't see how that's particularly worse than "branch with most recent commit". |
| 20:23 | <&jerith> | Assuming branches are actually independent. |
| 20:23 | <&McMartin> | The latter is easier to change if you need to force it~ |
| 20:24 | <&McMartin> | (Though yeah we also had a revision-override command) |
| 20:24 | <&jerith> | Nothing that matters should be seeing branch builds anyway. |
| 20:25 | <&jerith> | If you really need to push experimental stuff outside the branch test world, tag an unstable release or something. :-) |
| 20:26 | <&McMartin> | There is not actually a universal answer to "should QA get to see branch builds" |
| 20:26 | <&McMartin> | This place said "yes, absolutely" to that, in part because SVN branches are more heavyweight |
| 20:26 | <&McMartin> | While we also had people come in and boggle at this, since apparently they were used to people reintegrating and breaking everything for everyone |
| 20:27 | <&jerith> | Oh, QA should almost certainly see them. QA should also treat them as branches, not release candidates. |
| 20:27 | | Meatyhandbag [sebastianfe@Nightstar-ee1.oh7.224.136.IP] has joined #code |
| 20:28 | <&McMartin> | Right, though this also meant that under the SVN environment QA and dev needed no special protocol for "test autoupgrade from last release to branch" |
| 20:29 | <&McMartin> | So one wasn't written because it Just Worked, modulo bugs that the branch hopefully was fixing |
| 20:29 | | catadroid [catalyst@Nightstar-spe22l.dab.02.net] has quit [[NS] Quit: Bye] |
| 20:30 | <&jerith> | How did that work switching between two unrelated branches? |
| 20:30 | <&McMartin> | That wasn't a tested workflow, per se, but one would probably work and the other required a manual intervention |
| 20:32 | <&McMartin> | (if you deliberately engineered your branches so that an "upgrade" was actually a downgrade that couldn't handle data migration, that would have been on you, but (a) that never came up and (b) if it did we'd have demanded a pre-release bump in patchlevel) |
| 20:33 | <&jerith> | I was thinking more along the lines of "branch A adds thing 1, branch B adds thing 2, neither knows about the other". |
| 20:34 | <&jerith> | So switching between the two behaves like a downgrade in either thing 1 or thing 2. |
| 20:35 | <&McMartin> | Our protocol for testing things independently like that involves doing a full system reset between the two |
| 20:35 | <&jerith> | (I'm asking because I'm curious, not because I think it's a bad setup.) |
| 20:35 | <&McMartin> | (In practice we would assign each thing to a different QA engineer, and then get them both integrated with each other as quickly as possible.) |
| 20:35 | <&McMartin> | Generally we paired devs with QA leads and they worked together on test protocols and as stuff evolved we'd go through with it |
| 20:36 | <&McMartin> | We had a *much* stronger human element in our QA than is typical |
| 20:36 | <&McMartin> | The places where the spiders tended to live were places where unit tests consistently were the problem instead of the code. |
| 20:36 | <&McMartin> | Automated systemic tests for desktop software that talks to servers is hard =P |
| 20:37 | <&jerith> | My preferred protocol for QA like that is to start each session with a complete reset to the current (or relevant) release version, followed by autoupdate to the build being tested. |
| 20:37 | <&McMartin> | Yeah |
| 20:37 | <&jerith> | But that isn't always feasible. |
| 20:37 | <&McMartin> | For us it was always *possible* but time-consuming |
| 20:38 | <&McMartin> | So for iteration (or, of course, for testing things that requires two different builds with the feature in) it had to do both |
| 20:38 | <&jerith> | I've been bitten by leftover state from intermediate versions that meant QA worked fine but production broke. |
| 20:38 | <&McMartin> | Yeah |
| 20:39 | <&McMartin> | System reset is mandatory once you get to "everything is drafted and integrated, send the first complete version of the next version to QA" |
| 20:39 | <&jerith> | Much more recently, I've watched colleagues get bitten because their automated testing isn't where it should be. |
| 20:40 | <&McMartin> | Yes |
| 20:40 | <&McMartin> | Note that I often come off as sounding like I think automated testing is overrated |
| 20:41 | <&McMartin> | This is because the bugs I tended to get were things like "If MS Office is also installed, its keyboard/language select bar starts placing itself over parts of your display, interfering with proper operation of our product" |
| 20:41 | <&jerith> | We've hired an excellent QA lead, but because stupid reasons he's spent a bunch of his time loading content into a crappy system over and over again instead of actually leading QA. |
| 20:41 | <&McMartin> | And this is the sort of thing automated testing does not catch. |
| 20:42 | <&jerith> | Oh, and I meant I watched them get bitten specifically by the upgrade thing. |
| 20:42 | <&McMartin> | Oh, right. |
| 20:42 | <&McMartin> | I don't recall for sure |
| 20:42 | <&McMartin> | But I think they used a dd-like approach for system resets |
| 20:43 | <&jerith> | Because their automated tests started never ran migrations. |
| 20:43 | <&McMartin> | Yeah |
| 20:43 | <&McMartin> | WHen I first joined that company we had an attempt at a full automated test |
| 20:43 | <&jerith> | So the migrations were only ever tested manually on an ad-hoc QA system. |
| 20:44 | <&jerith> | This is all web stuff, though. |
| 20:44 | <&jerith> | So much less tricky to test than your things. |
| 20:44 | <&McMartin> | It would download the installer, run it, start it up, log in to that server with appropriate credentials, subscribe to content, install it, configure and launch a VM, which would then do detectable things, then shut down, power off, uninstall, cleanup |
| 20:44 | <&jerith> | That sounds... ambitious. |
| 20:44 | <&McMartin> | That is literally the minimum to test the basic operation of anything, too |
| 20:45 | <&McMartin> | I would estimate the ratio of "the unit tests failed because something is wrong with the code you did" to "the unit tests failed because something went sideways in that chain of spaghetti" to be about 1:35 |
| 20:45 | <&McMartin> | ... which is why it didn't last much longer, and also why our QA was more human-heavy than usual |
| 20:45 | <&McMartin> | Individual modules were unit-tested |
| 20:45 | <&McMartin> | That was so very much not the Work Of Testing |
| 20:46 | <&jerith> | Anyway, I suspect most of your bugs were weird interactions because you already had decent code-level testing. |
| 20:46 | <&McMartin> | (Meanwhile, the server team would deploy 5,000 automated mock clients and just stand there shouting GO FORTH, MY ARMY OF ROBOTS!) |
| 20:46 | <&McMartin> | Yep |
| 20:46 | <&jerith> | Last time I unleashed an army of robots on my system, it defeated them. |
| 20:47 | <&McMartin> | While I don't consider myself an expert, my tentative conclusion here is that how human-heavy your QA has to be depends a lot on how much of the things that can go wrong involve "weird interactions" |
| 20:47 | <&jerith> | That was a very long time ago, though. |
| 20:47 | <&McMartin> | And there's a definite sense from some quarters that weird interactions are not actually bugs in your code, but the fault of the end user or system administrator |
| 20:47 | <&McMartin> | And my pushing back against that is what produces the impression I'm anti-automated tests |
| 20:48 | <&jerith> | I've never seen you as anti-automated test, FWIW. |
| 20:48 | <&McMartin> | okay |
| 20:48 | <&jerith> | Especially not in conversations like this one. :-) |
| 20:49 | <&jerith> | It might be because I tend to assume that decent automated testing is a starting point, not an unattainable goal. |
| 20:50 | <&jerith> | Meanwhile, Bunnee is getting very frustrated next to me giving her mom tech support over the phone. |
| 20:55 | <&McMartin> | Oh dear |
| 20:57 | <&jerith> | Her mom is now following instructions instead of reading everything on the screen, so all is good. |
| 20:58 | | catalyst [catalyst@Nightstar-bt5k4h.81.in-addr.arpa] has joined #code |
| 21:24 | <@froztbyte> | I am making good headway in writing some automated minions |
| 21:24 | <@froztbyte> | for testing our stuff |
| 21:25 | <@froztbyte> | but it's quite the process because holy crap moving components within moving components |
| 21:25 | <@froztbyte> | (not in the sense of over-complexified anything, it's just the nature of what's actually being sold) |
| 21:25 | <@froztbyte> | but it's going to be fuuuuuuuun when I can explode some servers at the touch of a button |
| 21:26 | <&ToxicFrog> | McMartin: apart from stuff like versioneer, git has a general purpose mechanism for adjusting file contents just before commit (or just after checkout, or both) |
| 21:26 | <&ToxicFrog> | Which can be used to implement stuff like this without much trouble. |
| 21:27 | <&ToxicFrog> | What you can't do is implement exactly "replace this with the current commit ID", because the commit ID is a hash derived in part from the file contents, although things like "commits since last tag" are entirely possible. |
| 21:30 | <&ToxicFrog> | Re: weird interactions: we actually have a thing in snowcat that brings up a complete serving stack with a variety of configurations, sends a whole bunch of traffic through it, and checks both the results of the traffic and the contents of the logs. IME the ratio of problems with your code vs. problems with the test infrastructure itself is about 1:1, which is good enough to be useful. |
| 21:30 | <&ToxicFrog> | But we also have a team dedicated just to maintaining this thing, so. |
| 21:31 | <&ToxicFrog> | catalyst: as noted earlier I am generally pro-git! |
| 21:32 | < catalyst> | aha :) |
| 21:32 | <&ToxicFrog> | Er. As in "I am in favour of it", not as in "I am a pro at git", although I have some experience with it. |
| 21:32 | <&McMartin> | TF: Yeah, being a Gigantic Corporation with properly organized priorities helps a lot for this |
| 21:33 | <&McMartin> | We, uh, burned out three QA-Dev engineers on that thing and then decided to cut our losses for the good of humanity |
| 21:33 | <&ToxicFrog> | Eep. |
| 21:33 | <&McMartin> | I think one of them left the industry to get into autocross. >_> |
| 21:34 | <&McMartin> | catalyst: I don't think I said this directly to you, so: thank you for the video link yesterday! That is in fact *exactly* the level I was hoping to be targeted at |
| 21:34 | < catalyst> | Awesome |
| 21:34 | <&McMartin> | viz. "people who use the C++ language like the demoscene uses defunct chipsets, and who really probably shouldn't be" |
| 21:35 | | Meatyhandbag [sebastianfe@Nightstar-ee1.oh7.224.136.IP] has quit [Client exited] |
| 21:40 | <&McMartin> | Also, he's talking up "A Tour of C++" which I think I need to acquire and force upon my co-workers |
| 21:40 | <&McMartin> | ("C++, unlike war, changed a lot. Here's what you need.") |
| 21:44 | | * TheWatcher readsup |
| 21:50 | <@TheWatcher> | I do note that, for several projects I either use or am involved with (some involving dozens of devs), annotated git tags are pretty much The Standard Release Marker and it seems to work - of course, many of them get around the problem of clashing tags by essentially only having one or two devs who are allowed to set them... |
| 21:51 | | thalass [thalass@Nightstar-m49.o7s.158.104.IP] has joined #code |
| 21:51 | | mode/#code [+o thalass] by ChanServ |
| 21:51 | | Turaiel[Offline] is now known as Turaiel |
| 21:52 | <@celticminstrel> | I wish I could use C++14 in XCode 4. :/ |
| 22:11 | <@celticminstrel> | Anyone know if there's a way to make XCode relink static libraries if they've changed? |
| 22:11 | <@celticminstrel> | Maybe if I added it to the build phase instead of the command-line options... |
| 22:18 | <@celticminstrel> | But they're not showing up in Products. :/ |
| 22:37 | <@celticminstrel> | It's annoying how XCode doesn't properly understand where your products are and doesn't let you manually fix it. |
| 22:38 | <@TheWatcher> | But it Just Works~ |
| 22:45 | <@celticminstrel> | Only if you don't mess with the build products location in build settings. |
| 22:45 | <@celticminstrel> | You'd think it would be able to tell that you've done that, but apparently not. |
| 23:00 | <&ToxicFrog> | TheWatcher: the problem being solved here is not "how do you mark releases in git" but "how do you make sure the program as released reports itself as the right version, without needing to remember to make an "update version numbers" commit" |
| 23:05 | | GreenGuy [uid85383@Nightstar-om40rg.irccloud.com] has quit [[NS] Quit: Connection closed for inactivity] |
| 23:48 | | Meatyhandbag [sebastianfe@Nightstar-ee1.oh7.224.136.IP] has joined #code |
| 23:48 | | Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has joined #code |
| 23:48 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
| 23:49 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has joined #code |
| 23:49 | | mode/#code [+o himi] by ChanServ |
| --- Log closed Fri Sep 04 00:00:45 2015 |