search of the:   for: 
code logs -> 2011 -> Tue, 27 Dec 2011< code.20111226.log - code.20111228.log >
--- Log opened Tue Dec 27 00:00:29 2011
00:01 Reiver [orthianz@3CF3A5.E1CD01.C6689C.33956A] has joined #code
01:24
< ToxicFrog>
Hmm.
01:25
< ToxicFrog>
Possible _DEBUG check to add: have the client and server check each other's class heirarchies to make sure they match.
01:25 * McM[xmas] starts looking where the scalpel should go on this 1KLOC Python script.
01:48 Pigeon [NSwebIRC@Nightstar-27138e8c.res.rr.com] has joined #code
01:50 * Pigeon sets a stump with a harpoon in it down. This will do.
01:52
< Pigeon>
It sounded simple. Find a path through some random points, so that the distance between each was as short as it could be
01:55
< Pigeon>
Then I realized it was like the box lid folding problem. Where you can't fold all the flaps without sorta bending one. Or something like that.
02:16
< McM[xmas]>
Ha *ha*
02:16
< McM[xmas]>
dissection: success
02:17
< McM[xmas]>
Now my largest file is 386 lines, and that file is the one that will be eventually going away (it's the code generator that can't handle functions).
02:18
< Tamber>
\o/
02:19
< McM[xmas]>
The parser's gonna get bigger (it's 247 lines now) because it doesn't actually handle all the constructs I want to handle.
02:29
< McM[xmas]>
Oh man
02:29 * McM[xmas] makes a tangle with git.
02:31 Kindamoody[zZz] is now known as Kindamoody
02:31 Rhamphoryncus [rhamph@Nightstar-14eb6405.abhsia.telus.net] has joined #code
02:32 celticminstrel is now known as celmin|movie
02:32
< McM[xmas]>
Is there a way to create a bare respository and then have a totally different repo push to it?
02:33
< Tamber>
Y...es, if I'm thinking what you are.
02:33
< McM[xmas]>
Basically, I have a master directory that has bare repos of all my stuff so that I can get everything in one place, more or less.
02:33
< Tamber>
You just have to add the bare repository as a remote.
02:33
< McM[xmas]>
But that isn't the place where I edit it.
02:34
< Tamber>
(It'll take a directory path just as well as an URL, IIRC.)
02:34
< McM[xmas]>
Right
02:34
< McM[xmas]>
In this case it *is* a URL; I did a git init on a different machine while offline.
02:34
< Tamber>
Aha.
02:35
< Tamber>
Well, either way; it'll work.
02:35
< McM[xmas]>
Now to learn how to do remotes manually, I guess.
02:35
< Tamber>
(That's how you create repositories for gitweb.)
02:36
< Tamber>
"git remote add <name> <url>"
02:53 Stalker [Z@Nightstar-5aa18eaf.balk.dk] has quit [Ping timeout: 121 seconds]
02:58
< Ling>
-*- McM[xmas] starts looking where the scalpel should go on this 1KLOC Python script. <-- when I had a 17kLoC JS file to deal with I started with my boss' face (he wrote it)
02:59
< Ling>
Then I went for the PHP file that generated it.
03:03<~Vornicus> in js, huge files happen more naturally and occasionally are the only sensible way to do things.
03:04
< Ling>
I refactored it to 900LoC
03:04
< Ling>
Adding functionality and comments.
03:05 Attilla [Obsolete@Nightstar-d42c1553.as43234.net] has quit [Ping timeout: 121 seconds]
03:05<~Vornicus> Nice.
03:08<~Vornicus> Pigeon: when you say "the distance between each is as short as can be", I take it you want to minimize the maximum distance travelled in a single hop? you might wish to try to find the least spanning tree.
03:10
< Pigeon>
Yeah, that's it! ... oh, there's a thing for that? Hotdog! Thanks
03:11<~Vornicus> In fact I think (but cannot see an immediate proof) that this is optimal: each step in the standard least spanning tree algorithm creates the graph of all locations that can be moved between with a maximum inter-location distance of x.
03:15<~Vornicus> okay, yes, proven.
03:17<~Vornicus> The only time you reject an edge is when there's already a shorter edge that joins the two portions of the graph that the edge would join.
03:18 Stalker [Z@Nightstar-3602cf5a.cust.comxnet.dk] has joined #code
03:18
< Pigeon>
This is perfect!
03:27<~Vornicus> Once you've completed the tree, pathfinding on just the tree will give you the full details for any pair of points.
03:35<~Vornicus> If you don't have a distance metric, you don't need to worry about a cost function at all, because the distance doesn't tell you whether you're going the right direction. If you do, you might wish to use it to order your candidates a la A*
03:37 celmin|movie is now known as celticminstrel
03:38
< Pigeon>
I think distance was the only factor. Needed a way to connect random locations on a map without criss crossing or such
03:49
< McM[xmas]>
The prereq for this is that you can't have a cycle in your graph with a negative cost to run through
03:49
< McM[xmas]>
Because then there's no "shortest path", you just keep running the negative cycle forever, etc.
03:53<~Vornicus> No, that's total path
03:53<~Vornicus> We're looking for longest path segment minimization, so no individual path segment affects it, and there's no effect for negative-length cycles
04:28 Rhamphoryncus [rhamph@Nightstar-14eb6405.abhsia.telus.net] has quit [Client exited]
05:01 * McM[xmas] .
05:02
< McM[xmas]>
"yo momma so fat she sat on a binary tree and flattened it to a linked list in constant time"
05:02
< Tamber>
?
05:02
< Tamber>
...hee
05:07
< iospace>
..
05:07<~Vornicus>
05:08
< McM[xmas]>
I have weird friends on IM, what can I say
05:08 * iospace eyes McM[xmas]
05:08
< McM[xmas]>
What, you didn't think I'd receive a message like that and not pass it along.
05:09
< iospace>
yes but it doesn't exempt you from getting eyed
05:53 iospace is now known as iosleep
05:54 * McM[xmas] reads the git book, finds some things that appear to be Blatant Lies.
05:54
< McM[xmas]>
While it may be true at the repo-structure level, I find myself a bit skeptical of the claim that git has no concept of deltas.
05:55
< McM[xmas]>
My skepticism comes from the fact that one would expect merges to not work without this concept.
05:55
< Tamber>
Indeed.
05:57
< McM[xmas]>
It's also treating objects as atomic and equivalent to files, which I also find a bit unusual.
06:13
< McM[xmas]>
Since that would imply that if you make N revisions to a file, the space required in the repo is N * (length of file), with whatever your compression system can then give you.
06:23
< McM[xmas]>
Aha, I've found what I needed for this.
06:23
< McM[xmas]>
I need to do a local bare clone, and then copy that directory over into my Collection Of Repositories.
06:24
< McM[xmas]>
Then I can clone that wherever.
06:41 Kindamoody is now known as Kindamoody|out
07:16 Pigeon [NSwebIRC@Nightstar-27138e8c.res.rr.com] has quit [[NS] Quit: Page closed]
07:41
< McM[xmas]>
\o/
07:43 Vash [Vash@Nightstar-8697fea9.wlfrct.sbcglobal.net] has quit [[NS] Quit: I<3craft Vorn!]
08:05
< McM[xmas]>
Success
08:07 celticminstrel [celticminst@Nightstar-5d22ab1d.cable.rogers.com] has quit [[NS] Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
08:14 eckse [eckse@Nightstar-f2dd5891.dsl.sentex.ca] has quit [Client closed the connection]
08:21
< McM[xmas]>
Oh man
08:21 * McM[xmas] finds his old notes on this.
08:21
< McM[xmas]>
https://hkn.eecs.berkeley.edu/~mcmartin/retro/HLL/callstack.html
08:21
< McM[xmas]>
I'm not sure if this is genius or madness
08:21
< McM[xmas]>
But now I do want to do enough of this compiler to make it a reality.
08:22
< McM[xmas]>
Or prove it's horribly broken; that's OK too~
08:23
< himi>
McM[xmas]: git stores whole files in a content-addressable database - all the revision control is on top of that
08:24
< McM[xmas]>
himi: OK, that raises the question of how merging is sensible and how it doesn't bloat the everliving shit out of the repo.
08:24
< himi>
The assumption is that disk is cheap, so why bother with trying to save it
08:25
< McM[xmas]>
... because you regularly are slamming the whole repo over the network?
08:25
< himi>
Merging makes the assumption that most merges will be disjoint
08:25
< McM[xmas]>
Er
08:25
< McM[xmas]>
Yes, but.
08:25
< himi>
Ah, but the network protocol can be optimised via other means
08:25
< McM[xmas]>
If merges aren't within a file, they aren't really merges, and git is supposed to be better at this than its competitors.
08:25
< himi>
If git finds that the merge /isn't/ disjoint, then it basically falls back to some other means of dealing with it
08:26
< himi>
Hah
08:26
< McM[xmas]>
It's the "some other means" I'm curious about, because that's its primary non-workflow-related advantage over SVN/Perforce/etc.
08:26
< himi>
The actual merge algorithms are probably a little different between the various revision control systems, but if one system finds something that works better than others, that'll end up becoming the standard
08:27
< himi>
The big difference with git is that it doesn't track things above that content addressable level
08:27
< McM[xmas]>
This does not sound like a feature, as stated.
08:27
< himi>
So things like renames and cut and paste and so on aren't in any way tracked, whereas most other systems do track them
08:28
< himi>
Git uses stuff on top to deal with that sort of thing
08:28
< himi>
. . . and that's where I can't h elp you, because I don't use it a nd it's a /long/ time since I followed its development
08:28
< McM[xmas]>
Heh
08:28
< himi>
TF's the guy to talk to, I imagine
08:28
< McM[xmas]>
I'm mostly annoyed
08:28
< McM[xmas]>
er
08:29
< himi>
Git annoys me, so I use mercurial instead
08:29
< McM[xmas]>
I'm mostly annoyed because I'm trying to get a one-sentence summary of why - besides DVCS workflow improvements - git performs better than svn.
08:29
< himi>
But then, I'm not Linus and I don't want to submit patches to him ;-)
08:29 * himi nods
08:29
< McM[xmas]>
Literally every answer I have gotten to this at all expertise levels is some form of "git is magic"
08:29
< himi>
Git is targeted at a different kind of development model to subversion
08:30
< himi>
Not just the distributed vs centralised difference, though
08:30
< McM[xmas]>
Yes, those are the DVCS workflow things I'm explicitly eliding.
08:30
< McM[xmas]>
I also -_- at their incredible vitriol towards subversion and insistence that they are entirely fundamentally opposed to it, all its assumptions, all it stands for, by all evidence all its *keywords*...
08:30
< McM[xmas]>
... and can transparently interoperate with it in both directions
08:31
< himi>
The biggest difference is that git is targeted at a really broad and diverse development environment, where almost all the development is disjoint and the merging is pretty much a matter of making sure that files don't get trashed accidentally
08:31 * himi snickers
08:32
< himi>
Git grew out of the Linux devs being pissed off by the fact that no one in the VCS community thought they were doing things the right way
08:32
< himi>
It's probably inevitable that the git community is a bit touchy about the 'traditional' VCS
08:33
< McM[xmas]>
I was entertained when a bunch of them took the reignition of major svn development as a personal affront
08:33
< himi>
In general, anyone who insists that svn is teh ebil should be ignored . . .
08:33
< McM[xmas]>
If I do that I'll never figure out how to use git, and there are too many projects on github I can't ignore~
08:33
< himi>
I wouldn't use it unless I had to, but hey . . .
08:34
< himi>
True
08:34
< McM[xmas]>
Your statements imply that Mercurial has noticable philosophical differences in workflow from git.
08:34
< McM[xmas]>
This is news to me; can you elaborate?
08:34
< himi>
Oh hell yes
08:34
< McM[xmas]>
(I know very little of Mercurial)
08:34
< himi>
Mercurial is designed to be simple to use the way that CVS is simple to use
08:34
< McM[xmas]>
OK, so, I remember CVS, and SVN was a step down in complexity. You'll have to unpack that. ;-)
08:35
< himi>
Well, CVS/SVN
08:35
< himi>
CVS' complexity was mostly because it ended up trying to do stuff that wasn't really supportable by the underlying architecture
08:36
< himi>
But the basic workflow of a simple one-person CVS system was very simple
08:36
< himi>
(funny how CVS is now past tense . . . )
08:37
< McM[xmas]>
(It can't grasp the concept of versioning multiple files simultaneously - it cannot meet even its own stated workflows)
08:37
< himi>
Mercurial works as if you're dealing with a single-user CVS system, aside from the fact that it's got all the infrastructure needed for distributed development
08:37
< himi>
From a user perspective
08:39
< himi>
(architecturally mercurial uses a git-alike database storing log-structured version files with additional stuff to tie things into changesets - it's designed to be fast working from disk, though it also works out reasonably space-efficient)
08:40
< himi>
But at the top level it's basically just change files, check them in, pull in merges, sort out conflicts, etc, all much the same way that CVS/SVN does it
08:40
< himi>
Git explicitly decides to do things differently
08:41
< McM[xmas]>
Although in practice git appears to do things the same way
08:41
< McM[xmas]>
They just don't admit it officially.
08:41 * himi nods
08:42
< himi>
Hey, version control at the user interface level is pretty much a solved problem
08:42
< himi>
For all that git is revolutionary in some ways, it doesn't bring anything much genuinely new to the user experience
08:42
< McM[xmas]>
Smugness and opacity~
08:43
< himi>
heh
08:43
< himi>
It's also worth noting that there's a lot of convergence b etween the popular VCSes
08:43
< McM[xmas]>
I need to use Git because the people who actually use Ophis all seem to prefer it.
08:44
< himi>
Git is much nicer to use than it started out, because they've basically realised that people who /don't/ read LKML religiously might w ant to use it
08:44
< himi>
And mercurial has implemented a fair bit of stuff to make it work more like git, because there's genuine use for some of those features
08:44
< himi>
Anyway
08:45
< himi>
If you have to learn it I'd suggest talking with TF about actual use cases
08:45
< McM[xmas]>
I have, in the past, and have worked through the manuals multiple times.
08:46
< himi>
And it's still problematic?
08:46
< McM[xmas]>
However, I'm still not clear on how it does what it does and that's the part that interests me - but the parts that interest me seem to be glossed over with blatant lies or "it's magic, works simply but not being subversion"
08:46
< McM[xmas]>
*by not being
08:46 * himi nods
08:47
< McM[xmas]>
Well, in this case I needed to migrate a repository from one machine to another, so I needed to work out how to do this, which was simple enough (clone into a bare repository, scp it into place, re-clone it on client machine)
08:47
< McM[xmas]>
You can probably dick with remotes to skip the reclone, but meh.
08:48
< himi>
What functionality did you want explained?
08:49
< McM[xmas]>
What's different about merges that results in fewer conflicts from the "chain of patches from the same ancestor" approach SVN does.
08:49
< McM[xmas]>
It gets better results, but there's no explanation of what it does or why it's better.
08:50
< himi>
The big difference is that rather than assuming that the immediate ancestor file is the best parent to merge from, git tries to figure out what the nearest parent content wise is, and merges from that
08:51
< himi>
This is the big philosophical difference between git and everything else (almost)
08:51
< himi>
Git assumes nothing about relationships across versions - it figures all that out separately
08:52
< himi>
Exactly /how/ I don't know - that stuff w as implemented after I gave up on it and switched to mercurial
08:56
< himi>
It helps that the main target of git /is/ cases where changesets are almost always disjoint . . .
10:03 himi [fow035@Nightstar-5d05bada.internode.on.net] has quit [Operation timed out]
10:13 Attilla [Obsolete@Nightstar-d42c1553.as43234.net] has joined #code
10:15 Rhamphoryncus [rhamph@Nightstar-14eb6405.abhsia.telus.net] has joined #code
10:18 himi [fow035@Nightstar-5d05bada.internode.on.net] has joined #code
10:25 mode/#code [-o Tarinaky] by ChanServ
10:32 jeroid [jerith@687AAB.5E3E50.88B070.E2F330] has joined #code
10:39 Rhamphoryncus [rhamph@Nightstar-14eb6405.abhsia.telus.net] has quit [Ping timeout: 121 seconds]
10:41 Rhamphoryncus [rhamph@Nightstar-14eb6405.abhsia.telus.net] has joined #code
10:46 Reiver [orthianz@3CF3A5.E1CD01.C6689C.33956A] has quit [Ping timeout: 121 seconds]
10:49 Rhamphoryncus [rhamph@Nightstar-14eb6405.abhsia.telus.net] has quit [Ping timeout: 121 seconds]
10:50 Rhamphoryncus [rhamph@Nightstar-14eb6405.abhsia.telus.net] has joined #code
10:52 Reiver [orthianz@3CF3A5.E1CD01.C6689C.33956A] has joined #code
11:47 Rhamphoryncus [rhamph@Nightstar-14eb6405.abhsia.telus.net] has quit [Ping timeout: 121 seconds]
11:50 jeroid [jerith@687AAB.5E3E50.88B070.E2F330] has quit [[NS] Quit: Bye]
11:50 Rhamphoryncus [rhamph@Nightstar-14eb6405.abhsia.telus.net] has joined #code
11:53 Attilla [Obsolete@Nightstar-d42c1553.as43234.net] has quit [Ping timeout: 121 seconds]
11:59 Attilla [Obsolete@Nightstar-d42c1553.as43234.net] has joined #code
12:31 You're now known as TheWatcher
12:55 Reiver [orthianz@3CF3A5.E1CD01.C6689C.33956A] has quit [Ping timeout: 121 seconds]
13:00 Reiver [orthianz@3CF3A5.E1CD01.C6689C.33956A] has joined #code
13:09 Reiver [orthianz@3CF3A5.E1CD01.C6689C.33956A] has quit [Ping timeout: 121 seconds]
13:15 Reiver [orthianz@3CF3A5.E1CD01.C6689C.33956A] has joined #code
13:19 Reiver [orthianz@3CF3A5.E1CD01.C6689C.33956A] has quit [Ping timeout: 121 seconds]
13:25 Reiver [orthianz@3CF3A5.E1CD01.C6689C.33956A] has joined #code
13:39 Reiver [orthianz@3CF3A5.E1CD01.C6689C.33956A] has quit [Ping timeout: 121 seconds]
13:44 Reiver [orthianz@3CF3A5.E1CD01.C6689C.33956A] has joined #code
14:02 Reiver [orthianz@3CF3A5.E1CD01.C6689C.33956A] has quit [Ping timeout: 121 seconds]
14:06 Reiver [orthianz@3CF3A5.E1CD01.C6689C.33956A] has joined #code
14:24 iosleep is now known as iospace
14:29
< Rhamphoryncus>
Interesting. Wikipedia uses a lot of data: URLs
14:29
< Rhamphoryncus>
Spacers are embedded directly in each page, tiny standard icons (such as the external link one) are embedded in the css file
14:31
< Rhamphoryncus>
And somehow this prevents firefox from admitting there is an image there
14:32
< ToxicFrog>
McM[xmas]: If by "performance" you mean "speed", a large part of it is that SVN hits the network for everything and git does not, but this does not explain why git is faster for stuff like clone (or why it's faster than Hg for most operations).
14:32
< ToxicFrog>
That said, I know very little of git's internal algorithms and storage formats, so I can't tell you exactly why.
14:32
< ToxicFrog>
(similarly, I know git merges are much less of a headache than SVN ones but not what differences in git's merge algorithm cause this)
14:33
< Rhamphoryncus>
iirc, the root of it is git tracks version chains differently
14:33
< ToxicFrog>
...also, for migrating a repository to another machine, shouldn't that just be "scp the entire repository over"?
14:34
< Rhamphoryncus>
It has a better idea of how divergent patches interrelate
14:49 Rhamphoryncus [rhamph@Nightstar-14eb6405.abhsia.telus.net] has quit [Ping timeout: 121 seconds]
14:51 Rhamphoryncus [rhamph@Nightstar-14eb6405.abhsia.telus.net] has joined #code
15:10 Rhamphoryncus [rhamph@Nightstar-14eb6405.abhsia.telus.net] has quit [Ping timeout: 121 seconds]
15:11 Rhamphoryncus [rhamph@Nightstar-14eb6405.abhsia.telus.net] has joined #code
15:52 Kindamoody|out is now known as Kindamoody
16:11 celticminstrel [celticminst@Nightstar-5d22ab1d.cable.rogers.com] has joined #code
16:24 WiFlyer [NSflashIRC@48DFF2.D7721A.E44CCA.0A4B64] has joined #code
16:32 WiFlyer [NSflashIRC@48DFF2.D7721A.E44CCA.0A4B64] has left #code []
16:36 AnnoDomini [annodomini@Nightstar-cbe8fb29.adsl.tpnet.pl] has joined #code
16:39 Rhamphoryncus [rhamph@Nightstar-14eb6405.abhsia.telus.net] has quit [Ping timeout: 121 seconds]
16:41 Rhamphoryncus [rhamph@Nightstar-14eb6405.abhsia.telus.net] has joined #code
16:47 celticminstrel is now known as celmin|away
17:06 Rhamphoryncus [rhamph@Nightstar-14eb6405.abhsia.telus.net] has quit [Ping timeout: 121 seconds]
17:07 Rhamphoryncus [rhamph@Nightstar-14eb6405.abhsia.telus.net] has joined #code
17:26 Rhamphoryncus [rhamph@Nightstar-14eb6405.abhsia.telus.net] has quit [Ping timeout: 121 seconds]
17:27 Rhamphoryncus [rhamph@Nightstar-14eb6405.abhsia.telus.net] has joined #code
17:32 EvilDarkLord is now known as Maze
17:51 Vash [Vash@Nightstar-8697fea9.wlfrct.sbcglobal.net] has joined #code
17:52 Vash [Vash@Nightstar-8697fea9.wlfrct.sbcglobal.net] has quit [[NS] Quit: I <3Lovecraft<3 Vorn!]
17:58
< Namegduf>
ToxicFrog: And set the config's remote.
17:58
< Namegduf>
But I love that that is otherwise basically right.
17:58 Kindamoody is now known as Kindamoody|out
17:59 * ToxicFrog ponders felt some more
17:59
< Namegduf>
I recently wanted to turn a local repo into a remote one, so I could work on it from elsewhere.
17:59
< ToxicFrog>
Does the client actually need a class heirarchy that mirrors the server's?
17:59
< Namegduf>
Just scp, then I can clone from another machine.
17:59
< ToxicFrog>
I mean, realistically, all the interesting stuff happens on the server.
17:59 Reiver [orthianz@3CF3A5.E1CD01.C6689C.33956A] has quit [Ping timeout: 121 seconds]
18:00
< ToxicFrog>
As far as the client is concerned, they're pretty much all felt.Token with different action lists.
18:01
< ToxicFrog>
Perhaps the server should send, rather than the type name, the full ancestry of the object; the client then instantiates the youngest type it knows about.
18:02
< ToxicFrog>
So the client can provide specializations (eg, it may be worthwhile providing a special felt.Deck that implements Deck:search() client-side), but in general the client can just create a generic type with appropriate fields and action list.
18:04 Reiver [orthianz@3CF3A5.E1CD01.C6689C.33956A] has joined #code
18:09 Reiver [orthianz@3CF3A5.E1CD01.C6689C.33956A] has quit [Ping timeout: 121 seconds]
18:13 Reiver [orthianz@3CF3A5.E1CD01.C6689C.33956A] has joined #code
18:37<~Vornicus> TF: the primary reason to do give the client more than just the action list is the ability to interpolate effects it knows should happen.
18:38 Rhamphoryncus [rhamph@Nightstar-14eb6405.abhsia.telus.net] has quit [Ping timeout: 121 seconds]
18:41<~Vornicus> THe other reason is to create actions (like deck.search) where it requests additional client-side input (showing the list of things in the deck in a picker) but doesn't necessarily show up to the other players.
19:07
< ToxicFrog>
Right.
19:08
< ToxicFrog>
What I'm saying is that for 90% of object types, you don't need either, so there's no reason the client should be forced to create mirror class definitions for those which consist of a single line.
19:12<~Vornicus> Hmmmm.... Yeah, okay, I agree with that.
19:17 Vash [Vash@Nightstar-8697fea9.wlfrct.sbcglobal.net] has joined #code
19:17 * Vornicus thinks: in some games, the "additional client-side input" is more like "user hints as to what you can do with the object"; in carcassonne, this would be, like, locking rotation to 90, and inter-tile magnets. But then you have dozens of different tile shapes and the server may need code for some of them!
19:18
< ToxicFrog>
Yeah. And I don't want to restrict the implementation of that either.
19:18
< ToxicFrog>
Stuff like the action list is basically the server telling the client "these are the allowable operations with the object"
19:18
< ToxicFrog>
And then it's up to the client how to make those available to the user.
19:19
< ToxicFrog>
What I'm currently toying with is this
19:19 * Vornicus gets crazythoughts about how he'd build a computerized carcassonne client.
19:19
< ToxicFrog>
At present, new objects are sent to the client as a (type,initializer) pair.
19:20
< ToxicFrog>
The client creates a new object of that type using that initializer, and if it doesn't have a definition for that type, it errors
19:20
< ToxicFrog>
I'm considering sending it as a (lineage,initializer) pair - so a descent.PlayerToken would be sent as { { "descent.PlayerToken", "felt.Token", "felt.Drawable", "felt.Object", "Object" }, initializer }
19:21
< ToxicFrog>
The client then walks the lineage and instantiates the first type it has a definition for.
19:21
< ToxicFrog>
Which in this case is probably felt.Token.
19:22
< ToxicFrog>
The client then has the option of implementing more specific types (for example, the GTK version of the client might implement descent.PlayerToken to have a stats popup on mouseover or something)
19:31
< ToxicFrog>
Speaking of which, I'm trying to come up with a better name for felt.Drawable.
19:31
< ToxicFrog>
there's felt.Object which is "anything that can exist in the game", which includes intangibles like the players themselves.
19:31 celmin|away is now known as celticminstrel
19:31<~Vornicus> "entity" is a classic one
19:32
< ToxicFrog>
felt.Drawable is the supertype for "stuff the player can interact with in some way", which means it probably has some on-screen representation, it has a defined position and parent and possibly children, it can receive UI events if on the client, etc.
19:32
< ToxicFrog>
But I feel like "Drawable" is the wrong term, because it implies the wrong things.
19:33<~Vornicus> InteractiveObject
19:33
< ToxicFrog>
(basically "something that exists on the table" as opposed to "something that is part of the game")
19:33<~Vornicus> What would be a thingthat's part of the game that's not on the table?
19:34
< ToxicFrog>
I am honestly having a hard time thinking of examples
19:35<~Vornicus> Maybe this level of the hierarchy isn't useful.
19:35
< ToxicFrog>
Oh wait
19:35
< ToxicFrog>
Sorry, misread you
19:35
< ToxicFrog>
Players are the obvious ones
19:35
< ToxicFrog>
They need to exist in-game so that sight and ownership relationships can be expressed, but aren't on the table and can't be directly interacted with
19:37 * Vornicus implements 52 pickup in Felt
19:39<~Vornicus> (always a certain amount of manhandling in that game)
19:42<~Vornicus> InteractiveObject seems the most sensible to me
19:49
< ToxicFrog>
Alright then
19:54<~Vornicus> gneh. okay, my polygon binder works, but I don't know what the hell I'm doing as far as choosing polygons to try to merge.
19:58 Kindamoody|out is now known as Kindamoody
20:26 Kindamoody is now known as Kindamoody[zZz]
20:34
< ToxicFrog>
Cocks.
20:34
< ToxicFrog>
I've blown up my ereader.
20:34<~Vornicus> D:
20:34 Attilla [Obsolete@Nightstar-d42c1553.as43234.net] has quit [Ping timeout: 121 seconds]
20:39
< celticminstrel>
Your what?
20:43 Attilla [Obsolete@Nightstar-d42c1553.as43234.net] has joined #code
20:43
< ToxicFrog>
celticminstrel: ereader. E-Reader. A device for reading ebooks.
20:45
< celticminstrel>
So, not the GBA attachment.
20:45
< ToxicFrog>
No.
20:45
< ToxicFrog>
This is specifically a Sony PRS-650, a reader with an e-ink touchscreen.
21:03
< McM[xmas]>
06:33 < ToxicFrog> ...also, for migrating a repository to another machine, shouldn't that just be "scp the entire repository over"?
21:03
< McM[xmas]>
09:58 < Namegduf> ToxicFrog: And set the config's remote.
21:03
< McM[xmas]>
09:58 < Namegduf> But I love that that is otherwise basically right.
21:04
< McM[xmas]>
The wrinkle, such as it was, is that I wanted the server to have a bare repo, not a checkout - so I needed to do a clone --bare first.
21:04
< AnnoDomini>
http://bash.org.pl/4818318/ <- "On a scale of 0 to 10, you got F points for that equation."
21:04
< Namegduf>
That's true.
21:04
< McM[xmas]>
But yeah, that was basically it.
21:04
< McM[xmas]>
Also I did a re-clone instead of directly re-setting the original's remotes.
21:04
< McM[xmas]>
Also:
21:04
< McM[xmas]>
06:32 < ToxicFrog> (similarly, I know git merges are much less of a headache than SVN ones but not what differences in git's merge algorithm cause this)
21:05
< McM[xmas]>
Based on further reading, it sounds very much like svn merges are roughly equivalent to git rebase.
21:05
< Namegduf>
A reclone works, yeah.
21:05
< McM[xmas]>
And git thinks that git rebase and git merge are different things, given the different commands with different results.
21:41 Maze is now known as EvilDarkLord
22:22 Thaqui [Thaqui@27B34E.D54D49.F53FA1.6A113C] has joined #code
22:59
< celticminstrel>
Rebase and merge are different.
23:14 Reiver [orthianz@3CF3A5.E1CD01.C6689C.33956A] has quit [Ping timeout: 121 seconds]
23:14 Reiver [orthianz@3CF3A5.E1CD01.C6689C.33956A] has joined #code
23:23 Reiver [orthianz@3CF3A5.E1CD01.C6689C.33956A] has quit [Ping timeout: 121 seconds]
23:30 Reiver [orthianz@3CF3A5.E1CD01.C6689C.33956A] has joined #code
--- Log closed Wed Dec 28 00:00:43 2011
code logs -> 2011 -> Tue, 27 Dec 2011< code.20111226.log - code.20111228.log >
 search of the:   for: 

[ Latest log file ]