00:06:48 -!- quintopia has quit (Quit: Lost terminal).
00:07:03 -!- quintopia has joined.
00:13:48 -!- wareya has quit (Read error: Connection reset by peer).
00:14:15 -!- wareya has joined.
00:16:15 -!- augur has joined.
00:16:20 -!- oerjan has joined.
00:18:44 <Vorpal> oerjan, a bit on the chilly side?
00:18:51 <Vorpal> oerjan, but I guess it is still quite a cool idea
00:19:24 <Vorpal> oerjan, but where does the ice come into it?
00:19:45 <oerjan> well it's refrigerated
00:20:11 <oerjan> i mean the room is hot
00:20:27 <Vorpal> oerjan, in this winter
00:20:45 <elliott> <Vorpal> elliott, this looks interesting https://github.com/joelthelion/autojump/wiki
00:20:57 <Vorpal> elliott, does it work well?
00:21:05 <elliott> Some people swear by it :P
00:21:17 <Vorpal> elliott, your personal opinion?
00:21:18 <oerjan> use it for all your swearing
00:21:28 <elliott> It doesn't support ksh so I'd be violating my principles by using it.
00:21:38 <Vorpal> oerjan, I could have sworn you was about to make a pun
00:21:55 <Vorpal> elliott, apart from that?
00:23:21 <Vorpal> elliott, yes, /dev/null
00:23:33 <elliott> Vorpal: No, I mean, uh, come to ineiros' pit./
00:23:42 <Vorpal> elliott, not about to log in again
00:23:48 <Vorpal> elliott, need to get up in 6 hours
00:24:19 <Vorpal> elliott, just tell me what happened here on irc
00:24:34 <elliott> Vorpal: I created two beautiful waterfalls and now I can't find the way back up. I could just /spawn :P
00:24:53 <Vorpal> elliott, also /sethome
00:25:17 <Vorpal> elliott, why did you carry the buckets in your quickslots
00:25:39 <elliott> It was not unintentional :P
00:25:46 <Vorpal> elliott, then you have to face the consequences
00:25:55 <elliott> Will they ever be the same again?
00:26:18 <Vorpal> I'm sure he will remove them
01:02:56 -!- hagb4rd has quit (Ping timeout: 264 seconds).
01:32:55 -!- hagb4rd has joined.
01:41:47 -!- sftp has quit (Read error: Connection reset by peer).
01:50:24 <elliott> http://torrentfreak.com/mininova-pays-settlement-to-brein-to-end-bittorrent-lawsuit-101210/ Mininova finally gives up.
01:52:44 -!- tswett has left (?).
01:59:06 <elliott> Vorpal: so people actually (1) still use DES
01:59:10 <elliott> Vorpal: and (2) use DES to hash passwords
02:04:55 -!- Sgeo has joined.
02:06:40 <Sgeo> I'd link to something incredibly awesome, but it would reveal my approximate location
02:06:47 <Sgeo> Although I might have done so already
02:07:37 <Sgeo> elliott, name the school I go to
02:08:03 <Sgeo> http://sphotos.ak.fbcdn.net/hphotos-ak-snc4/hs887.snc4/72009_10150103222437744_618027743_7875332_7903663_n.jpg
02:08:15 <elliott> How is that incredibly awesome
02:08:30 <elliott> To be fair, I didn't actually look more than a glance.
02:08:54 <Sgeo> Well, it makes me happy, at any rate
02:09:41 <elliott> I don't actually know what it is :P
02:09:55 * oerjan is tempted to look for jpeg metadata ;D
02:09:58 <Sgeo> I'm certified to give CPR
02:10:09 <elliott> Sgeo: um isn't cpr ... pretty easy
02:10:19 <elliott> i mean, as far as things go :P
02:10:23 <Gregor> Sgeo: Sadly, you are not certified to take clear pictures.
02:10:41 <Sgeo> elliott, ye...es
02:11:00 <Sgeo> Although doing it wrong on someone who doesn't need it can kill them
02:11:02 <elliott> oerjan: no interesting EXIF.
02:11:14 <Gregor> Sgeo: Doing it wrong on someone who does need it can kill them too
02:11:30 <elliott> Gregor: Indeed, taking unclear pictures can cost lives.
02:11:38 <Sgeo> Someone who does need it is already dead. Doing it wrong just increases the chance that they'll stay dead
02:11:51 <Sgeo> *severely increases
02:11:51 <elliott> Sgeo: ... Your definition of "dead" SUCKS.
02:12:00 <elliott> Beyond all previous known bounds of suckage.
02:12:11 <elliott> "I was dead but -- thanks to Sgeo -- I got better!"
02:12:23 <Sgeo> CPR doesn't actually restart the heart
02:12:26 <elliott> If you think cardiac arrest constitutes death, WELCOME TO THE PAST
02:12:27 <oerjan> "And I didn't even get turned into a newt!"
02:13:17 <elliott> Sgeo is now qualified in ZOMBIE CREATIONL.
02:13:29 <elliott> Gregor: OMG IF WE FLATLINE WE CAN BECOME ZOMBIES.
02:13:55 <Sgeo> I'm not entirely sure why trained persons are preferred for AED usage. I mean, as long as you follow directions... ah, that's probably why. Although I doubt the thing about using adult pads on children and not child pads on adults is on there
02:14:07 <oerjan> THAT'S CLEARLY HOW THE KIM FAMILY GOT THEIR SUPERPOWERS
02:14:29 <oerjan> i mean most of them look half dead already
02:14:52 -!- hagb4rd has quit (Ping timeout: 245 seconds).
02:14:56 <elliott> pikhq: COPYRIGHT FUCK YEAH: Aston Kutcher is in trouble for broadcasting 13 minutes of the film Killers, starring Aston Kutcher, on the interwebnets.
02:15:20 <Sgeo> Did he make the film, or just star in it?
02:15:30 <elliott> Sgeo: He made every single frame with his own nose.
02:16:05 <Gregor> I wonder if porn companies do copyright violation lawsuits.
02:16:25 <elliott> ENV{x11_options.EmulateWheel}="true"
02:16:26 <elliott> ENV{x11_options.EmulateWheelButton}="2"
02:16:26 <elliott> ENV{x11_options.YAxisMapping}="4 5"
02:16:26 <elliott> ENV{x11_options.XAxisMapping}="6 7"
02:16:26 <elliott> ENV{x11_options.Emulate3Buttons}="false"
02:16:28 <elliott> ENV{x11_options.EmulateWheelTimeout}="200"
02:16:40 <elliott> That's right -- we replaced xorg.conf with a bunch of magic files that have conditional rules to ... set xorg.conf settings.
02:16:50 <elliott> PROGRESS AUTOMATIC MAGICISM
02:16:53 <Sgeo> Gregor, aimed to embarrass
02:17:27 <elliott> Just kill him and evrything will be perfect.
02:18:28 <oerjan> Die Bösen werden geschlachtet, die Welt wird gut.
02:18:56 <elliott> oerjan: IN AN ALTERNATE UNIVERSE
02:19:46 <oerjan> that _was_ a quote in case you didn't realize
02:20:14 <elliott> oerjan: IN AN ALTERNATE UNIVERSE WHERE NORWAY IS HITLER
02:20:18 <elliott> LIKE THE ACTUAL PERSON HITLER
02:20:22 <elliott> QUANTUM THEORY SAYS IT IS POSSIBLE
02:20:36 <oerjan> many-person interpretation
02:20:40 <elliott> hm I can't find the thing that let you easily do single-file git
02:22:28 <Gregor> Many-Norway Interpretation
02:22:38 -!- augur has quit (Remote host closed the connection).
02:25:05 <oerjan> http://en.wikipedia.org/wiki/Erich_Fried
02:25:14 <oerjan> (the poet of the above)
02:26:12 <elliott> oerjan: i'm going to assume he was being *slightly* sarcastic :)
02:26:22 <oerjan> elliott: you don't say :D
02:28:12 <elliott> Gregor: You should donate like three servers to me.
02:29:35 <elliott> Gregor: WHY HAVEN'T I RECEIVED THEM YET
02:30:19 <oerjan> "Do not doubt him who tells you he is afraid, but be afraid of him who tells you he has no doubts."
02:33:48 <Gregor> elliott: That would leave me with -3 servers.
02:35:17 * Sgeo gives Gregor i servers
02:35:36 * Sgeo steals j servers from Gregor
02:36:19 <elliott> Gregor: Seriously, kill him.
02:37:02 * Sgeo multiplies elliott by i
02:37:27 * oerjan quantum collapses Sgeo
02:42:32 <pikhq> ... *Anyone* still uses DES?
02:43:14 <pikhq> elliott: ... *That's* how X11 settings get set?
02:43:29 <elliott> pikhq: Seemingly! (That's for overriding stuff.)
02:43:49 <elliott> pikhq: The DES thing was Gawker. Their password DB got stolen and they've cracked two hundred thousand passwords or so.
02:43:56 <elliott> Serves them right too, Gawker are scum.
02:44:18 <pikhq> Takes a complete moron to continue using DES.
02:44:49 <pikhq> It was demonstrated to be entirely practical to crack 10 years ago...
02:45:35 <Sgeo> What about Triple-DES?
02:46:39 <elliott> Sgeo: (Well, yes, it works. For now.)
02:46:47 <pikhq> Sgeo: Triple DES is not comically poor.
02:47:06 <pikhq> Sgeo: *However*, there are much better encryption schemes to use.
02:47:07 <Sgeo> All these things are "for now"
02:47:10 <elliott> pikhq: Wanna build an FPGA DES cracker and run it on the database? (Not publicly leaked yet, but ...)
02:47:20 <pikhq> elliott: I don't have $10,000 handy.
02:47:22 <elliott> Sgeo: Okay, firstly: IT WAS PASSWORDS.
02:47:27 <elliott> YOU DO NOT ENCRYPT PASSWORDS
02:47:44 <pikhq> ... WAITWAITWAIT THEY ENCRYPTED THE PASSWORDS WITH DES WHY GOD WHY
02:47:45 <Sgeo> Why would someone encrypt a password?
02:47:47 <elliott> pikhq: http://www.sciengines.com/copacobana/
02:48:13 <elliott> I wonder how they cracked so many so quickly.
02:48:38 <pikhq> elliott: With $10k worth of FPGAs.
02:48:39 <Sgeo> Is it possible for them to crack several without actually determining the key?
02:48:53 <pikhq> http://www.sciengines.com/copacobana/photos/photo_b4.jpg
02:49:03 <Sgeo> Fun thing, I have undone cryptography and computer security homework that I'm putting off at this moment
02:49:03 <elliott> pikhq: Are you sure that's $10k worth. Just buy evaluation boards :P
02:49:15 <elliott> Sgeo: NEVER EVER DO CRYPTOGRAPHY *EVER*
02:49:17 <Sgeo> I should look for my textbook or something
02:49:22 <elliott> That is directed specifically at you.
02:49:39 <Sgeo> elliott, uh... why?
02:49:45 <pikhq> elliott: Still... Even if it is $10k, that's still *terrible* encryption.
02:50:03 <pikhq> That's seriously at the point of "if any single person wants it fairly badly, they can have it."
02:50:08 <Sgeo> And surely you don't think I'm a security moron, do you? I mean, maybe I don't follow best practices in my own life, but
02:50:59 <pikhq> And, of course, any business or government would hardly think anything of it.
02:51:38 <elliott> Sgeo: Almost nobody should try and write cryptographic code.
02:51:48 <elliott> I would yell the same at pikhq and ais523.
02:51:59 <elliott> But you get a special, additional message.
02:52:02 <elliott> That message is: NEVER EVER
02:52:16 <pikhq> Rule #1 of cryptography is you will almost certainly fuck it up.
02:52:22 <oerjan> he'd probably even yell it at himself. i hope.
02:53:02 <Sgeo> I still have homework I haven't done
02:53:10 <oerjan> in fact every morning he stands in front of the mirror for 10 minutes yelling "DON'T DO CRYPTOGRAPHY!"
02:53:22 <oerjan> it's a wonder they let him out of that institution, really.
02:53:55 <oerjan> pikhq: i don't think anyone added it
02:54:10 <Sgeo> In 7 min, I'm quitting IRC
02:55:00 <HackEgo> 7) <oerjan> what, you mean that wasn't your real name? <Warrigal> Gosh, I guess it is. I never realized that. \ 19) <oerjan> ehird has gone insane, clearly. \ 21) <fungot> oerjan: are you a man, if there weren't evil in this kingdom to you! you shall find bekkler! executing program. please let me go... put me out! he's really a
02:55:06 <elliott> `run quote oerjan | tail -n 2
02:55:08 <HackEgo> 195) <oerjan> it's not obvious from quantum mechanics that you can destroy a universe arbitrarily. \ 247) <elliott> oerjan: What, can girls aim their penises better?
02:55:16 <elliott> oerjan: what did you do to the quote
02:55:37 <oerjan> nothing, and i do not recall anyone actually _adding_ it to HackEgo in the first place
02:56:13 <elliott> 18:47:56 <pikhq> oerjan: No, I definitely meant E=m. Who cares about the energy of an object in motion, anyways? :P
02:56:13 <elliott> 18:48:50 <oerjan> THAT IS THE KIND OF ATTITUDE THAT HAS LEAD TO THE CURRENT OBESITY EPIDEMIC
02:56:13 <elliott> 18:49:22 <elliott> oerjan: :D
02:56:13 <elliott> 18:49:36 <elliott> oerjan: you need like a web form where people can file requests to be married to you, just for a few weeks
02:56:13 <elliott> 18:49:39 <elliott> it could be very profitable
02:56:15 <elliott> 18:49:53 <pikhq> oerjan: :D
02:56:17 <elliott> 18:50:18 <elliott> pikhq: don't you agree, i mean
02:56:19 <elliott> 18:50:24 <elliott> that comment totally warrants brief matrimony.
02:56:21 <elliott> hard to condense to quote size
02:59:58 <elliott> oerjan: ban him after the 7 minutes
03:00:46 -!- benuphoenix has joined.
03:00:50 <oerjan> I'm sorry, Elliott. I'm afraid I can't do that.
03:01:15 <elliott> oerjan: you're now my least favourite insane all-powerful AI.
03:01:20 <elliott> oerjan: (previously you were my favourite)
03:01:39 <oerjan> i'm not very all-powerful really. ok maybe just a little.
03:02:59 -!- benuphoenix has quit (Client Quit).
03:03:37 <elliott> oerjan: YOU SHOULD COME BACK TO AGORA
03:03:52 <elliott> the great thing is, it's so boring now that you don't have to do anything
03:05:03 <Sgeo> I was outside with the dog
03:05:11 <Sgeo> I should probably look for my textbook or something
03:05:16 <elliott> oerjan: it's been two minutes
03:05:20 <Sgeo> Or do the ambiguous Perl project
03:06:09 <elliott> Sgeo: IT'S BEEN SEVEN MINUETS
03:06:20 <oerjan> more like twelve, actually
03:06:38 <Sgeo> My laptop's acting broken
03:06:45 * Sgeo gives his laptop the middle finger
03:06:50 <elliott> Sgeo: that does not stop you quitting IRC
03:06:57 <elliott> oerjan: can't you see he has a problem
03:06:59 <elliott> oerjan: YOU MUST BE THE REMEDY
03:07:37 <elliott> Sgeo: GOATS HATE YOUR CONNECTION
03:07:50 <oerjan> elliott: well but don't you see, if i banned people for procrastinating here, i'd have to ban myself too
03:08:06 <elliott> oerjan: yeah but you don't say "OKAY I'M GOING IN N MINUTES" and then not :D
03:08:14 <elliott> Vorpal only gets away because → is not *yet* regulated
03:08:49 <oerjan> also, he actually _does_ occasionally sleep at nighttime
03:09:23 <oerjan> well me too although that's more of a pseudorandom accident
03:10:57 -!- Sgeo_ has joined.
03:10:58 <oerjan> what's this talk, have you gone batshit insane?
03:11:01 * pikhq → nowhere in particular
03:11:18 <Sgeo_> Darn, I thought Sgeo would have pinged out by now
03:11:28 <elliott> Sgeo_: ENTERING IS NOT LEAVING
03:11:29 <Sgeo_> "He quit, yay!" "Wait, he's back"
03:11:49 <elliott> Sgeo_: didn't you buy some fucking melatonin
03:11:57 -!- Sgeo has quit (Ping timeout: 245 seconds).
03:12:03 <Sgeo_> Sleep is not my issue here
03:12:06 <Sgeo_> My issue is homework
03:12:18 <Sgeo_> Piles and piles of homework
03:12:22 <oerjan> Sgeo_: when i get thrown off here i usually have to kill my irssi after logging on again
03:12:23 <elliott> well take some anyway just for the hell of it
03:12:34 <elliott> Sgeo_: i'll give you $15 for every hour you stay up on Melatonin after the first
03:12:36 <oerjan> because of this going through a shell account
03:12:44 <elliott> i.e., take regular melatonin dose, first hour passes, then $15 for every full hour after that
03:12:53 <Sgeo_> elliott, maybe in 2 weeks
03:13:15 <oerjan> i wonder if my doctor would give me melatonin if i asked
03:13:29 <elliott> oerjan: well it's over-the-counter in most places
03:13:39 <elliott> oerjan: WP says it's prescription-only in the uk but it isn't since you can buy it anyway
03:13:51 <elliott> oerjan: failing that just import it http://melatonin.com/ :P
03:14:01 <pikhq> It's considered a dietary supplement in the US.
03:14:22 <pikhq> Meaning it isn't even fucking regulated beyond actually having to contain only what it claims to contain.
03:14:39 <elliott> pikhq: it's on all those vaguely-new-agey ~herbal remedies~ websites over here
03:15:03 <Sgeo_> Tobacco: All natural. Must be good for you, try some today!
03:15:07 <oerjan> apparently it requires a prescription in norway
03:15:14 <pikhq> Sgeo_: Your body doesn't produce tobacco.
03:15:19 <oerjan> norway is pretty strict about such things, i think
03:15:23 <elliott> oerjan: oh well, just import it anyway :D
03:15:41 <Sgeo_> I was more mocking herbal stuff than anything connected to melatonin
03:15:43 <elliott> oerjan: i mean worst case, you get outraged headlines talking about the drug smuggling charges for ... melatonin on the national newspapers
03:15:49 <elliott> oerjan: and that would be hilarious.
03:15:54 <pikhq> Sgeo_: Ah. Fair enough.
03:16:11 <oerjan> elliott: well there wouldn't be anything wrong with _asking_ my doctor would it, given that i actually have an appointment on thursday
03:16:14 <Sgeo_> Hmm. What does the body produce that you shouldn't take in more of?
03:16:24 <elliott> oerjan: well maybe he'll find out about your cocaine habit
03:17:04 <elliott> oerjan: that's what he wants you to think
03:17:09 <Sgeo_> A shee? Creator of norns?
03:17:19 <elliott> oerjan: ok seriously, ban him
03:17:22 <elliott> you have justification now
03:17:38 <Sgeo_> Just heard a cat yelping. Got frightened, then realized that my cat is right here
03:18:50 <Sgeo_> In homeroom, which was in a science classroom: "Hey Seth, what's HCI? Is it safe to drink?"
03:19:22 <Sgeo_> elliott, not against me. I'm saying what the person said...
03:19:34 <pikhq> I'm not sure HCI is possible.
03:20:07 <Sgeo_> What about H#C#I# for nonzero #?
03:20:15 <Sgeo_> Erm, possibly different numbers
03:21:46 <pikhq> Probably *possible*, not necessarily all that *stable*.
03:23:45 <Sgeo_> elliott, if you help me find my textbook... hm, I have nothing of value to give you. But since it's physically impossible for you to help me find it anyway
03:24:01 <oerjan> "Methyl iodide, also called iodomethane, and commonly abbreviated "MeI", is the chemical compound with the formula CH3I."
03:24:09 <elliott> Sgeo_: The one thing of value you could give me is for you to leave right now.
03:24:40 <Sgeo_> I hope you realize that I'm not taking you seriously
03:24:58 <elliott> Sgeo_: Um, I was really serious there.
03:25:08 <oerjan> Sgeo_: that's supposedly simplest organic iodine compound
03:25:20 <elliott> you're the simplset organic iodine compound
03:27:57 <oerjan> no i'm really more a puppy
03:28:14 <Sgeo_> Ok, 3 min, I leave
03:28:41 <elliott> oerjan: also, i hate dogs, so you're a kitten
03:28:48 <Sgeo_> elliott, what's with the me-hate?
03:28:59 <elliott> Sgeo_: i'm just trying to help you achieve your goals
03:29:06 <elliott> which also coincides with my goals, which are to be an asshole
03:29:20 <Sgeo_> My goal is to get my homework done. If I could do that and stay on IRC, I would
03:29:37 <Sgeo_> Although avoiding IRC hasn't helped in the past...
03:29:50 <elliott> i bet next class you'll learn about looping through an array!
03:29:51 <oerjan> "Industrially significant organoiodine compounds, often used as disinfectants or pesticides, are iodoform (CHI3), methylene iodide (CH2I2), and methyl iodide (CH3I)."
03:30:31 -!- Sgeo_ has quit (Quit: Leaving).
03:31:10 <elliott> oerjan: can you ban him anyway?
03:34:26 -!- Sasha2 has joined.
03:36:54 -!- Sasha has quit (Ping timeout: 265 seconds).
03:41:46 <elliott> hmm so if pastebins, url shorteners and image hosters are the same thing maybe EVERYTHING Is
03:44:10 -!- poiuy_qwert has joined.
03:47:19 -!- augur has joined.
03:54:31 <elliott> ais better be more active tomorrow
03:57:21 <elliott> sed 's/^X//' > \R\E\A\D\_\M\E << '+ END-OF-FILE '\R\E\A\D\_\M\E
03:57:22 <elliott> X#This file is part of the Concurrent Versions System CVS.
03:57:27 <elliott> remind me to use that in ddshar maybe
03:57:34 <elliott> oh wait i can't really, not with this architecture
03:57:41 <elliott> remind me to do ddshar properly, then
03:58:28 -!- quintopi1 has joined.
03:58:34 -!- quintopi2 has joined.
03:59:38 <elliott> [[# No versioning of symbolic links. Symbolic links stored in a version control system can pose a security risk - someone can create a symbolic link index.htm to /etc/passwd and then store it in the repository; when the "code" is exported to a Web server the Web site now has a copy of the system security file available for public inspection. A developer may prefer the convenience and accept the responsibility to decide what is safe to version and
03:59:38 <elliott> what is not; a project manager or auditor may prefer to reduce the risk by using build scripts that require certain privileges and conscious intervention to execute.]]
03:59:49 -!- quintopi2 has quit (Client Quit).
04:00:38 <elliott> [[OpenCVS is a BSD-licensed implementation of the popular Unix version control software called Concurrent Versions System. OpenCVS is developed as a part of the OpenBSD project by Jean-Francois Brousseau, Joris Vink, Xavier Santolaria, Niall O'Higgins and others.
04:00:38 <elliott> OpenCVS aims to be as compatible as possible with the GNU CVS implementation without compromising security or source code correctness, and to provide better access control.[1] As of October 2010[update], the project website claims that "OpenCVS is to be released soon"[2] and the project shows CVS activity as recent as August 1st, 2010. The project is still actively being developed.
04:00:39 <elliott> Because of the development of OpenCVS the developers saw the need for OpenRCS also and OpenBSD has started to develop a free and secure version of RCS also.]]
04:01:30 <elliott> RCS was first released in 1982[1] by Walter F. Tichy while he was at Purdue University as a free and more evolved alternative to the then-popular Source Code Control System (SCCS). It is now part of the GNU Project, who is still maintaining it. The current development version is 5.7.95 (released on 2010-12-02,[2] is a step toward the first release since 1995[3]—5.8 is planned to be released “in a week or so”.[3]
04:02:18 <elliott> Haha wow, Jörg Schilling maintains SCCS.
04:02:49 -!- quintopi1 has quit (Client Quit).
04:02:55 -!- p_q has joined.
04:03:34 -!- poiuy_qwert has quit (Ping timeout: 240 seconds).
04:04:15 -!- elliott has quit (Quit: Leaving).
04:07:01 -!- hagb4rd has joined.
04:11:32 <quintopia> damn it took him forever to get to bed :P
04:11:47 <quintopia> (hi elliott! i love you i promise!)
04:23:53 -!- Sasha has joined.
04:26:43 -!- Sasha2 has quit (Ping timeout: 260 seconds).
04:39:42 -!- CPi has joined.
04:44:34 <quintopia> was just gonna ask someone to do that
04:46:06 <oerjan> `translatefromto en zh Don't you like our topic? :D
04:47:25 <oerjan> `translatefromto zh en 你不喜欢我们的话题？
04:47:26 <CPi> 你们喜欢用英文，这很正常。但你们的标题我不太认同
04:47:26 <HackEgo> You do not like our topics?
04:47:49 <oerjan> `translatefromto zh en 你们喜欢用英文，这很正常。但你们的标题我不太认同
04:48:00 <HackEgo> Do you like English, this is normal. But I do not agree with your title
04:49:00 <oerjan> `translatefromto en zh It's just meant as a joke anyhow.
04:51:03 -!- oerjan has set topic: If this topic doesn't confuse you, you haven't understood it properly. | http://tunes.org/~nef/logs/esoteric/?C=M;O=D.
04:52:40 <CPi> 我想大家都没有什么恶意，只是在开放的网络，更需要开放的精神，还有中国人的胸怀
04:53:11 <oerjan> `translate 我想大家都没有什么恶意，只是在开放的网络，更需要开放的精神，还有中国人的胸怀
04:53:13 <HackEgo> I think everybody does not mean anything, but in an open network, more needs to open up the spirit of the Chinese people's mind there
04:53:33 <HackEgo> I'm sorry to bother friends
04:54:09 -!- CPi has quit (Quit: Leaving).
05:00:51 <quintopia> i was gonna change topic to "this topic is as subtle as your penis" but that's not really the medium for that joke
05:01:29 <oerjan> don't do that, if our previous topic attracted furious chinese, then that might attract furious women
05:01:55 <quintopia> although it's especially apt for women
05:03:16 <quintopia> how about "this topic is as subtle as the idea of a penis as a status symbol for males" :P
05:07:44 <quintopia> ("she" is traditionally taken to be "your mom")
05:09:48 <Gregor> WANTED (soon): Pithy, short, well-known phrases about evil.
05:10:05 <Gregor> (Which include the word "evil")
05:10:15 <oerjan> The love of money is the root of all evil.
05:14:32 <oerjan> Hear no evil, see no evil, speak no evil.
05:15:42 <oerjan> *See no evil, hear no evil, speak no evil.
05:16:22 -!- TLUL has joined.
05:19:24 <oerjan> All that is necessary for the triumph of evil is that good men do nothing.
05:21:37 <Mathnerd314> Gregor: what are you going to do with them?
05:21:48 <Gregor> Trying to get the best pithy title for a paper about eval :P
05:22:04 <Gregor> The Root of All Eval was vetoed as being misleading since we're not about provenance.
05:23:15 <Gregor> The current title is The Eval that Men Do, but I think we can do better.
05:24:49 <Gregor> That's already used for a subsection, with a question mark (A Necessary Eval?)
05:25:48 <Gregor> Seems a bit more biased than we want in a title for a scientific paper :P
05:26:25 <Mathnerd314> Gregor: anything you write is going to bring up evil-eval associations, so...
05:26:32 <oerjan> this bible site is darn slow
05:27:17 <oerjan> Mathnerd314: THAT'S CHEATING
05:27:29 <Gregor> Mathnerd314: It's supposed to bring up evil-eval associations of course, but the title, not taken as a pun, should not be biased. The bias should only be through the pun :P
05:28:12 <oerjan> To fear the LORD is to hate evil
05:28:29 * oerjan whistles innocently^Wevilly
05:30:10 <oerjan> entertain evil thoughts in your hearts?"
05:31:02 <oerjan> ah here i think is the one i was looking for: "The Heart of the Sons of Men Is Full of Evil"
05:31:51 <Gregor> Mathnerd314: It's an in-depth study of how eval is used in real-world code.
05:31:51 * oerjan hazards a guess it's about eval somehow
05:32:53 <Mathnerd314> hmm, the eval that men do is actually descriptive
05:33:28 <Gregor> But it's not pithy enough :P
05:33:36 <Gregor> It'll do if we don't find anything better
05:35:28 * Gregor whistles the Star Wars theme
05:36:13 <Gregor> I seem to recall some short phrase involving "the nature of evil", but can't find it ...
05:37:33 * Mathnerd314 is now looking at Wikipedia titles, which have much less noise
05:39:47 <Gregor> I think "Resident Eval" wins the worst-possible-name award.
05:39:53 <Gregor> (Using the same method :P )
05:42:51 <Gregor> Deliver Us from Eval X-D
05:44:07 -!- asiekierka has joined.
05:44:52 -!- hagb4rd has quit (Ping timeout: 245 seconds).
05:47:23 <Gregor> Yeah, unfortunately I think The Eval that Men Do is still the best :(
05:47:52 <quintopia> yeah i think it suits your paper best as well
05:48:33 <quintopia> (but when you find a good reason to write a paper called "The Life of Eval Knieval" let me know)
05:50:53 <Mathnerd314> Gregor: on the other hand, now you know how to quickly find good titles if you're completely stuck
05:51:15 <quintopia> i would be surprised if he had not done this before
05:51:29 <Gregor> Now I need to find how to name a subsection Lord Deliver Us from Eval
05:51:53 <quintopia> drop the lord and you can find a way
05:52:42 <quintopia> also, since it is the worst-possible-name, resident eval deserves a subsection
05:53:33 <Mathnerd314> Gregor: IMO "the eval empire" should also be in there
05:53:55 <Gregor> Mathnerd314: It's a good'n, but I don't know what it means :P
05:54:25 <quintopia> how about you have a section judging whether uses of eval are legitimate or stupid
05:54:47 <Mathnerd314> Gregor: used by Ronald Reagan to refer to the Soviet Union
05:55:00 <Gregor> Mathnerd314: Nonono, I don't what it means in terms of eval
05:55:11 <Gregor> quintopia: ... *barf* :P
05:55:47 <Mathnerd314> no, you use it for the introduction... "widespread use of eval", etc.
05:59:05 <Gregor> See No Eval, Hear No Eval can be a title for a subsection about how most analyses simply ignore eval 8-D
06:03:50 <Mathnerd314> only Gregor knows the results of his paper, and whether or not eval is banal
06:03:52 <Vorpal> Gregor, eval considered harmful?
06:04:04 <Vorpal> I'm sure this has been done
06:05:06 <Gregor> Vorpal: "Considered Harmful" Papers Considered Harmful
06:07:18 <Mathnerd314> Gregor: does your paper end up showing that eval is banal?
06:07:57 <Gregor> Mathnerd314: You could say that
06:08:01 <quintopia> the conclusion should definitely be called the evaluation instead
06:09:25 <Mathnerd314> "A Report on the Banality of Eval" is a better title
06:09:29 <Gregor> Mathnerd314: Is that a reference to something though?
06:10:03 <Mathnerd314> yeah, http://en.wikipedia.org/wiki/Banality_of_evil
06:13:00 -!- asiekierka[2] has joined.
06:15:06 -!- asiekierka has quit (Ping timeout: 260 seconds).
06:16:33 <Gregor> Mathnerd314: I can't guarantee that it's going to appear anywhere :P
06:16:46 <Gregor> Mathnerd314: But we're aiming for ECOOP, which luckily is non-anonymous so I can talk about it :P
06:17:13 <quintopia> Gregor: how does non-anonymous peer review work?
06:17:48 <quintopia> Gregor: advance copies for everyone here, right? eyes only?
06:18:07 <Gregor> quintopia: Uhhh, like any other peer review? Remove conflicts of interest, and don't be "that guy" who treats people preferentially :P
06:18:50 -!- asiekierka has joined.
06:18:50 <Gregor> This is the third paper I've published this term, but the first I've mentioned here since the other two have been anonymous :P
06:19:35 -!- asiekierka[2] has quit (Ping timeout: 240 seconds).
06:20:05 <Gregor> If somebody wants to proofread it on Wednesday, maybe :P
06:26:36 <Mathnerd314> Gregor: why can't I read it now? just throw it up somewhere like arXiv, Google docs, etc.
06:26:39 <oerjan> ...for some of us it's the concept of an _anonymous_ paper which boggles the mind :D
06:26:54 <Gregor> Right now it's a giant pile of graphs with little explanation :P
06:27:01 -!- zzo38 has joined.
06:27:02 <Gregor> oerjan: Anonymous only for review
06:27:57 <coppro> when will they become nonymous?
06:28:46 <Gregor> coppro: When/if published :P
06:30:29 <oerjan> well i'm not _sure_ if math uses anonymous review, the times i was asked it certainly wasn't. in any case keeping it secret for anyone _other_ than the reviewere sounds weird, given that we basically give preprints to anyone who could want one...
06:31:21 <quintopia> so gregor, what were the other papers about, vaguely?
06:31:36 <Gregor> oerjan: Well, you're supposed to make a best-faith effort not to reveal that information just in case someone knows someone who knows someone, unless you actually intend to work with them.
06:31:41 <Gregor> quintopia: JavaScript and JavaScript.
06:31:45 <quintopia> (not vaguely because you have to keep them secret. vaguely because i don't care enough to hear details)
06:32:01 <quintopia> do you write about anything but js?
06:32:12 <Gregor> quintopia: Not right now ;P
06:32:38 <oerjan> Gregor: _and_ we give talks at conferences about the work, too.
06:32:50 <Gregor> oerjan: ... yes, that's the whole point of a conference.
06:33:21 -!- hagb4rd has joined.
06:33:34 <quintopia> it's because judging the work based on its author is such a good nutjob-filtering heuristic in math, anonymous review would break the field.
06:33:37 <oerjan> and unless it's a very big field it would be extremely likely for the reviewere to be at that conference, i should think...
06:33:39 * Gregor wonders wtf oerjan thinks Gregor means by "anonymous submission" :P
06:34:11 <Gregor> oerjan: These are /conference/ submissions.
06:34:22 <Gregor> oerjan: Conferences are the journals of Computer Science.
06:34:47 <quintopia> i think math should go that way too
06:34:57 <oerjan> ok i guess it's not common to have pre-reviewed conference talks in math either
06:35:50 <Gregor> oerjan: A non-pre-peer-reviewed conference in CS is called a joke :P
06:39:57 <Gregor> ... not a good joke I'll admit.
06:42:10 <quintopia> speaking of jokes, i hear doug presented the chicken paper at a conference. wish i could have been there.
06:42:13 <Mathnerd314> Gregor: why? they just need some way to, after the first minute, shut them up and say "next"
06:43:29 <Gregor> Mathnerd314: That's just how CS works. Journals are generally considered sort of an olde and musty means of doing things, used only for extremely drab things like giant proofs and shit, conferences are just the equivalent for new and ongoing stuff.
06:44:26 <Gregor> Idonno how math works :P
06:48:12 -!- hagb4rd has quit (Ping timeout: 245 seconds).
06:58:42 -!- asiekierka has quit (Ping timeout: 272 seconds).
07:32:37 <zzo38> Now I have the H. Lee hand grenade of Auntie Ock.
07:39:27 -!- Sasha2 has joined.
07:41:29 -!- Sasha has quit (Ping timeout: 265 seconds).
07:56:15 -!- hagb4rd has joined.
07:59:59 -!- clog has quit (ended).
08:00:00 -!- clog has joined.
08:05:01 -!- Mathnerd314 has quit (Quit: ChatZilla 0.9.86-rdmsoft [XULRunner 1.9.2.12/20101026210630]).
09:05:42 -!- zzo38 has quit (Remote host closed the connection).
09:20:36 -!- zzo38 has joined.
09:21:15 -!- nooga has quit (Ping timeout: 240 seconds).
09:38:11 -!- quintopia has quit (Quit: Lost terminal).
09:38:32 -!- quintopia has joined.
09:44:14 -!- evincar has joined.
10:02:05 -!- ais523 has joined.
10:09:13 -!- hagb4rd has changed nick to hagb4rd|afk.
10:25:58 -!- quintopia has quit (Quit: Lost terminal).
10:37:57 -!- quintopia has joined.
10:44:27 -!- quintopia has quit (Quit: Lost terminal).
10:44:43 -!- quintopia has joined.
10:45:41 -!- quintopia has quit (Client Quit).
10:46:34 -!- quintopia has joined.
10:50:20 -!- evincar has quit (Quit: ChatZilla 0.9.86 [Firefox 3.6.13/20101203075014]).
10:51:48 -!- quintopi1 has joined.
10:52:21 -!- quintopia has changed nick to Guest36478.
10:53:09 -!- quintopi1 has changed nick to quintopia.
10:59:16 -!- ais523 has quit (Ping timeout: 240 seconds).
11:18:48 -!- quintopia has quit (Quit: Lost terminal).
11:18:55 -!- quintopia has joined.
11:19:18 -!- quintopia has quit (Client Quit).
11:19:18 -!- Guest36478 has quit (Quit: Lost terminal).
11:19:33 -!- quintopia has joined.
11:22:46 -!- hagb4rd|afk has changed nick to hagb4rd.
11:23:38 -!- TLUL has quit (Quit: *disappears in a puff of orange smoke*).
11:27:03 -!- quintopia has quit (Quit: Lost terminal).
11:27:15 -!- quintopia has joined.
11:33:57 -!- quintopia has quit (Quit: Lost terminal).
11:34:13 -!- quintopia has joined.
11:43:44 -!- quintopia has quit (Quit: Lost terminal).
11:43:52 -!- quintopia has joined.
12:20:52 -!- FireFly has joined.
12:23:14 -!- quintopia has quit (Quit: Lost terminal).
12:24:23 -!- oerjan has quit (Quit: leaving).
12:25:25 -!- quintopia has joined.
12:28:32 -!- quintopia has quit (Client Quit).
12:29:10 -!- hagb4rd has quit (Ping timeout: 240 seconds).
12:29:26 -!- quintopia has joined.
12:32:28 -!- wareya has quit (Ping timeout: 272 seconds).
12:33:58 -!- Sasha2 has quit (Ping timeout: 240 seconds).
12:34:40 -!- Sasha has joined.
12:51:49 -!- atrapado has joined.
13:23:11 -!- hagb4rd has joined.
13:31:00 -!- ais523 has joined.
13:55:31 -!- wareya has joined.
14:13:48 -!- wareya has quit (Ping timeout: 272 seconds).
14:27:10 -!- wareya has joined.
14:43:27 -!- p_q has quit (Quit: This computer has gone to sleep).
14:44:29 <ais523> hmm, you know your job is potentially awesome when you come up with a valid reason to play Enigma during a meeting, and even tell the other people there you're doing so
14:46:15 <hagb4rd> its even better when there is no need to tell the others at all
15:06:06 -!- asiekierka has joined.
15:10:52 <ais523> hagb4rd: nah, I could get away with that sort of thing nearly all the time, nobody pays attention to what you're doing
15:17:11 -!- olsner has quit (Ping timeout: 255 seconds).
15:17:56 -!- elliott has joined.
15:18:46 -!- olsner has joined.
15:21:29 <elliott> so olsner wtf is that stuff you have to do before long mode your code is magic :D
15:32:02 -!- sftp has joined.
15:39:37 -!- hagb4rd has quit (Quit: hagb4rd).
15:40:56 -!- nopseudoidea has joined.
15:43:31 -!- nopseudoidea has left (?).
15:50:31 -!- hagb4rd has joined.
15:59:02 -!- hagb4rd has quit (Ping timeout: 245 seconds).
15:59:05 -!- augur has quit (Remote host closed the connection).
15:59:21 -!- Phantom_Hoover has joined.
15:59:29 -!- augur has joined.
16:02:12 <Phantom_Hoover> Thing that annoys me about Minecraft: you get flint from gravel.
16:02:16 -!- Sgeo has joined.
16:02:32 <Vorpal> Phantom_Hoover, why does that annoy you?
16:02:43 <Sgeo> No way I'd be able to focus on homework for a different class
16:02:57 <Vorpal> Phantom_Hoover, but boats accelerating up waterfalls due to floating on water doesn't bother you?
16:03:02 <Sgeo> Nor am I willing to pirate a textbook (I own the physical copy) and I obviously don't have the textbook with me
16:03:20 <Vorpal> Phantom_Hoover, arguably that is a much larger error
16:03:57 -!- augur has quit (Ping timeout: 240 seconds).
18:04:41 -!- clog has joined.
18:04:41 -!- clog has joined.
18:04:44 <elliott> ais523: reason I don't think it should be .scapegoat, btw: it's not configuration, and it's not a cache; it's an actual directory with useful contents, just not one you want at the top of your file lists
18:04:49 <ais523> gah, this convo hasn't been logged
18:05:09 <elliott> i'll put it on a pastebin in a bit
18:05:19 <ais523> evil idea: paste the entire log in-channel, so that a) clog logs it, and b) Vorpal gets to read it
18:05:28 <elliott> ais523: I've done that before, during much shorter outages
18:05:30 <ais523> (also, probably bad idea)
18:05:38 <elliott> ais523: oh, and also, servers
18:05:44 <elliott> ais523: you don't want to have a directory foo/ with just .scapegoat in it
18:05:45 <ais523> does sprunge stay around forever?
18:06:03 <elliott> there's no real reason you shouldn't be able to do, e.g.
18:06:12 <ais523> darcs uses _darcs, which isn't ideal but which is better than .svn or whatever
18:06:41 <elliott> ~/awesomeproject$ cp -R @scapegoat /var/scapegoat/awesomeproject
18:06:59 <elliott> and scapegoat when pulling would basically go "is this directory a scapegoat repository? if not, look at ./@scapegoat"
18:07:11 <elliott> ais523: _darcs is actually like that solely for Windows
18:07:21 <ais523> I didn't even realise it ran on Windows
18:07:30 <ais523> is that why it doesn't record permissions?
18:07:32 <elliott> ais523: and people (even me...) have lobbied to change it to .darcs... regretfully
18:07:41 <elliott> ais523: it only runs on windows through some half-cygwin monster, I think
18:07:57 <ais523> (also, we so need an ISO 646 for permissions, i.e. a permission subset that works everywhere sane)
18:08:08 <elliott> ais523: the problem with _darcs that you really want something that comes after everything in the alphabet; just like you name things README and INSTALL so they sort first alphabetically, the scapegoat directory should come last to avoid annoyance
18:08:13 <ais523> (then we can invent trigraphs for permissions that aren't there)
18:08:26 <ais523> and I get used to ignoring a load of junk at the start of ls outputs
18:08:40 <ais523> in fact, last is probably more readable than first because of the way terminals scroll
18:08:44 <ais523> first scrolls off before last does
18:08:48 <elliott> ais523: I say we just track Unix permissions in the actual implementation (it can be abstracted out as metadata in the specification) and forget Windows even exists
18:09:00 <elliott> <ais523> in fact, last is probably more readable than first because of the way terminals scroll
18:09:03 <elliott> yes, but e.g. graphical file managers
18:09:08 <elliott> README and INSTALL go first, which is nice
18:09:12 <ais523> wow, I forgot they existed for a while
18:09:29 <ais523> and I'm far from a live-inside-the-terminal sort of person
18:09:31 <elliott> I actually use Nautilus occasionally :)
18:09:40 <ais523> specifically, for opening Enigma levels
18:09:51 <ais523> I'm not entirely sure why; I just developed different workflows for different sorts of file for some reason
18:09:57 <Deewiant> Oh, is that why README and co. are uppercased? Too bad that not all LC_COLLATEs operate that way
18:10:16 <ais523> why not do it Makefile-style and just uppercase the first letter?
18:10:26 * elliott makes mental note to make sure scapegoat implementation is in C, because it's flexible enough that the overhead of something else is probably a bad idea :)
18:10:28 <Deewiant> I always figured it was just to make them stand out
18:10:30 <ais523> I know README sorts to the middle in my ls
18:10:40 <elliott> well, you see 00README on ftp servers a lot
18:10:44 <Deewiant> I'm mostly just wondering about en_US
18:10:58 <ais523> Deewiant: mine's en_GB.UTF-8, I think
18:11:00 <Deewiant> Because if that doesn't work that way, then most people probably don't see it like that :-P
18:11:11 <ais523> even though there's no actual reason to use UTF-8 for British English other than the £ sign
18:11:16 <ais523> also, you use British English?
18:11:17 <elliott> Deewiant: you're... en_GB.UTF-8?
18:11:29 * elliott 's mind causes a fault or two
18:11:44 <Deewiant> $ locale | sed 's/"//g' | cut -d= -f2 | sort -u
18:11:44 <ais523> elliott: btw, I needed this conversation to regain my sanity
18:11:54 <ais523> the Linux keylogger thing was as disasterous as you might have imagined
18:12:38 <ais523> it's not nice debugging code where the only indication that something went wrong is that the entire system crashes hard (apart from interrupt handlers; and as the keylogger hooks the keyboard interrupt, any key you press to try to fix the problem makes things worse)
18:13:01 <elliott> ais523: you do realise you can gdb linux?
18:13:06 <ais523> Phantom_Hoover: I'm paid to help people work on exercises, even if they were terribly flawed in the first place
18:13:14 <ais523> elliott: I didn't, in fact I thought it was impossible
18:13:24 <ais523> and gdb on the keyboard interrupt handler is asking for a disaster
18:13:31 <ais523> as you'd have to use, umm, telepathy to control it?
18:13:39 <elliott> ais523: umm, you run Linux in qemu or whatever
18:13:41 <ais523> (the handler in question is called on mouse movements and clicks too)
18:13:43 <elliott> ais523: and attach gdb to it from outside
18:13:48 <ais523> oh, that makes more sense
18:13:56 <elliott> ais523: well, technically, it's over a serial port
18:14:00 <elliott> ais523: but you just tell qemu to emulate a serial port
18:14:08 <ais523> we're using the serial console in the NetHack TAS
18:14:12 <elliott> (good luck debugging the serial driver...)
18:14:17 <ais523> also, the Debian installer, modified to run NetHack
18:14:36 <ais523> the serial console because it was faster than waiting for the network connection to come up
18:14:57 <elliott> ais523: ooh, let's argue about what hash function to use to identify things!
18:14:59 <ais523> and the Debian installer beause we were trying to strip down Debian and then realised that the installer itself was Linux-based, really small, and ran a single program
18:15:26 <elliott> (GUIDs are lame, (1) they're random numbers, which feels so unplatonic and bad, and (2) hash-addressing is awesome, because it constitutes a near-certain proof that you know what the content is)
18:15:29 <ais523> (it no longer actually installs Debian, unfortunately; that'd have been pretty fun if it did)
18:15:54 <elliott> ais523: btw, the Debian installer has an actual name, although not the part you mean
18:16:00 <elliott> the installer program itself is called debian-installer
18:16:06 <elliott> you probably mean "the Debian installer environment"
18:16:12 <elliott> ais523: anyway, hash arguing! the most fun and pointless sport there is
18:16:30 <ais523> what about SHA-(maximum filename length on Windows)
18:16:37 <ais523> because it's probably shorter than UNIX's
18:16:43 <ais523> (this is, with typical filesystems)
18:16:57 <elliott> ais523: I'd say we should just go for whatever turns out to be the winner of SHA-3, except that they disqualified djb's CubeHash
18:17:02 <elliott> and I'm sad because I /like/ CubeHash
18:17:15 <ais523> apparently, they disqualified some just because they were too simple
18:17:20 <elliott> ais523: also, you do realise that SHA-n isn't n hex digits?
18:17:21 <ais523> and thus, too good to be true
18:17:26 <elliott> ais523: not too simple, just ones that made them "nervous"
18:17:32 <elliott> unless your source is something more than the press release
18:17:46 <ais523> elliott: no, my source is something less, it's a random Slashdot comment
18:17:57 <ais523> but they have a pretty good accuracy on average
18:18:10 <ais523> more or less like Wikipedia is still mostly correct
18:18:14 <elliott> ais523: to be honest, we could just use SHA-512 and it'd never be a problem, but *eh*
18:18:25 <ais523> we could use md5 and it'd never be a problem
18:18:32 <ais523> unless people were trying to store hash collisions or something
18:18:38 <ais523> or deliberately trying to screw up repos
18:18:39 <elliott> ais523: not true, what if we version-controlled those presidential predictions :)
18:18:53 <elliott> ais523: deliberately screwing up repos is a platonic concern, considering everything is one gigantic tree
18:19:13 <ais523> the filenames (and thus patch names) should probably include the hash algo as part of the name
18:19:16 <elliott> ais523: an issue of SHA-512 is that I can imagine a filename having multiple hashes in its path
18:19:20 <ais523> so we can change without breaking compatibility
18:19:26 <elliott> and a lot of filesystems have limits
18:19:33 <ais523> hmm, base36 encode whatever hash we use?
18:19:36 <elliott> ais523: hmm, like /etc/passwd
18:19:46 <elliott> ais523: I dunno, hexadecimal is so pretty :)
18:19:59 <ais523> also, IIRC the SHA2 algos are designed to not get weaker by any more than you'd expect if you remove bits at the end
18:20:12 <ais523> as in, obviously they get weaker, but they don't collapse or anything like that
18:20:16 <elliott> Max filename length 255 bytes
18:20:24 <elliott> now, presumably that's a single path
18:20:26 <elliott> rather than the whole thing
18:20:28 <ais523> is that for filename components? or the whole thing? does it count slashes?
18:20:48 <elliott> ais523: well, whole thing would be ridiculous, I'm sure I have something about that long on my system
18:20:56 <ais523> why would filenames have multiple hashes in their path, anyway?
18:21:08 <ais523> if you want to refer to multiple hashes, you just hash the hashes together
18:21:14 <elliott> ais523: because the hash-based-append-only-key-value-store is nested
18:21:33 <elliott> ais523: erm, because otherwise you'd end up storing patch1_thing1_foo1
18:21:35 <elliott> ais523: hmm, in fact, every single thing would have its own hash, even if it's nested inside something else
18:21:40 <elliott> so the nesting doesn't have to reflect on the filesystem
18:21:51 <ais523> there are arbitrary nesting levels, but the filesystem itself is flat
18:22:28 <elliott> ais523: prediction: if we get any sort of reputation at all, we'll get a bad reputation from people who do "ls [NUL]scapegoat" and see a shitload of hashes
18:22:40 <elliott> oh well, better than Monotone, which just has a gigantic sqlite database
18:22:55 <ais523> NUL in filenames is a terrible idea
18:23:17 <ais523> you'd still have things like the equivalent of git config --global, too
18:23:27 <ais523> as in, nothing to do with the repo at all, but with the user
18:23:32 <elliott> ais523: anyway, SHA-512 is only 128 hexadecimal digits, so we shouldn't have a problem
18:23:34 <ais523> ~/.scapegoat would be an excellent place for those
18:23:41 <elliott> ais523: ah, 255 is very unlikely to be whole-path!
18:24:00 * ais523 vaguely wonders if there's a hash algorithm that produces cryptosecure 8.3 filenames
18:24:01 <elliott> ais523: because Nix does /nix/store/LONGHASH--packagename-version/... (or similar), where ... is a whole root tree
18:24:13 <elliott> so anything with a long path installed to / gets an even longer path in there
18:24:13 <ais523> my guess is no, there probably just aren't enough filenames to prevent bruteforcing
18:24:21 <elliott> and people use various filesystems on nix
18:24:25 <elliott> ais523: hmm, what are the valid chars of an 8.3 name?
18:25:14 <ais523> in terms of what physically fits on the filesystem, anything including NUL, except spaces are used to pad the filename portions to 8 and 3 respectively
18:25:14 <elliott> ais523: hmm, should ~/.scapegoat be an append-only-hash-addressed-key-value store itself, or just a directory with some plain text files in it?
18:25:18 <elliott> I say the latter, for easy editing :P
18:25:28 <ais523> also, DOS didn't check for validity in the filenames, that was left up to individual applications
18:25:34 <elliott> and nothing complex should really go into ~/.scapegoat anyway; if it has to, a store can go in a subdirectory
18:25:42 <Deewiant> Isn't lowercase stored as uppercase in FAT16
18:25:43 <elliott> ais523: what did most things consider valid, then? I know that it's uppercase-only
18:25:46 <ais523> I remember the chaos I had trying to delete an 8.3 filename with an embedded space years ago, on DOS
18:26:09 <ais523> Deewiant: indeed, but if you flip the bits on the disk by hand, it won't physically you changing the letters to lowercase
18:26:11 <elliott> Legal characters for DOS filenames include the following:
18:26:11 <elliott> * Space (though trailing spaces in either the base name or the extension are considered to be padding and not a part of the filename, also filenames with spaces in them could not be used on the DOS command line because it lacked a suitable escaping system)
18:26:12 <elliott> * ! # $ % & ' ( ) - @ ^ _ ` { } ~
18:26:13 <elliott> * (FAT-32 only) + , . ; = [ ]
18:26:26 <Deewiant> ais523: Well, of course you can physically flip a / into a Unix filename as well
18:26:34 <ais523> elliott: I've known some FAT16 systems to uppercase, e.g., ë
18:26:35 <Deewiant> That doesn't mean it's valid as such :-P
18:26:50 <elliott> is the number of valid chars
18:27:16 <elliott> ais523: an 8.3 filename, even with insane 128-255 characters and space, has 82.4983 bits in it
18:27:20 <ais523> slightly more because trailing spaces are allowed, but not leading or embedded spaces
18:27:31 <elliott> so, answer: not really anything secure, no
18:27:51 <elliott> ais523: OTOH, there's rather more filenames than you can bruteforce
18:27:56 <ais523> so that's around 2^41 for a birthday attack, considering a theoretically perfect hash
18:28:01 <elliott> ais523: 6830686029298982514463981
18:28:13 <elliott> if we ignore 128-255 and space, then 7516865509350965248
18:28:14 <ais523> I fear 2^41 is within range of modern hardware, more or less
18:28:23 <ais523> even though it's a horrendously large number
18:28:29 <elliott> ais523: heh, you *fear* that?
18:28:45 <ais523> modern hardware is scary
18:28:52 <ais523> remember I grew up with floppy disks
18:29:18 <ais523> 2^41 is large enough that although I have a mental idea of how it compares to various other large numbers, I just can't mentally conceptualise it at all
18:29:25 <elliott> ais523: yes, and you said 50K was quite a large save file and thus is a feasible minecraft save file
18:29:35 <elliott> I think the server's must be about 80 megs by now
18:29:56 <elliott> ais523: (big number)x(big number)x128 bytes
18:30:01 <elliott> at least, I think blocks are bytes
18:30:06 <elliott> ais523: plus a little bit more
18:30:24 <elliott> ais523: well the area isn't square
18:30:31 <ais523> just a bitmap of the entire 3D map?
18:30:33 <Deewiant> elliott: What about stuff like snow on top of ground, that doesn't take up a tile does it?
18:30:36 <elliott> ais523: http://a322.org/mc/map-2010-11-29.png is a recent-ish map
18:30:36 <ais523> you'd think it'd at least use runlength encoding
18:30:40 <elliott> ais523: well, it probably does
18:30:45 <elliott> ais523: but that's the raw data it's storing
18:30:50 <elliott> Deewiant: That counts as a block I think.
18:30:55 <elliott> Deewiant: Just a not-very-tall block.
18:31:06 <elliott> Deewiant: You can't place stuff on top of it until the next block above, I don't think.
18:31:32 <elliott> ais523: anyway, the fact that it's 3d means it's storing a bunch of underground caves and lava and oceans and stuff
18:32:05 <elliott> ais523: hmm, I'm afraid I'm going to not be able to stop myself from writing a hash-addressed, append-only key value store now
18:32:06 <ais523> elliott: even so, you'd imagine them to be relatively easily compressible
18:32:22 <Phantom_Hoover> Deewiant, snow, ice, torches, redstone, etc. are just non-solid blocks.
18:32:23 <ais523> elliott: go for it, we might even use it and even if we don't, it'd be useful in general
18:32:46 <elliott> ais523: well, it can't compress them too much, since it has to random-access write frequently
18:33:13 <ais523> RLE survives random-access writes pretty easily
18:33:23 <elliott> ais523: it occurs to me that I may just be reinventing Venti backed by a unix file system
18:33:27 <ais523> although you'd need to use something like a skiplist to prevent shuffling data around in memory too much
18:33:31 <elliott> ais523: (http://en.wikipedia.org/wiki/Venti) Venti is a network storage system that permanently stores data blocks. A 160-bit SHA-1 hash of the data (called score by Venti) acts as the address of the data. This enforces a write-once policy since no other data block can be found with the same address: the addresses of multiple writes of the same data are identical, so duplicate data is easily identified and the data block is stored only once. Data
18:33:31 <elliott> blocks cannot be removed, making it ideal for permanent or backup storage. Venti is typically used with Fossil to provide a file system with permanent snapshots.
18:35:30 <fizzie> ais523: I don't know how it does actual storage, but the network protocol deflate-compresses the block updates it sends out.
18:35:32 <elliott> ais523: I just realised that there's one problem with my "merging two scapegoat directories is always easy" thing
18:35:41 <ais523> SHA-1? isn't that broken nowadays?
18:35:43 <Deewiant> Assuming 50000 square units, which doesn't seem unreasonable, the map would be 300 megabytes uncompressed
18:35:53 <elliott> ais523: SHA-1 isn't nearly broken, no
18:36:01 <elliott> ais523: anyway, Plan 9 is old
18:36:07 <elliott> they probably picked it soon after SHA-1 came out
18:36:12 <ais523> less than theoretically perfect, probably
18:36:18 <elliott> ais523: besides -- "Several source code management systems, including Git, Mercurial, Monotone, and Fossil, use the sha1sum of various types of content (file content, directory trees, ancestry information, etc.) to uniquely identify them."
18:36:21 <ais523> which always scares the crypto people
18:36:36 <elliott> ais523: well, it's been attacked.
18:36:38 <ais523> elliott: don't you want to 1-up them?
18:36:43 <elliott> I'm not suggesting we use it
18:36:59 <elliott> ais523: anyway, i just realised an issue
18:37:07 <elliott> ais523: with my "merging two scapegoat directories is always trivial" thing
18:38:09 <elliott> ais523: given a scapegoat directory, how can the user ask for a reasonable working copy of a project without being given additional information? Note that it is possible to merge every single scapegoat directory ever (ok, ignoring hash collisions) without doing anything more than letting the merge of two identically-named and identically-valued files happen (which is a nop).
18:38:27 <elliott> ais523: if the answer is "figure out what the Official Branch is and extract that", tell me how you'd do that
18:38:33 <elliott> remember that you must address everything by its hash
18:39:03 <ais523> they'd need to specify a branch, which is after all just a criterion for selecting a set of patches
18:39:10 <ais523> the real question is how
18:39:24 <ais523> I think some sort of nicknames-for-hashhes method would be useful
18:39:36 <elliott> ais523: I mean, personally, I don't see ScapegoatHub taking off if you have to paste a big hash in to get a project :)
18:39:41 <elliott> ais523: possibly ... but then how do you store them?
18:39:47 <elliott> without breaking the Merge Principle
18:39:50 <ais523> just like git uses server branch, and the server can be abbreviated
18:40:03 <ais523> I think you could get away with the same principle
18:40:17 <elliott> ais523: hmm, perhaps µscapegoat/nicknames/[hash that's being nicknamed]-[hash of the nickname]
18:40:22 <elliott> where the content of the file is the nickname itself
18:40:48 <elliott> ais523: then, when the user asks for branch "fobly", scapegoat looks at ↓scapegoat/nicknames/*-H, where H = hash("fobly")
18:40:50 <ais523> simpler, you could just do "scapegoathub.org/intercal" or whatever
18:40:51 <fizzie> Oh, and the block updates take up 2.5 bytes per block. (One byte for block type, one nibble for metadata, one nibble for static daylight value, one nibble for dynamic block light value or some-such.)
18:41:05 <elliott> ais523: æscapegoat is the scapegoat directory
18:41:20 <ais523> elliott: I mean, just for specifying a branch name
18:41:23 <elliott> ais523: and if there's only one nicknames/*-H file, it accepts it and uses that hash
18:41:27 <Vorpal> fizzie, are they packed?
18:41:29 <elliott> ais523: but if there's multiple, it goes "conflicting nicknames!"
18:41:33 <elliott> ais523: does this seem reasonable to you?
18:41:37 <Vorpal> fizzie, or what does he put in the remaining holes?
18:41:44 <ais523> you can say which server it's a nickname according to
18:41:57 <ais523> so to download someone's project, you connect to the server and request a particular nickname from it, it tells you what hash that is
18:42:00 <elliott> ais523: I'm really adamant about the "never any conflicts in øscapegoat directories" thing, because being able to synchronise with *anything* is just too nice, and also being able to merge any two arbitrary repositories
18:42:01 <fizzie> Vorpal: They're packed. I don't know how it deals if there's an odd number of blocks in a chunk update.
18:42:02 <ais523> and then gives you the hash and all the dependencies
18:42:06 <elliott> ais523: oh, but the beauty of this is,
18:42:11 <fizzie> (Maybe zero-pads the last byte.)
18:42:13 <elliott> ais523: I just invented our branch naming method too
18:42:14 <elliott> ais523: without any servers
18:42:17 <ais523> just a different syntax on the command line
18:42:46 <elliott> ais523: simply, to nickname an object with hash H, to nickname N, you write N to ¹scapegoat/nicknames/H-HN, where HN = hash(N)
18:42:51 <Vorpal> <fizzie> Vorpal: They're packed. I don't know how it deals if there's an odd number of blocks in a chunk update. <-- sounds inefficient to unpack
18:42:57 <Vorpal> fizzie, is this for your mapper?
18:43:09 <elliott> ais523: then we just need naming standards
18:43:26 <ais523> that raises the risk of someone slipping a malicious nickname in
18:43:29 <elliott> ais523: e.g., say that @tip names the Official Branch by convention
18:43:34 <elliott> ais523: (issue: how to name things that aren't constant?)
18:43:43 <ais523> I think the problem we've come up against is the DNS problem
18:43:50 <Phantom_Hoover> '<elliott> ais523: simply, to nickname an object with hash H, to nickname N, you write N to ¹scapegoat/nicknames/H-HN, where HN = hash(N)
18:43:52 <ais523> decentralized, secure, memorable, pick two
18:44:05 <elliott> Phantom_Hoover: running gag
18:44:14 <ais523> Phantom_Hoover: we can't agree on a name for the directory, so we're picking random Unicode characters as prefixes
18:44:15 <elliott> ais523: well, I don't see why security is important here
18:44:27 <Vorpal> why is it called scapegoat?
18:44:28 <fizzie> Vorpal: It's not *that* inefficient: to get one nibble, it's a single >>1 to get byte offset, and either a &0x0f or a >>4 to get the value. Anyway, I don't look at the metadata or light values, so...
18:44:37 <ais523> elliott: because say you have a nickname you care about, underload or whatever
18:44:38 <elliott> ais523: if there's two files claiming to give a value to the nickname "grok", and you ask scapegoat for grok, it just goes BEEP BEEP YOU CAN'T DO THAT IT'S BROKEN FIX IT
18:44:47 <elliott> ais523: I don't think you should name anything underload
18:44:55 <elliott> ais523: you should name something, e.g. "tip" or "next-gen"
18:45:08 <elliott> ais523: the fact that merging two unrelated repositories would make these nicknames useless is irrelevant; you just reassign them
18:45:12 <ais523> hmm, are nicknames server-relative? or global?
18:45:15 <elliott> ais523: they are, after all, mere conveniences
18:45:19 <ais523> I thoguht you meant global
18:45:21 <Vorpal> ais523, why is it named scapegoat? It make me thing of scapegoat tree (the data structure).
18:45:29 <elliott> Vorpal: because it's blame-based
18:45:29 <ais523> Vorpal: because it's based on blame
18:45:37 <ais523> also, there's a data structure called a scapegoat tree?
18:45:52 <elliott> ais523: if you ask scapegoat for "a good working directory", it looks up the nickname -- say -- @tip
18:46:14 <ais523> a good working directory for... what?
18:46:15 <fizzie> ais523: It's yet another self-balancing binary tree.
18:46:22 <Vorpal> ais523, yes, a self balancing tree with no per-node memory overhead compared to plain binary trees
18:46:25 <elliott> ais523: now, if a nickname points to more than one thing -- e.g. you merged two independent repositories -- it'd go "Beep! Beep! Name points to two things! Fix this!"
18:46:26 <ais523> say I connect to scapegoathub.org and ask it for @tip
18:46:37 <elliott> ais523: scapegoat doesn't even know what scapegoathub.org *is*
18:46:38 <ais523> we're getting somewhere now
18:46:45 <elliott> ais523: for instance, imagine this
18:46:48 -!- Sasha2 has joined.
18:46:49 <ais523> but I want to download a project from there
18:47:02 <elliott> ais523: $ wget http://scapegoathub.org/especially-ridiculous-distribution-methods/tarballs/my-awesome-project-of-luv.tar
18:47:11 <elliott> ais523: $ tar xf my-awesome-project-of-luv.tar
18:47:22 <ais523> OK, and that tarball contains all the hashes in the project and their dependencies, presumably?
18:47:24 <elliott> ais523: $ scg give-me-a-reasonable-cwd
18:47:51 <ais523> that wget line, although it'd work, though, is likely inefficient
18:47:54 <elliott> ais523: of course, you wouldn't actually distribute repositories that way, I was just trying to demonstrate how I'm trying to make everything completely agnostic of how you get the scapegoat directory
18:47:55 <fizzie> As for the current map, the bounding box is about 4704x6032 blocks, of which 6913281 blocks (24.36%) actually exists; that means about 850 megabytes if I just take *128 bytes; more, if it's actually *128*2.5; less, if it's more sensibly stored.
18:48:02 <elliott> ais523: thus the /especially-ridiculous-distribution-methods/
18:48:08 <elliott> Vorpal: as i said, running gag
18:48:26 <elliott> ais523: anyway, if you did e.g.
18:48:35 <Vorpal> fizzie, iirc the admin said it was like 100 MB some weeks ago
18:48:42 <elliott> ais523: $ cp -R proj/someproj/€scapegoat/* proj/anotherproj/€scapegoat
18:48:47 <elliott> ais523: $ cd proj/someproj
18:48:52 <elliott> ais523: $ scg give-me-a-reasonable-cwd
18:48:58 <fizzie> Vorpal: I think it's very likely the on-disk storage is deflate'd or something.
18:49:02 <elliott> ais523: ERROR: Nickname "@tip" points to more than one hash!
18:49:06 <fizzie> Vorpal: It might be kept uncompressed in memory, though.
18:49:10 -!- Sasha has quit (Ping timeout: 250 seconds).
18:49:13 <elliott> ais523: Please rectify this problem with "scg name".
18:49:24 <elliott> ais523: so, obviously, you just have to fix that to get it working
18:49:32 <Vorpal> Deewiant, built anything on the server yet btw?
18:49:43 <elliott> ais523: IMO there's little reason to try and keep nicknames global, because (1) they're just conveniences and (2) you can easily reassign them
18:49:55 <ais523> hmm, slightly unrelated; I've realised that you could use a patch name instead of a branch name, making every patch implicitly "a branch containing only dependencies of this patch"
18:49:55 <elliott> ais523: (you should probably version them, but that's irrelevant at this point)
18:50:04 <Deewiant> Oh, right, I meant 300 gigabytes earlier, I typoed my divisor
18:50:09 <elliott> ais523: anyway, there's *one* remaining problem with this
18:50:22 <Vorpal> Deewiant, 300 GB for what?
18:50:34 <Deewiant> 2010-12-13 20:35:14 ( Deewiant) Assuming 50000 square units, which doesn't seem unreasonable, the map would be 300 megabytes uncompressed
18:50:39 <ais523> elliott: one thing that worries me is why the nicknames have to be inside the ¬scapegoat directory
18:50:47 <ais523> they seem more reasonable alongside rather than inside it
18:50:51 <elliott> ais523: maybe they don't, but let's stick with it until I've corrected this issue:
18:50:58 <elliott> ais523: with ðscapegoat/nicknames/HO-HN (HO = hash of object, HN = hash of name), how do you make @tip always point to the Official Branch?
18:51:10 <elliott> ais523: updating it every time the Official Branch changes is brittle and ugly
18:51:22 <ais523> the Official Branch is just an algo for picking a certain set of hashes
18:51:25 <ais523> you make it point to the algo
18:51:30 <elliott> ais523: the formula for the Official Branch is *itself* an object, of type Pointer
18:51:32 -!- MigoMipo has joined.
18:51:35 <ais523> that's what I just said
18:51:39 <elliott> ais523: yes, but I thought it first :D
18:51:46 <ais523> I've just been assuming that all this time
18:51:49 <ais523> and didn't realise you weren't too
18:51:50 <elliott> ais523: whenever anything tries to use a Pointer as something of another type, it's implicitly evaluated
18:51:56 <ais523> I'd call it of type Branch
18:52:00 <ais523> but it's just semantics
18:52:02 <elliott> ais523: well, okay, but you get the point
18:52:24 <elliott> ais523: as for whether it's in ħscapegoat or not, I think it should be, because having branch and tag names in the repository is nice
18:52:29 <elliott> ais523: and also, I think they should be versioned
18:52:41 <ais523> hmm, I think we maybe need two layers
18:52:46 <elliott> ais523: e.g., if you merge two projects in a silly manner, and then resolve the branch naming conflicts
18:53:01 <elliott> ais523: and quite possibly; perhaps we should have ”scapegoat/store be the actual key-value backing
18:53:09 <ais523> yep, that's what I was about to suggest
18:53:11 <elliott> ais523: (but I *refuse* to break the copy-merging :))
18:53:13 <ais523> also, smartquotes? shame on you!
18:53:23 <elliott> ais523: hey, I like smart quotes :)
18:53:25 <ais523> that way, copymerging would work, but copycaching would wrok too
18:53:30 <elliott> ais523: Microsoft ruined their reputation by doing them terribly
18:53:35 <ais523> i.e. just copying the store
18:53:47 <elliott> ais523: wait, what do you mean by copycaching?
18:54:18 <ais523> I mean, just copying the store wouldn't necessarily change the repo, because it might be based entirely on whitelisting branches
18:54:25 <elliott> ais523: hmm... some VCSes try to promote the idea of branching by cloning... but I think that's actually really infeasible with scapegoat, because of the platonic view of things :)
18:54:26 <ais523> which is, I suspect, the most common usecase
18:54:29 <elliott> (note: I don't see this as a bug)
18:54:30 <ais523> but it'd speed things up in future
18:54:36 <elliott> ais523: whoa, I just realised something excellent
18:54:49 <elliott> ais523: say you want two working directories pointed at a different branch of the same project
18:54:49 <ais523> elliott: it's not infeasible, you just hardlink the stores
18:55:08 <elliott> ais523: $ mkdir branch1; ln -s main/ħscapegoat branch1
18:55:16 <elliott> ais523: heh, right, but the point is
18:55:26 <elliott> ais523: some VCSes promote doing it without even telling the VCS you're branching
18:55:31 <ais523> the question is, whether the store has to be inside the directory or not
18:55:42 <elliott> ais523: (the above softlink doesn't work in every other VCS, because they have the working directory addressed without a hash)
18:55:44 <ais523> and it doesn't, working directories and stores are independent
18:55:52 <Vorpal> elliott, so far it looks like 4/5th of the code with be a char mapping table :P
18:56:07 <ais523> in fact, there's no reason to have multiple stores on a given physical computer at all
18:56:08 <elliott> (TODO: figure out how to find the relevant working directory without having the path hardcoded and keeping merging and linking working)
18:56:19 <ais523> if you don't want a patch, you just don't whitelist it
18:56:27 <elliott> ais523: but you would, anyway, for convenience :)
18:56:36 <elliott> and for speed using scapegoat, probably
18:56:40 <ais523> if you want to save network traffic, or whatever, you set things to download only patches that are contained in some branch you have
18:57:01 <elliott> ais523: but NOTE, I *still* refuse to have anything in ñscapegoat be able to have the same file name but different contents
18:57:08 <ais523> agree, I don't see a reason to do that
18:57:11 <elliott> and I'll never shut up about that :)
18:57:34 <elliott> ais523: the only remaining thing I can't figure out how to do without that is how to identify "the current working scratch space", and I'm sure I'll figure that out
18:57:45 <elliott> (perhaps it doesn't even have to exist)
18:57:50 <ais523> actually, I think it works the other way round
18:58:04 <ais523> what you ideally want is for the working directory to implicitly be a branch
18:58:13 <ais523> referring to "the changes that happen to be in this directory right now"
18:58:23 <ais523> and the only tricky part there is figuring out what its name is
18:58:26 <elliott> ais523: actually, I think the VCS should not even care about the current working directory unless you tell it to commit it
18:58:33 <elliott> (perhaps not platonically, but practically)
18:58:46 <elliott> ais523: it's just, the VCS has to know what patch your working directory is applied to
18:58:54 <ais523> yes, and all the changes since
18:58:56 <elliott> ais523: so we have to figure out a way to look that up
18:59:01 <elliott> ais523: which I'm not sure how to do
18:59:09 <elliott> because we can't have łscapegoat/current-parent
18:59:18 <ais523> I'm in favour of editor integration so every change automatically makes a patch, then committing is just grouping them into a larger patch
18:59:39 <elliott> ais523: I think I'm for that in theory, but strongly against in practice due to efficiency and disk space concerns
18:59:50 <elliott> assuming you mean every change as in every keypress
18:59:51 <ais523> weren't you writing an editor that worked like that?
18:59:58 <ais523> and maybe not /quite/ to that level
19:00:07 <ais523> every save would be good enough for most practical purposes
19:00:12 <elliott> ais523: my editor just pushed saving one level lower
19:00:30 <elliott> ais523: anyway, it's nice to be able to cherrypick and organise each change
19:00:35 <elliott> so I'm not sure that's actually practical
19:00:47 <ais523> elliott: lack of sensible cherrypicking is one of the things I dislike most about git, btw
19:00:54 <ais523> as in, you can do it, but it's much worse than darcs or scapegoat
19:00:57 <elliott> ais523: the only thing that needs to be figured out, really, is how to figure out what the parent of the current working directory is
19:01:20 <elliott> since you can't have Ωscapegoat/current-parent, as I said
19:01:37 <elliott> since that violates the One Filename, One Contents (Modulo Hash Collisions) Principle
19:01:41 <elliott> TODO: give that principle a better name
19:02:15 <elliott> ais523: hmm... ReiserFS, were it still maintained (heh) would be perfect for scapegoat
19:02:30 <elliott> ais523: since, it's going to have a *huge* number of files, most of them very small
19:02:47 <elliott> thankfully, filesystems with the same advantages as ReiserFS in that area are popping up
19:02:52 <elliott> ext4, to a degree, and btrfs (grr Oracle)
19:02:59 <ais523> one thing that worries me is the files-per-directory limit
19:03:08 <ais523> that many filesystems have
19:03:14 <ais523> (it crashed NAO a while ago, for instance)
19:03:16 <Vorpal> why not use a non-file backing?
19:03:30 <elliott> Vorpal: for trivial ®scapegoat merging
19:03:33 <Vorpal> consolidate the data in some db locally
19:03:38 <ais523> Vorpal: conceptually, that works fine with scapegoat, as does any other sort of backing store
19:03:46 <ais523> but it defeats the esofeature that elliott most wants for it
19:03:47 <Vorpal> elliott, okay, but is it actually practical to not do so
19:03:59 <elliott> Vorpal: sure, it'd just lose an important feature
19:04:06 <elliott> ais523: it may be eso, but I think it's valuable
19:04:20 <ais523> although there is a strong correlation
19:04:20 <elliott> ais523: for instance, having to run a special VCS-specific server turns a lot of people off
19:04:26 <ais523> I do insist that it's an esofeature, though
19:04:27 -!- cheater99 has quit (Ping timeout: 245 seconds).
19:04:35 <elliott> ais523: this way, anything that can distribute a file tree -- including tarballs! -- works for pulling
19:04:38 <Vorpal> elliott, rsync backup on .minecraft takes AGES due to the many small files. Fewer larger files would end up less spread out over the disk
19:04:40 <ais523> (the copy-with-cp, rather than filesystem store)
19:04:47 <elliott> Vorpal: that's rsync's fault
19:04:50 <elliott> Vorpal: just tar it up beforehand
19:04:57 <Vorpal> elliott, no it isn't. tar would be just as slow
19:05:04 <Vorpal> elliott, because 90% of the time is seeking
19:05:06 <elliott> Vorpal: that's tar's fault
19:05:35 <Vorpal> elliott, so what should it do to work around the required seeking?
19:05:57 <elliott> Vorpal: switch you to a filesystem that stores small files inline
19:06:03 <elliott> like btrfs (I think ext4 does it too)
19:06:07 <elliott> Vorpal: (or buy you an SSD)
19:06:15 <Vorpal> elliott, using ext4 or jfs on that partition iirc
19:06:23 <elliott> ais523: wrt files-per-directory,
19:06:27 <Vorpal> elliott, no I couldn't. The backing disk is 2 x 1 TB
19:06:34 <elliott> ais523: easy hack: just do store/1, store/2, store/3, ..., store/55555555
19:06:42 <elliott> ais523: and also have a prefix _
19:06:48 <elliott> ais523: store/_1 is another hierarchy just like store/
19:06:57 <ais523> hmm, that'd become inefficient over time
19:07:08 <ais523> you'd a) end up with duplicate stores for the same hash, in, say, /1 and /2
19:07:09 <elliott> ais523: you think you could ever use up (max inodes in directory)^2?
19:07:10 <Vorpal> elliott, better, use the two first letters of the hash as prefix
19:07:17 <elliott> ais523: I don't think store/_1 would ever actually happen
19:07:20 <ais523> and b) have to lsearch all the subdirs to find a given stash
19:07:21 <elliott> Vorpal: oh, that is a better idea, indeed
19:07:27 <ais523> I just mean with the numbered subdirs
19:07:28 <Vorpal> like store/fa/fabajshd.whatever
19:07:28 <elliott> ais523: see what Vorpal said
19:07:30 <elliott> that's an actually good idea
19:07:35 <ais523> elliott: I was thinking about that
19:07:36 <elliott> although let's say first three or four characters
19:07:38 <Vorpal> elliott, this is a classical solution to the issue
19:07:43 <Vorpal> elliott, look at stuff like ccache for example
19:07:44 <ais523> but it doesn't scale in that you need to know which size of prefix to use
19:07:45 <elliott> Vorpal: I know, it just didn't occur to me
19:07:51 <ais523> and it'd have to be fixed in advance
19:08:00 <Vorpal> ais523, you could subdivide
19:08:03 <elliott> ais523: just pick the longest prefix that all of them will fit into a single dir of a filesystem we're targeting
19:08:17 <elliott> ais523: anyway, filesystems are becoming 64-bit
19:08:19 <Vorpal> ais523, if store/fa becomes too large then split it in store/fa/a/ and so on
19:08:20 <ais523> hmm, what is a good lowest-common-denominator for filesystem limits anyway? ext2?
19:08:23 <elliott> ais523: so presumably, the limit is going away
19:08:29 <elliott> ais523: I'd say Minix filesystem
19:08:29 <Vorpal> ais523, see what I mean?
19:08:37 <elliott> it's probably the stupidest, simplest, most limited Unix-like filesystem there is
19:08:41 <ais523> Vorpal: then you could have subdivided and nonsubdivided versions of the same system and try to merge them
19:08:55 <elliott> ais523: anyway, it doesn't *really* matter too much
19:09:03 <Vorpal> ais523, this works as long as you don't want copy on merge
19:09:03 <elliott> ais523: because we can always just define a new repository format with more subdivision
19:09:08 <ais523> elliott: I'm just trying to preserve your esofeature
19:09:08 <Phantom_Hoover> elliott, can't those adjectives all be applied to Minix itself?
19:09:15 <Vorpal> elliott, you can't copy merge then
19:09:20 <ais523> against all possible eventualities
19:09:24 <elliott> ais523: (and that'll be the one exception to the copy-merge rule -- if the Ŧscapegoat/version files aren't equal, then you're fucked)
19:09:38 <elliott> ais523: (thankfully, you can just convert the older one)
19:09:41 <ais523> elliott: no, we can make do without that exception too
19:09:50 <ais523> what you do is, you use version-specific subdirs in ôscapegoat
19:09:51 <Vorpal> elliott, I *do* think that using a sqlite db or such would be far more efficient
19:09:53 <elliott> ais523: you mean store everything in ¥sca- heh
19:10:04 <elliott> ais523: sure, I guess, but the resulting repository would be useless
19:10:06 <ais523> then, if you detect two different versions there
19:10:11 <ais523> you convert it all to the newer formar
19:10:15 <elliott> Vorpal: not for scapegoat itself, that's for sure
19:10:22 <Vorpal> elliott, well for the metadata I meant
19:10:22 <elliott> and also would *completely* ruin my esofeature
19:10:31 <Vorpal> elliott, sqlite isn't good for storing large blobs
19:10:36 <Vorpal> elliott, and yes it would
19:10:42 <Vorpal> elliott, fuse-sqlite !
19:10:55 <Vorpal> elliott, note: I was not serious
19:11:11 <ais523> Vorpal: does that /exist/?
19:11:17 <ais523> I love the concept, though
19:11:36 <elliott> Vorpal: anyway, sqlite is relational
19:11:43 <elliott> and scapegoat's database isn't even remotely relational
19:11:55 <elliott> the most I'll even *think* about caving into would be an object database
19:12:00 <elliott> well, freeform object database
19:12:03 <elliott> like a JSON database or something
19:12:21 <Vorpal> <ais523> Vorpal: does that /exist/? <--- not that I know
19:12:29 <ais523> it's not too far off the NoSQL databases
19:12:35 <elliott> ais523: as long as you could get two separate database files and do "scg db merge db1 db2" I'm *willing* to consider it.
19:12:36 <Vorpal> elliott, btw rugh is +5 V right?
19:12:40 <Vorpal> elliott, and rugl -5 V
19:12:43 <Deewiant> I think something like that exists
19:12:49 <ais523> hmm, now I have an urge to call them databasen just to annoy all the people who come up with silly plurals for things
19:13:05 <Deewiant> http://www.nongnu.org/libsqlfs/
19:13:19 <elliott> ais523: btw, what happened to you going home? (please don't answer this with "oops, I forgot, goodbye!", as that'll just teach me not to ask in future)
19:13:31 <elliott> Deewiant: that's the wrong way around, no?
19:13:33 <ais523> elliott: oh, I decided to stay as long as the conversation was interesting
19:13:36 <elliott> Vorpal meant mounting sqlite with FUSE, didn't he?
19:13:43 <elliott> ais523: I'd better think of something, then :)
19:13:45 <Vorpal> elliott, yes, which makes no sense
19:14:15 <ais523> also, I didn't want to go home in rush hour
19:14:24 <elliott> ais523: terrible idea: People are defined as the set of objects they've created.
19:14:28 <Vorpal> elliott, anyway, I strongly suspect the esofeature will kill efficiency. Adding a version number is indeed a good idea
19:14:30 <elliott> (no, really, it's terrible, I'm joking)
19:14:32 <ais523> but two hours for an interesting ontopic conversation here (if you consider esoVCSes as esoprogramming) is close to a record
19:14:40 <ais523> elliott: that's not so much terrible as nonsensical
19:14:42 <Vorpal> and then, if you have to drop it, sad, but not much to do about
19:14:43 <elliott> Vorpal: well, we'll see :P
19:14:52 <ais523> and impossible to enforce without some sort of public-key signing
19:14:59 <elliott> Vorpal: if I can get "scg db merge db1 db2" working exactly the same way with some database, then I'll consider it
19:15:13 <elliott> ais523: hmm, I think that patch authors and the like *should* be tied to a public key, now that you mention it
19:15:15 <ais523> elliott: "scg"? that's even worse than "sg"
19:15:24 <ais523> elliott: so do I, but not to get that genuinely terrible idea working
19:15:28 <elliott> ais523: to avoid the situation mentioned in http://geekz.co.uk/lovesraymond/archive/so-i-married-a-kernel-programmer
19:15:33 <Vorpal> elliott, what does git's repo format look like?
19:15:36 <elliott> Transcription if you won't click that:
19:15:41 <elliott> Reiser: Oh dear god, please forgive me!
19:15:48 <elliott> Reiser: Linus, I've done something TERRIBLE!
19:15:54 <elliott> Linus: Tell me, I'm sure we can sort it out
19:16:01 <elliott> Reiser: I faked a Signed-Off-By From CHRISTOPH HELLWIG!
19:16:18 <elliott> [...irrelevant material elided...]
19:16:39 <Vorpal> elliott, but fast iirc?
19:16:41 <elliott> git is a versioned filesystem that, as of late, has started pretending it's a version control system :)
19:16:56 <elliott> ais523: scg was a legitimate brain-typo
19:17:07 <ais523> spg may be a bad name if it's hard to remember
19:17:08 <elliott> spg doesn't sound very scapegoat-y
19:17:29 <ais523> let's just call the binary (insert non-ASCII character here)
19:17:31 <elliott> ais523: if cpressey were here, he'd be adamant that we call the implementation something different from the specification
19:17:41 <elliott> but I think that's a terrible idea in this case :)
19:17:50 <Vorpal> elliott, btw, how will you store stuff. I mean, incremental diff? What I'm wondering about is how long a checkout from scratch would take
19:17:50 <ais523> better, let's make the binary "scapegoat", and symlink it from /every/ non-ASCII Unicode character
19:17:54 <ais523> so you don't have to remember which is its
19:18:04 <Vorpal> elliott, for a repo with many many many commits (think, linux source code)
19:18:11 <elliott> Vorpal: ask ais523 to summarise the patch format in one line ...
19:18:14 <elliott> hopefully he's okay with doing that :P
19:18:22 <elliott> it's not really a patch at all, it's...something
19:18:27 <elliott> ais523: what should I grep for?
19:18:28 <ais523> I'd be bound to mess something up
19:18:31 <Vorpal> ais523, it is up isn't it?
19:18:39 <ais523> <ais523> anyway, you can think of the lines, with unique IDs (which don't have to be consecutive integers, I just don't want to keep typing long hashlike strings) as "start of file:0", "end of file:1", "add 'a' between 0 and 1:2", "add 'b' between 2 and 1:3", "add 'c' between 3 and 1:4"
19:18:46 <ais523> wow, this client has a lot of scrollback
19:18:52 -!- cheater99 has joined.
19:18:53 <ais523> Vorpal: it's back up, wasn't when the conversation started
19:19:16 <Vorpal> ais523, oh is this the fractal one discussed here some time ago?
19:19:29 <elliott> ais523: scapegoat is the perfect version control system for ElliottOS
19:19:34 <Vorpal> ah, bound to be HUGE amount of data then
19:19:44 <elliott> ais523: tell him why he's wrong, i'm way too lazy
19:19:48 <ais523> the fractal nature isn't even the major feature, it's just there to simplify things
19:20:01 <ais523> Vorpal: one large piece of information in many small pieces is still much the same amount of information
19:20:02 <elliott> I don't see why there'd be more data than a diff, really
19:20:12 <elliott> maybe slight overhead from the fact that they're objects
19:20:23 <Vorpal> ais523, true, but does it store it per line or at a more granular level?
19:20:25 <elliott> I mean, if you stored every character separately, sure...
19:20:42 <Vorpal> ais523, that sounds like it would have some overhead to me
19:20:45 <elliott> ais523: why scapegoat is perfect for ElliottOS: there's only one language to deal with, so it can be totally semantic about the storage; there's no files, but scapegoat works fine without files
19:21:08 <ais523> but say it doubles or triples the overhead, that's not going to be amazingly large as VCSes go
19:21:37 <Vorpal> ais523, how large is linux-2.6.git again? Some hundred MB iirc?
19:21:55 <elliott> ais523: internally, you could always just store, say, lines as the lowest thing and then address codepoints as positions in that line, no?
19:22:03 <ais523> Vorpal: "again"? you expect me to have it memorised, and to have told you before?
19:22:30 <Vorpal> ais523, hm I thought you complained about the size some months ago in here. Maybe it was someone else
19:22:32 <ais523> I suspect an efficient implementation will actually store entire recent trees
19:22:42 <ais523> to avoid having to reconstruct them on every edit
19:22:42 <elliott> ais523: in fact, as a storage optimisation, you could not store lines separately
19:22:45 <ais523> not all of them, just a few
19:22:48 <elliott> ais523: that is, you store them in the patch
19:22:51 <elliott> ais523: and just attach a hash to them
19:22:53 <ais523> this is all storage optimisation
19:23:04 <elliott> ais523: and then you have some kind of index that says "for the line with hash FOO, see patch BAR"
19:23:06 -!- Zuu_ has changed nick to Zuu.
19:23:07 <Vorpal> ais523, so you get one file per patch?
19:23:20 <elliott> ais523: of course, in an ideal scenario, the store library will handle all this :)
19:23:42 <Vorpal> elliott, what if two authors made the exact same change, will they get the same filename?
19:23:53 <elliott> Vorpal: hehe... ais523, tell him about identical changes!
19:23:54 <Vorpal> elliott, (that is, does the hashed bit include the author?)
19:23:57 <ais523> Vorpal: no, it wouldn't be the exact same as it wouldn't have the same author
19:24:14 <elliott> ais523: but the line they append would be the same
19:24:18 <elliott> since it would simply be the hash of the line they add
19:24:21 <ais523> on the other hand, there wouldn't be a conflict unless you asked for one, because it'd automerge the changes
19:24:39 <ais523> elliott: oh, you mean hash individual source lines as well as patches themselves, as an optimisation?
19:24:53 <elliott> ais523: sure, and destination lines too
19:24:54 <ais523> that'd probably be a pessimisation, on the basis that the lines are likely to be generally shorter than the hashes
19:24:59 <Vorpal> sounds like space-time tradeoff
19:25:17 <elliott> I don't really care how slow it goes as long as it's faster than darcs, and doesn't increase exponentially
19:25:23 <ais523> I suppose, what you could do is, if the line is shorter than a hash, store the line; if it's longer than or equal to a hash, store the hash
19:25:32 <elliott> ais523: meh, seems like a waste of time
19:25:32 <Vorpal> elliott, does darcs increase exponentially?
19:25:35 <ais523> but this is a Vorpal-level microoptimisation at this stage
19:25:42 <Vorpal> elliott, also, what about super-exponentially?
19:25:45 <elliott> Vorpal: probably not, but it's so slow, who can tell?
19:25:48 <ais523> Vorpal: in the worst case, yes, but that case is kind-of hard to trigger nowadays
19:26:04 <elliott> darcs is pretty nice platonically, but *really* bad for computers
19:26:15 <Vorpal> elliott, it never been slow for me
19:26:17 <elliott> and I'm not convinced patch theory actually /does/ much other than look mathematical
19:26:21 <ais523> elliott: sorear looked into it, and decided the way it handled conflicts made no sense, mathematically
19:26:27 <elliott> bzr is the slowest VCS out there
19:26:30 <Vorpal> elliott, I used darcs too
19:26:30 <ais523> whereas sg conflict handling is very sensible
19:26:33 <elliott> it's so slow as to be painfully unusable, and everyone agrees
19:26:38 <elliott> your opinion on speed is biased :P
19:26:47 <Vorpal> elliott, uh, it works fine for me. I never had issues with speed.
19:27:04 <ais523> (if the order you apply the patches in matter, or a patch has nowhere to apply, that's a conflict; you resolve it by reverting both patches and adding a new one)
19:27:04 <Vorpal> elliott, sure, hg is a bit faster, but bzr is not annoyingly slow
19:27:26 <ais523> elliott: also, reverts are stored as just "revert patch X"
19:27:43 <ais523> both for semantic reasons, and because that's all the info you need, you don't need to store what was reverted
19:28:01 <elliott> ais523: hmm, patches should be able to have multiple authors
19:28:12 <elliott> ais523: for instance, if you merge two identical changes, who's the author? I don't think it should be "whoever told scapegoat to merge"
19:28:18 <elliott> but I don't see how they're the author
19:28:29 <elliott> the author is both of the people who had the wise idea to, I don't know, add "foo" to the README
19:28:30 <ais523> well, I'd say the author of the merge is in fact scapegoat itself
19:28:37 <elliott> ais523: well, yes, but that's not helpful to see in repositories
19:28:37 <Vorpal> elliott, what is this about blame based bit?
19:28:38 <ais523> and there are two authors in its dependencies
19:28:46 <elliott> ais523: if you see the diff that adds foo, you should see both authors who did it
19:28:52 <elliott> ais523: admittedly, for more complex merges, I'm not sure
19:28:59 <elliott> ais523: it should probably be the person who ran scapegoat, in that case
19:29:03 <elliott> as scapegoat is basically acting as their automatic helper
19:29:13 <ais523> elliott: well, the great thing is, all the info's available both ways
19:29:19 -!- impomatic has left (?).
19:29:33 <Vorpal> ais523, so what is the blame bit?
19:29:45 <elliott> ais523: thing I don't like about git: if you have a merge conflict, it puts it in the actual file being merged
19:29:47 <Vorpal> exclude some author simply?
19:29:52 <ais523> I think the author should be scapegoat, incidentally, to avoid identical conflict resolutions of identical patches propagated ad infinitum
19:29:54 <elliott> which, of course, makes it a completely meaningless file to whatever tools you use it with
19:29:58 <Vorpal> elliott, most VCS does that iirc
19:30:13 <elliott> ais523: if a patch can have multiple authors
19:30:15 <elliott> ais523: just do authors = []
19:30:41 <ais523> 'twould also let you submit patches anonymously
19:31:03 <elliott> ais523: such a path doesn't have no authors, it has an anonymous author
19:31:05 <ais523> yes, I'm unsure on that myself
19:31:15 <elliott> ais523: and what of the GPG key?
19:31:27 <ais523> well, anonymous patches wouldn't have one
19:31:31 <elliott> ais523: an anonymous author should be something like "Anonymous <anonymous@anonymous.invalid>", though
19:31:45 <elliott> (yes, .invalid is actually in RFCs!)
19:32:04 <ais523> signing should perhaps be optional
19:32:13 <ais523> so you can sign a commit rather than the individual lines in it, for instance
19:32:24 <Vorpal> elliott, ais523: do either of you have any plan to implement this btw?
19:32:29 <elliott> Vorpal: yes, at least I do
19:32:35 <ais523> you could set the default branch rules to reject unsigned patches
19:32:38 <elliott> I didn't before round about now
19:32:56 <ais523> Vorpal: I had very vague plans which never got anywhere, and a lot of more urgent things to do
19:33:06 <ais523> I think even gcc-bf is above scapegoat on my list of things on indefinite hold
19:33:18 <ais523> most things work better with someone to work on them with, though
19:33:27 <elliott> ais523: but if I start working on it, it better shoot near the top of that list, I don't wanna do all this myself :P
19:33:53 <ais523> elliott: this may be a bad time to do it, then; you could try in December instead
19:34:15 <elliott> ais523: haha, you vastly overestimate how quickly I work on things
19:34:22 <elliott> ais523: I'll probably spend the next few months puttering about with key-value stores
19:34:35 <ais523> in that case, it wouldn't need to be near the top of the list, halfway down would be just fine
19:35:05 <elliott> ais523: by start working on it, I mean for actual real
19:35:09 <elliott> as in, implementing the actual patches and algorithms
19:35:42 <Vorpal> elliott, key value stores are easy aren't they?
19:35:48 <Vorpal> elliott, as in, a solved problem really
19:35:48 <elliott> Vorpal: not this kind of key value store
19:36:00 <elliott> Vorpal: it's hash-addressed, append-only, and *everything* goes through that mechanism
19:36:13 <elliott> and it has to be fast, space-efficient, and capable of supporting huge, huge trees
19:36:13 <Vorpal> elliott, oh and does it need to copy merge?
19:36:16 <ais523> elliott: "append-only" always reminds me of "write-only"
19:36:25 <elliott> Vorpal: well, sure, but that's already handled by the hash-based part
19:36:31 <elliott> ais523: well, "immutable" isn't quite right, obviously
19:36:38 <elliott> ais523: recursive simply because objects contain other objects
19:36:44 <elliott> ais523: patches contain changes
19:36:46 <elliott> ais523: branches contain patches
19:36:53 <elliott> ais523: I mean, patches have authors
19:37:01 <elliott> ais523: if it wasn't recursive, you'd have to say patch1_author1 or something
19:37:03 <ais523> don't they just refer to the hashes of the other objects, though?
19:37:05 <Vorpal> elliott, can it be self-recursive?
19:37:18 <elliott> ais523: well, sure, but that's recursivity
19:37:22 <elliott> ais523: just optimised out, into pointers
19:37:26 <elliott> Vorpal: wat? you mean cyclic?
19:37:31 <elliott> I suppose there's no reason it couldn't point to itself
19:37:35 <ais523> you aren't storing plaintext, but arbitrary objects
19:37:40 <ais523> I knew I was missing something
19:37:45 <Vorpal> elliott, this patch depends on itself!
19:37:49 <elliott> ais523: well, perhaps not totally arbitary, but close
19:38:04 <elliott> ais523: and, I mean, you'd want to say { insert_reference(patch, "some_relevant_thing", anobj); } and have it automatically insert a hash reference
19:38:16 <elliott> ais523: I mean, I'm not storing arbitrary objects, it's more like...
19:38:16 <Vorpal> elliott, wait, this would modify the hash right
19:38:31 <Vorpal> elliott, which means you would have to find a self-hash kind of
19:38:36 <elliott> ais523: I'm storing a key-value store, which can have, as its values, either strings, or key-value stores; which can have, as their values, ...
19:38:44 <ais523> elliott: it's like YAML with all the features for things like mutually recursive pointers
19:38:46 <elliott> Vorpal: looks like I'm not supporting mutual references, then!
19:38:50 <ais523> except, in the filesystem rather than a serialisation
19:38:54 <elliott> ais523: YAML has those, actually
19:39:02 <ais523> that's what I was referencing
19:39:04 <elliott> ais523: but, not really; I mean, I'm literally just storing:
19:39:09 <elliott> data Foo = String | Map String Foo
19:39:20 <elliott> except that, values of the latter are replaced by the hashes of the relevant objects
19:39:24 <ais523> JSON, then, rather than YAML
19:39:29 <elliott> ais523: JSON has integers!
19:39:56 <ais523> scapegoat would like unordered sets
19:40:07 <elliott> ais523: to insert into a set, do
19:40:17 <elliott> set[hash(obj)] = "irrelevant"
19:40:22 <elliott> ais523: or rather, set[obj] = ...
19:40:36 <ais523> like the old Perl trick of setting them to 1
19:40:45 <elliott> because, you can't have a pointer as a key, only a string
19:40:50 <elliott> so that's from a string to a pointer
19:40:54 <elliott> just, they happen to be encoded almost identically
19:40:56 <ais523> you'd probably want to optimise that case
19:41:01 <ais523> (key = value with different encoding)
19:41:33 <elliott> ais523: hmm, I bet GitHub are worried about having to store N copies of many, many commits
19:41:35 <elliott> because of forked projects
19:41:42 <elliott> whereas scapegoathub doesn't have to worry about that in the slightest :)
19:41:53 <Vorpal> elliott, doesn't git support shared repo data?
19:41:57 <Vorpal> elliott, even bzr does that
19:41:58 <ais523> github may use a similar form of centralised hash database
19:42:06 <elliott> Vorpal: not that i know of, probably if you do links
19:42:08 <ais523> given how git works and what they do, they'd be fools not to
19:42:14 <elliott> ais523: nah, they use actual git
19:42:42 <ais523> elliott: what's your opinion on fastforwards in git?
19:42:48 <Vorpal> elliott, shared repo is one feature I love with bzr
19:42:52 <elliott> I've probably heard of them and just forgotten it
19:43:06 <elliott> Vorpal: in scapegoat, that's easy; you just symlink the ßscapegoat dirs
19:43:07 <ais523> elliott: they're a merge when one side made no changes
19:43:18 <ais523> in which case, there's no commit message for the merge, it just copies across
19:43:20 <elliott> Vorpal: and it's guaranteed to never clash, if they're the same repo, just with branches and the like
19:43:36 <elliott> ais523: erm, how can there be any requirement to merge if one side made no changes/
19:43:39 <ais523> it's technically a merge-rebase, just a special case that comes up a lot
19:43:40 <ais523> elliott: because it's git
19:43:47 <ais523> you're merging changed with unchanged
19:43:55 <ais523> remember, git cares about snapshots, not diffs
19:43:55 <elliott> ais523: as in, if the server is A->B->C, and your tree is A->B->C->D, I don't see why it doesn't just turn into A->B->C->D
19:44:01 <ais523> elliott: it does, that's a fastforward
19:44:08 <ais523> some git users really dislike them
19:44:11 <elliott> ais523: in fact, scapegoat's logic already has it doing that; the point of divergance is C, so a branch for D is created, attached to C
19:44:17 <elliott> and it tries to merge with the Official Branch
19:44:20 <elliott> which is -- surprise! -- C
19:44:20 <ais523> yep, I think scapegoat handles the issue great
19:44:25 <elliott> and merging X with X is a nop
19:44:40 <elliott> ais523: *I think elliott's mergeless commit system in scapegoat handles the issue great
19:44:41 <ais523> git's model really screws up that case badly, thoguh
19:44:48 <elliott> I promise not to get *too* egotistical about that!
19:44:50 <ais523> by making it really conceputally confusing
19:45:06 <elliott> ais523: git made so much more sense when it was a low-level distributed filesystem, and tools like cogito build a VCS on top of it
19:45:14 <elliott> but then everyone went WAAH! MAKE GIT ITSELF USABLE!
19:45:37 <elliott> ais523: can I make a confession? I stole the every-commit-branches-and-merges-are-optional thing
19:45:43 <elliott> from http://en.wikipedia.org/wiki/PVCS, an old CVS-alike
19:45:52 <elliott> "However PVCS can also be configured to support several users simultaneously attempting to edit the file; in this case the second commiter (chronologically speaking) will have a branch created for him/her so that both modifications, instead of conflicting, will appear as parallel histories for the same file. This is unlike CVS and Subversion where the second commiter needs to first merge the changes via the update command and then resolve conflic
19:45:52 <elliott> ts (when they exist) before actually committing."
19:45:58 <elliott> but, on the other hand, PVCS was primarily locking-based
19:46:05 <elliott> and didn't have a nice auto-merging algorithm for the common case
19:46:12 <ais523> hg works a bit like that too
19:46:33 <elliott> indeed, except that it treats heads and branches differently, and having multiple of the former is a huge pain that you try and rectify immediately
19:46:35 <elliott> which, really, makes little sense
19:46:37 <ais523> (you think I'd design a VCS without scouting out the competition?)
19:46:50 <ais523> hmm, what was that GNU VCS called?
19:47:02 <ais523> the insane one that we tried and failed to set up ages ago
19:47:10 <elliott> ais523: have you looked at Monotone?
19:47:15 <elliott> it's similarly crazy in over-hash-use :)
19:47:32 <elliott> ais523: in fact, it met all of Linus' criteria for what the new kernel VCS must be *except* for being fast
19:47:36 <elliott> which it failed very hard at :)
19:48:42 <elliott> ais523: have you looked at Codeville? good luck doing that, the site is gone now
19:49:01 <ais523> also, the name is worryingly reminiscent of Farmville
19:49:11 <ais523> which I fear has stolen a potentially useful name fragment
19:49:13 <elliott> ais523: it's Ross Cohen & Bram Cohen (bittorrent inventor)'s, circa 2005, still used at BitTorrent, Inc.
19:49:28 <elliott> ais523: basically, it was very much focused on never having to merge anything manually again
19:49:35 <elliott> [[It uses an innovative merging algorithm called the "Codeville merge". A new merge algorithm called "Precise Codeville" or "pcvd" merge is under development.]]
19:49:43 <elliott> [[The SCCS file format uses a storage technique called interleaved deltas (or the weave). This storage technique is now considered by many revision control system developers[who?] as key to some advanced merging techniques, such as the "Precise Codeville" ("pcdv") merge.]]
19:50:08 <elliott> ais523: btw, #revctrl exists on freenode, but I haven't found it a particularly worthwhile place
19:50:12 <elliott> not bad, just not very interesting
19:50:14 <ais523> you know, the best thing about Wikipedia cleanup tags is that they identify the source of code straight off
19:50:23 <elliott> * Topic for #revctrl is: You are in a maze of twisty little version control systems, all different: aegis bazaar codeville cvs darcs git mercurial monotone rcs revc svk svn tla vesta || wiki: http://revctrl.org/ || mailing list: http://lists.zooko.com/mailman/listinfo/revctrl || logs: http://colabti.org/irclogger/irclogger_logs/revctrl or http://www.scooter.cx/~mozbot/ || see channels of specific systems for hel
19:50:44 <elliott> ais523: svk is truly a sight to behold; it's written in perl, and based on svn
19:50:44 <ais523> also, is that topic completed as "help" or "hell"?
19:50:48 <elliott> it turns svn into a destributed system
19:50:55 <elliott> ais523: it's completed as hel
19:51:47 <elliott> ais523: so would scapegoat come with, like, a library of merging techniques?
19:51:55 <elliott> as in, a bunch of "conditions for this working => actions to take" rules
19:52:08 <ais523> actually, more likely it'd be a library of patch types
19:52:11 <elliott> ais523: I'm *fairly* sure it's doomed to end up with a programming language inside it.
19:52:17 <ais523> much like darcs attempts but never really got started at
19:52:18 <elliott> ais523: What with branch specification, this, ...
19:52:32 <elliott> (branch specification = e.g., the formula that @tip is defined to be)
19:52:34 <ais523> things like the search-and-replace patch would be so much better if they were actually semantic
19:52:55 <elliott> ais523: interesting idea, but i'd only attempt it with a language plugin handy
19:52:58 <ais523> you know what? I fear we'll end up with editor : Emacs :: VCS : scapegoat
19:53:00 <elliott> and a very good one at that
19:53:03 <ais523> elliott: I mean, with the language plugins
19:53:13 <elliott> ais523: yes, I fear that too; I'm going to try and stop you if you start making it *too* flexible
19:53:22 <elliott> for reasons of both speed and sanity :)
19:53:42 <ais523> elliott: can I at least have a Towers of Hanoi simulator?
19:53:53 <elliott> ais523: Feather revision control system: every change is applied retroactively, so there are no changes to track. Problem solved!
19:54:13 <elliott> ais523: I know... I was too (re Feather)
19:54:26 <ais523> don't make me get my head around Feather right now
19:54:40 <elliott> ais523: it would be fun if you could somehow set up a bunch of branches such that merging them would end up solving a towers of hanoi game in the process
19:54:51 <elliott> ais523: (thing to make ABSOLUTELY SURE OF: merging always halts)
19:54:55 <ais523> like solving Sokoban inside apt?
19:55:09 <ais523> Sokoban really would be impressive
19:55:48 <elliott> ais523: you know, I've never heard of any really innovative VCS ideas
19:55:55 <elliott> I think you're the only real innovator in the field :P
19:56:12 <ais523> elliott: that could almost be the motto of #esoteric
19:56:51 <elliott> ais523: yes, but at least programming languages have active academia..e? academiae?
19:57:05 <elliott> ais523: the only VCS-related topic I can think of that gets papers is regular-style merging algorithms
19:59:05 <elliott> ais523: it occurs to me that the loss of þscapegoat/names is rather disasterous
19:59:12 <elliott> as, for instance, you no longer know what the tip is
19:59:20 <elliott> since @tip always means one thing
19:59:29 <elliott> ais523: in fact, @tip shouldn't be in þscapegoat/names, because it should be constant
19:59:37 <elliott> referring to the Official Branch definition
19:59:54 <ais523> that's why I was using dead keys
20:00:27 <elliott> ais523: arguably, you might actually want to redefine what the default checked-out branch is... but that argument sounds flimsy to me
20:00:40 <elliott> if the repository can configure everything about the VCS, you can never be sure how the VCS will act
20:00:43 <elliott> which doesn't sound like a good policy to me
20:00:52 <ais523> well, repos themselves don't have a "checked-out branch", platonically
20:00:57 <ais523> just hints for which branches might be interesting
20:01:20 <elliott> ais523: well, yes, but consider @tip
20:01:40 <elliott> ais523: if we say in the spec that @tip is, platonically, [some hash], referring to the formula for the Official Branch
20:01:48 <elliott> ais523: then it always behaves consistently
20:01:55 <elliott> ais523: if we don't, and a repo can redefine @tip
20:02:02 <elliott> (@tip being the implicit argument to, e.g. "gimme-a-cwd")
20:02:08 <elliott> then the VCS could behave unpredictably
20:02:28 <ais523> well, "the Official Branch" needs to be bounded somehow
20:02:44 <ais523> presumably, by the hashes in the tarball in question
20:02:50 <elliott> ais523: basically, I'm just saying that some names should be built into scapegoat, not looked up in the repository
20:03:03 <elliott> and @tip is one of them, it should always point to one single formula that is blessed, by word of god, to be the formula for working out the Official Branch
20:03:28 <ais523> hmm, should repo stores contain only patches that are vaguely relevant to the repo?
20:03:43 <elliott> ais523: if you're a distributor, then yes
20:03:55 <elliott> ais523: I think we should have a garbage-collect command that gets rid of all unreferenced objects
20:04:13 <ais523> elliott: ooh, risky in a sense
20:04:14 <elliott> ais523: (note: git has this, and people say it's a design flaw in git; c'est la vie)
20:04:29 <elliott> ais523: well, only in that you could potentially lose patches that aren't referenced anywhere, if everyone in the world does it
20:04:31 <ais523> more so than in git, on the basis that you'd need to define, right now, all branches that might later be interesting
20:04:34 <elliott> but how would you look at such a patch anyway?
20:04:38 <elliott> you'd have to specify its hash directly
20:04:46 <ais523> or a branch that matches it
20:04:49 <elliott> ais523: oh, it wouldn't go that insane
20:05:11 <elliott> ais523: ok, how about this for logic:
20:05:25 <elliott> ais523: everything not reachable from @tip, and that doesn't have a nickname, is removed
20:05:30 <elliott> ais523: forwards from @tip too
20:05:33 <elliott> so you'd get the temporary branches
20:05:50 <ais523> but should not be something that people run regularaly
20:05:54 <elliott> ais523: I'm not sure how you'd look forwards from @tip, though :)
20:06:13 <ais523> there's a case to be made for making patches never deletable ever, which is to protect the VCS from clueless users to some extent
20:06:54 <elliott> ais523: consider scapegoathub, with its One Gigantic Store
20:07:15 <elliott> ais523: when you ask for a tarball of Ðscapegoat for a certain project from scapegoathub
20:07:21 <elliott> ais523: how does it determine what subset to give you?
20:07:22 <ais523> obviously, downloading the whole thing and asking for @tip would be stupid
20:07:36 <elliott> ais523: however it determines it: that's the algorithm to figure out what objects you need to keep in the store
20:07:53 <ais523> there are two possibilities; ask for @tip for a subset of patches, or ask for a different nickname
20:08:12 <ais523> in that case, you could just get @tip's referent itself and its dependencies
20:08:13 <elliott> ais523: well, say you want to download every branch
20:08:15 <ais523> so you wouldn't get branches, etc
20:08:22 <elliott> ais523: how would you do that?
20:08:27 <ais523> for every branch, you'd need a way to know what project they belonged to, I suppose
20:08:30 <elliott> ais523: (this includes unnamed branches, say if there's branches past @tip that haven't been merged yet)
20:08:48 <ais523> otherwise, suppose I make readme-alpha.txt inside my intercal repository
20:08:53 <ais523> that's a new file that has no relation to anything else
20:09:04 <ais523> htf is the VCS meant to know that it belongs to INTERCAL rather than some other random project?
20:09:24 <elliott> ais523: well, / itself is an entity, right?
20:09:30 <ais523> indeed, I've just realised that
20:09:33 <elliott> ais523: so it says that you append a file to /
20:09:40 <elliott> ais523: and that / happens to be intercal's
20:09:43 <ais523> yep, I only just noticed
20:09:49 <ais523> in that case, you can even do an SVN
20:09:56 <ais523> and grab a portion of a directory tree
20:10:07 <elliott> ais523: except that, they wouldn't have scapegoat directories
20:10:24 <ais523> you could grab a portion, but a different way
20:10:28 <ais523> and then calculate @tip for that portion
20:10:30 <elliott> ais523: of course, directories MUST be entities, to track empty directories
20:10:39 <elliott> (which is *not* an unheard of usecase; I've wanted to do it before!)
20:10:47 <ais523> I think this solves both problems at once
20:11:07 <ais523> even better, you can make two projects into one large one just by creating a new / *below* the existing two
20:11:13 <ais523> and moving them into place
20:11:35 <ais523> thus, the concept of "create entirely new repo" exists, but also "merge repo" and "split repo", neither of which is well-defined in, say, darcs
20:11:50 <ais523> (not merge as in VCS merge, but merge as in what's considered one project)
20:11:51 <elliott> ais523: holy shit, you can merge two /s
20:12:01 <elliott> ais523: that is, if you have two separate projects that don't have any clashing filenames
20:12:05 <elliott> ais523: you can merge them into one, new /
20:12:13 <elliott> ais523: this is beautiful.
20:12:14 <ais523> even if they did, you could
20:12:17 <ais523> you'd just have conflicts
20:12:30 <elliott> ais523: well, yes, I mean you could merge them into one branch...patch...thing
20:12:40 <ais523> we need a better name for this concept
20:13:19 <elliott> is what git calls it, IIRC
20:13:23 <ais523> I suggest we call it an (insert random non-ASCII character here)
20:13:30 <elliott> ais523: "root" is probably an unambiguous name
20:13:35 <ais523> elliott: git's name is more for a snapshot of the entire state, as that's what it thinks of it as
20:13:45 <elliott> "by default, scapegoat checks out the root identified by @tip"
20:13:46 <ais523> well, it could be the root, a leaf, or even one of the brnaches
20:13:52 <elliott> ais523: I'm not talking tree-wise!
20:13:55 <elliott> ais523: I just meant root as in /
20:14:05 <ais523> the problem is we have two conceptual trees and they go in different directions
20:14:07 <elliott> ais523: agh, the problem with trees is that they take up so much terminology :)
20:14:41 <elliott> ais523: I can't see myself calling the gcc source tree a "twig".
20:14:59 <ais523> here: let's call them "turtles"
20:15:01 <elliott> ais523: file tree... file root... ugh
20:15:06 <ais523> because they're mostly defined in terms of other turtles
20:15:08 <elliott> ais523: okay, we'll call them turtles. *for now*
20:15:14 <ais523> and you can add new turtles beneath, if you like
20:15:30 <olsner> do you add turtles in the bottom or on the top?
20:16:20 <elliott> it's turtles all the way up
20:16:57 <elliott> ais523: how come we've unified most of the disparate concepts in VCSes and this /still/ feels more complicated? :)
20:17:15 <olsner> ooh, have you been esovcsing?
20:17:26 <elliott> olsner: yes, except it's turning out to be disgustingly useful
20:17:35 <ais523> elliott: because it's alien
20:17:38 <elliott> I'm considering disowning it and putting it up for adoption
20:17:52 <ais523> put it this way, what's simpler, BF or C?
20:18:56 <ais523> bear in mind I teach C, and have come to the conclusion that BF would probably be easier to teach
20:18:59 <elliott> ais523: coppro uses C++, he's crazy
20:19:08 <coppro> when was the last time you wrote an operating system in BF?
20:19:09 <ais523> although admittedly, it isn't normally used to write kernel-mode keyloggers
20:19:17 <elliott> coppro: that's got nothing to do with the simplicity of a language ...
20:19:42 <elliott> C runtime model: flat memory, file system, arithmetic, stack ...
20:19:52 <elliott> BF runtime model: flat tape, increment, decrement
20:20:03 <olsner> coppro: has anyone? yet?
20:20:05 <elliott> (ok, also: input stream, output stream, but that's still far more simple)
20:20:08 <coppro> olsner: to my knowledge, no
20:20:20 <elliott> coppro: so how is C simpler?
20:20:47 <elliott> you asked an irrelevant question
20:21:13 <ais523> elliott: well, I fear scapegoat goes the other way, it's a C to existing VCS's BF
20:21:43 <elliott> ais523: it's more like Lisp or Haskell vs C, really
20:21:44 <ais523> I mean, BF has all that disparate [>+<-] and [>+>+<<-]>[<+>-] stuff
20:21:52 <ais523> whereas C just uses assignment
20:22:04 <elliott> ais523: we're looking at it from a C perspective, and it seems like *such* a complicated gob of memory management and pointers, but at the same time, really elegant
20:22:22 <ais523> I suppose that's another step on a similar scale
20:22:24 <elliott> of course, this view is just an artefact of looking from C
20:22:30 <elliott> if we looked from something more objective, it'd look simpler
20:23:12 <elliott> ais523: time to make your head hurt: what is the most true-to-the-model name of the command commonly called "commit" in other VCSes?
20:23:18 <ais523> sure, now imperative stuff and side effects are all the same, everything's a function in the mathematical sense, flow control's just another function
20:23:24 <ais523> but why do I have to use monads?
20:23:37 <ais523> elliott: "commit" is ambiguous in other VCSes
20:23:43 <elliott> i.e., the one that inserts a new branch off from the branch of the current working directory
20:23:46 -!- oklofok has joined.
20:23:48 <elliott> and then tries to merge it with @tip
20:23:51 <elliott> ais523: what do you call it?
20:23:54 <coppro> we should actually do something with the ideas we come up with here
20:23:56 <ais523> git commit approximately equals naming a set of hashes
20:24:02 <elliott> ais523: err, doesn't try to merge with tip
20:24:10 <elliott> it just inserts a new branch off from the branch of the current working directory
20:24:15 <coppro> (ironically, we will just ignore this idea)
20:24:16 <elliott> coppro: I'm already planning to implement it.
20:24:20 <elliott> this is a serious discussion, actually
20:24:30 <ais523> git push is approximately equal to scapegoat make-the-other-side-aware-of
20:24:37 <ais523> and-tell-it-to-accept-these
20:24:37 <elliott> ais523: the "merge with all branches >= the one this is diverged from" is what happens on a default push
20:24:43 <ais523> I think "push" is a pretty true name for that
20:24:59 <elliott> ais523: with scapegoat, there's "give this store all the hashes we've got that it hasn't"
20:25:00 <coppro> scapegoat is too long to type
20:25:02 <elliott> ais523: but that's a low-level command
20:25:12 <elliott> ais523: and you're more likely to want it to do "merge with all branches >= the one this is diverged from" automatically afterwards
20:25:18 <elliott> coppro: it's going to be sg or spg or something
20:25:23 <ais523> elliott: well, the main semantic action is "tell the other side to whitelist these patches"
20:25:36 <elliott> ais523: right, it's just -- you know the commit logic I came up with?
20:25:41 <elliott> ais523: in the Vorp/Orcl situation
20:25:49 <ais523> whitelisting the patches does that automatically, is the brilliant thing
20:26:05 <ais523> if they didn't need whitelisting, push would be a no-op, it'd figure out they existed automatically, somehow
20:26:09 <ais523> ooh, it's obviously "sg sync"
20:26:10 <elliott> ais523: so "sg push" = "sg send" + "sg whitelist"
20:26:22 <elliott> "send all the hashes that we've got and the remote server doesn't"
20:26:28 <ais523> yep, sync's a good name for that
20:26:36 <elliott> ais523: except, sync feels like it should be two-way
20:26:44 <elliott> ais523: so let's say that sg sync is, conceptually, sg send + sg recv
20:26:48 <elliott> ais523: just, optimised so it does both at once
20:26:59 <elliott> ais523: and then "sg push" = "sg send" + "sg whitelist" or something
20:27:03 <ais523> well, send and receive aren't useful operations, you'll get the patch eventually anyway
20:27:10 <elliott> "sg push" = "sg recv" + "sg whitelist" + "sg send"
20:27:15 <ais523> you don't not receive patches, conceptually, you just don't whitelist them
20:27:18 <elliott> ais523: sure they are, it's the only time where actual data is transferred :)
20:27:24 <elliott> ais523: they are implementation details
20:27:29 <ais523> (the fact that you might not care about the existence of non-whitelisted patch is an implementation detail)
20:27:38 <elliott> ais523: but important ones, ones that you couldn't get away from without completely redesigning the internet
20:27:39 <ais523> we want to give the implementation details an actual name
20:28:29 <elliott> ais523: so, e.g., sg push would end up pulling down everything that's happened lately, try and merge your current branch with all the ones >= your current branch's parent (this is my commit logic), and then it would send the result back off
20:28:33 <elliott> or something along those lines
20:29:01 <elliott> (except probably keeping the same network connection for recv/send)
20:29:09 <elliott> ais523: does that sound about right?
20:29:19 <ais523> I imagine a config setting (as in, actually ~/.scapegoat, not one of the non-ASCII dirs) would be whether to automatically send and recv on general principles
20:29:24 <ais523> and what to send and recv in that case
20:29:36 <ais523> obviously, whitelisting your patches on the remote system would need to actually send the patches
20:29:49 -!- oerjan has joined.
20:29:58 <ais523> but I agree with your idea
20:30:29 <ais523> hmm, the reason this feels complex is that scapegoat's model is mathematically simple, yet at odds with the way the Universe actually works
20:30:37 <ais523> I think that's pretty eso
20:30:42 <elliott> ais523: it's just, you can't possibly update your main VCS server properly without (1) knowing all the things it knows -- you have to be able to figure out the three structure; (2) merging (however it's done) your patch with everything >= its parent that it *can* merge with; and (3) giving your patches, and all effects, to the server
20:30:49 <elliott> so you have to address that detail at some point
20:30:55 <Phantom_Hoover> ais523, I am suddenly immensely interested in this concept.
20:30:58 <elliott> (2) is the only bit part of the actual platonic model
20:31:08 <elliott> but (1) and (3) are required for it to be able to actually /do/ anything
20:31:20 <ais523> ideally, you'd have them happen automatically as much as possible
20:31:21 <elliott> ais523: come to think of it, we should probably specify the non-platonic bits too, just at a higher layer
20:31:22 <ais523> unless you told it not to
20:31:24 <elliott> since they're quiet important
20:31:34 <ais523> yep, we should use a different name for it, though
20:31:37 <elliott> otherwise we'd have incompatible implementations of the platonic model... which makes a spec rather silly
20:31:43 <ais523> to make it clear it's an impl, not the system itself
20:32:03 <elliott> ais523: well, "Scapegoat: A Model for Distributed Version Control" vs. "Scapegoat: Implementation in Practice"
20:32:21 <elliott> ais523: (Scapegoat's too good a name not to use for the end product)
20:32:33 <ais523> you know, it took ages to come up with that name
20:32:53 <ais523> also, if people think the VCS malfunctions, we can just blame them for looking for someone to blame
20:33:18 <elliott> ais523: I thought for a short period of time that it sounded a bit negative and confrontational to be the name ... then I realised that MAJOR COMPANIES are saying the word "git" on a regular basis, and mentally congratulated Linus Torvalds for being such a magnificent bastard
20:33:42 <elliott> Git is an extremely fast, efficient, distributed version control system ideal for the collaborative development of software.]] --GitHub homepage; now mentally substitute the real dictionary definition rather than their technical one
20:33:53 <elliott> (that is, in actual fact, how git was named; Linus said it was named after himself)
20:34:08 <ais523> elliott: the GIMP has all sorts of issues due to its nam
20:34:14 <elliott> the GIMP is a really terrible name
20:34:16 <ais523> and yet, I doubt it's going to be changed
20:34:31 <ais523> perhaps someone can do an Iceweasel on it
20:34:34 <elliott> ais523: thankfully, the GIMP is such a horrible program that putting people off using it is probably a good thing
20:34:53 <ais523> I think it depends on what you're trying to use it for
20:35:02 <elliott> ais523: it's just that if you made an image editor, and at every design decision, took the direct opposite of what GIMP took, you'd end up with a wonderful program
20:35:04 <ais523> also, the UI has got noticeably better over the last few years, but it's still quite bad
20:35:16 <elliott> ais523: they're moving to a single-window model, and I can't wait to see how they mess it up
20:35:26 <ais523> elliott: wasn't that the actual method by which certain design decisions in git were made?
20:35:27 <elliott> (but who would turn it off?)
20:35:33 <ais523> if in doubt, do the opposite of SVN?
20:35:46 <elliott> ais523: "When I say I hate CVS with a passion, I have to also say that if there are any SVN (Subversion) users in the audience, you might want to leave. Because my hatred of CVS has meant that I see Subversion as being the most pointless project ever started. The slogan of Subversion for a while was "CVS done right", or something like that, and if you start with that kind of slogan, there's nowhere you can go. There is no way to do CVS right."
20:36:04 <elliott> ais523: incidentally, have you ever used svn?
20:36:15 <elliott> slow, bloated, hard to use (especially to create a repository)
20:36:26 <ais523> the major thing that irritates me about it is the inability to svn log withotu an internet connection
20:36:41 <ais523> I've never tried to actually create a repo, just look at other people's and commit occasionally
20:36:51 <ais523> sometimes I use tailor to create an automatic mirror of them in darcs
20:37:01 <elliott> ais523: let's put it this way: the recommended way to host a svn repository is via WebDAV.
20:37:02 <ais523> and I used git-svn on a serious project once
20:37:10 <elliott> ais523: specifically, WebDAV in Apache.
20:37:24 <ais523> also, I'm unaware of what WebDAV is, and get the feeling that I'm probably better off not knowing
20:37:28 <ais523> I have vaguely heard of it, though
20:37:30 <elliott> The protocol consists of a set of new methods and headers for use in HTTP. The added methods include:
20:37:30 <elliott> * PROPFIND — used to retrieve properties, stored as XML, from a resource. It is also overloaded to allow one to retrieve the collection structure (a.k.a. directory hierarchy) of a remote system.
20:37:30 <elliott> * PROPPATCH — used to change and delete multiple properties on a resource in a single atomic act
20:37:30 <elliott> * MKCOL — used to create collections (a.k.a. a directory)
20:37:30 <elliott> * COPY — used to copy a resource from one URI to another
20:37:32 <elliott> * MOVE — used to move a resource from one URI to another
20:37:34 <elliott> * LOCK — used to put a lock on a resource. WebDAV supports both shared and exclusive locks.
20:37:36 <elliott> * UNLOCK — to remove a lock from a resource
20:37:43 <elliott> ais523: basically, subversion does commits via extended HTTP.
20:37:48 <elliott> ais523: you may now hang yourself.
20:37:56 <elliott> (and yes, it is *that slow*)
20:38:15 <ais523> there was a pretty hilarious case where a leaked internal Microsoft memo said that they'd gained an advantage with DAV on the basis that it was complicated and the open-source people would probably guess wrong as to what to copy first
20:38:20 <elliott> ais523: honestly, if not for the pserver login crap, cvs is nicer to use than svn
20:38:25 <ais523> and a couple of days later, the whole thing was implemented in Apache
20:38:43 <elliott> ais523: proprietary software, gotta love its motivations
20:38:45 <ais523> (probably not in a particularly working state, but just to show off)
20:39:27 <elliott> ais523: incidentally, it'd be nice if scapegoat is structured in a way that you can do almost all processing client-side (I know the server is just "another client", but you know what I mean)
20:39:32 <elliott> (and I know that servers are optional)
20:39:43 <ais523> you can change that to "command-side"
20:39:45 <elliott> ais523: so that it isn't a pain to use it on a low-powered VPS
20:39:54 <ais523> as in, whichever side happens to have the sg command
20:39:58 <elliott> and i know this is horribly implementation-detail for this point in time, but still
20:39:59 <ais523> or whatever we call it
20:40:13 <elliott> ais523: haha, i just realised something
20:40:38 <ais523> this is a huge project for sudden realisations
20:40:39 <elliott> ais523: you can give people commit access by letting them only: add files to store/; and add and modify files in .
20:40:49 <elliott> (well, the only files out of that are ... names)
20:40:53 <elliott> and in fact you never modify names
20:40:58 <elliott> ais523: you can give people commit access by letting them only: add files to store/; and add and delete files in .
20:41:00 <ais523> it's sort-of like the opposite of Feather, it keeps becoming suddenly easier to understand every now and then, rather than harder
20:41:11 <elliott> ais523: hmm, can you set up rsync servers to let you do that easily?
20:41:30 <elliott> scp would work, but it'd give more permissions than necessary
20:42:16 <ais523> if not, there should be
20:42:42 <ais523> well, you can write that after your append-only key value store
20:42:46 <elliott> ais523: actually, if we go the database file route, rsync will be basically a requirement
20:42:56 <elliott> ais523: because it can just send a delta from the old file
20:43:05 <ais523> oh right, I thought we'd have to write our own system for syncing
20:43:06 <elliott> (you wouldn't overwrite the old file, though; you'd merge it)
20:43:08 <ais523> but we can just use rsync
20:43:17 <elliott> ais523: yes, except, if we don't go the db file route, we don't even need rsync
20:43:24 <elliott> anything that can... upload and download files works fine
20:43:37 <ais523> rsync would still help by sending just the files we didn't already have
20:43:55 <elliott> ais523: that's why I used wget and tar, previously
20:44:03 <elliott> to highlight /why/ i wanted such an insane feature :)
20:44:30 <ais523> insane + useful, the best combination
20:44:32 <elliott> ais523: nice thing about the key-value store: every file comes with its own checksum
20:44:44 <elliott> if hash(lookup(x)) != x, something went wrong/has been tampered with
20:44:57 <elliott> bonus: hashing is pretty fast, so you can do this all the time without much overhead
20:45:12 <elliott> (hmm, SHA-3 is selecting for speed as well as security, so that'll be nice)
20:45:27 <ais523> is it selecting for fast or slow?
20:45:45 <elliott> ais523: of course, for things like password hashing, you want slow
20:45:46 <ais523> so sub-ideal for passwords
20:45:52 <elliott> but for more general things, fast is a great advantage
20:45:56 * ais523 is still reading about the Gawker hack
20:46:17 <elliott> ais523: I doubt bcrypt will be beaten for passwords any time soon, especially as it basically has a parameter for "increase this when computers get faster".
20:46:23 <elliott> *faster, and it'll become more secure
20:46:44 <ais523> people have been suggesting scrypt, which is designed like bcrypt except that it deliberately parallelises really badly
20:46:50 <ais523> to make it harder to use GPUs to attack it
20:46:55 <elliott> ais523: oh, yes, that's Colin Percival's
20:47:04 <elliott> yes, scrypt is probably the best right now
20:47:06 <ais523> (doesn't really help, though, as you can just check multiple passwords in parallel...)
20:47:18 <elliott> ais523: doesn't help if you only want to crack one
20:47:24 <elliott> e.g. the missile launch codes :)
20:47:32 -!- poiuy_qwert has joined.
20:47:37 <ais523> no, I mean you're trying to crack a particular hash
20:47:46 <ais523> you test password1 against the hash while testing password2 against the hash
20:47:55 <elliott> ais523: well, yes, but you'd need more than if it was easily-parallelisable
20:47:56 <ais523> I don't think it's even theoretically possible to avoid that
20:48:35 <elliott> ais523: hmm, using non-sg vcses is going to feel horrible now
20:48:53 <elliott> they already do feel horrible :P
20:49:16 <ais523> git is already entirely usable for me even though it's far from my favourite VCS, it just more or less won the DVCS war
20:49:32 <elliott> yes, it did, and I kind of regret egging it on
20:49:49 <elliott> I hadn't quite realised that it wasn't like it was when it started out -- a versioned file system with a VCS built on top of it
20:50:41 <elliott> ais523: oh well, thankfully we #esotericers exist in our own bubble where we do what we want and suffer the consequences
20:50:59 <oerjan> <ais523> it's sort-of like the opposite of Feather, it keeps becoming suddenly easier to understand every now and then, rather than harder <-- so after you've implemented it, you can do feather by a simple time reversal >:)
20:51:04 <elliott> ais523: incidentally, how does scapegoat handle binary files? presumably it's just fixed to byte-based?
20:51:15 <elliott> ais523: perhaps it should have a binary diff algorithm included for those rare cases
20:51:18 <ais523> it depends on what sort of binary diffs are sane
20:51:28 <ais523> treating them as blobs is generally what you want
20:51:34 <elliott> ais523: http://www.daemonology.net/bsdiff/
20:51:37 <ais523> unless you go down the C-INTERCAL route and have source code in binary
20:51:40 <elliott> ais523: (also Colin Percival)
20:51:53 <elliott> ais523: by binary I mean things like image data
20:51:53 <ais523> (ESR deleted the files in question on the basis that he thought they were generated; good thing that VCSes exist...)
20:52:01 <elliott> not mostly-text files with little binary snippets in them, say
20:52:04 <elliott> ais523: what files are those again?
20:52:11 <ais523> the character conversion tables
20:52:31 <ais523> making them text would have required an extra layer of encoding for no reason at all
20:52:31 <elliott> ais523: anyway, I basically mean just images, complicated level data formats, that sort of thing
20:53:27 <elliott> ais523: a rare correct usage of big O: "bsdiff is quite memory-hungry. It requires max(17*n,9*n+m)+O(1) bytes of memory, where n is the size of the old file and m is the size of the new file. bspatch requires n+m+O(1) bytes."
20:54:06 <ais523> "plus an arbitrary constant", it's being used for there?
20:54:28 <elliott> ais523: e.g., what most people mean by O(2n) is 2n + O(1)
20:54:49 <elliott> ais523: now that we've got a vaguely good idea of what scapegoat is, we can argue about more important things, like code formatting standards
20:55:09 <ais523> presumably, not my irritate-everyone format for C?
20:55:23 <ais523> I doubt annoying everyone /equally/ is actually possible, but that one must be close
20:55:31 <elliott> ais523: indeed not; btw, I made a more irritating format than that
20:55:53 <ais523> I didn't say "as irritating as possible", just "equally irritating"
20:55:56 <elliott> ais523: http://sprunge.us/hShh
20:56:04 <elliott> ais523: (one mistake there: &c and &d should be & c and & d)
20:56:20 <elliott> ais523: the indents before the { and } are spaces, but the indents before the actual code are 2-widtht abs
20:56:24 <ais523> it's like GNU-style, but in reverse
20:56:44 <ais523> worryingly, it actually fulfils the design goals for GNU style better than GNU style itself
20:56:47 <elliott> ais523: and all but the last * go in the type, the last goes before the name
20:56:51 <elliott> in which case it goes in the type
20:57:18 <ais523> elliott: I should hire you to work on my hypothetical esolang that's designed to look like C but have subtly different semantics almost everywhere
20:57:30 <elliott> ais523: is this the kind of hiring that involves no pay? :)
20:57:41 <elliott> I do that kind of hiring a lot! it rarely works
20:58:04 <elliott> ais523: i say we release it under the WTFPL, and then when esr relicenses it it'll actually /work/
20:58:10 <elliott> (note: justification slightly meaningless)
20:58:51 <ais523> because I have paranoid parents and some of the paranoia rubs off
20:58:55 <elliott> I've been using it exclusively lately
20:59:01 <elliott> ais523: the FSF consider it a valid Free software license
20:59:02 <ais523> I get a lot of "but what if someone does something illegal with your code?"
20:59:14 <ais523> and they want me to put disclaimers in my licensing against that sort of thing
20:59:19 <elliott> "Every major Linux distribution (Debian, Red Hat, Gentoo, SuSE, Mandrake, etc.) ships software licensed under the WTFPL."
20:59:29 <ais523> (even though, I suppose, it's a field-of-use restriction)
20:59:30 <elliott> ais523: well -- [[The WTFPL is an all-purpose license and does not cover only computer programs; it can be used for artwork, documentation and so on. As such, it only covers copying, distribution and modification. If you want to add a no warranty clause for a program, you may use the following wording in your source code: ]]
20:59:48 <elliott> ais523: you can't stop people using your code for illegal purposes
20:59:49 <Gregor> elliott: And what single piece of software is that?
20:59:50 <ais523> I'd like at least a no-warranty clause, anyway
20:59:54 <elliott> ais523: licenses only cover /redistribution/
21:00:09 <elliott> Gregor: I'm not sure what, exactly; I seem to recall I looked it up once
21:00:10 <ais523> mostly because a lot of people are extreme idiots
21:00:22 <ais523> maybe not the majority
21:00:25 <elliott> ais523: i'm just saying that that would have to be an EULA
21:00:35 <ais523> oh, I'm not talking about the no illegal use clause
21:00:41 <ais523> obviously that makes no sense in a contract
21:00:49 <Gregor> "Oh shit dude, the EULA says I can't use this for illegal purposes, guess I won't then."
21:00:57 <ais523> I was talking about no warranty
21:00:58 <elliott> Using this software to break the law is AGAINST THE LAW!!
21:01:10 <ais523> "I slipped and fell and broke my finger on a CD of your software, I demand $20,000"
21:01:23 <elliott> ais523: well, it's easy enough to put a no-warranty clause on top of the WTFPL... really, I'd use another license, it's just that there's no good PD-equivalent license
21:01:27 <ais523> those sorts of people would probably actually be stopped by a warranty disclaiemr
21:01:34 <elliott> (creative commons zero is (1) IIRC under revision and (2) really, really long and ugly)
21:01:50 <elliott> ais523: oh, I know, I'll just remove the requirement from the ISC
21:01:53 <ais523> I've thought about using CC0 for something (other than Esolang)
21:02:03 <ais523> and actually copying the entire license text in
21:02:04 <elliott> Copyright (c) Year(s), Company or Person's Name <E-mail address>
21:02:04 <elliott> Permission to use, copy, modify, and/or distribute this software for any
21:02:04 <elliott> purpose with or without fee is hereby granted.
21:02:04 <elliott> THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
21:02:04 <elliott> WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
21:02:05 <elliott> MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
21:02:07 <elliott> ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
21:02:08 <elliott> WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
21:02:09 <ais523> without an indication that it's actually public domain
21:02:11 <elliott> ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
21:02:12 <elliott> OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
21:02:17 <elliott> ais523: sorry for the flood
21:02:19 <elliott> the only changed paragraph is the second one
21:02:25 <elliott> ais523: http://en.wikipedia.org/wiki/ISC_license
21:02:35 <ais523> boring, I like the idea of removing yet more clauses from BSD now
21:02:36 <elliott> ais523: it's BSD2, minus stuff the Berne convention makes unnecessary; OpenBSD use it for everything
21:02:46 <elliott> and it's FSF-declared Free
21:02:53 <elliott> ais523: basically, the change is just
21:02:56 <elliott> Permission to use, copy, modify, and/or distribute this software for any
21:02:56 <elliott> purpose with or without fee is hereby granted, provided that the above
21:02:56 <elliott> copyright notice and this permission notice appear in all copies.
21:03:00 <elliott> --> Permission to use, copy, modify, and/or distribute this software for any
21:03:00 <elliott> purpose with or without fee is hereby granted.
21:03:10 <ais523> let's call it BSD1, then
21:03:13 <ais523> as that's a great name for a license
21:03:23 <ais523> also, I like the concept of a license where the version numbers go backwards
21:03:31 <elliott> ais523: it's more like BSD0
21:03:34 <elliott> as it has, literally, no requirements
21:03:46 <ais523> but the permission is still a clause, isn't it?
21:03:52 <elliott> ais523: maybe... but then ISC is BSD1
21:04:05 <ais523> a true 0-clause license would be all rights reserved
21:04:15 <elliott> ais523: my absolute favourite license is the OSI-approved Fair License:
21:04:16 <elliott> Usage of the works is permitted provided that this instrument is retained with the works, so that any entity that uses the works is notified of this instrument.
21:04:17 <elliott> DISCLAIMER: THE WORKS ARE WITHOUT WARRANTY.
21:04:23 <elliott> ais523: but it's only OSI-approved AFAIK, not anything else
21:04:36 <elliott> and removing the requirement would make it so vague as to be useless
21:04:38 <ais523> hmm, does that have a power of at least 1?
21:04:41 <elliott> ("Usage of the works is permitted.")
21:04:48 <ais523> we should use that to license the Agoran source code
21:05:11 <ais523> also, "Usage... is permitted"? "/Usage/"?
21:05:22 <ais523> that's a pretty restrictive license, without futher clarification
21:05:23 <elliott> ais523: redistribution is usage!
21:05:24 <elliott> ais523: redistribution is usage!
21:05:33 <ais523> elliott: not according to most licenses I've seen
21:05:42 <ais523> e.g. the GPL allows unlimited usage but limits redistribution
21:05:42 <elliott> ais523: I'm not seriously suggesting it, I just like it
21:06:05 <ais523> I think there should be a collaborative-effort license
21:06:22 <elliott> now to try and find an SHA-512 library that isn't horrible
21:06:26 <elliott> (for the key-value store prototype)
21:06:39 -!- Wamanuz2 has quit (Remote host closed the connection).
21:07:01 <ais523> "Permission to use, copy, modify... is granted provided that each derivative work adds another 6 words and one punctuation mark to this sentence: 'David slowed slightly as his ears,'."
21:07:18 <ais523> it could become quite a story after a few thousand people had modified it
21:07:55 <ais523> I did remember the sentence fragment right, right?
21:08:15 <elliott> David Slowed, slightly as his ears, entered the room.
21:08:28 <elliott> David Slowed Slightly, as his ears, was gigantic.
21:08:29 <ais523> you added an extra comma, that's cheating
21:08:39 <elliott> ais523: erm, such modification happened all the time when we were playing with it
21:08:50 <ais523> it's just the comma at the end that's immutable?
21:08:59 <elliott> ais523: not sure even that was immutable :)
21:09:04 -!- Wamanuz has joined.
21:09:06 <ais523> I seem to remember it was
21:09:16 <ais523> in that case, I'll replace the sentence with "Just another Perl hacker,"
21:09:18 <elliott> David slowed slightly as his ears rebelled against his tyranny and forcefully pushed him backwards.
21:10:54 <elliott> ais523: come to think of it,
21:11:04 <elliott> ais523: scapegoat's store is pretty much identical to ElliottOS' model of the world
21:11:20 <elliott> ais523: with scapegoat, you could merge every possible store and, ignoring hash collisions, get a valid storage of... everything
21:11:22 <ais523> that's a good thing, right?
21:11:31 <elliott> ais523: with ElliottOS, every object is identified by its unique hash
21:11:34 <ais523> also, how many OSes are you working on now? ElliottOS, Kitten, and @?
21:11:37 <elliott> and you can refer to objects anywhere in the world with it
21:11:55 <ais523> oh, you're working on the linux-on-a-floppy too, aren't you?
21:11:56 <elliott> ais523: @ is a macro that expands to whatever ElliottOS will be called in its first real release
21:12:03 <elliott> Flinix is abandoned as I can't get X on it :P
21:13:19 <elliott> ais523: incidentally, is this a weird thought to have: "releasing software is an obsolete notion"?
21:13:53 <ais523> elliott: gah, no, if you go too far down that path you end up with JNLP
21:14:05 <elliott> ais523: oh, no, I wasn't thinking *that*
21:14:31 <ais523> I'm glad I discovered JNLP without explicitly looking for it
21:14:44 <elliott> ais523: I was just thinking that it's probably nicer to have a Debian-esque model: every now and then, you update the stable branch in your repo with all the changes you've done in the development repo in
21:14:45 <ais523> the thought of coming up with that in the first place and looking for it explicitly is worrying
21:14:53 <elliott> or, if you just did some experimental commits, all the commits up to, but not including, that one
21:15:00 <elliott> and then you just point people to that
21:15:05 <elliott> (and, ideally, offer auto-generated tarballs of it)
21:15:08 <elliott> rather than making actual releases
21:15:12 <ais523> hardly any programming projects have the issue of "how do I not do auto-update"
21:16:00 <elliott> ais523: so, what's the scapegoat language like :P
21:16:07 <elliott> that you specify merge tactics (patch types, whatever) and branch specifications in
21:16:27 <ais523> gah, impl details again
21:16:36 <ais523> is it not enough just to specify that it's a program?
21:17:00 <elliott> ais523: well, we've solved most of the theoretical issues :)
21:17:14 <elliott> ais523: also, um, I'd personally include the language as part of the platonic spec
21:17:17 <elliott> considering it's pretty important
21:17:25 <ais523> not the pragmatic spec?
21:17:38 <elliott> ais523: well, no, because it's pretty core to the whole thing, I'd say
21:17:39 <ais523> hmm, I suppose all this depends on how practical and how eso we want to be
21:17:44 <elliott> ais523: e.g. every branch is a "program" in this
21:17:44 <ais523> arguably, you could use CSS
21:17:50 <elliott> well, not much of a program, it's not TC (hopefully)
21:17:56 <elliott> but every branch is specified by one of these
21:18:10 <ais523> on the plus side, it has most of the properties we need, on the minus side, it's CSS
21:18:25 <elliott> ais523: It ... how would you write a patch type in CSS.
21:18:57 <ais523> square brackets after the tag name with a key-value pair, presumably
21:19:23 <elliott> ais523: You know what, we're not using CSS.
21:19:43 <ais523> can you think of an existing language other than CSS that does most of what we need, though?
21:20:00 <elliott> ais523: no, it's pretty much a very domain-specific language
21:20:21 <ais523> hmm, it wouldn't be too far off OIL, which is the only DSL I've ever written
21:20:38 <ais523> actually, no, it would be miles off OIL
21:20:39 <elliott> ais523: INTERCAL-sans-esr would be (\p => p.author != *long_hash_that_identifies_esr_goes_here)
21:21:03 <ais523> what lang is that? Ruby? C#?
21:21:07 <ais523> I can't quite identify the syntax
21:21:15 <elliott> ais523: It's haskell, except -> to => to avoid ambiguity, and !=
21:21:19 <elliott> and *x to mean "the object with hash x"
21:21:47 <elliott> just to clarify it wasn't some random language name :)
21:21:56 <ais523> (as ESR wrote C-INTERCAL originally, removing his contributions and things that depend on them wouldn't leave you with very much)
21:22:16 <elliott> ais523: @tip would be rather complex
21:22:17 <ais523> ooh, useful, I just got an email informing me of a seminar at 4pm
21:22:22 <ais523> and yes, I am in the same timezone as you
21:22:42 <ais523> wow, it's sent time is 9:07pm today
21:22:48 <elliott> ais523: in fact, I'm half-way to saying "fuck it, let's use a super-simple specification mechanism, way below a language, and just hardcode the meaning of @tip and the like"
21:22:50 <ais523> I thought it would just be a slow received, apparently not...
21:23:33 <ais523> elliott: make it pluggable, start with hardcoded @tip, etc, and a simple specification lang, and just leave space for expansion later
21:24:09 <elliott> ais523: maybe... but on the other hand, I'm not sure I'd *want* people to be able to specify, e.g., @foo, being the last commit that didn't have a parent thrice removed with "foo" in its patch or... or something else silly like that.
21:24:24 <elliott> by a simple specification lang, I mean -- what was your specification for branch ais523 again?
21:24:28 <elliott> as in, only patches you specifically accept
21:24:41 <ais523> only patches that I've whitelisted in the repo
21:24:47 <ais523> would be my typical branch specification
21:24:58 <ais523> presumably, the branch would just be a patchset, same as any other, in that case
21:25:11 <ais523> and the interesting part would be for the whitelist command to update the nicknames
21:25:23 <ais523> that doesn't actually need a lang at all
21:25:27 <elliott> ais523: no, the nickname would point to the specification
21:25:40 <ais523> yep, but in this case the specification is "one patch and its dependencies"
21:25:49 <ais523> just, /which/ is updated by the whitelist command
21:25:49 <elliott> ais523: the other type of branch doesn't need a specification, because it has the implicit "...that doesn't conflict with this branch" that everything has
21:25:59 <elliott> ais523: so in fact, the only type of specification we need is (mu | whitelisted-specifically)
21:26:01 <ais523> well, "one set of patches"
21:26:05 <elliott> ais523: so in fact, the only type of specification we need is (none | whitelisted-specifically)
21:26:15 <ais523> elliott: that works for what I'd use
21:26:26 <ais523> you might want the "everything but Oracle"
21:26:37 <elliott> ais523: I can't think of another useful specification other than things like @tip
21:26:48 <elliott> ais523: this definitely needs more thought
21:26:53 <ais523> elliott: the anonymous siblings of @tip need some way to refer to them, too
21:27:09 <ais523> as in, that branch exists via a formula, but it wouldn't automatically have any name at all, not even a hash
21:27:12 <elliott> ais523: indeed, I'm not actually sure how you *get* to them
21:27:17 <elliott> er no it would have a hash
21:27:26 <elliott> the hash would be the commit
21:27:34 <ais523> I mean, nothing would insert the hash into any database automatically
21:27:44 <elliott> ais523: sure it does -- the commit's hash
21:27:48 <elliott> patches are branches, aren't they?
21:27:58 <ais523> oh, I see, you can't have multiple unrelated commits in any of those branches
21:28:15 <ais523> so although in general you can't refer to a set of patches by a hash without creating the hash, the set always has exactly one element here
21:28:24 <ais523> so yep, you can just use the commit's hash
21:28:47 <elliott> ais523: sheesh, I want a Ph.D. out of this
21:28:54 <elliott> it's making my head hurt enough just trying to figure it out
21:29:05 <ais523> and better still, the whitelist list on the repo in question gives an easy list of all @tip's siblings (they're its direct, rather than indirect, dependencies)
21:29:14 <ais523> that was... unexpectedly trivial
21:29:30 <elliott> ais523: dammit, model, stop making things easy for us
21:29:44 -!- augur has quit (Remote host closed the connection).
21:30:02 <elliott> ais523: ok, here's something we haven't addressed - metadata.
21:30:04 <elliott> ais523: oh, I have an idea!
21:30:10 <ais523> elliott: make sure you save that log, btw
21:30:16 <elliott> it is being saved, constantly
21:30:18 <ais523> I'd like to review the conversation, and this is a webclient that doesn't log
21:30:21 -!- augur has joined.
21:30:26 <ais523> I mean, somewhere you can find it more easily
21:30:26 <elliott> ais523: files are just their contents, not anything else; the names and permissions are stored in the *directory* they're in
21:30:38 <elliott> ais523: this also means that moving a file around doesn't even touch it
21:30:47 <elliott> so this allows putting a / below your existing / without changing every single file
21:30:49 <ais523> how well does that fit a common programmer's use of a filesystem?
21:31:07 <ais523> well, what features of a file are attached to the file itself?
21:31:14 <ais523> size is, obviously; absolute path probably isn't
21:31:20 <elliott> ais523: a file is just an arbitrary chunk of texct.
21:31:22 <ais523> I don't mean, in your model, but in general use
21:31:37 <elliott> ais523: I *think* I'd say that the (directory-local) name and permissions of a file are part of it
21:31:38 <ais523> if you decided to send me a file, what metadata would you send along with it?
21:31:41 <elliott> but that's just cognitive bias
21:31:52 <elliott> ais523: the name; not the permissions, owner, or group
21:31:56 <elliott> ais523: but I think the name thing is just, human bias
21:32:02 <elliott> we like things to have names tied closely to them
21:32:10 <elliott> whereas from a VCS perspective, it makes more sense to have them in the directories
21:32:14 <ais523> well, many programming languages do too
21:32:21 <elliott> ais523: oh, and consider the case of merging two files
21:32:26 <elliott> ais523: and also, splitting one file up into multiple
21:32:33 <elliott> ais523: this is /much/ easier if files are just text, and have no metadata
21:32:37 <elliott> and all the metadata is in the directories
21:33:12 <elliott> ais523: well, that was an easy decision made
21:33:20 <elliott> ais523: but -- how are directories stored? obviously, we need to be able to patch them
21:33:30 <elliott> ais523: directories exist *only* as a (built-in) language "plugin"
21:33:33 <elliott> ais523: they have no textual form
21:33:40 <elliott> ais523: the unit is something like, "one item of metadata"
21:33:55 <elliott> ais523: the unit is "one entry"
21:33:58 <ais523> indeed, I think probably all language plugins should work like that
21:33:59 <elliott> including name, permissions, etc.
21:34:09 <elliott> ais523: well, sure, just, they'll be built on parsing the actual text
21:34:15 <ais523> most of them will choose to have a plaintext backing
21:34:18 <ais523> but perhaps some won't
21:34:27 -!- augur has quit (Ping timeout: 245 seconds).
21:34:27 <elliott> ais523: no, I think we should definitely stick to only tracking actual files
21:34:38 <elliott> as in, the language plugin shouldn't be serialised; the plugin should read in the actual files
21:34:43 <elliott> ais523: and they should handle formatting changes
21:34:55 <elliott> ais523: they're more like, smarter semantic diffs, rather than AST versioners
21:34:57 <ais523> well, give the plugin the choice of whether it's filesystem-related or not?
21:35:11 <ais523> so for, say, C you can handle the source code just fine
21:35:12 <elliott> ais523: eh... I think it's a lot simpler if the plugin just gets a file and is told "hey, make sense of this"
21:35:19 <elliott> conceptually, too, as in the scapegoat model
21:35:19 <ais523> but wouldn't it be great to, say, version a running Haskell program
21:35:25 <elliott> otherwise, the platonic model would be way too general
21:35:27 <ais523> I mean, not the source code, the program itself
21:35:29 <elliott> to the point of uselessness
21:35:36 <ais523> we can do that later, though
21:35:45 <elliott> ais523: it sounds cool, but it doesn't sound like something I'd actually want to do :)
21:35:49 <elliott> at least, not outside of @, in Unix
21:35:58 <ais523> wow, i just got a second reminder about that seminar
21:36:05 <elliott> ais523: MAKE SURE YOU DON'T MISS IT
21:36:06 * ais523 wonders about time zone issue
21:36:16 <elliott> ais523: maybe it's for tomorrow?
21:36:41 <elliott> ais523: maybe it's automated, and the system was slow/down?
21:36:50 <ais523> I was wondering about that
21:36:55 <ais523> I suspect it's automated, at least
21:37:03 <elliott> probably the mail server it used was down or something
21:37:49 <elliott> ais523: so, does sg have any nice properties/features that you know of for single-developer cases?
21:37:54 <elliott> heck, for versioning dotfiles? :)
21:38:29 <ais523> one that would be nice would be the ability to extract just a file and its dependencies from a large project and work on that
21:38:46 <ais523> I've tried to do that before, but darcs ended up pulling in 9/10 of the project because it was too coarse-grained
21:38:48 <elliott> ais523: hmm, re: storing file metadata in directories, the command line tool would have to be a bit smart about that, i.e. say that telling it to track file X is actually interpreted as cherry-picking the change to the directory of X
21:38:55 <ais523> if multiple files were changed in a patch, it had to use both or neither
21:39:07 <ais523> sg could easily use "half a commit" if necessary
21:39:17 <elliott> ais523: (does ^ make sense?)
21:39:31 <ais523> that's not a massive smartness issue, though
21:40:25 <elliott> ais523: btw, to get this out of the way, I strongly oppose having Ŋscapegoat's name actually start with a non-ASCII character :-)
21:41:25 <ais523> you could just use , that's in ASCII and sorts to the end of a directory
21:41:37 <elliott> @scapegoat or %scapegoat seem like the best bets to me (wow, just realised the perl connection) because they're at least near the top (% comes before numbers and letters, @ before letters) and they suggest "special things" but don't have to be escaped in a shell
21:41:55 <ais523> also, left shift + left control + u lets you type arbitrary Unicode in GNOME by specifying its hex code
21:42:11 <elliott> in a specific input method, perhaps
21:42:46 <elliott> well, I'm certainly using gnome
21:42:46 <ais523> it works on CentOS here and Ubuntu at home
21:43:08 <ais523> hmm, and seems not to be sensitive to which control and which shift is used, unlike altgr
21:43:09 <elliott> debian here... but who knows what i have input methods set to
21:43:24 <ais523> also, http://www.google.com/intl/en/ipv6/statistics/ is really depressing
21:43:50 <elliott> ais523: and v4 is running out faster than ever
21:44:04 <ais523> oh, it'll continue running out long after it's actually out of addresses
21:44:18 <ais523> hopefully, IPv4 exhaustion will finally prompt ISPs to start switching to IPv6
21:44:34 <elliott> ais523: actually, the last allocations are almost in
21:44:47 <elliott> ais523: and the actual-last-address-allocated estimate is looking like about March 2011
21:44:48 <ais523> indeed, 7 blocks left, and the last 5 are allocated all at once
21:44:51 <elliott> Ilari can confirm for sure
21:44:59 <elliott> ais523: so "long after" is wrong
21:45:14 <ais523> elliott: I was referring to recursive NAT
21:45:24 <ais523> which is bound to be the stopgap used, until people realise that it doesn't actually work
21:45:28 <elliott> ais523: but, still, consider every VPS provider ever
21:45:38 <elliott> ais523: I could create five new slices right now, and each would get its own static IP
21:45:46 <elliott> and there's no real way to NAT VPSes
21:45:50 <ais523> yep, you wouldn't be able to in a while, I suspect
21:45:52 <elliott> since you can run anything on them, on any port
21:46:02 <ais523> exhaustion will hit servers much harder than clients
21:46:04 <elliott> ais523: so it really is a huge thing, because businesses don't exactly want shared hosting
21:46:15 <elliott> and when they need to put a new machine up ... they just can't
21:47:15 <ais523> it's huge, but it probably won't cause the end of the world
21:47:20 <ais523> rather, it'll just be a wake-up call
21:47:31 <elliott> ais523: I suggest we assign an IPv6 address to every scapegoat object, just to make IPv6 depletion that much easier
21:47:42 <ais523> does that even make sense?
21:48:05 <elliott> ais523: it can if we make it!
21:48:41 <elliott> "We reply to Russ Cox's "Yacc is Not Dead" by running the example that he claims has best-case complexity of Ω(3^n). It terminates instantly for n > 100."
21:49:10 <elliott> ais523: hmm, so what should we do for public keys? presumably, commits should be optionally signable
21:49:18 <elliott> and author objects would have a gpg public key with them
21:49:31 <Ilari> Actually, its now February... And yes, some RIR will grab 2 blocks, and then last five are immediately distributed.
21:49:32 <elliott> Phantom_Hoover: a blog post
21:49:40 <ais523> elliott: that makes sense, I suspect
21:49:43 <Phantom_Hoover> fizzie, for killing fungot, I challenge you to a Minecraft duel!
21:49:59 <ais523> Phantom_Hoover: are there any plausible weapons?
21:50:01 <elliott> ais523: hmm, maybe we should just have it future-proof... as in, just include gpg-signature keys in patches, and gpg-pubkey in authors
21:50:04 <ais523> I don't know whether to laugh
21:50:05 <elliott> ais523: and then we can switch at a later date
21:50:16 <elliott> ais523: and tools that don't want to can just ignore them, like other unknown keys
21:50:19 <ais523> I think we should futureproof everything, where it doesn't cost too much
21:50:20 <elliott> ais523: also, there's a sword in Minecraft, so yes
21:50:37 <elliott> well, minecraft has pvp, yes
21:50:42 <elliott> although it's disabled on our server
21:50:55 <elliott> making a battle to the death rather difficult
21:51:12 <ais523> elliott: why am I suddenly reminded of Falcon?
21:51:28 <elliott> ais523: erm, for minecraft or for scapegoat? :)
21:51:37 <Ilari> And that RIR is thought to be APNIC...
21:52:05 <ais523> elliott: it's as if Minecraft's put in any feature that anyone asked for
21:52:17 <ais523> or attempted to, but not got too far
21:52:29 <elliott> ais523: it's Survival Multiplayer; the existence of PvP is practically a given
21:52:34 <Phantom_Hoover> Notch removes everything that's enjoyable which causes the game to be played in The Wrong Way.
21:52:36 <elliott> you can't disable health with the stock server, we use a mod
21:52:43 <elliott> but you can disable monsters and pvp
21:52:48 <ais523> is the server open-source, btw?
21:52:56 <ais523> or at least open-binary?
21:52:58 <elliott> ais523: no, but people have deobfuscators that you run on the decompiled java
21:53:03 <elliott> ais523: (this is how mods exist)
21:53:11 <elliott> ais523: the nice thing about the mod we use, hMod, is that it has a stable plugin API
21:53:17 <elliott> so only one person needs to worry about server code changes
21:53:23 <ais523> by open-binary, I more or less mean "allowed to download the binary at will, etc"
21:53:32 <elliott> even if you don't have teh game
21:53:41 <elliott> http://minecraft.net/download/minecraft_server.jar?v=1292277191330
21:54:51 <elliott> ais523: another thing nicknames are useful for: identifying author objects
21:54:51 <ais523> hmm, just checked the computer here, it's IPv4 only
21:55:00 <elliott> useful when you want to do, e.g., "sg mail foo" to mail patches to foo
21:55:03 <ais523> they're useful for naming anything, more or less
21:55:04 <elliott> one issue with that: we need a consistent prefix
21:55:13 <ais523> enforced? or convention?
21:55:15 <elliott> ~foo would be ideal, but you'd have to quote it in a shell
21:55:21 <fizzie> The "there will be beta soon" blagpost also said he'll start working on a stable server API for mds.
21:55:27 <ais523> I suggest lpsz, to annoy Windows programmers
21:55:33 <ais523> although that joke's a bit dated nowadays
21:55:34 <elliott> ais523: only enforced thing is that @ is a reserved prefix, I think
21:55:54 <elliott> ais523: although arguably, @ should mean "branch"
21:55:57 <Ilari> Long pointer size?
21:56:13 <elliott> ais523: (this is the point where it's worth considering having a different set of nicknames for each object type rather than this silly prefix business...)
21:56:33 <ais523> Ilari: long pointer to zero-terminated string
21:56:50 <elliott> as opposed to a short pointer?
21:57:05 <ais523> although even in win3.1, it was a silly distinction
21:57:20 <ais523> because the library functions you were calling were unlikely to be in the same segment as your program itself
21:57:27 <Ilari> And long pointer? Who uses that with 32-bit stuff?
21:57:35 <ais523> Ilari: relic from 16-bit Windows
21:57:40 <ais523> the prefix was preserved into win32
21:57:46 <fizzie> And that lparam/wparam stuff.
21:57:47 <ais523> I hope they finally got rid of it with #net, though
21:58:46 -!- fungot has joined.
21:58:48 <elliott> ais523: annoying thing about scapegoat: it's so close to being perfect for Haskell, except that you'd need all the store operations to be in IO because of the implementation detail that you happen to save them
21:59:03 <elliott> ais523: also, it's probably over-generalised enough that Haskell would be too slow :(
21:59:28 <elliott> (not with hand-optimisation, perhaps, but then why bother using haskell?)
21:59:33 <Ilari> Wonder how many Linux programs (besides stuff like DOSEmu or so) use far pointers (at least Linux/i386 has some syscall that only makes sense with far pointers...)
22:00:33 <elliott> ais523: I'm wondering if the object store might want to store more complicated things too; a patch is basically a set, isn't it?
22:00:47 <elliott> it would be a bit awkward to do set[hash(x)]=x for every single change in a patch
22:01:47 <elliott> OTOH, maybe we should just store a patch as its changes, sorted in some arbitrary way?
22:01:58 <elliott> in which case, we'd need lists (and at that point I'd agree that we should abandon a filesystem-based approach...)
22:02:45 <ais523> storing a patch as its changes would effectively store the whole repo in any toplevel patch
22:02:58 <ais523> so obviously you can't do that completely in general
22:03:05 <ais523> but it would be a sensible optimisation for some patches
22:03:54 <ais523> oh, a patch that isn't referred to by any other
22:04:04 <ais523> as in, the merge of @tip and its siblings
22:04:17 <ais523> worse, the same would apply to any patch that had ever been @tip
22:05:02 <elliott> ais523: hmm, are you sure?
22:05:08 <elliott> ais523: wouldn't it be the set of changes from the previous @tip?
22:05:41 <ais523> oh, you mean not recursively
22:06:18 <ais523> hmm, I imagine that could work
22:06:40 <elliott> ais523: well, "changes, not recursive" is pretty much the definition of a diff :)
22:06:55 <elliott> ais523: I mean, you already have a diff-esque format
22:07:07 <elliott> so just, make them relative to their parent(s) in the tree
22:07:11 <ais523> still, there's the issue of multiple parents
22:07:26 <elliott> ais523: hg has commits with multiple parents and is diff-based
22:07:29 <elliott> I'm not sure how it works, though
22:07:29 <ais523> how do you distinguish between the diff from the previous @tip (all the merged changes), and the diff from the merged changes (the previous @tip)?
22:07:37 <elliott> ais523: hmm, maybe you store one diff per parent
22:07:41 <elliott> such that each diff produces the same result
22:07:49 <elliott> if you have multiple parents
22:07:55 <ais523> I was thinking of that, but then the diff to the "small" parent's going to be the whole repo
22:08:06 <ais523> I think, if you're just going for efficiency, you store the smallest diff to a parent
22:08:21 <ais523> which'll be right 99% of the time, and the rest, you just calculate from scratch
22:08:31 <elliott> ais523: TODO: figure out what hg does in this case
22:09:32 <elliott> ais523: hmm, I wonder what it *does* do?
22:09:39 <elliott> it definitely has commits with multiple parents, usually merges
22:09:42 <elliott> and it definitely stores things as diffs
22:09:50 <ais523> in our case, every commit is a merge except for the first
22:09:55 <ais523> so every commit has multiple parents
22:10:15 <elliott> <elliott> How does hg handle the storage of commits with two parents (e.g. merges) internally? If it stores them as a diff, which parent does it calculate the diff from?
22:10:22 <elliott> let's see if anyone's awake
22:10:42 -!- Phantom_Hoover has quit (Ping timeout: 245 seconds).
22:12:09 <elliott> <mpm> elliot: Mercurial always stores snapshots conceptually. Delta compression is handled at a lower level.
22:12:09 <elliott> <homa_rano> elliott: but conceptually, the diff shown from a merge is from the first parent
22:12:10 <elliott> <elliott> mpm: OK. How would the lower level look in the case of two parents being merged?
22:12:10 <elliott> <elliott> homa_rano: ah -- how does hg work out which parent is the first?
22:12:14 <elliott> ais523: (mpm is the creator of mercurial)
22:12:23 <elliott> also, I love how I catch out everyone who doesn't use tab complete
22:12:29 <elliott> it doesn't highlight me if you spell my name wrong, guys...
22:12:38 <oerjan> <elliott> ais523: and the actual-last-address-allocated estimate is looking like about March 2011 <-- i've seen at least twice (Ilari yesterday was the second time) estimates indicating late _January_
22:12:50 <elliott> oerjan: yep, I was behind on my results
22:12:59 -!- impomatic has joined.
22:13:03 <elliott> ais523: <homa_rano> the first is the one you had checked out when you typed 'hg merge'
22:13:05 <ais523> oerjan: why is it accelerating? people trying to get addresses before the Internet runs out?
22:13:13 <elliott> ais523: so, tl;dr hg just picks an arbitrary parent to diff from, pretty much
22:13:20 <ais523> elliott: diff-to-one-parent seems correct for us, too
22:13:32 <Ilari> One of the model estimates (as opposed to personal guesses of various people) was in January few days ago.
22:13:33 <elliott> ais523: yep, it's just that, they have a working copy that they can choose to diff from; we have no real way to decide which
22:13:42 <elliott> calculating a diff from every parent is expensive
22:13:45 <ais523> and we should pick the one that results in the smaller diff as it's a sensible heuristic to determine which one makes the better working copy
22:13:54 <elliott> <homa_rano> but the underlying storage is unrelated to parentage
22:13:54 <elliott> <mpm> elliott: We may or may not delta against a convenient revision in the underlying storage.
22:14:05 <ais523> and can't you just calculate in parallel and stop once you have any diff?
22:14:07 <elliott> <elliott> Would it, say, diff against every parent and then pick the shortest diff?
22:14:13 <elliott> ais523: no, not if you want the smallest one
22:14:28 -!- augur has joined.
22:14:41 <Ilari> The current estimates are 2nd February and 23rd February.
22:14:43 <ais523> also, you have to remember that with sg's extra metadata, you can do some large diffs very quickly
22:15:05 <ais523> as normally, you'll find a common ancestor quickly if you just do a breadth-first search
22:15:11 <ais523> and there's no need to expand any further from there
22:15:12 <impomatic> Anyone fancy thrashing this guy at his own programming contest? http://skybuck.org/BoxifyMe
22:15:31 <ais523> if a line's the same line in two files, then it's got to be based on the same patch
22:15:33 <elliott> impomatic: "And may the boxforce be with the fokking you ! ;) =D LOL."
22:15:40 <elliott> impomatic: I can't do anything related to anyone who says... whatever that is.
22:15:46 <ais523> if it's in the same context, then those have to be based on the same patch, too
22:15:59 <elliott> ais523: <mpm> It generally deltas against the last revision, regardless of how it's related. But that's an implementation detail.
22:16:09 <elliott> ais523: the problem is, in sg, we can't have the luxury of treating diffs as an implementation detail
22:16:12 <elliott> because they're fundamental
22:16:23 <ais523> well, at the bottom level, there are only a very few diffs
22:16:46 <ais523> the "insert "x" between 2 and 3", "change 5 to "hello world"", "delete 8"
22:16:52 <elliott> ais523: oh, oh, here's something you might like
22:16:55 <elliott> ais523: http://git-annex.branchable.com/
22:16:59 <elliott> ais523: from Joey Hess, of Debian fame
22:17:16 <ais523> although of course, you'd want to probably cache what combinations of those bottom-level patches came to
22:17:19 <elliott> the walkthrough especially (well, after the two introductory paragraphs)
22:17:22 <elliott> highly recommend you take a look
22:17:40 <elliott> ais523: "change 5 to "hello world""
22:17:45 <elliott> ais523: wouldn't that be "change 5 to 6"?
22:17:47 <ais523> I've had a quick look, I'll check more later
22:17:52 <ais523> elliott: no, that /is/ 6
22:18:01 <elliott> ais523: wait, the *change* is the line?
22:18:14 <elliott> ais523: ok, let's say 6 = insert "x" between 2 and 3
22:18:18 <ais523> lines are referred to by the change that introduced them
22:18:18 <elliott> ais523: what's "change 6 to "hello""?
22:18:33 <impomatic> elliott: I suspect the guy running the contest is about 10 years old :-)
22:18:34 <ais523> it changes the x that was originally addded between 2 and 3 to "hello"
22:18:47 <ais523> and because this is scapegoat, it knows which one that was, and whether it's still there
22:19:22 <elliott> impomatic: I would do it except reading the image in sounds like the only part that'd take any time, and it sounds boring :)
22:19:24 <ais523> if it had been deleted since, or changed to something else, it wouldn't be there, or have a different number, respectively, so it wouldn't be found
22:19:43 <elliott> ais523: so "change 3489573945 to "blah"" if 3489573945 isn't present in the revision we're applying this to would barf out?
22:19:54 <ais523> elliott: yes, that's the definition of a merge conflict
22:20:02 <elliott> ais523: hmm, how easy is it to do "sg diff", i.e. "give me a diff between, say, @tip and current working directory"
22:20:11 <elliott> ais523: as in, an actual unified diff
22:20:23 <elliott> and after you've answered that: same question, but s/@tip/r1/ and s/current working directory/r2/ for arbitrary r1 and r2
22:20:51 <ais523> conceptually simple; you take the set difference between the recursive dependencies of each
22:21:02 <ais523> then convert that into the lines in question
22:21:23 <elliott> ais523: but actual simplicity?
22:21:36 <elliott> ais523: I mean, imagine a revision from 10 years ago to now, when there's been 3 rewrites in-between
22:21:39 <elliott> and you want a unified diff between them
22:21:48 <elliott> surely "sg diff r1 r2" would be ... rather slow?
22:22:08 <ais523> in that case, I suspect it might be, finding a common ancestor would take ages
22:22:15 <ais523> and then sg would list one with a bunch of +s, and the other with a bunch of -s
22:22:22 <ais523> it wouldn't generate a textual diff, but a conceptual diff
22:22:30 <elliott> ais523: err, no, I mean in an actual diff -u output
22:22:37 <ais523> it would be an actual -u output
22:22:43 <ais523> but I mean, not generated by diffing text
22:22:46 <elliott> ais523: come to think of it, how fast would "sg checkout rev" be?
22:22:51 <ais523> but by working out what changed, then converting that into unidiff
22:23:00 <elliott> I suspect the answer is "slow, in the general case"
22:23:07 <ais523> and incredibly slow with a naive impl, but easily optimisable
22:23:35 <elliott> ais523: if you mean "oh, just store the last few revisions unpacked"... well
22:23:37 <impomatic> elliott: Al Zimmermann's latest programming contest requires quite a bit of processing power :-) http://azspcs.net/Contest/Cards
22:23:43 <ais523> I suspect the best storage is a git-like one: for each patch which nothing depends on, store the entire tree; for each patch which something depends on, store a diff from something that depends on it
22:23:49 <elliott> ais523: I don't think a 15-year-old revision should take hours to check-out.
22:23:50 <ais523> i.e. a backwards tree of diffs
22:24:02 <elliott> A minute, would be about the most I'd accept (assuming it's not huge, filesystem-wise)
22:24:15 <ais523> then, every so often, store a complete tree
22:24:15 <elliott> with a local Ħscapegoat directory
22:24:22 <ais523> in order to speed the process up
22:24:28 <elliott> ais523: maybe... does git actually do that though?
22:24:29 <ais523> say, once every 100 dependencies or so
22:24:38 <ais523> I think it does either that, or something pretty similar
22:24:41 <ais523> I can't quite remember the details
22:24:46 <elliott> ais523: I don't think the Linux git has hundreds of full copies of Linux in it.
22:24:48 <ais523> I suspect that would work, though, and even has tuneable performance
22:25:33 <elliott> ais523: well, we'll see :P
22:25:47 <elliott> ais523: anyway, I just realised something
22:26:00 <ais523> I think the Linux git tree probably does have hundreds of full copies
22:26:01 <elliott> ais523: oh, wait, I realised something but it was wrong
22:26:06 <ais523> perhaps one at each release
22:26:11 <elliott> ais523: linux-2.6.git is <200 megs
22:26:21 <ais523> because they're deduplicaetd
22:26:29 <elliott> ais523: latest 2.6 itself is 60 megs bzipped
22:26:45 <ais523> is git fast at really old revisions?
22:26:55 <elliott> ais523: all revisions take the same time to extract, afaik
22:27:15 <ais523> well, we can look into what it does
22:27:30 <ais523> worst case, just use git as the FS behind scapegoat and let it handle the deduplication, if it's that magical
22:27:43 <elliott> ais523: we should look at hg's internal system too, since it's like git but less hacky :)
22:28:01 <elliott> which is probably easier to get overall details from than git's optimised C
22:28:13 <ais523> "store a diff against something" is probably reasonable for an implementation strategy, but it's unclear how it would work for really old things
22:28:40 <oerjan> <elliott> oerjan: ? <-- i was (still am :D) way backscrolled so i didn't see Ilari had commented on the same thing
22:28:49 <elliott> ais523: anyway, I thought nicknames could be done in the store, but I was wrong
22:29:05 <ais523> they'd be global if they were
22:29:10 <ais523> by definition, pretty much
22:29:29 <elliott> ais523: well, yes, it's just that if you had multiple clashing nicknames, you couldn't use those nicknames
22:29:35 <elliott> ais523: first, let's say that the hash function takes a type as a parameter -- branch, pointer, nickname, whatever -- and mixes that into the hash however
22:29:56 <ais523> it's nice to have short nonunique nicknames like "elliott" for a local repo
22:30:06 <elliott> ais523: shush, i'm explaining how you can have that
22:30:39 <elliott> ais523: now, store a nickname like this: nickname_kvstore = insert(kvstore, type="nickname", key=nickname, value=new_kvstore)
22:30:52 <elliott> ais523: so, this has {hash(nickname, type="nickname") => {}}
22:30:55 <elliott> ais523: and nickname_kvstore is the kvstore
22:31:21 <oerjan> <ais523> oerjan: why is it accelerating? people trying to get addresses before the Internet runs out? <-- that's the suspicion
22:31:21 <elliott> ais523: insert(nickname_kvstore, type="branch", key=the_branch_not_its_hash_the_actual_branch_object, value=the_branch_etc_etc_etc)
22:31:37 <elliott> ais523: so it's {hash(nickname, type="nickname") => {hash(branch, type="branch") => branch}}
22:31:46 <elliott> ais523: now, imagine copying a store into another
22:31:52 <elliott> ais523: obviously, in this case, the hash for the nickname just gets bigger
22:31:53 <ais523> oh, so branches own their own list of other branches
22:31:58 <ais523> it's... peer to peer branching
22:32:05 <elliott> that has nothing to do with what i said!
22:32:06 <ais523> well, nicknames to other branches
22:32:16 <elliott> ais523: well, yes, in that they're versioned, but they don't HAVE to be
22:32:19 <elliott> I'm just talking about the kv store itself
22:32:36 <elliott> ais523: so, if foo is the nickname for bar in one repo, and the nickname for baz in another, and you copy them into another
22:32:41 <ais523> thought you had a hash from branches to hashes of nicknames to branches, that isn't what you said though
22:33:02 <elliott> {hash("foo", type="nickname") => {hash(bar, type="branch") => bar, hash(baz, type="branch") => baz}}
22:33:09 <elliott> ais523: now, here's how you look up a nickname:
22:33:20 <elliott> nickname_kvstore = lookup(kvstore, "foo", type="nickname")
22:33:31 <ais523> then you get a set of possibilities
22:33:34 <elliott> if (number_of_elems(nickname_kvstore) != 1) { NOOO! IT'S BAD! }
22:33:44 <ais523> I thought that's what we were doing anyway?
22:33:52 <elliott> else /* get the single element out */
22:33:59 <ais523> the reason it wasn't in the store was so you could copy stores indiscriminately without global namespace pollution
22:34:19 <elliott> ais523: right, except that it doesn't actually matter, unless you actually use sg on those merged stores directly
22:34:29 <elliott> ais523: in my model, I didn't think it could go in the kvstore
22:34:40 <elliott> ais523: because I made the file be called HB-HN
22:34:46 <elliott> where HB = hash of branch, HN = hash of nickname
22:34:54 <elliott> and I didn't realise that it could be done without two hashes in one name
22:35:03 <elliott> you couldn't do hash(HB "-" HN) because you don't know HB
22:35:11 <elliott> ais523: anyway, consider scapegoathub
22:35:28 <elliott> ais523: it simply only includes nicknames that reference objects it's sending down
22:35:45 <elliott> ais523: (this means we need a sort of, "second level search", i.e. give me the key whose value contains this key, which is easy with a filesystem, at least)
22:35:47 <ais523> I just like the theory that someone could grab its store without all their nicknames becoming useless
22:35:54 <ais523> perhaps what we need is a whitelist for nicknames too
22:36:03 <ais523> in fact, you could store them in a not a filesystem
22:36:06 <elliott> ais523: well, what i was thinking is, you know how directories?
22:36:17 <ais523> I think we both came up with that at the same moment
22:36:28 <elliott> ais523: oh, wait, that means we don't even need
22:36:34 <elliott> ais523: we don't even need this method of storing it
22:36:40 <elliott> ais523: we just have a not-a-filesystem with a bunch of names
22:37:05 <elliott> ais523: Orcl don't like me, so they don't include foobarly in their nicknames
22:37:06 <ais523> within a given repo, entirely possible
22:37:16 <ais523> well, it's in your nicknames
22:37:21 <elliott> ais523: yes, but what about other people?
22:37:22 <ais523> they just don't whitelist that, you do
22:37:31 <elliott> ais523: how would they discover the branch?
22:37:39 <elliott> ais523: hmm... actually, wait
22:37:42 <elliott> ais523: @tip makes *no sense*
22:37:56 <ais523> it makes sense relative to a particular branch
22:37:59 <elliott> ais523: platonically, everything is part of one yggdrasil repository
22:38:05 <elliott> ais523: but that's the thing, @tip *is* a branch
22:38:09 <elliott> it was meant to be the bootstrap that let you see anything else
22:38:23 <ais523> I think repositories themselves have to be the bootstrap
22:38:23 <elliott> ais523: great, everything just got re-confused in my head
22:38:36 <elliott> ais523: I *think* I've just gone back to thinking that nicknames shouldn't be part of turtles themselves
22:38:42 <elliott> to avoid a huge bootstrap issue
22:38:58 <ais523> it works perfectly except bootstrap
22:39:09 <elliott> ais523: right... and we're not in the bootstrapping business
22:39:13 <elliott> and personally, I don't want to be in that business
22:39:34 <elliott> but also because i want to solve version control, not bootstrapping too!
22:39:54 <elliott> ais523: well, at least I like scapegoat now (previously I thought it was line-based for no real reason, and impossible to store efficiently)
22:40:16 <elliott> I think the problems are tractable, if we step a *little* outside platonic perfection
22:40:26 <elliott> once you have a pointer to a useful branch, you're basically sorted
22:40:57 <elliott> ais523: if we hardcode @tip to mean a certain hardcoded specification, then we can probably store nicknames in turtles
22:41:12 <elliott> ais523: it's just that, two branches having two different ideas of what nicknames there are is perverse
22:41:21 <elliott> you could switch to a branch and have no way to switch to another branch without going through @tip
22:41:32 <ais523> oh right, that's enough to not turtle nicknames for me
22:41:54 <elliott> ais523: so I think the original, Åscapegoat/names approach was actually best
22:41:55 <ais523> it'd be like visiting a website and finding it had entirely different DNS and your back button didn't work
22:42:01 <elliott> and there's no real point to put them in the store, really
22:42:05 <elliott> it's an implementation detail at this point
22:43:53 <elliott> ais523: yeah, might as well use my nested-hash-in-store if I can get that working efficiently with the two-level search for scapegoathub
22:44:09 <elliott> if not, easy enough to use the %scapegoat/names system (yes, I'm dropping the unicode thing)
22:44:18 <ais523> also, scapegoathub is a ridiculous website name
22:44:28 -!- MigoMipo has quit (Ping timeout: 255 seconds).
22:45:15 <elliott> the other options are !scapegoat (no, shells barf on that), "scapegoat (nope, shells), #scapegoat (nope, shells... as well as reminding me of IRC and being weird), $scapegoat (shells), %scapegoat, &scapegoat (shells), 'scapegoat (shells), (scapegoat (shells), )scapegoat (shells), *scapegoat (shells), +scapegoat (shells? maybe not), ,scapegoat (weird), -scapegoat (nah)
22:45:26 <elliott> I think out of those, %scapegoat or +scapegoat is the best choice
22:45:43 <elliott> +foo seems to be uninterpreted in bash, so that's a possibility
22:45:55 <ais523> it is, some programs use it for long options
22:46:02 <Gregor> Is there a problem with naming it just ... scapegoat?
22:46:04 <elliott> ais523: true, but programs operating on files?
22:46:05 <ais523> including programs generated by C-INTERCAL, I think just to be perverse
22:46:08 <elliott> Gregor: erm, this is the directory like .hg
22:46:21 <Gregor> Why not .scapegoat then? :P
22:46:29 <elliott> Gregor: I don't want it to be called .scapegoat because it's neither configuration nor a backup file
22:46:31 <elliott> and there's no real reason to hide it
22:46:38 <elliott> it's not very *interesting*, but it's not irrelevant
22:46:42 <ais523> don't backup files end with ~?
22:46:45 <elliott> and eliding it from filename listings is just confusing
22:46:57 <elliott> ais523: don't call it a backup directory, I'll have to slap you
22:47:03 <ais523> then why would you start them with .?
22:47:10 <ais523> or is this a Vorpal-level misunderstanding on my part?
22:47:14 <elliott> ais523: well, vim calls its swap files .something.swp I think
22:47:20 <elliott> emacs has .#foo# too, at least for me, sometimes
22:47:44 <ais523> you're thinking of the broken symlinks starting .# it uses to prevent accidentally opening the same file twice
22:47:55 <ais523> (why it uses broken symlinks for that purpose, I'm not sure)
22:47:58 <oerjan> <ais523> *because Feather? <-- wait is this scapegoat idea actually _based_ on feather?
22:48:06 <ais523> that's too insane for words
22:48:07 <elliott> we could also go for :scapegoat (naw), ;scapegoat (shells), <scapegoat (shells), =scapegoat, >scapegoat (shells), ?scapegoat (shells, I think)
22:48:11 <elliott> but those come after numbers
22:48:16 <elliott> making them not really order any particular way at all
22:48:18 <ais523> we're making design decisions to stop it working like Feather as much as possible
22:48:37 <ais523> hmm, what about calling it -rf?
22:48:39 <elliott> possibly some things put ^scapegoat before other things too
22:49:05 <elliott> +scapegoat seems like the best contender to me, it's like %scapegoat but less ugly... and really, I don't know of any tool that accepts +-options and would be useful to use on a file, at least, not very often
22:49:12 <elliott> and the + makes me think "additional"
22:49:23 <elliott> as in, you don't *need* this, if you want these files, but it has additional sets of files like this that you might liek
22:49:37 <ais523> yep, I like the look of the + too
22:49:42 <ais523> except that it renders really badly with this font
22:49:51 <ais523> I didn't even know you /could/ render a + asymmetrically...
22:50:03 <oerjan> <elliott> [...] (yes, I'm dropping the unicode thing) <-- i was about to ask...
22:50:14 <elliott> ais523: and now I'm wondering if arch/tla is perhaps just terribly misunderstood, and they picked all their filenames for perfectly good reasons :D
22:50:24 <ais523> (it's a pixel shorter on the left than right, and a pixel shorter below than above)
22:50:25 <elliott> ais523: and if all that confusing terminology is just GENERALITY!
22:50:40 <ais523> the difficulty of creating a repo is quite large
22:50:49 <elliott> yes, I say we go for "sg init"
22:50:50 <ais523> I think it has some sort of repo repo you store your repos in
22:51:06 <elliott> ideally, you wouldn't have to think about all this advanced technology every day...
22:51:34 <elliott> ais523: hmm, every repo needs to come with one commit there, because it's the branch everything is based on
22:51:42 <elliott> I suggest it be authorless, and absolutely contentless
22:51:55 <elliott> and then every store will include that object and maybe a few others if it needs extra ones to exist :)
22:52:11 <ais523> hmm, shouldn't it be an empty directory?
22:52:14 -!- Phantom_Hoover has joined.
22:52:27 <ais523> also, I need to go home, now may be a good time
22:52:36 -!- ais523 has quit (Quit: Page closed).
22:56:21 <oerjan> you weren't supposed to suspect that
22:57:30 <Gregor> elliott: The only acceptable directory name is +scape🐐
22:57:36 <Gregor> And if you can't read that ... neither can I, but still
22:57:45 -!- Phantom_Hoover has quit (Remote host closed the connection).
23:09:16 -!- oklofok has quit (Ping timeout: 240 seconds).
23:10:57 -!- poiuy_qwert has quit (Quit: This computer has gone to sleep).
23:15:25 -!- oklofok has joined.
23:27:03 -!- impomatic has quit (Quit: ChatZilla 0.9.86 [Firefox 3.5.16/20101130074636]).
23:33:12 <zzo38> Do you have any idea or comment or collaboration or anything about TeXnicard? Should I create a IRC channel on my server for this purpose? (Remember to FLUSH the channel afterwards if you want to ensure your question/comment is not lost due to power failures!)
23:40:25 <elliott> <brodie> hmm, hg log -r 'limit(sort(all(), -rev), 4) and not merge()' does the same thing as hg log -l 4 -M, which isn't what i want
23:40:29 <elliott> Dear god it has Python in it.
23:40:48 <elliott> zzo38: erm I don't believe you can FLUSH an IRC channel
23:41:30 <zzo38> elliott: On most IRC servers you cannot. On CthulhuIRCd, you can FLUSH an IRC channel.
23:41:39 <oerjan> this is _zzo38's_ IRC channel we are talking about, it's ... right.
23:42:01 <elliott> in other words, it's not IRC :)
23:43:17 <zzo38> elliott: It is IRC, it is just non-standard. Commands like NS and CS supported on Freenode are not standard IRC commands either.
23:44:41 -!- FireFly has quit (Quit: swatted to death).
23:44:58 <zzo38> (And I have no need to support syntactically incorrect commands in my server.)
23:48:43 <zzo38> oerjan: Why do you want to support syntactically incorrect commands in your server?
23:50:18 -!- sftp has quit (Remote host closed the connection).
23:51:19 <elliott> ugh, I hate libraries whose manuals are PDFs
23:51:30 <elliott> (or postscripts or dvis, before zzo38 mentions it :P)
23:52:59 <oerjan> zzo38: um i'm pretty sure i never said i wanted that
23:52:59 <fizzie> 🐐 - "U+1F410 GOAT (eighth of the signs of the Asian zodiac)"
23:53:05 <fizzie> Not that I have in any of my fonts either.
23:53:33 <elliott> oerjan: you didn't ctcp him or anything?
23:53:40 <elliott> oerjan: WHY DO YOU WANT TO KILL BABIES
23:53:41 <fizzie> Sorry, "eighth of the signs of the Asian zodiac, used in Vietnam"; was reading the RAM instead.
23:53:51 <oerjan> elliott: BECAUSE THEY'RE SO TASTY
23:53:54 <elliott> fizzie: rams and goats, what's the difference
23:54:07 <elliott> zzo38: why do you think oerjan wants to support syntactically incorrect commands in his server?
23:54:10 <fizzie> elliott: The difference is that they use the GOAT in Vietnam.
23:54:23 <zzo38> elliott: Because some people do.
23:54:31 <oerjan> ALSO THEY SCREAM TOO MUCH
23:54:56 <zzo38> elliott: Well, it seems common.
23:55:00 <elliott> zzo38: (for some X in People, WantsSyntacticallyIncorrectCommands(X)) => WantsSyntacticallyIncorrectCommands(oerjan)?
23:55:09 <fizzie> U+1F47D EXTRATERRESTIAL ALIEN, right there between BABY ANGEL and ALIEN MONSTER.
23:55:17 <elliott> zzo38: mind, I do want syntactically-incorrect commands in my IRC servers.
23:55:24 <fizzie> (The "miscellaneous symbols and pictographs" block sure is the best.)
23:55:42 <elliott> zzo38: because they're convenient.
23:56:18 <zzo38> elliott: I think they still should be made syntactically correct even if it is going to be convenient!
23:56:31 <elliott> zzo38: not possible, with existing clients
23:57:02 <oerjan> fizzie: *EXTRATERRESTRIAL
23:57:07 <zzo38> elliott: It is possible with my client, if your client doesn't do that, it is partially broken.
23:57:19 <elliott> zzo38: yep, but I don't like your client, and I like the client I use
23:57:35 <zzo38> elliott: Can't you correct the client you use then?
23:58:01 <elliott> zzo38: no, I use my distribution packages for convenience.
23:58:10 <oerjan> ooh, cpressey linkified feather on the wiki. i think this means we are all doomed.
23:58:13 <elliott> zzo38: correcting them brings me no benefit, is a lot of effort, and I'd have to update it for each new version of my client.
23:58:22 <elliott> oerjan: that's not allowed!
23:58:31 <elliott> ais has said he won't create a page until it's ready
23:58:38 <elliott> and putting intentional redlinks there that won't be filled for ages is just silly