| --- Log opened Fri Apr 16 00:00:44 2010 |
| --- Day changed Fri Apr 16 2010 |
| 00:00 | <@McMartin> | Derakon: My issue was that Ruby claims to have this, despite ???!!??:!!!?? being a valid statement. |
| 00:00 | <@McMartin> | Er, expression |
| 00:01 | <@McMartin> | And despite having block syntax, which is a completely wack-assed implementation of lambda arguments while pretending they're completely unprecedented but also too obvious to explain |
| 00:01 | <@McMartin> | I'm unaware of how the scope is different from a normal callable argument, though; what changes? |
| 00:03 | | * Derakon heads out |
| 00:03 | | Derakon [Derakon@Nightstar-1ffd02e6.ucsf.edu] has quit [[NS] Quit: Leaving] |
| 00:11 | <@ToxicFrog> | McMartin: Haskell is actually increasingly irritating me, because I really like it but never seem to have any problems that it fits |
| 00:11 | <@McMartin> | Yes, that's why it spoils you =( |
| 00:34 | <@McMartin> | Hot. The new I7 build is going to have a "publish as web page" option, where it JSON's the z-code and links in the Parchment interpreter |
| 00:51 | | You're now known as TheWatcher[T-2] |
| 00:53 | | You're now known as TheWatcher[zZzZ] |
| 01:09 | | Attilla [Attilla@FBC920.3488E2.03ED7E.3EC87F] has quit [Connection reset by peer] |
| 01:35 | | gnolam [lenin@Nightstar-38637aa0.priv.bahnhof.se] has quit [[NS] Quit: Z?] |
| 01:49 | | Orthia [orthianz@Nightstar-c830764f.xnet.co.nz] has joined #code |
| 03:24 | | Thaqui [Thaqui@27B34E.D54D49.F53FA1.6A113C] has quit [Client closed the connection] |
| 04:17 | | Searh [Z@26ECB6.A4B64C.298B52.D80DA0] has quit [Ping timeout: 121 seconds] |
| 04:40 | | Serah [Z@3A600C.A966FF.5BF32D.8E7ABA] has joined #code |
| 04:46 | | Rhamphoryncus [rhamph@Nightstar-8931f88f.abhsia.telus.net] has quit [Client exited] |
| 05:50 | | Serah [Z@3A600C.A966FF.5BF32D.8E7ABA] has quit [Ping timeout: 121 seconds] |
| 06:06 | | AnnoDomini [annodomini@Nightstar-ef91445b.adsl.tpnet.pl] has joined #code |
| 06:07 | | mode/#code [+o AnnoDomini] by Reiver |
| 08:25 | | gnolam [lenin@Nightstar-38637aa0.priv.bahnhof.se] has joined #code |
| 08:41 | | Thaqui [Thaqui@27B34E.D54D49.F53FA1.6A113C] has joined #code |
| 09:04 | | GeekSoldier_ [Rob@Nightstar-e86e3e0d.ip.cablemo.net] has joined #code |
| 09:04 | | GeekSoldier [Rob@Nightstar-e86e3e0d.ip.cablemo.net] has quit [Ping timeout: 121 seconds] |
| 09:39 | | RichardBarrell [mycatverbs@Nightstar-58acb782.cable.virginmedia.com] has quit [Ping timeout: 121 seconds] |
| 09:50 | | You're now known as TheWatcher |
| 11:34 | | Orthia [orthianz@Nightstar-c830764f.xnet.co.nz] has quit [Client closed the connection] |
| 11:37 | | Attilla [Attilla@FBC920.3488E2.03ED7E.3EC87F] has joined #code |
| 11:37 | | mode/#code [+o Attilla] by Reiver |
| 11:41 | | Orthia [orthianz@Nightstar-c830764f.xnet.co.nz] has joined #code |
| 11:43 | | Orthia [orthianz@Nightstar-c830764f.xnet.co.nz] has quit [Client closed the connection] |
| 11:49 | | Orthia [orthianz@Nightstar-c830764f.xnet.co.nz] has joined #code |
| 12:21 | | Thaqui [Thaqui@27B34E.D54D49.F53FA1.6A113C] has quit [Connection closed] |
| 12:23 | | AnnoDomini [annodomini@Nightstar-ef91445b.adsl.tpnet.pl] has quit [Ping timeout: 121 seconds] |
| 12:25 | | AnnoDomini [annodomini@Nightstar-6be0f4b4.adsl.tpnet.pl] has joined #code |
| 12:25 | | mode/#code [+o AnnoDomini] by Reiver |
| 12:31 | | cpux is now known as shade_of_cpux |
| 12:55 | | GeekSoldier_ is now known as GeekSoldier |
| 13:19 | | Orth [orthianz@Nightstar-acffacc3.xnet.co.nz] has joined #code |
| 13:22 | | Orthia [orthianz@Nightstar-c830764f.xnet.co.nz] has quit [Ping timeout: 121 seconds] |
| 14:05 | | celticminstrel [celticminstre@Nightstar-f8b608eb.cable.rogers.com] has joined #code |
| 14:06 | < celticminstrel> | Ugh. What is wrong with this computer? :/ |
| 14:10 | <@TheWatcher> | Crashity? |
| 14:16 | < celticminstrel> | Yep. |
| 14:16 | < celticminstrel> | When it goes to sleep it won't wake up. |
| 14:17 | < celticminstrel> | Googling suggests that resetting the PRAM and/or SMC might help... |
| 14:19 | <@jerith> | Give it more amphetamines? |
| 14:19 | < celticminstrel> | <_< |
| 14:35 | | Rhamphoryncus [rhamph@Nightstar-8931f88f.abhsia.telus.net] has joined #code |
| 14:36 | | Serah [Z@3A600C.A966FF.5BF32D.8E7ABA] has joined #code |
| 14:46 | | celticminstrel [celticminstre@Nightstar-f8b608eb.cable.rogers.com] has quit [Client exited] |
| 14:48 | | Orthia [orthianz@Nightstar-7de495fb.xnet.co.nz] has joined #code |
| 14:50 | | Orth [orthianz@Nightstar-acffacc3.xnet.co.nz] has quit [Ping timeout: 121 seconds] |
| 15:04 | | celticminstrel [celticminstre@Nightstar-f8b608eb.cable.rogers.com] has joined #code |
| 17:04 | | Serah [Z@3A600C.A966FF.5BF32D.8E7ABA] has quit [Ping timeout: 121 seconds] |
| 17:39 | | Serah [Z@26ECB6.A4B64C.298B52.D80DA0] has joined #code |
| 17:45 | | celticminstrel [celticminstre@Nightstar-f8b608eb.cable.rogers.com] has quit [[NS] Quit: *hums* Can't stay now!] |
| 18:41 | < Rhamphoryncus> | Mmmm turing machines. My favourite form of pure programming. |
| 20:09 | | Taki^ [jwjw@Nightstar-9b459f81.consolidated.net] has joined #code |
| 20:12 | | Thaqui [Thaqui@27B34E.D54D49.F53FA1.6A113C] has joined #code |
| 20:53 | | celticminstrel [celticminstre@Nightstar-f8b608eb.cable.rogers.com] has joined #code |
| 21:52 | < Namegduf> | Hmm, interesting. |
| 21:52 | < Namegduf> | http://www.tideland.biz/articles/coding-in-go/build-functions-for-lazy-evaluatio n <-- What do the functional peoples think of this? |
| 21:53 | < Namegduf> | I find the use of interface{} a little ugly, it's the Go equivalent of void* |
| 21:54 | <@AnnoDomini> | If you point at the void long enough, the void also points at you... |
| 21:54 | < Namegduf> | XD |
| 21:56 | < Namegduf> | The only real issue I see with it is that there's no way to get anything but a continuous stream out of it. |
| 21:57 | < Namegduf> | But that could be fixed by adding a parameter in various places. |
| 21:57 | < Namegduf> | I'm wondering what the people with more functional knowledge see as actually deficient, if they can read it. |
| 21:58 | < Namegduf> | Aside their lack of commenting. |
| 22:04 | <@McMartin> | Sorry, was at lunch |
| 22:04 | <@McMartin> | Let me see |
| 22:04 | <@AnnoDomini> | I have no functional knowledge. |
| 22:05 | <@McMartin> | Mmm. It's been a good while since I've messed with go, but I believe interface{} is a little cleaner than void* |
| 22:05 | < Namegduf> | It actually is, mostly because you can unbox safely |
| 22:06 | <@McMartin> | It's more "seriously, I don't use this object so it doesn't matter what it is" |
| 22:06 | < Namegduf> | Yeah. |
| 22:06 | <@McMartin> | It's closer to ML's 'a.. |
| 22:06 | < Namegduf> | And you can check what type it is when unboxing, which is very nice for Printf |
| 22:06 | <@McMartin> | Ah, yeah |
| 22:06 | < Namegduf> | This code doesn't do that, though. |
| 22:06 | | * McMartin did a little of that with binary decoding, IHRC. |
| 22:07 | < Namegduf> | I'm not sure what interface{} adds to the raw pointer, but I suspect it's some kind of type ID. |
| 22:07 | <@McMartin> | It may only be AST annotations. |
| 22:08 | < Namegduf> | Best as I remember, an interface is implemented as a two-part structure containing a pointer to the right function table, and a pointer to the data. |
| 22:08 | <@McMartin> | Hm. Yeah, and then the first one would be NULL in this case |
| 22:08 | < Namegduf> | But there's special stuff for interface{} where the first part isn't a pointer and doesn't need dereferencing, and the data isn't a pointer if the interface{} is boxing up something that fits in a wordanyway. |
| 22:08 | <@McMartin> | Which could be optimizable |
| 22:08 | <@McMartin> | Right |
| 22:08 | <@McMartin> | That's an implementation detail |
| 22:08 | <@McMartin> | It *could be* a void pointer at the end of the day |
| 22:09 | < Namegduf> | Yeah. |
| 22:09 | <@McMartin> | The only reason you'd want to not unbox it automatically is for uniform reference semantics, say because you're optmizing for code size |
| 22:09 | <@McMartin> | But if you're optimizing for code size, you aren't writing in Go, at least not the last time I looked at it. >_< |
| 22:10 | < Namegduf> | Hmm. |
| 22:10 | <@McMartin> | My Go knowledge is too rusty to make sense of a lot of what's going on here. |
| 22:10 | < Namegduf> | Ah. |
| 22:10 | <@McMartin> | It *looks* like it's using goroutines to function like Python generators to function like lazily generated infinite lists |
| 22:11 | <@McMartin> | In which case, yeah, that's more or less how you'd do it, but it doesn't give you lazy evaluation generally, just generators |
| 22:11 | < Namegduf> | Hmm. |
| 22:12 | <@McMartin> | You also don't get your full history the way you would with lazily generated infinite lists, but the ability to switch that off is a feature. >_> |
| 22:12 | < Namegduf> | You could store it in the magic "state" thing. |
| 22:12 | < Namegduf> | Which pretty much is "whatever the eval function feels like storing", so far as I can tell. |
| 22:13 | <@McMartin> | Mleh |
| 22:13 | <@McMartin> | Like, I'm not sure how you'd use this to compute two mutually recursive functions |
| 22:13 | < Namegduf> | Hmm. |
| 22:13 | < Namegduf> | That wouldn't work, because they're using goroutines for it. |
| 22:14 | <@McMartin> | I have some stuff to deal with right now, but I can dig up some Haskell code in three to five hours to make it a little clearer |
| 22:14 | < Namegduf> | I kind of wonder why. |
| 22:14 | <@McMartin> | No obvious equivalent to "the pointer to the head of the list" |
| 22:15 | < Namegduf> | Hmm? |
| 22:16 | <@McMartin> | The subprocess I have thinking about this thinks that's an important difference between the Haskell infinite lists and the goroutine/generator setup. |
| 23:18 | <@McMartin> | Hm. Forwarding a PSA: http://sourceforge.net/projects/javara/ is apparently a good cleanup tool if you have a bunch of random Java cruft left on your system |
| 23:27 | <@McMartin> | A question, for those of you more familiar with modern software than I: what's a good RCS for home development? I've been meaning to learn git or mercurial but don't know if they're worth the effort for a home LAN, or if one is noticably better than the other. |
| 23:27 | <@McMartin> | I have pretty extensive cvs/svn experience. |
| 23:27 | <@Vornicus> | Git is entirely localized. |
| 23:27 | <@McMartin> | Isn't hg too? |
| 23:27 | <@Vornicus> | I don't know about mercurial, but jerith pointed me at git earlier. |
| 23:27 | < Namegduf> | Both are localised and quite similar in functionality and behaviour. |
| 23:28 | < Namegduf> | I prefer git due to more intelligent merging and reverting. |
| 23:28 | <@jerith> | I was pointing you at bzr, actually. |
| 23:28 | < Namegduf> | For basic operations, there's usually a 1:1 correspondance between commands. |
| 23:28 | <@jerith> | git is less a VCS and more a branch management tool. |
| 23:29 | <@jerith> | Similar featuresets, different aims. |
| 23:29 | < Namegduf> | Git's equally a VCS *and* more a branch management tool. |
| 23:29 | < Namegduf> | Aims for git are pretty much defined as "provide VCS functionality to the Linux kernel", so I'd disagree. |
| 23:30 | < Namegduf> | Mercurial is pretty much identical in that respect, though. |
| 23:30 | < Namegduf> | Both do branching in similar fashion. |
| 23:30 | <@jerith> | Namegduf: A branch management tool is a superset of a VCS. |
| 23:30 | < Namegduf> | Maybe, but calling it "less of a VCS" suggests that its less functional when all you want is a VCS |
| 23:30 | < Namegduf> | Which isn't really true |
| 23:31 | <@jerith> | git's a fantastic tool, but its focus makes it harder to use as a VCS if you're not managing branches. |
| 23:31 | < Namegduf> | If you say so. |
| 23:31 | < Namegduf> | I would insist that the same applies to Mercurial if so. |
| 23:32 | <@jerith> | I've never used hg beyond "acquire some code". |
| 23:33 | < Namegduf> | I don't see how git could be simplified for straight VCS use, I'm in the habit of going "git init" "git add" "git commit" and bang for small projects with no other setup, but without knowing the reasoning for saying git is harder to use as a VCS. |
| 23:33 | <@jerith> | darcs and bzr have most of the VCS features that git does, but lacke the powerful branch manipulation stuff. |
| 23:33 | < Namegduf> | The branch manipulation stuff stays out of my way unless I invoke it, in my experience. |
| 23:34 | <@jerith> | Namegduf: I've seen people accidentally create a second branch and then get into a state they can't get out of. |
| 23:34 | < Namegduf> | How the hell do you do that |
| 23:34 | < Namegduf> | I mean, to create a branch, you need to be using "git branch" in the first place. |
| 23:34 | <@jerith> | Well, they can't get out of it because they don't know the tool.. |
| 23:35 | | * jerith shrugs. |
| 23:35 | < Namegduf> | Well, okay, or tinkering with very low level stuff you shouldn't be touching and I don't know about, that might be able to cause it. |
| 23:36 | <@jerith> | I'd probably like it more if I knew it better, but bzr gives me all I need and I get launchpad's bonuses as well. :-) |
| 23:36 | < Namegduf> | What does launchpad do that Gitorious, Github, and Bitbucket (Mercurial's) not, out of interest? |
| 23:37 | <@jerith> | Integration. |
| 23:37 | < Namegduf> | Integration? |
| 23:37 | <@jerith> | Issue tracker, repo, code reviews, etc. all in one package. |
| 23:37 | < Namegduf> | Ah. |
| 23:37 | < Namegduf> | So similar to Sourceforge, but hopefully less sucky |
| 23:38 | <@jerith> | So very, very less sucky. |
| 23:38 | <@McMartin> | Hm, it looks v. much like part of my issue is that I really do mostly still want something largely client-server. |
| 23:38 | <@McMartin> | Which seems to be what git push is for? |
| 23:39 | < Namegduf> | Yeah. |
| 23:39 | < Namegduf> | Typical flow for something on a remote server: |
| 23:39 | <@jerith> | McMartin: All the dvcs tools will do that. |
| 23:39 | < Namegduf> | <git|hg> clone ssh://someplace//path/to/repo repo |
| 23:40 | < Namegduf> | Enter repo, make changes... "hg commit" or "git commit -a", "<hg|git> push" |
| 23:41 | < Namegduf> | I find it very entertaining how similar the commands are, because Mercurial is praised by some for a really nice interface, while git is described as harder to use but more MacGuyver; my conclusion is that these people liked creating articles with pictures of MacGuyver but had never actually used at least one of the two tools. |
| 23:42 | <@jerith> | Namegduf: Notice the extra param to git commit there. |
| 23:42 | < Namegduf> | Haha. |
| 23:42 | <@McMartin> | Hmm. How's git's interaction with SSH generally and putty specifically? |
| 23:42 | | * McMartin would like to use a Linux machine with no special packages as a server for the Windows and Mac machines on that LAN. |
| 23:42 | < Namegduf> | Windows git runs off Cygwiny-like stuff |
| 23:42 | < Namegduf> | But is nicely packagedish |
| 23:43 | < Namegduf> | Cloning remote repos over SSH works as expected. |
| 23:43 | < Namegduf> | jerith: Yeah, that's true, but makes sense once you get just one step more complex. |
| 23:43 | <@jerith> | bzr has sensible defaults for the single-branch case. git has sensible defaults for the multi-branch case. |
| 23:43 | < Namegduf> | Er... no. |
| 23:44 | <@McMartin> | Hrm. |
| 23:44 | < Namegduf> | Git does not do crap all with branches or have you issue any commands relating to branches unless you tell it to explicitly. |
| 23:44 | | * McMartin pokes at Git's Windows support |
| 23:44 | <@McMartin> | This will not integrate well with what I already have installed. |
| 23:44 | | * jerith shrugs. |
| 23:45 | <@jerith> | I'm mostly relaying what I've seen and heard. I really haven't used git enough to have my own opinions. |
| 23:45 | < Namegduf> | Seriously, git init/add/commit/pull/push/rm/revert don't even mention branches. |
| 23:46 | < Namegduf> | Well, maybe on the side as "branch master" or similar. |
| 23:46 | | * TheWatcher readsup |
| 23:46 | <@TheWatcher> | Have they actually fixed git in cygwin yet? |
| 23:46 | < Namegduf> | No idea, I didn't use it "in Cygwin" |
| 23:46 | <@McMartin> | All my searching involves finding stuff that implies they've instead half-ported it to MSYS |
| 23:46 | <@jerith> | It's less about dealing with them explicitly and more about not assuming that there's only one branch in there. |
| 23:46 | < Namegduf> | I think I used http://code.google.com/p/msysgit/ |
| 23:46 | <@TheWatcher> | Last I attempted to use it, it was hideously broken. |
| 23:47 | <@McMartin> | Which implies in turn that it won't, frex, interface with Pageant |
| 23:47 | < Namegduf> | I don't believe any commands deal with said assumption/lack thereof. |
| 23:47 | < Namegduf> | Everything is done on the current branch, and you don't switch branch unless you use "git branch". |
| 23:47 | < Namegduf> | There's an automatic "master" branch by default when a repo is created fresh. |
| 23:48 | <@McMartin> | Hg, meanwhile, is Python |
| 23:48 | < Namegduf> | I dislike Merc mostly because for some idiotic reason, it's not quite so true on this as git |
| 23:48 | < Namegduf> | Reverting via hg backout is done by creating a branch based on the change you're reverting, then a simple undo |
| 23:48 | <@jerith> | "revert" does something unexpected on git. |
| 23:48 | < Namegduf> | Then merging that new head |
| 23:49 | < Namegduf> | jerith: "git revert <commit ID>" does something unexpected? |
| 23:49 | <@McMartin> | "unexpected" = "different than svn revert"~ |
| 23:49 | <@jerith> | Because it assumes you want to revert a commit on a branch, rather than reverting the working directory to the most recent repo version. |
| 23:49 | < Namegduf> | Er, what |
| 23:49 | < Namegduf> | s/ on a branch// |
| 23:50 | < Namegduf> | It assumes you want to "Revert an existing commit" |
| 23:50 | <@McMartin> | Yeah. That's not what svn revert menas. |
| 23:50 | < Namegduf> | Because that is what its name is. |
| 23:50 | <@McMartin> | svn revert means "revert local edits". |
| 23:50 | <@McMartin> | Doesn't touch the server. |
| 23:50 | <@jerith> | "revert a commit" makes sense for a branch management tool. |
| 23:50 | < Namegduf> | I don't know where branch comes into it. I think if you tried to revert a change which wasn't on your current branch, it might bitch at you. |
| 23:51 | < Namegduf> | I'm pretty sure "undo this change in history" makes sense for a VCS |
| 23:51 | <@jerith> | "revert local edits" makes sense for a VCS. |
| 23:51 | < Namegduf> | "revert previous change" also makes sense for a VCS. |
| 23:52 | <@jerith> | Namegduf: Absolutely. |
| 23:52 | < Namegduf> | This really does sound like "Isn't exactly the same commands and names for them" is being equated to "isn't a valid interface decision for that job" |
| 23:52 | <@jerith> | And "previous change" typically means "in the working dir" rather than "committed to the repo". |
| 23:52 | < Namegduf> | Why? |
| 23:52 | <@McMartin> | Namegduf: This is why I put a tilde on it. |
| 23:52 | <@McMartin> | But yes, this is endemic when people bitch about non-POSIX APIs, so I see no reason it should be different here |
| 23:53 | < Namegduf> | Not having used SVN or any other VCS before I used git, "git revert" did exactly what I was expecting |
| 23:53 | < Namegduf> | And I'd probably find SVN's to be weirdly named; "svn clean" would be something like what I'd expect for a specific command for that. |
| 23:53 | | shade_of_cpux is now known as cpux |
| 23:54 | <@jerith> | svn doesn't have a command for that. |
| 23:54 | < Namegduf> | By "that", I was meaning what SVN does for svn revert |
| 23:54 | <@McMartin> | Right. |
| 23:54 | < Namegduf> | (Git uses... git reset --hard HEAD, which is long because you're blowing away changes, which is considered bad.) |
| 23:54 | <@jerith> | You revert by applying a reverse patch and committing a new revision. |
| 23:54 | < Namegduf> | Eww. |
| 23:54 | < Namegduf> | That's what git does, but it does it for you. |
| 23:54 | <@McMartin> | svn is, recall, five years olders than git/hg |
| 23:55 | <@McMartin> | And was in turn an iterative refinement of the vastly older CVS, which it improved upon by actually knowing what directories were |
| 23:55 | < Namegduf> | Ah. |
| 23:55 | <@jerith> | svn's focus is on storing revision history for a linear development path. |
| 23:55 | <@McMartin> | CVS, meanwhile, improved on its predecessors by making it possible to have more than one person check out a repo at any given time. |
| 23:55 | <@McMartin> | revision control systems are not exactly a rapidly evolving field. |
| 23:55 | < Namegduf> | I'm aware that git has a more spread focus. |
| 23:55 | <@McMartin> | But svn, cvs, and its predecessor all used largely the same command names for everything. |
| 23:56 | <@McMartin> | Which is why redefining "revert" is bucking a many-year tradition, at least. |
| 23:56 | <@jerith> | git's focus is on shuffling patches between branches and maintaining different but similar lines of development. |
| 23:56 | < Namegduf> | I'd say that git's focus is both. |
| 23:56 | <@jerith> | What most people actually want in a VCS is something in the middle. |
| 23:57 | < Namegduf> | I've just never observed that to actually hmake the use more complex, because I've never heard an explanation other than "command names are different!" |
| 23:57 | < Namegduf> | At least now I understand why people like Mercurial more for the command interface. |
| 23:57 | <@McMartin> | Looks like I'll have to do some integration tests. |
| 23:57 | < Namegduf> | Because while its reverting is vastly, vastly inferior and involves two commits in history |
| 23:57 | < Namegduf> | It calls it "hg backout" |
| 23:57 | <@jerith> | git was written for the Linux kernel, which is one of the most complex source trees around. |
| 23:57 | <@McMartin> | If Hg can talk to Pageant and msysgit can't, that's pretty much an instantly deciding factor for me |
| 23:58 | < Namegduf> | Sounds good. |
| 23:58 | <@McMartin> | If msysgit also demands its own copy of msys/mingw, that would be a probable but not *instant* deciding factor. |
| 23:58 | <@McMartin> | I'd rather maintain two parallel compiler installs than two parallel SSH authentication installs. |
| 23:59 | < Namegduf> | The only annoying difference I've found so far aside the revert/backout difference is "Mercurial's merging feels stupider" and "Mercurial cannot rebase", but rebase is an evil, evil operation anyway |
| 23:59 | | * ToxicFrog upreads |
| --- Log closed Sat Apr 17 00:00:00 2010 |