| --- Log opened Tue Jan 13 00:00:37 2015 |
| 00:14 | | Derakon[AFK] is now known as Derakon |
| 00:24 | <&McMartin> | Also, ugh |
| 00:24 | <&McMartin> | This is my third straight day of shotgun-debugging UI code |
| 00:24 | | * McMartin switches his desktop background back to the Ikaruga NO REFUGE screenshot. |
| 00:24 | <@celticminstrel> | Shotgun-debugging? |
| 00:25 | <&Derakon> | CM: "maybe it's this code here. Nope, that wasn't it. Maybe it's this other code over here", etc. |
| 00:25 | <&Derakon> | As opposed to more methodical methods. |
| 00:25 | <&McMartin> | Well |
| 00:25 | <&McMartin> | It's still methodical |
| 00:25 | <&McMartin> | It's systematically going through all the things that can go wrong, altering them in ways that could be relevant, and seeing if it affects the bug |
| 00:25 | <&Derakon> | It can save a lot of time...if your guesses are reasonably close. :) |
| 00:26 | <&McMartin> | If the changes do exactly what I expect - and so far they have - then it removes a whole class of things |
| 00:26 | <&McMartin> | ... there are many, many classes of things |
| 00:26 | <&Derakon> | Speaking of many classes. |
| 00:26 | <&Derakon> | Today I inverted our class organization. |
| 00:27 | <&McMartin> | Up next: Rotate 90 degrees, translate to Haskell~ |
| 00:27 | <&Derakon> | Previously we'd had an "api" package, and everything else was the internal code. |
| 00:27 | <&Derakon> | Now all of the internal code is placed in various "internal" packages (e.g. "display/internal", "data/internal", etc.) and the api is everything else. |
| 00:27 | <&Derakon> | This involved moving literally every file in the core program. |
| 00:27 | <&Derakon> | The diff was 6000 lines long; the output of "git status" was 700. |
| 00:28 | <@celticminstrel> | I'm in the middle of refactoring right now. :/ |
| 00:29 | | Nat0 [Jbone@Nightstar-ptgjic.customer.broadstripe.net] has quit [[NS] Quit: Leaving] |
| 00:30 | <&McMartin> | Anyway, yeah. My new wallpaper until things sort out: https://hkn.eecs.berkeley.edu/~mcmartin/screenshots/no_refuge.jpg |
| 01:03 | | * Vornicus pokes vaguely at Reiv |
| 01:08 | < Reiv> | Vorn! |
| 01:09 | < Reiv> | Did you sketchy a diagram |
| 01:10 | <~Vornicus> | city_connection (gameID, mapID, regionID, cityID, userID, order) fk (gameID, mapID) --> game, fk (mapID, regionID, cityID) --> city, fk (gameID, mapID, regionID) --> active_regions, fk (gameID, userID) --> players I think covers all the bases |
| 01:11 | <~Vornicus> | I don't have ERD sketching tools |
| 01:14 | <~Vornicus> | oh, also unique (gameID cityID userID), unique (gameID cityID order) |
| 01:16 | <~Vornicus> | ...with map®ion in both of those... |
| 01:17 | < Reiv> | https://www.draw.io/ |
| 01:18 | < Reiv> | Are these the many:Many tables then |
| 01:20 | <~Vornicus> | this is the table I was struggling with |
| 01:20 | <~Vornicus> | it's got a *lot* of connections. |
| 01:21 | < Reiv> | I will agree |
| 01:21 | < Reiv> | Remind me precisely which bit a city_connection is |
| 01:22 | < Reiv> | If it isthe bit I think it is, I suspect this has too many connections |
| 01:22 | <~Vornicus> | City Connection is "the player has purchased a connection to this city" |
| 01:23 | <~Vornicus> | The keys are: "must be on the map for this game", "must be a city on this map", "must be in a region that this game is playing in", "must be a player in this game" |
| 01:23 | <~Vornicus> | Then the uniques are "must be the only connection this player has to this city" and "must be the only connection of this order for this city" |
| 01:24 | <~Vornicus> | I guess that first key is redundant with the region one |
| 01:25 | < Reiv> | A connection, eh |
| 01:25 | < Reiv> | Oh, you mean "put a brick house thingy on the board" right? |
| 01:25 | <~Vornicus> | Right |
| 01:26 | < Reiv> | OK, you've got too many links in the initial set, yeah |
| 01:27 | < Reiv> | What is regionID and cityID ? |
| 01:28 | <~Vornicus> | regionID and cityID are -- okay let me explain with an example |
| 01:28 | < Reiv> | I would alos be reluctant to have userID; I'd be inclined to have playerID instead (AKA player 1, 2, 3, 4, which link through game to Bob, Alice and Joe) |
| 01:29 | <~Vornicus> | the USA map is map 1; there are six regions, one of them is map 1 region 1, which I'll say is northeast; in that region there are 7 cities, of which one is map 1 region 1 city 1, which I'll say is New York. A lot of this is to make it so I can check the keys pretty easily. |
| 01:31 | < Reiv> | oh, right |
| 01:31 | < Reiv> | hm |
| 01:31 | <~Vornicus> | At game start, you select some number of regions (for 4 players, you typically select 4 regions) to play in |
| 01:31 | < Reiv> | oh yes I remember, OK |
| 01:31 | < Reiv> | I think that we've got overloaded tables here, and/or I've misunderstood the point |
| 01:32 | < Reiv> | You want to have a table state that tracks "Bob, who is Blue, placed the third Connection on Essen" |
| 01:32 | <~Vornicus> | These tables I've talked about are *only* those tables that are linked to city_connection. there's several other tables I haven't referenced yet |
| 01:32 | < Reiv> | You want to have a table state that tracks "Essen is spot #17 on the Germany Board; it is in the Central region." |
| 01:33 | <~Vornicus> | Right, that's the city table |
| 01:33 | < Reiv> | So city_connection is the gamestate of what's getting put into a city? |
| 01:34 | <~Vornicus> | Correct |
| 01:36 | < Reiv> | So it needs to track (cityID, playerID, gameID, order) fk(cityID) |
| 01:36 | < Reiv> | er, ignore the fk bit for the moment |
| 01:37 | < Reiv> | Pretty sure that's all it needs; you could stick in boardID for convinience, I guess, but it's not essential |
| 01:39 | < Reiv> | You know that you're in City #17 in Game #5, and Game #5 (game) tells you it's Germany (map), and in Germany, City #17 is Essen, with 3 slots and in the Central region (city). |
| 01:39 | <~Vornicus> | boardID and regionID I have noted down as "part of city's PK" actually~ |
| 01:39 | < Reiv> | boardID is good, regionID is not so much but eh whatever |
| 01:40 | < Reiv> | germany17 would be enough |
| 01:40 | < Reiv> | germanyCentral17 is overkill beyond convinience, and does that mean you also have a germanyNorth17 as well? |
| 01:40 | < Reiv> | Unless I misunderstand the rules, regions do not have massive turn-to-turn effects (with the possible exception of Korea) |
| 01:41 | < Reiv> | They're more about initial placement, yes? |
| 01:41 | <~Vornicus> | Several regions are nuclear-free |
| 01:41 | <~Vornicus> | You can't have a nuclear station unless you have cities outside those regions. |
| 01:41 | < Reiv> | Okay, but that still seems sensible to be a 'check region on the correct table' solution |
| 01:42 | < Reiv> | I wouldn't need the key for that so much; I still think one map with X cities is key enough. |
| 01:42 | < Reiv> | Because regions are inherently children of their map, so you're gaining nothing by the double-concatenation. |
| 01:43 | <~Vornicus> | Well there is also "you can only build cities on regions chosen active at the start of the game" |
| 01:44 | < Reiv> | Right, but again, that's a "Check region"; you'll be hitting that table for "maximum spots in city" anyway, right |
| 01:44 | < Reiv> | No harm in pulling out a couple columns in the process; again you don't want to be examining the key directly for it. |
| 01:45 | < Reiv> | All adding the region is doing is making a key longer, for no real gain |
| 01:45 | | * Reiv shrugs |
| 01:45 | < Reiv> | Concatenated keys are really best for many:many tables anyway |
| 01:45 | < Reiv> | Occasionally this means your key is the entire table |
| 01:46 | < Reiv> | (cityID,playerID,order) could make a pretty tidy PK for the city_connection table. |
| 01:47 | <~Vornicus> | Aha, yes, you're right |
| 01:48 | <~Vornicus> | I was going on the assumption that an FK was sufficient for all of my known restraints but it is not |
| 01:51 | < Reiv> | nope |
| 01:51 | < Reiv> | oops, no got that one wrong |
| 01:51 | < Reiv> | gameID,cityID,order would be the PK |
| 01:52 | < Reiv> | You could throw in playerID too, to save double-builds, I guess |
| 01:52 | < Reiv> | no wait that's terrible, ignore me |
| 01:53 | < Reiv> | you want either order or player, not both, and then you have to have a constraint on the other one anyway |
| 01:53 | < Reiv> | I would go gameID,cityID,playerID and leave Order to itself, because Order is less critical anyway and should be a sequence |
| 01:56 | < Reiv> | Game7EssenBlue is a useful unique. |
| 01:56 | < Reiv> | (These should really be numbers, but hey ho) |
| 01:56 | < Reiv> | (english is more intelligible at this point) |
| 01:56 | <~Vornicus> | oh ha ha ha, I'm sitting here and realized that it *is* possible to go full-fks-only, but I need Yet Another Table... |
| 01:56 | < Reiv> | Yes, you want two tables here |
| 01:56 | <~Vornicus> | (yeah, I know) |
| 01:56 | < Reiv> | One for which player in which game is in which spots |
| 01:57 | <~Vornicus> | ??? |
| 01:57 | < Reiv> | One for which city in which map is which spot |
| 01:57 | < Reiv> | and now the word 'which' is officially unintelligble to me |
| 01:59 | <~Vornicus> | I'm not sure what you're after now |
| 01:59 | <~Vornicus> | Understand that this structure I've given you is a mere segment of what's out there. |
| 02:00 | < Reiv> | I gather that |
| 02:00 | < Reiv> | We really should get some diagrams sketched~ |
| 02:00 | < Reiv> | Do you no longer have Visio? |
| 02:01 | <~Vornicus> | more along the lines of: Visio is on the Windows half of my machine, which requires half an hour and a system restore to boot |
| 02:03 | < Reiv> | ow, OK then |
| 02:03 | < Reiv> | Alas, I think we need diagrams to get very far here |
| 02:03 | < Reiv> | One builds to the diagram, else one drowns in the details whilst coding |
| 02:03 | <&McMartin> | dot |
| 02:03 | < Reiv> | dot? |
| 02:05 | <~Vornicus> | dot is a tool for drawing diagrams |
| 02:05 | <&McMartin> | a component of the graphviz package - a minilanguage for drawing diagrams |
| 02:06 | <~Vornicus> | Unfortunately I have no idea how to get it to do anything that I want it to do more complex than "connect these" |
| 02:10 | <&ToxicFrog> | If you want a GUI, xfig (powerful) or dia (user-friendly) |
| 02:10 | <~Vornicus> | How are they for ERDs |
| 02:13 | <&ToxicFrog> | I've never done ERDs with either. I know dia has prefab shapes and stuff for them, but neither has first-order awareness of ERD concepts AFAIK |
| 02:33 | <~Vornicus> | Technically, I could get back to just-keys with... two additional tables: city_slot (holds individual slots on teh city) and game_steps_passed (which tells you what steps of the game have passed); this... yeah. It gets ridiculously stupid |
| 02:35 | | Turaiel[Offline] is now known as Turaiel |
| 02:37 | < Reiv> | zefuck |
| 02:37 | < Reiv> | Does game_steps_passed have more than one row per game? |
| 02:38 | <~Vornicus> | Yeah, it's kind of silly like that~ |
| 02:38 | < Reiv> | what is it tracking |
| 02:40 | <~Vornicus> | There's three "steps" in Power Grid; step 1's the early game, when people don't have many cities; step 2 is the midgame, when the city count has grown past a certain number (7 for the leading player); step 3 is the late game, starting when the first cycle of plant offerings is exhausted. In step 1 you can only connect to the first slot on cities (the first two, on 4-spot cities in Japan); in step 2 you can connect to the second; in step 3 |
| 02:40 | <~Vornicus> | you get the third and final slot. |
| 02:43 | <~Vornicus> | adding them makes it possible to confirm city connections with only foreign keys: city slots are city,step,subindex; game steps passed are game,step; city connetions then are game,city,step,subindex,player, with the natural joins to those two |
| 02:43 | <~Vornicus> | It's completely ridiculousthough |
| 02:54 | <~Vornicus> | (you need subindex for japan only, as far as I am aware, but there are like 20 maps and I know rule quirks for maybe half of them) |
| 03:13 | <&McMartin> | Shotgun debugging session: A success! |
| 03:14 | <~Vornicus> | Woot |
| 03:14 | <&McMartin> | Of the two problems I was actively investigating, one is now flat-out solved and the other has isolated the bug to ten lines of straight-line code. |
| 03:14 | <&McMartin> | I call that a good day |
| 03:57 | < Reiv> | That's cute, but why is that an extra table instead of a column on Game ? |
| 03:58 | < Reiv> | Oh, yeah, step is good |
| 03:58 | < Reiv> | Though I don't know if it gets an entire table to it, it's a useful field to have. |
| 03:59 | < Reiv> | McMartin: straight-line code? |
| 03:59 | < Reiv> | So in your example Vorn, what's subindex? |
| 03:59 | <&McMartin> | Reiv: No loops or branches |
| 03:59 | <~Vornicus> | subindex is, well it's usually 1 |
| 03:59 | < Reiv> | McMartin: aha |
| 03:59 | < Reiv> | Real question: What is on the 'step' table that makes it a 1:many with Game? |
| 04:00 | <~Vornicus> | But for places where I need to distinguish between two slots that can both be occupied starting at the same step (Japan), it can have several different values |
| 04:00 | <~Vornicus> | game/1, game/2, game/3; it says what city segments can be occupied |
| 04:01 | < Reiv> | hm |
| 04:01 | < Reiv> | I dunno |
| 04:01 | <~Vornicus> | No, this isn't serious |
| 04:01 | < Reiv> | Surely a game progresses from 1 to 2 to 3 |
| 04:01 | <~Vornicus> | Usually. |
| 04:01 | < Reiv> | So you can just track current step as a column on Game |
| 04:02 | <&Derakon> | Can't the game logic derive what step you're in by examining the state of the board? |
| 04:02 | < Reiv> | And then have the CityConnections track which steps are full, with the maximum being the Game state |
| 04:02 | < Reiv> | Derakon: One imagines it does derive it, but storing a value somewhere explicitly is useful |
| 04:02 | < Reiv> | AKA the game works out when the thing ticks over, then writes it down. |
| 04:02 | < Reiv> | As for Japan: At what point do cities get simultaneous fillings? |
| 04:02 | <~Vornicus> | Der: ...technically, but it's hard - you need to get the highest number of cities for any player on the map, and also check to see whether the Step 3 card has been played |
| 04:02 | < Reiv> | Is it 1, 2, 4? Or 1, 3, 4? |
| 04:03 | <~Vornicus> | Reiv: understand this isn't a serious suggestion, this is "how it is possible but insane" |
| 04:03 | < Reiv> | It is insane, and I bet I can maintain the insanity without the sillyness :p |
| 04:03 | <~Vornicus> | But: Japan's large cities get 2 slots open in step 1, the third slot in step 2, and the fourth in step 3 |
| 04:03 | < Reiv> | Granted, not with a /natural/ join, but natural joins are made of the devil anyway |
| 04:03 | <~Vornicus> | All these so far are natural joins indeed. |
| 04:04 | < Reiv> | Oh, so you could declare that those cities have a step capacity of step+1 ? |
| 04:04 | <~Vornicus> | (the only one I don't have that luxury for, so far, is the links graph) |
| 04:04 | < Reiv> | Natural joins are the devil |
| 04:04 | < Reiv> | inner joins are sufficient |
| 04:04 | < Reiv> | left joins are awesome |
| 04:04 | < Reiv> | right joins are lazy |
| 04:04 | <~Vornicus> | Eh. Natural join is an inner join |
| 04:05 | < Reiv> | outer joins are nuts |
| 04:05 | <&Derakon> | IIRC thtere are boards that have cities with only step 2/3 slots in thtem, too. |
| 04:05 | <&Derakon> | Er, thtem. |
| 04:05 | <~Vornicus> | It just happens to be using (all the common fields) |
| 04:05 | < Reiv> | antijoins are awesome, if only they were allowed in more languages~ |
| 04:05 | <&Derakon> | ...fucking keyboard. |
| 04:05 | <&Derakon> | Or maybe it was steps 1/3 only. |
| 04:05 | <~Vornicus> | Der: madness |
| 04:05 | <&Derakon> | But yeah, I'd want to enumerate the cities precisely with their slots. |
| 04:05 | <~Vornicus> | I know Japan has smaller cities, but I don't know if they're all 1/2, or all 1/3, or a mixture |
| 04:05 | < Reiv> | Derakon: Yeah, I think that's the way to go |
| 04:05 | < Reiv> | And that can be done neatly enough |
| 04:05 | <~Vornicus> | Which actually, uh |
| 04:06 | <~Vornicus> | Is exactly what I was suggesting for half of this crazy join system |
| 04:06 | <&Derakon> | Or alternately, I guess you could have a "custom cities" table, and if a city isn't in that table then you assume it's a 1/1/1 city. |
| 04:06 | < Reiv> | Step and Capacity and lots of rows, whee |
| 04:06 | < Reiv> | Actually, Derakons idea is good too |
| 04:06 | < Reiv> | Actually, Derakons idea is best of the lot I think |
| 04:07 | <&Derakon> | The vast majority of cities are 1/1/1. |
| 04:07 | <&Derakon> | Except on the Japan map~ |
| 04:07 | < Reiv> | So, have types |
| 04:07 | <&Derakon> | Oh, yeah, duh. |
| 04:07 | < Reiv> | They can be id numbers, it don't matter |
| 04:07 | < Reiv> | Normal, or 1, or whatever, is your standard 1:1,2:2,3:3 |
| 04:08 | < Reiv> | Then you can have the alternatives join on different bindings for Huge, Small, 1and3, etc, whatever you want to call 'em |
| 04:08 | < Reiv> | And thus it neatly joins to everything, for when it matters, and you've maintained normalisation |
| 04:09 | < Reiv> | Or if it turns out this is a waste of time, just duplicate rows. Depends just how much data is in the city-connections table to start with. (I suspect Vorn would prefer proper normalisation, though.) |
| 04:10 | <~Vornicus> | the city connections table is not very much non-fk-ish data at all. "what round was this placed" if anything |
| 04:18 | <~Vornicus> | Oh, Japan has 1 1 2 3, 1 2, and 2 3 |
| 04:23 | <~Vornicus> | Which definitely suggests something explicit. My Extreme Normalization is probably not it~ |
| 04:26 | <~Vornicus> | But it has been a fun exercise seeing what I can do with it |
| 04:31 | <~Vornicus> | The biggest difficulty, and this is why there's a lot of places that are strained with it, is that an fk seems only able to look at one table. |
| 04:33 | <~Vornicus> | So things I'd want to be able to do, I can't do easily - I can't go "Tokyo is a megacity" and then show a generic "these are the slots in a megacity" and have that checkable via FK constraints |
| 04:33 | <~Vornicus> | or rather, have "blue has bought this slot in Tokyo" checkable via fk constraints |
| 04:38 | <~Vornicus> | similarly, this is what had me put "region" as part of a city's key; one of the game's constraints is "the region the city you're connecting to is in must be active in this game"; to make this a foreign key constraint, I have to have the region on the city connections table, and have it show up in the city table too |
| 04:43 | < Reiv> | Oh, small note |
| 04:43 | < Reiv> | You don't actually want to be rocking fk *restraints* too much |
| 04:43 | < Reiv> | fk restraints are a pain in the ass to work with in general terms |
| 04:43 | < Reiv> | Better to use rules. |
| 04:44 | < Reiv> | constraints are... finicky, usually. |
| 04:44 | <~Vornicus> | When you say rules -- do you mean the "on update" and "on delete" stuff, or |
| 04:44 | < Reiv> | p much |
| 04:44 | < Reiv> | And on joins |
| 04:44 | < Reiv> | You can do a lot on a join, if you avoid natural joins (which are awful) |
| 04:44 | < Reiv> | (mostly because one day you'll add a column to a table, and all of a sudden your query logic just got changed) |
| 04:45 | <~Vornicus> | Oh, I see |
| 04:45 | <~Vornicus> | so be explicit then |
| 04:45 | < Reiv> | Right |
| 04:45 | < Reiv> | Hence why natural joins are evil; they look the same until a column name changes~ |
| 04:45 | < Reiv> | At least with an inner join, the code will then *tell you off* because the two columns no longer match and you haven't updated the column name in the join decleration. |
| 04:45 | < Reiv> | If you can, use INNER JOIN table ON table.column = othertable.column |
| 04:46 | < Reiv> | That way it's all neat and tidy and easier to track (and copy+paste) |
| 04:46 | <~Vornicus> | guess this explains also why my usings get turn to ons when I plug it into a view and then pull it back out |
| 04:46 | < Reiv> | right |
| 04:46 | < Reiv> | use ons to start with |
| 04:46 | <~Vornicus> | (though why it sees fit to scope stuff all the way down to the schema, I'm not sure why) |
| 04:46 | < Reiv> | It makes the typing a little clunkier, but makes the code more maintainable in the long run |
| 04:47 | < Reiv> | And if you're hand-typing the suckers then you get to choose intelligent aliases etc too |
| 04:47 | < Reiv> | Else you end up with autogenerated code full of T1.whatever |
| 04:47 | < Reiv> | And that's just ugly >_> |
| 04:48 | < Reiv> | It also grants you the power of using LEFT JOIN and its various trickery without needing to suddenly rewrite the whole bloody line |
| 04:48 | < Reiv> | LEFT JOIN, properly written, can include antijoins, after all, and that's always fun |
| 04:48 | <~Vornicus> | Left join is my friend |
| 04:48 | < Reiv> | v. |
| 04:49 | < Reiv> | So yeah, skip the NATURAL JOINS, they're a false economy, and fk constraints are usually solving a problem the hard way |
| 04:49 | < Reiv> | better to do it via joins or code; keep fk constraints for "Fucking this up will break something", not "We are implementing game logic here" |
| 04:49 | | * Vornicus has used the "select ifnull(count(b_id),0), a_id from a left join b on a.a_id = b.a_id group by a_id" trick about 5 times in his current work project |
| 04:50 | < Reiv> | That's a good one |
| 04:50 | < Reiv> | I quite like the one I did the other day with forcing empty rows |
| 04:50 | < Reiv> | I then managed to script the display layer to only reveal rows which had a non-null primary key column |
| 04:50 | < Reiv> | So the 'filler' rows needed for the graphs didn't show up in the dynamic tables beneath. ^.^ |
| 04:51 | < Reiv> | Anyway, if all else fails, draw this stuff on a sheet of paper and photo it or something :P |
| 04:52 | | * Reiv heads home for the day. |
| 04:55 | <~Vornicus> | Simplifying this out it's pretty easy: city lives in region, region lives in map, city_connection hooks player and city together, city_type tells you whether a city is normal, large, small, or late |
| 04:55 | <~Vornicus> | or... something like that |
| 04:56 | <~Vornicus> | city has a city_type field; I don't know whether that hooks to something |
| 05:02 | <~Vornicus> | then game's got step round phase, player has user and game, and also things like money. player resources has the various resources, split out because it feels better; similarly you have player plants, which indexes into the plants collection; I also have the *actual* plants deck, which includes all the cards in the actual deck, indexed into the collection. This has an order; the market is all those with order 0, the deck is all the rest, |
| 05:02 | <~Vornicus> | when I push something back into the deck it gets max(order) + 1 as its order |
| 05:04 | <~Vornicus> | and when something gets dropped entirely (by being bought, discarded for being too small, or similar things) it just gets deleted from there |
| 05:05 | <~Vornicus> | Think I keep track of turn order on the players |
| 05:09 | | Derakon is now known as Derakon[AFK] |
| --- Log closed Tue Jan 13 05:19:44 2015 |
| --- Log opened Tue Jan 13 05:27:01 2015 |
| 05:27 | | TheWatcher [chris@Nightstar-ksqup0.co.uk] has joined #code |
| 05:27 | | Irssi: #code: Total of 39 nicks [15 ops, 0 halfops, 0 voices, 24 normal] |
| 05:27 | | mode/#code [+o TheWatcher] by ChanServ |
| 05:27 | | Irssi: Join to #code was synced in 38 secs |
| 05:28 | | AverageJoe [evil1@Nightstar-2ofrtr.ph.cox.net] has joined #code |
| 05:39 | | Vornicus [vorn@ServerAdministrator.Nightstar.Net] has quit [[NS] Quit: Leaving] |
| 05:58 | | AverageJoe [evil1@Nightstar-2ofrtr.ph.cox.net] has quit [[NS] Quit: Leaving] |
| --- Log closed Tue Jan 13 06:04:22 2015 |
| --- Log opened Tue Jan 13 06:11:38 2015 |
| 06:11 | | TheWatcher [chris@Nightstar-ksqup0.co.uk] has joined #code |
| 06:11 | | Irssi: #code: Total of 39 nicks [16 ops, 0 halfops, 0 voices, 23 normal] |
| 06:11 | | mode/#code [+o TheWatcher] by ChanServ |
| 06:12 | | Irssi: Join to #code was synced in 38 secs |
| 06:31 | | himi [fow035@Nightstar-dm0.2ni.203.150.IP] has quit [Ping timeout: 121 seconds] |
| 06:52 | | 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!] |
| 06:56 | | celticminstrel [celticminst@Nightstar-de4ll6.dsl.bell.ca] has joined #code |
| 06:56 | | mode/#code [+o celticminstrel] by ChanServ |
| 07:05 | | 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!] |
| 08:02 | | Kindamoody[zZz] is now known as Kindamoody |
| 08:57 | | Orthia [orthianz@Nightstar-6er.o7s.224.119.IP] has quit [Ping timeout: 121 seconds] |
| 08:59 | | Orthia [orthianz@Nightstar-i3tgud.callplus.net.nz] has joined #code |
| 08:59 | | mode/#code [+o Orthia] by ChanServ |
| 09:46 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has joined #code |
| 09:46 | | mode/#code [+o himi] by ChanServ |
| 10:25 | | Kindamoody is now known as Kindamoody|afk |
| 12:16 | < abudhabi> | Dammit. |
| 12:16 | < abudhabi> | I'm investigating switching over from GlassFish to WildFly. |
| 12:16 | < abudhabi> | But I can't for the life of me figure out how to do a custom JNDI resource (java.util.Properties) thing under WildFly. |
| 12:35 | | * abudhabi also fights massive drowsiness. |
| 13:28 | <@Tarinaky> | Stupid question. |
| 13:28 | <@Tarinaky> | If I take a C++ iterator |
| 13:28 | <@Tarinaky> | And I add 2 to it |
| 13:28 | <@Tarinaky> | That's an iterator right? |
| 13:28 | <@Tarinaky> | it+2 is of type iterator? |
| 13:31 | <@TheWatcher> | yes |
| 13:33 | <@Tarinaky> | so someVector.begin()+2 is the third element? |
| 13:38 | <@TheWatcher> | yep |
| 13:41 | | * Tarinaky tries to make use of <algorithm> to solve a problem and expand knowledge |
| 13:48 | <@Tarinaky> | Yay lambdas |
| 14:18 | | * Tarinaky complains loudly about UTF16 to anyone who'll listen |
| 14:37 | | * TheWatcher args, is about at the point where he's going to set up emacs to just autocorrect dov -> div |
| 14:38 | <@TheWatcher> | My HTML is full of dragons >.< |
| 14:45 | < abudhabi> | Why? |
| 14:47 | <@TheWatcher> | "Dov" translates as "Dragonkind" in the dragon language of TES games. |
| 14:53 | < abudhabi> | Make a keyboard shortcut that drives <div>. |
| 14:55 | | celticminstrel [celticminst@Nightstar-de4ll6.dsl.bell.ca] has joined #code |
| 14:55 | | mode/#code [+o celticminstrel] by ChanServ |
| 15:39 | | Checkmate [Z@Nightstar-484uip.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?] |
| 16:25 | | Turaiel[Offline] is now known as Turaiel |
| 16:35 | | Turaiel is now known as Turaiel[Offline] |
| 16:40 | | Turaiel[Offline] is now known as Turaiel |
| 16:55 | | Turaiel is now known as Turaiel[Offline] |
| 16:57 | | abudhabi is now known as Julius |
| 17:40 | | Checkmate [Z@Nightstar-484uip.cust.comxnet.dk] has joined #code |
| 17:40 | | mode/#code [+o Checkmate] by ChanServ |
| 19:40 | | Kindamoody|afk is now known as Kindamoody |
| 19:56 | | gizmore [kvirc@Nightstar-40g2pn.pools.vodafone-ip.de] has quit [[NS] Quit: KVIrc 4.3.1 Aria http://www.kvirc.net/] |
| 20:07 | | gizmore [kvirc@Nightstar-40g2pn.pools.vodafone-ip.de] has joined #code |
| 21:16 | < Reiv> | Vorn: Looks good. Are you storing the shuffled decks in each game in the database? |
| 21:17 | < Reiv> | If so you need an intermediate table for Deck, that goes between Plants and Game and stores order of the deck for each game. |
| 21:50 | | Kindamoody is now known as Kindamoody[zZz] |
| 22:23 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has quit [Ping timeout: 121 seconds] |
| 22:25 | | Vorntastic [Vorn@Nightstar-k70f1n.ct.comcast.net] has joined #code |
| 22:28 | < Vorntastic> | Reiv! Two things: 1. I have discovered that my knowledge of that count trick was incomplete; I did not until today know how to filter the things I am counting |
| 22:28 | < Vorntastic> | Second, you mentioned earlier that the undirected graph makes life easier but I don't see how; could you enlighten me? |
| 22:30 | < Vorntastic> | Oh, and yeah, there's deck and deck template or something. |
| 22:31 | < Vorntastic> | There's several primary decks; in addition some maps come with additional cards that shuffle in (Scandinavia replaces certain plants based on the chosen regions, for instance) |
| 22:37 | < Reiv> | undirected graph? |
| 22:38 | < Reiv> | Right, so clearly you have a Play Deck and you have a Card Stock or something, with a key noting which cards go where and a special rules column alongside |
| 22:38 | < Reiv> | eg, "GERMANY" "STANDARD" vs "SCANDINAVIA" "EXCLUDESOUTH" or something, or whatever |
| 22:39 | < Vorntastic> | A little less involved, but yes. |
| 22:39 | < Vorntastic> | Undirected graph: links between cities are undirected, weighted graph (as in graph theory) edges. |
| 22:41 | < Vorntastic> | I need to be able to pull the whole graph in the active regions so I can get the distance grid. |
| 22:41 | < Vorntastic> | You said it was easier than possibly including one-way edges but I don't believe you. |
| 22:41 | | * McMartin figures out why his build is failing |
| 22:41 | <&McMartin> | It's because something is killing the compiler! |
| 22:41 | | * McMartin octuples that VM's RAM. |
| 22:42 | < Vorntastic> | Anyway time to go home. You can tell the second sight. |
| 22:48 | | Vornlicious [Vorn@Nightstar-goodrv.sub-70-215-13.myvzw.com] has joined #code |
| 22:52 | | Vorntastic [Vorn@Nightstar-k70f1n.ct.comcast.net] has quit [Ping timeout: 121 seconds] |
| 22:53 | | Kindamoody[zZz] [Kindamoody@Nightstar-966hb4.mobileonline.telia.com] has quit [Ping timeout: 121 seconds] |
| 22:55 | | Vornlicious [Vorn@Nightstar-goodrv.sub-70-215-13.myvzw.com] has quit [[NS] Quit: Bye] |
| 23:20 | | Vornicus [vorn@ServerAdministrator.Nightstar.Net] has joined #code |
| 23:20 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
| 23:21 | < Reiv> | Vornicus: I spoke nothing of one-way edges, I have no idea what you're talking about |
| 23:21 | < Reiv> | I'm also mildly puzzled as to what you're trying to do with these distance grid stuff |
| 23:21 | < Reiv> | Do you mean "To make things line up neatly on the map" |
| 23:22 | <~Vornicus> | No |
| 23:23 | < Reiv> | OK |
| 23:24 | <~Vornicus> | Like: it costs, if you've got a connection in, say, San Francisco, then buying a connection to Las Vegas costs 14 (plus the costs for actually building the connection itself) |
| 23:25 | < Reiv> | oh right yes |
| 23:26 | < Reiv> | I'm not convinced as to the best way to store such data. It's pretty horrible no matter what you do. |
| 23:26 | < Reiv> | Anyway, now I know what you mean by directional edges |
| 23:27 | < Reiv> | First question: How would you store spatial graphs in a program? |
| 23:29 | <~Vornicus> | Usually my spatial graph is something like: {'Seattle': {'Billings': 9, 'Boise': 12, 'Portland': 3}, 'Billings': {'Seattle': 9, 'Boise' 12}, 'Boise': {'Seattle': 12, 'Portland': 13, 'Billings': 12}, 'Portland': {'Boise': 13, 'Seattle': 3}} |
| 23:30 | <~Vornicus> | Then for the distance grid I'd apply Floyd-Warshall to get what's actually a complete graph with the correct minimal distances |
| 23:32 | <~Vornicus> | Now, I could, technically, store them one direction only |
| 23:32 | <~Vornicus> | The problem then becomes: I need to filter both sides for out-of-play cities |
| 23:33 | < Reiv> | oh, if that's how you're doing it, then go directional, sure |
| 23:33 | | jeroud [sid10043@Nightstar-a1k27g.irccloud.com] has quit [A TLS packet with unexpected length was received.] |
| 23:34 | < Reiv> | SEATTLE | BILLINGS | 9; SEATTLE | BOISE | 12 etc |
| 23:34 | < Reiv> | In writing it like so, you can actually skip the reverse if it is useful to do so |
| 23:34 | <~Vornicus> | It kind of is |
| 23:39 | < Reiv> | It's... something really stupid sounding, but works |
| 23:40 | | * Reiv tries to remember it off the top of his head |
| 23:40 | < Reiv> | oh yeah |
| 23:41 | <~Vornicus> | I guess for most I'd *need* to check both directions anyway; simply checking one would not give me anything sensible even if I did a.nodeID a.edgeID join b.nodeID b.edgeID on a.edgeID = b.edgeID and a.nodeID != b.nodeID, I'd still need to WHERE both B and A |
| 23:41 | < Reiv> | city as city_start INNER JOIN city as city_end ON city_start.start = city_end.end OR city_start.end = city_end.start |
| 23:41 | < Reiv> | I feel dirty every time I type that. Deliciously dirty. >_> |
| 23:42 | <~Vornicus> | I'm not sure what you just did |
| 23:43 | <~Vornicus> | Oh, that does "give me a sequence" sort of, but it doesn't work for generic graphs |
| 23:43 | < Reiv> | It's a self join between two columns, where you cannot gurantee which column should be 'first' |
| 23:44 | < Reiv> | It will give you all the cities joined up with each respective partner, in either direction, with the costs attached. The problem you will have is that when filtering it will need to be on two columns at once without further trickery. |
| 23:45 | < Reiv> | A marginally more robust, if vastly more complex method is to have routes and cities in two different tables, but then you end up with a rather nasty many:many table that joins neatly, but is hard to manually edit. |
| 23:47 | < Reiv> | SEATTLE | 19 ; SEATTLE | 20 ; BILLINGS | 19 ; BOISE | 20 etc |
| 23:47 | < Reiv> | And then you join on the second column and you get SEATTLE | BILLINGS; BILLINGS | SEATTLE; etc |
| 23:48 | < Reiv> | Er, those numbers were a key, not costs |
| 23:48 | <~Vornicus> | I caught that |
| 23:48 | < Reiv> | You probably have a whole other table for costs, or duplicate costs on every number-pair. |
| 23:48 | <~Vornicus> | THe other thing is, well |
| 23:48 | < Reiv> | I'm not sure which one is worse. :p |
| 23:49 | <~Vornicus> | The latter :P |
| 23:49 | < Reiv> | Ehhh |
| 23:49 | < Reiv> | It is fixable by running MAX(cost) on the number pair |
| 23:49 | <~Vornicus> | I did that node-edge thing up there, and yes, I would still have to WHERE both B and A |
| 23:49 | < Reiv> | Oh wait, is this to clean out regions etc? |
| 23:49 | <~Vornicus> | So it doesn't win me anything, and makes life terrib |
| 23:50 | <~Vornicus> | Yes |
| 23:50 | < Reiv> | Right, do my second solution |
| 23:50 | <~Vornicus> | seattle billings 9, seattle boise 12? |
| 23:50 | < Reiv> | Filter based on regions & map & etc in the CITY table before you join the CONNECTIONS table |
| 23:50 | < Reiv> | SEATTLE 19 ; SEATTLE 20 ; BILLINGS 19 ; BOISE 20 |
| 23:51 | < Reiv> | You can filter out all the BOISE's in one go if need be, y'see |
| 23:51 | <~Vornicus> | Still appear to need to apply the filter twice, unless you know how to, uh |
| 23:51 | < Reiv> | shouldn't do, it's an inner self join on the link table |
| 23:52 | < Reiv> | Filter out *before* you join to it |
| 23:52 | <~Vornicus> | but |
| 23:52 | <~Vornicus> | no, confused |
| 23:55 | < Reiv> | OK |
| 23:55 | < Reiv> | Your CONNECTIONS table has the City on one side, and then just a random key number thingy on the other |
| 23:56 | < Reiv> | You join CONNECTIONS to CONNECTIONS on that key, which causes a minor form of cross-join to happen, because there's two possible combinations for each pair of keys |
| 23:56 | < Reiv> | (SEATTLE | BOISE and BOISE|SEATTLE) |
| 23:57 | <~Vornicus> | Stop |
| 23:57 | <~Vornicus> | How do I filter and do this just once |
| 23:57 | < Reiv> | oh |
| 23:58 | <~Vornicus> | 'cause htis *still* as far as I can tell requires me to do the bit that filters on region on both city halves |
| --- Log closed Wed Jan 14 00:00:53 2015 |