| --- Log opened Mon Jan 12 00:00:22 2015 |
| 00:10 | <@celticminstrel> | XD |
| 00:13 | | Vornicus [vorn@ServerAdministrator.Nightstar.Net] has joined #code |
| 00:14 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
| 01:18 | <@celticminstrel> | I wonder if [NSMenu itemWithTitle:] will still work if the menus are localized. |
| 01:18 | <@celticminstrel> | It seems unlikely. |
| 01:18 | <@celticminstrel> | But not impossible. |
| 01:19 | <&McMartin> | IIRC this should be very easy to test - you can localize all the basics with a couple mouseclicks under System Preferences and a reboot. |
| 01:19 | <@celticminstrel> | ...reboot? |
| 01:20 | <@celticminstrel> | Ah, not actually necessary. |
| 01:21 | <&McMartin> | IIRC bits of the resources stay cached so you end up in a weird hybrid state of some English and some Foreign until a full reinitialize. |
| 01:21 | <@celticminstrel> | I dunno, but I moved French up and launched something, and all the menus were French. |
| 01:21 | <@celticminstrel> | That said, I hadn't launched that particular program since last reboot. |
| 01:22 | <@celticminstrel> | I just put the order back and relaunched it and it was all English again. |
| 01:23 | <@celticminstrel> | It specifically says in System Preferences that changes take effect next time you open them. |
| 01:23 | <@celticminstrel> | But maybe it does get cached in later system versions. I dunno. |
| 01:23 | <@celticminstrel> | Even with French at the top, my program was all English. |
| 01:25 | <@celticminstrel> | I'd probably need to add some translations to test it. |
| 01:25 | <@celticminstrel> | Maybe because none of the menus are really standard. |
| 01:27 | <@celticminstrel> | I was using itemWithTitle instead of itemAtIndex so that it would remain correct if I decided to reorder the menu. |
| 01:28 | <@celticminstrel> | Though maybe I could actually set it up to automatically attach actions... |
| 01:29 | <@celticminstrel> | (Which of course is what you're supposed to do anyway.) |
| 01:30 | < Reiv> | Vornicus! |
| 01:31 | < Reiv> | I will not explain unto you the normalisation technique |
| 01:31 | < Reiv> | Instead you will tell me what you want to do and I will hack something together that is ugly and wrong but probably work OK~ |
| 01:32 | <~Vornicus> | hahahaha |
| 01:33 | < Reiv> | Because 'the technique' is 'know when it is time to stop being perfectionist and write the damn thing' |
| 01:33 | < Reiv> | Oh, and views. |
| 01:33 | < Reiv> | Use views. |
| 01:34 | < Reiv> | That way when you discover six months down the track that your database normalisation was Horrible and Wrong because you Hadn't Thought About It, you can rewrite the whole backend from scratch, if you must, and the views don't give a shit |
| 01:36 | <~Vornicus> | OK so building a database for Power Grid. The parts I'm primarily concerned about at the moment are cities: when a player connects to a city, is there a way to ensure that the city is on the map associated with the game |
| 01:36 | <~Vornicus> | and yes, views are my bestie |
| 01:36 | < Reiv> | ah, Power Grid |
| 01:37 | < Reiv> | OK, so wait a moment. What do you mean 'associated with the game' |
| 01:37 | < Reiv> | I suspect I know, but I want to check. This is a client/server setup, with multiple instances of a game running at the same time? |
| 01:37 | <~Vornicus> | Correct |
| 01:38 | <~Vornicus> | ANd each game is associated with a map: US, say, or Germany |
| 01:40 | < Reiv> | Then... hm, probably 'cities' is a many:many junction table, with extra columns for built order (useful mostly for consistent presentation) and colour |
| 01:40 | < Reiv> | Game on one side, Board on the other |
| 01:41 | < Reiv> | Board has the information about which number is which city, what it's called, prices, etc |
| 01:41 | < Reiv> | Game stores the information about which Players are involved, what Turn, etc |
| 01:42 | < Reiv> | Of course this isn't really a diagram this is just my initial thoughts |
| 01:42 | < Reiv> | (Game would also, perhaps suprisingly, store the amount of resources on each track [and it is a good thing I've played this game before, huh]) |
| 01:42 | < Reiv> | (Board would track the varying costs-per-spot, I guess, if that's a thing that changes I don't know) |
| 01:42 | < Reiv> | ((I've only ever played Germany)) |
| 01:43 | < Reiv> | ((If they do change, though, you want the varying costs to be on a side table to avoid having thirty columns; easy enough done)) |
| 01:44 | <~Vornicus> | (it changes, uh, drastically, in the case of Korea - there's two tracks there) |
| 01:44 | < Reiv> | There you go then |
| 01:45 | <~Vornicus> | (very complicated, Korea is) |
| 01:45 | < Reiv> | Having it a side table with Board, Resource, Spot, Cost works out well for you then |
| 01:45 | < Reiv> | You just end up having Resource being CoalN and CoalS or whatever. |
| 01:45 | < Reiv> | Or put in a spare column to track that special case, but I suspect a different attribute is easier. |
| 01:46 | < Reiv> | but anyway that's an implementation detail |
| 01:47 | < Reiv> | Does mean that each Game has a Resources table alongside it though, so you can track which resource is used by which game and how much is present |
| 01:47 | <@celticminstrel> | I can easily link actions to menuitems using the interface builder. The part I can't figure out is setting the "represented object" of the menuitem. |
| 01:48 | <~Vornicus> | Resources aren't much an issue for me at the moment as cities |
| 01:48 | < Reiv> | (IE, there are currently 12 Coal available. You'd then check the ResourceSpots table to work out what the twelfth spot [remaining or used is up to you] is worth. Etc.) |
| 01:48 | < Reiv> | Cities link to a Board, which has an ID for each city |
| 01:48 | | Alek [omegaboot@Nightstar-c8t.a00.36.73.IP] has quit [Ping timeout: 121 seconds] |
| 01:48 | < Reiv> | That's how you work out that City #47 is in fact Essen and wants to go in the middle of your pretty UI or whatever |
| 01:49 | <~Vornicus> | Right that's the easy part |
| 01:49 | < Reiv> | Couple ways to do it |
| 01:50 | < Reiv> | City is also linked to Game, so you know which game we're talking about for a given city; this then has, eg, 3 columns (is it always three?) where you store the player colours as they sneak in. (Player colours may actually be 1, 2, 3 etc) |
| 01:50 | < Reiv> | So that way you know which city for which game has which player attached to it right now. |
| 01:50 | <~Vornicus> | (Japan has 2- and 4- spot cities) |
| 01:51 | < Reiv> | A probably better way (yep, that's why) is to have your rows for City be, eg, "Mapspot","Game","Colour","Spot" |
| 01:53 | < Reiv> | Then Mapspot has "Mapspot"(eg, 17),"Name"(Essen),"Spots"(3),"Cost"(It's always x2 and x3 for the later ones right) |
| 01:53 | < Reiv> | And then... hn |
| 01:53 | < Reiv> | I guess you need to link cities together |
| 01:53 | < Reiv> | Welp, that bit's awful, tough |
| 01:53 | <~Vornicus> | That's another table anyway |
| 01:53 | < Reiv> | That's a many:many table somewhere else, right |
| 01:53 | < Reiv> | Do they ever have one-way directions? |
| 01:53 | <~Vornicus> | (10 15 20 for 3-thing cities; 10 10 15 20 for 4-thing cities in Japan; I don't remember any others) |
| 01:53 | <~Vornicus> | Nope. |
| 01:53 | < Reiv> | 'k, that makes it easier |
| 01:54 | < Reiv> | That bit is easy enough for you; but you do choose whether you want your queries to be neat or your data >_> |
| 01:54 | < Reiv> | Or, y'know, write a proper function somewhere in the actual code. Probably the better way. |
| 01:56 | < Reiv> | anyway |
| 01:57 | < Reiv> | You probably end up with Players, Game, Map, Resources, Stations (which holds who holds each station right now), Deck (which hold stations)...hm |
| 01:57 | <@celticminstrel> | It doesn't look like there's any way to do this. |
| 01:57 | < Reiv> | There's an odd non-shuffled deck going on in there isn't there, that's a pain |
| 01:57 | | Alek [omegaboot@Nightstar-c8t.a00.36.73.IP] has joined #code |
| 01:58 | | mode/#code [+o Alek] by ChanServ |
| 01:58 | < Reiv> | Ignore my Deck ideas, they're probably wrong until I work out the implications |
| 02:00 | < Reiv> | Oh, and there are People. |
| 02:00 | < Reiv> | If you want to have consistent login info or something |
| 02:00 | <~Vornicus> | Yeah, that part I know how to do~ |
| 02:01 | < Reiv> | Really, Game is the key and the heart. It interacts heavily with a lot of tables, but pretty much all the other tables link back to Game eventually. |
| 02:02 | < Reiv> | People joins Players who joins Game. Game joins Cities which joins Map. Game joins Resources which joins [Data on map resource types and costings, I can't think of a name]. Game joins Cards which joins Deck, I suspect Cards is awful but usable anyway. |
| 02:03 | < Reiv> | Game actually holds relatively sparse information; much of what it tracks ends up in the side tables, because this is a real sucker for many:many relationship tables. |
| 02:05 | < Reiv> | Player has its keys sprinkled throughout Cards, Cities, and Resources (or at least a sister table that says how many of each, each player has, I haven't thought about that one yet) |
| 02:05 | < Reiv> | You then view the thing as a Player by joining on Player keys, as a map by joining on Cities, and Game acts as the key so you know *which game* is in question. |
| 02:06 | < Reiv> | That's my fifteen minute analysis of the problem, anyway |
| 02:06 | < Reiv> | If I had the time (which I really really don't this week :/) I'd visio up a little diagram for you |
| 02:07 | < Reiv> | If you've the time yourself, have a crack at it and then I can help critique and bugfix as we go |
| 02:07 | <~Vornicus> | sir your wedding is a gigantic production and in... 6 days? |
| 02:07 | < Reiv> | haha no |
| 02:07 | < Reiv> | 7 weeks |
| 02:07 | < Reiv> | but this does not change the production much >_> |
| 02:07 | <~Vornicus> | oh, that's a little further out |
| 02:08 | < Reiv> | I love you man, but I'm not going to be at work helping design board game state databases in my afternoon tea break when the wedding is six days away, I am going to be on annual leave and losing what little hair remains >_> |
| 02:10 | <~Vornicus> | :P |
| 02:11 | <~Vornicus> | also my calculation was incorrect based on the date I thought you'd picked: 13 days~ |
| 02:11 | < Reiv> | snerk |
| 02:11 | < Reiv> | why do you think my wedding is in 13 days |
| 02:12 | <~Vornicus> | Because I thought your wedding was jan. 23 |
| 02:13 | < Reiv> | oh! |
| 02:13 | < Reiv> | That is reasonable, it was at one point |
| 02:13 | < Reiv> | But then certain people would have been unable to make it that we wanted to make it, enough to actually change the date over |
| 02:13 | < Reiv> | It's now Feb 28th. |
| 02:13 | < Reiv> | My beloved vetoed delaying the wedding a year so we could have Feb 29th ;_; |
| 02:13 | <~Vornicus> | Hahaha |
| 02:14 | < Reiv> | Seriously, that would have been /awesome/ |
| 02:14 | < Reiv> | Bugger the annual dinner, save up and go on holiday somewhere to celebrate the anniversay! |
| 02:14 | < Reiv> | It's only every four years, make it a big one, etc |
| 02:21 | | Turaiel[Offline] is now known as Turaiel |
| 02:22 | | Alek [omegaboot@Nightstar-c8t.a00.36.73.IP] has quit [Ping timeout: 121 seconds] |
| 02:26 | | Alek [omegaboot@Nightstar-c8t.a00.36.73.IP] has joined #code |
| 02:26 | | mode/#code [+o Alek] by ChanServ |
| 02:30 | | HotShot [HotShot@Nightstar-39c4pa.nap.wideopenwest.com] has quit [Connection closed] |
| 03:12 | | SmithKurosaki [SmithKurosa@Nightstar-iq52tu.cable.rogers.com] has quit [[NS] Quit: Bye] |
| 03:35 | < Reiv> | Vornicus: Do you know how to assemble ER diagrams? |
| 03:35 | <~Vornicus> | Sure. Remember that, once upon a time, *I* taught *you* how to database~ |
| 03:39 | <&Derakon> | ... |
| 03:40 | <&Derakon> | I read ER as "endoplasmic reticulum". |
| 03:40 | <~Vornicus> | Is that even a thing, or are you just stringing strange words together |
| 03:40 | <&Derakon> | It's a cell organelle. |
| 03:40 | <&Derakon> | IIRC it's a sort of assembly framework for proteins. |
| 03:40 | <~Vornicus> | Aha |
| 03:41 | <&Derakon> | My second guess was "emergency room". |
| 03:43 | <~Vornicus> | yeah no. Entity Relationship |
| 03:43 | <~Vornicus> | which are those boxes & arrows descriptions of databases. |
| 03:44 | < Reiv> | Oh no, I know that one too |
| 03:44 | < Reiv> | Vornicus: When did you do that |
| 03:44 | < Reiv> | ... oh that's right you did too haha |
| 03:44 | < Reiv> | How the tables have turned~ |
| 03:45 | < Reiv> | (not really, but hush I don't get to be the Wisened One very often) |
| 04:35 | | VirusJTG [VirusJTG@Nightstar-6i5vf7.sta.comporium.net] has quit [Connection closed] |
| 04:54 | | Turaiel is now known as Turaiel[Offline] |
| 05:08 | | Derakon is now known as Derakon[AFK] |
| 05:13 | | Orthia [orthianz@Nightstar-1od.f1k.224.119.IP] has quit [Ping timeout: 121 seconds] |
| 05:26 | | Vornicus [vorn@ServerAdministrator.Nightstar.Net] has quit [[NS] Quit: Leaving] |
| 05:45 | | macdjord [macdjord@Nightstar-r9vt2h.mc.videotron.ca] has quit [Ping timeout: 121 seconds] |
| 05:48 | | Checkmate [Z@Nightstar-pdi1tp.customer.tdc.net] has quit [Ping timeout: 121 seconds] |
| 05:48 | | macdjord [macdjord@Nightstar-r9vt2h.mc.videotron.ca] has joined #code |
| 05:49 | | mode/#code [+o macdjord] by ChanServ |
| 06:00 | | Kindamoody[zZz] is now known as Kindamoody |
| 06:06 | | Orthia [orthianz@Nightstar-1od.f1k.224.119.IP] has joined #code |
| 06:06 | | mode/#code [+o Orthia] by ChanServ |
| 07:16 | | celticminstrel [celticminst@Nightstar-de4ll6.dsl.bell.ca] has quit [[NS] Quit: And lo! The computer falls into a deep sleep, to awake again some other day!] |
| 07:45 | | Checkmate [Z@Nightstar-484uip.cust.comxnet.dk] has joined #code |
| 07:45 | | mode/#code [+o Checkmate] by ChanServ |
| 08:07 | | Kindamoody is now known as Kindamoody|afk |
| 08:15 | | Red_Queen [Z@Nightstar-484uip.cust.comxnet.dk] has joined #code |
| 08:15 | | mode/#code [+o Red_Queen] by ChanServ |
| 08:15 | | Checkmate [Z@Nightstar-484uip.cust.comxnet.dk] has quit [Connection closed] |
| 12:01 | | Orthia [orthianz@Nightstar-1od.f1k.224.119.IP] has quit [Ping timeout: 121 seconds] |
| 12:04 | | VirusJTG [VirusJTG@Nightstar-6i5vf7.sta.comporium.net] has joined #code |
| 12:06 | | Orthia [orthianz@Nightstar-6er.o7s.224.119.IP] has joined #code |
| 12:06 | | mode/#code [+o Orthia] by ChanServ |
| 13:41 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has quit [Ping timeout: 121 seconds] |
| 14:17 | | Orthia [orthianz@Nightstar-6er.o7s.224.119.IP] has quit [Ping timeout: 121 seconds] |
| 14:22 | | Orthia [orthianz@Nightstar-n2d7kk.callplus.net.nz] has joined #code |
| 14:22 | | mode/#code [+o Orthia] by ChanServ |
| 15:01 | | EvilDarkLord [jjlehto3@Nightstar-evu5hu.org.aalto.fi] has quit [Connection closed] |
| 15:59 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has joined #code |
| 16:00 | | mode/#code [+o himi] by ChanServ |
| 16:16 | | celticminstrel [celticminst@Nightstar-de4ll6.dsl.bell.ca] has joined #code |
| 16:16 | | mode/#code [+o celticminstrel] by ChanServ |
| 16:41 | | Orthia [orthianz@Nightstar-n2d7kk.callplus.net.nz] has quit [Ping timeout: 121 seconds] |
| 16:45 | | Orthia [orthianz@Nightstar-ola.g3b.224.119.IP] has joined #code |
| 16:46 | | mode/#code [+o Orthia] by ChanServ |
| 16:48 | <@Tarinaky> | http://www.deadcoderising.com/java-8-no-more-loops/ |
| 16:52 | | Orthia [orthianz@Nightstar-ola.g3b.224.119.IP] has quit [Ping timeout: 121 seconds] |
| 16:56 | | Orthia [orthianz@Nightstar-6er.o7s.224.119.IP] has joined #code |
| 16:56 | | mode/#code [+o Orthia] by ChanServ |
| 17:02 | <&ToxicFrog> | Tarinaky: "the thing I hate about Java is having to write all these loops", said no-one ever~ |
| 17:06 | <@Tarinaky> | Still. This is still an interface you need to know if you do any serious work in Java ever. |
| 17:06 | <@Tarinaky> | Since these are features even C++ has now-a-days |
| 17:07 | <@celticminstrel> | Some of them C++ has had almost forever. |
| 17:07 | <@celticminstrel> | Like method references and <algorithm> |
| 17:07 | <@celticminstrel> | Lambdas of course are newer. |
| 17:08 | <@Tarinaky> | okay, I didn't know about <algorithm> |
| 17:08 | <@Tarinaky> | Neat |
| 17:11 | <@celticminstrel> | ...seriously? |
| 17:11 | <@celticminstrel> | What about <numeric>? |
| 17:11 | <@Tarinaky> | Nope |
| 17:11 | <@celticminstrel> | Those two are the template algorithm headers, I think. |
| 17:12 | <@celticminstrel> | Do you actually use C++? |
| 17:12 | <@Tarinaky> | Scarily, yes. |
| 17:12 | <@celticminstrel> | Scarily indeed. |
| 17:12 | <@Tarinaky> | Although /oestensibly/ it's all written in Ruby. |
| 17:12 | <@celticminstrel> | Hm? |
| 17:12 | <&ToxicFrog> | Tarinaky: it is, but thankfully I don't actually do any work in Java these days. |
| 17:12 | <@Tarinaky> | And then I have to use C++ for what I can't do in Ruby |
| 17:13 | <@Tarinaky> | Which is mostly just straight forward stuff. |
| 17:14 | <@celticminstrel> | I see. |
| 17:14 | <@Tarinaky> | "Oestensibly written in LISP, but hacked together in PERL." xkcd on reality. |
| 17:19 | <@Tarinaky> | <numeric> is a bit weird and I'm not sure I get some of these functions. |
| 17:27 | <@Tarinaky> | I'll be sure to keep <algorithm> in mind in future. |
| 17:27 | <@celticminstrel> | I don't think I use <numeric> much. Though occasionally I use accumulate... I think that's in <numeruc>? |
| 17:27 | <@celticminstrel> | ^numeric |
| 17:27 | <@Tarinaky> | Yeah, accumulate is straight forward. |
| 17:27 | <@Tarinaky> | And I guess iota is good for initialising arrays? |
| 17:27 | <@celticminstrel> | I keep thinking max/min are in <numeric>, but they're actually in <algorithm>. |
| 17:27 | <@Tarinaky> | If... you do that a lot... |
| 17:28 | <@celticminstrel> | Oh, that one's new. I didn't know about that one. |
| 17:28 | <@Tarinaky> | I'm not sure it's actually clearer than typing out int a[10] = { 0,1,2,3,4,5,6,7,8,9 } though. |
| 17:29 | <@celticminstrel> | It's not. |
| 17:29 | <@Tarinaky> | But I'm sure it's a good way to look clever :P |
| 17:29 | <@celticminstrel> | But what if your array was 10000 elements long? |
| 17:30 | <@Tarinaky> | Then you /probably/ have SQL so4mewhere in your stack~ |
| 17:30 | <@celticminstrel> | I don't see what's so strange about the functions in <numeric>... |
| 17:30 | <@celticminstrel> | Inner product is a generalization of vector dot products. |
| 17:30 | <@celticminstrel> | (That's mathematical vector, not std::vector.) |
| 17:31 | <@Tarinaky> | (I know what a vector is) |
| 17:31 | <@celticminstrel> | Partial sum is pretty straightforward, though I don't know what it would be useful for. |
| 17:31 | <@celticminstrel> | Same with adjacent difference. |
| 17:31 | <@Tarinaky> | The way inner_product is described is confusing and, if I understand what it says, counter-intuitive. |
| 17:32 | <@Tarinaky> | They're all very situational. |
| 17:33 | <@Tarinaky> | It says it calculates the inner-product of the fence-post pairs of values in the collection. |
| 17:33 | <@Tarinaky> | Then sums that fence-post collection. |
| 17:34 | <@celticminstrel> | I have no idea what that means. |
| 17:34 | | gizmore [kvirc@Nightstar-40g2pn.pools.vodafone-ip.de] has joined #code |
| 17:34 | <@Tarinaky> | Where inner-produce and sums can actually be arbitrary functions. |
| 17:34 | <@Tarinaky> | Because Templates |
| 17:34 | <@celticminstrel> | Yeah, there's the overload that takes binary operators. |
| 17:35 | <@celticminstrel> | Oh hey, there's a <system_error> header... I wonder if I can use that to replace strerror somehow...3 |
| 17:36 | <@Tarinaky> | celticminstrel: If you have some list x then the fence-post pairs are a list one shorter than the original list formed of ordered pairs of the form y_n = (x_n, x_(n+1)) |
| 17:36 | <@Tarinaky> | I don't know what the proper name for that is |
| 17:36 | <@celticminstrel> | Ah. |
| 17:36 | <@Tarinaky> | But I imagine the planks of wood between fence posts |
| 17:38 | <@Tarinaky> | Whereas my intuition expects a function called inner_product to take two collections as inputs. |
| 17:38 | <@celticminstrel> | That's what it does though? |
| 17:39 | <@celticminstrel> | Though the collections are expressed as iterators. |
| 17:39 | <@Tarinaky> | If it is then the documentation is confusing. |
| 17:39 | <@celticminstrel> | In fact you could pass two portions of the same collection. |
| 17:40 | | * Tarinaky has another look |
| 17:40 | <@celticminstrel> | The documentation I was looking at didn't say anything about fence-posts. |
| 17:40 | <@Tarinaky> | You're right, reading it again. |
| 17:43 | <@Tarinaky> | That's more useful. |
| 17:44 | <@Tarinaky> | Does C++ have zip and map yet? :P |
| 17:45 | <@celticminstrel> | I think it has map somewhere in <algorithm>? |
| 17:45 | <@Tarinaky> | map is transform. |
| 17:45 | | * celticminstrel nods. |
| 17:45 | <@celticminstrel> | I don't think it has zip though. |
| 17:45 | <@Tarinaky> | zip could be implemented using inner_product, but that'd be silly |
| 17:46 | <@celticminstrel> | Oh? |
| 17:50 | <@Tarinaky> | Well if you replace the inner product function with one that creates a tuple and the accumulate function with an identity function. |
| 17:50 | <@Tarinaky> | Although this does require doing horrible things to type signatures |
| 17:50 | <@Tarinaky> | I said it'd be silly. |
| 17:51 | <@celticminstrel> | Remind me what zip does? |
| 17:51 | <@Tarinaky> | Takes two lists as input and returns a single list of ordered pairs. |
| 17:51 | <@Tarinaky> | z(n) = (x(n),y(n)) |
| 17:53 | <@celticminstrel> | So... something like inner_product(list1.begin(), list1.end(), list2.begin(), vector(), bind(&vector::push_back, _1, _2), make_pair) |
| 17:54 | | * celticminstrel isn't sure that bind call will actually work though. |
| 17:54 | <@Tarinaky> | I'm affraid I need to be getting back to work |
| 17:54 | <@celticminstrel> | 'kay |
| 17:55 | <@celticminstrel> | Oh, you'd need to specify the vector's template arguments. |
| 17:56 | <@celticminstrel> | Which would be <pair<T,T>> where T is the value_type of the lists. |
| 17:56 | <@celticminstrel> | ie decltype(list1)::value_type |
| 18:07 | <@Tarinaky> | It's be easier to just write zip from scratch. |
| 18:28 | <@celticminstrel> | Would it? |
| 18:29 | | gnolam_ [lenin@Nightstar-t1tbf0.cust.bahnhof.se] has joined #code |
| 18:30 | <@celticminstrel> | Actually, you could probably implement it better with transform(list1.begin(), list1.end(), list2.begin(), outlist.begin(), make_pair) |
| 18:30 | <@celticminstrel> | Though that requires you to first set up the output list. |
| 18:30 | <@celticminstrel> | Maybe replace outlist.begin() with inserter(outlist, outlist.begin()) |
| 18:31 | | gnolam [lenin@Nightstar-t1tbf0.cust.bahnhof.se] has quit [Ping timeout: 121 seconds] |
| 18:31 | | gnolam_ is now known as gnolam |
| 18:31 | | mode/#code [+o gnolam] by ChanServ |
| 18:37 | <@celticminstrel> | What's with TinyXML not supporting STL? They even claim this is an advantage. |
| 18:38 | <@celticminstrel> | (TinyXML2, technically.) |
| 18:48 | <@Tarinaky> | celticminstrel: Compared to torturing inner_product into being zip; yes writing zip from scratch would be. |
| 18:48 | <@Tarinaky> | Transform works though. |
| 19:17 | <@Tarinaky> | celticminstrel: STL can be a little awkward to extend and compiler errors are counter-intuitive. |
| 19:17 | <@Tarinaky> | And by extend I mean add a new collection type with iterators and all the rest, I don't just mean composition. |
| 19:18 | <@Tarinaky> | Hmm... |
| 19:18 | <@Tarinaky> | What's the difference between for_each and unary transform? |
| 19:20 | <@celticminstrel> | for_each doesn't do anything with the passed function's return value. |
| 19:20 | <@Tarinaky> | Oh nm |
| 19:20 | <@Tarinaky> | I see. |
| 19:21 | <@Tarinaky> | for_each is in-place while Transform creates an output list. |
| 19:21 | <@celticminstrel> | Not quite. |
| 19:21 | <@celticminstrel> | I think transform could also be done in-place? |
| 19:21 | <@Tarinaky> | Well, yes. |
| 19:21 | <@Tarinaky> | But you shouldn't |
| 19:22 | <@Tarinaky> | There's no point discarding the return value of a function if the function doesn't have some implied side-effect |
| 19:22 | <@celticminstrel> | for_each doesn't transform anything. |
| 19:22 | <@Tarinaky> | Unless the function does. |
| 19:22 | <@celticminstrel> | Though of course the function you pass could. |
| 19:22 | <@celticminstrel> | Yes that. |
| 19:24 | <@Tarinaky> | If the function doesn't transform anything then what was the point :P |
| 20:54 | | Kindamoody|afk is now known as Kindamoody |
| 21:53 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has quit [Connection closed] |
| 21:56 | | celticminstrel [celticminst@Nightstar-de4ll6.dsl.bell.ca] has quit [Ping timeout: 121 seconds] |
| 22:06 | | celticminstrel [celticminst@Nightstar-de4ll6.dsl.bell.ca] has joined #code |
| 22:06 | | mode/#code [+o celticminstrel] by ChanServ |
| 22:23 | | mac [macdjord@Nightstar-r9vt2h.mc.videotron.ca] has joined #code |
| 22:23 | | mode/#code [+o mac] by ChanServ |
| 22:26 | | macdjord [macdjord@Nightstar-r9vt2h.mc.videotron.ca] has quit [Ping timeout: 121 seconds] |
| 22:29 | <&McMartin> | It occurs to me that the tail-call optimization is literally calling up what you cannot put down |
| 22:32 | | Nat0 [Jbone@Nightstar-ptgjic.customer.broadstripe.net] has joined #code |
| 23:00 | | EvilDarkLord [jjlehto3@Nightstar-evu5hu.org.aalto.fi] has joined #code |
| 23:21 | | Kindamoody is now known as Kindamoody[zZz] |
| 23:25 | | himi [fow035@Nightstar-dm0.2ni.203.150.IP] has joined #code |
| 23:25 | | mode/#code [+o himi] by ChanServ |
| 23:26 | | Red_Queen [Z@Nightstar-484uip.cust.comxnet.dk] has quit [Operation timed out] |
| 23:33 | | Vornicus [vorn@ServerAdministrator.Nightstar.Net] has joined #code |
| 23:33 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
| --- Log closed Tue Jan 13 00:00:37 2015 |