00:00:12 <Ngevd> I may make a Piet-like language with pure functions
00:00:32 <EgoBot> Traceback (most recent call last):
00:00:40 <lambdabot> No instance for (GHC.Num.Num GHC.Types.Char)
00:01:08 <lambdabot> No instance for (GHC.Num.Num GHC.Types.Char)
00:01:39 <HackEgo> /home/hackbot/hackbot.hg/multibot_cmds/lib/limits: line 5: exec: poop: not found
00:01:48 <HackEgo> /home/hackbot/hackbot.hg/multibot_cmds/lib/limits: line 5: exec: : not found
00:02:05 <elliott> PlacentaProphet: It's in tr_60.cmd
00:02:24 <elliott> Gregor: btw what does the tr actually stand for
00:02:31 <Ngevd> One step no darker -> id
00:02:37 <Ngevd> One step one darker -> const
00:02:44 <oerjan> <augur> would you be inclined to point to the rectangle <-- i would be inclined to say that vision has enough unintuitive illusions that i wouldn't try and guess the result by reasoning.
00:02:45 <Ngevd> One step two darker -> ap
00:02:57 <Ngevd> I have been here for a while
00:03:08 <augur> oerjan: im just incredibly skeptical that people would do that
00:03:11 <Ngevd> Thinking of a Piet-like language with pure functions
00:03:18 <augur> whereas someone on reddit is certain people would
00:04:05 <Ngevd> It will also be self-modifying
00:04:07 <pikhq> Yeah, that's the sort of thing where the only way to be certain would involve actually doing the study.
00:04:23 <elliott> And disguising it so people don't hesitate for five minutes :P
00:05:25 <PlacentaProphet> elliott: so is the sender sending the thing that the receiver is receiving
00:05:33 <augur> pikhq: well i'd do the study if i could
00:05:38 <Ngevd> One with bignums, one with functions
00:06:01 <PlacentaProphet> @ask Gregor so is the sender sending the thing that the receiver is receiving
00:07:42 -!- Ngevd has quit (Quit: long shot but fungot).
00:08:22 <PlacentaProphet> elliott: also I'm pretty sure you don't have to declare commit_queue global
00:10:37 -!- Haschim has joined.
00:10:50 <PlacentaProphet> also Transaction could just inherit from Thread and then you don't need to define your own start.
00:13:08 <PlacentaProphet> command += ['-R', hackenv] I am led to believe that .extend() is faster than += on lists. this is a matter of grave importance.
00:13:13 <pikhq> augur: Seems like a lot of effort just to show up a random guy on Reddit, though. :P
00:13:34 <augur> pikhq: well, its part of a bigger discussion regarding color perception
00:13:35 <PlacentaProphet> elliott: obviously I've reduced my efforts to nitpicking your code since I have no clue what is actually causing the bug.
00:13:40 -!- Haschim has left.
00:13:42 <elliott> PlacentaProphet: Wait, wait, let me try to care: HNNNNNNNG can't.
00:13:44 <augur> pikhq: dealing with some very subtle issues
00:13:52 <augur> really, i want to talk to some himba speakers
00:13:56 <augur> but thats not possible.
00:15:01 <elliott> PlacentaProphet: args is a tuple.
00:15:13 <pikhq> augur: Yeah, color perception is hella weird. You'd know better than I, of course.
00:15:33 <augur> pikhq: no, its actually not very weird, not in regards to what im talking about anyway
00:16:01 <elliott> PlacentaProphet: Join #hackbotloony
00:16:02 <pikhq> Well, it just seems weird that it's to an extent affected by language.
00:16:10 <augur> pikhq: the issue is more that people don't understand that translations aren't perfect, and so relying on translations when doing science is very bad
00:16:11 <pikhq> You'd think that, e.g. "blue" would be a universal concept.
00:16:22 <augur> pikhq: no, its not affected by language
00:16:32 <pikhq> augur: Okay, maybe I'm describing this wrong.
00:16:47 <augur> you're just mislead by fluff popsci crap
00:17:14 <pikhq> augur: But, e.g. Japanese "aoi", though usually translated as "blue" really can't be translated that naively.
00:17:22 <elliott> PlacentaProphet: You are not spamming.
00:17:37 <pikhq> It refers to things that are blue, sure, but on the other hand it can refer to some things we'd consider green.
00:17:41 <pikhq> And that seems rather strange.
00:17:56 <augur> yes i suppose it "seems rather strange"
00:18:08 -!- ais523 has quit (Remote host closed the connection).
00:18:13 <augur> i mean, it doesnt seem strange to me, but whatever
00:18:45 <pikhq> I guess what I'm really coming down to is "language works differently than the layman expects it to".
00:19:12 <pikhq> Anyway, bit of a tangent. Whoooo.
00:23:17 -!- pkzip1 has joined.
00:23:38 -!- pkzip1 has left.
00:24:40 -!- elliott has quit (Remote host closed the connection).
00:25:16 -!- elliott has joined.
00:29:39 -!- evincar has joined.
00:29:45 <oerjan> > odd . floor $ tan 1.57
00:30:36 <augur> pikhq: the real problem, i find, is twofold
00:30:48 <augur> one, people love this popular whorfian bullshit
00:30:58 <augur> and they find any excuse to believe it
00:31:00 <augur> for some fucking reason
00:31:09 <oerjan> that's why they're all learning klingon.
00:31:15 <augur> two, people don't realize that words dont always mean the same thing to everyone else
00:31:37 <evincar> What? People still believe in linguistic relativity? :(
00:32:02 <augur> evincar: usually just mild forms of it, but yes
00:32:14 <pikhq> Man, freaking Sapir-Whorf.
00:32:23 <oerjan> evincar: i got a question about number of words for snow on a quiz just the other day.
00:32:28 <evincar> Well, there are some limited situations in which it can be shown to apply...
00:32:34 <oerjan> strangely, for sami, not eskimo.
00:32:42 <pikhq> Particularly as presented in 1984. Newspeak was such a dumb idea.
00:32:52 <evincar> According to an article I read once, English has more words for snow-related things than Inuit or whatever.
00:32:53 <augur> evincar: if by "apply" you mean "imperceptably", yes.
00:33:10 <evincar> If you count sleet, hail, etc.
00:33:16 <evincar> English has a lot of words in general.
00:33:24 <pikhq> "Thoughtcrime is doubleplusgood" Seriously, Orwell? You thought that couldn't be done?
00:33:30 <augur> and if by "apply" you mean "only when doing language tasks", yes
00:33:47 <pikhq> Anyways: it's not like neologisms are *uncommon*.
00:33:49 <augur> pikhq: E-prime pisses me off
00:34:06 <augur> oh your language lacks a copula, therefore it prevents people from expressing opinion as fact
00:34:27 <pikhq> If a speaker of a language doesn't have a word for a concept, but needs to talk about that concept, they will *make something up*.
00:34:44 <evincar> I want to hear you call Benjamin Whorf a child rapist.
00:34:44 <oerjan> pikhq: obviously in oceania, neologisms are treason.
00:34:55 <augur> evincar: benjamin whorf isnt the e-prime guy
00:35:00 <PlacentaProphet> pikhq: you have too much faith in the creativity of the average person.
00:35:01 <pikhq> oerjan: Eh, in Oceania everything's treason anyways.
00:35:19 <augur> PlacentaProphet: even without neologisms, you have periphrasis
00:36:47 <PlacentaProphet> my understand was that the Sapir-Whorf hypothesis claimed that using a particular language resulted in thinking about things /differently/, not necessarily that things can become /impossible/ to express.
00:37:10 <oerjan> <augur> oh your language lacks a copula, therefore it prevents people from expressing opinion as fact <-- i could imagine a language with some kind of evidentials so that you could not confuse opinion with fact without outright lying...
00:37:12 <pikhq> PlacentaProphet: The strong form of the hypothesis makes the claim that things can become impossible to express.
00:37:15 <evincar> But Orwell took it into fictionland.
00:37:44 -!- tiffany has quit (Quit: nyu~).
00:37:50 <oerjan> it might not actually exist, or be stable, but i could imagine it.
00:37:50 <evincar> oerjan: We imagine languages all the time that don't actually exist.
00:37:54 <pikhq> The strong form of the hypothesis, of course, is incredibly bullshit.
00:38:31 <augur> oerjan: that language is called Quechua
00:38:33 <augur> and you dont have to lie
00:38:36 <augur> you just have to be wrong
00:38:47 <augur> or not understand that your opinion isnt fact
00:38:48 <PlacentaProphet> a language as a map of words to meanings could, at a single point in time, be unable to express a word. of course in practice this is not how languages work.
00:39:15 <Vorpal> elliott, this is oblivion: http://deadendthrills.com/wp-content/uploads/2011/06/Oblivion-2011-06-07-23-56-58-24.jpg
00:39:27 <elliott> Oblivion with at housand mods :P
00:39:31 <augur> thats not oblivion
00:39:47 <Vorpal> augur, exactly what elliott said
00:39:50 <Vorpal> I just want those mods
00:40:00 <augur> you just wanna jerk off to that chick
00:40:05 <PlacentaProphet> and this is not certainly how the human brain works Morrowind that give it Oblivian-esque graphics
00:40:08 <elliott> http://deadendthrills.com/?cat=141
00:40:25 <elliott> <PlacentaProphet> and this is not certainly how the human brain works Morrowind that give it Oblivian-esque graphics
00:40:38 <Vorpal> augur, speaking of which... Apparently there is already a "naked female" skyrim mod....
00:40:49 <Vorpal> I'm not going to try it :P
00:40:51 <PlacentaProphet> there are mods in Morrowind that give it Oblivian-esque graphics
00:41:36 <oerjan> elliott: don't be obsidious
00:41:37 <Vorpal> elliott, I need to see if he did any morrowind
00:41:52 <Vorpal> because... vanilla morrowind is /ugly/
00:42:12 <elliott> http://deadendthrills.com/category/the-elder-scrolls-iii-morrowind/
00:43:09 <Vorpal> elliott, what about witcher 2?
00:43:26 <elliott> Vorpal: Googling showed up http://www.flickr.com/photos/futurilla/3200260681/ only, which is part of a GROUP called Dead End Thrills :P
00:43:36 <elliott> Which I suspect is just run by random people ripping it off.
00:44:03 <elliott> Vorpal: Apparently not! Going by EXTREMELY RELIABLE URL HAX.
00:44:19 <Vorpal> the on-site search seems broken
00:45:12 <elliott> http://deadendthrills.com/?s=skyrim ;; not too broken
00:49:30 <Vorpal> elliott, oh and a lot of the visual impressiveness in witcher 2 is dynamic effects
00:49:40 <Vorpal> the way plants move in the wind. The motion blur
00:49:46 <elliott> Not as good as ELLIOTTCRAFT.
00:49:59 <elliott> Elliottcraft has dynamic... POLYGONS...
00:50:18 <Vorpal> elliott, but really, what do you mean?
00:50:30 <elliott> Vorpal: Dynamic... DYNAMISM
00:50:34 <Vorpal> elliott, and is it available yet?
00:50:48 <Vorpal> elliott, I only consider released games you see
00:50:58 <evincar> Higher-Order Perl is an enjoyable read. I can't believe I hadn't gotten around to it.
00:51:17 <monqy> sounds like a cakeprophet thing
00:52:44 <elliott> monqy: no its mark j dominus hes a good person
00:53:05 <monqy> and kaceprophet isnt? :o
00:53:43 <monqy> maybe I willl read higher-order perl sometime when i am not killing myself over this awful python
00:54:23 <elliott> http://hop.perl.plover.com/book/pdf/HigherOrderPerl.pdf
00:54:51 <HackEgo> yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes \ yes
00:55:03 <HackEgo> no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no \ no
00:55:47 <evincar> Chapter 6 is interesting. Infinite Streams.
00:56:09 <evincar> I wonder why more garbage-collected languages don't use laziness. It's so convenient.
00:56:23 <evincar> No, it's just another name for infinite lists.
00:56:25 <monqy> makes side-effects even more confusing?
00:56:37 <PlacentaProphet> evincar: ...I, yes I know, but those don't exist in Perl normally
00:56:38 <evincar> Solution: avoid side-effects.
00:57:09 <monqy> but everyone is too awful to avoid side-effects
00:57:11 <evincar> No, regular old cons-lists with promises.
00:57:43 <evincar> E.g. node($head, promise { $rest })
00:59:38 <evincar> Could be prettier. So could the rest of Perl.
00:59:53 <PlacentaProphet> I believe you could use ties to make infinite lists look like normal Perl lists.
01:00:23 <evincar> Probably. I've never had need to mess with ties.
01:00:58 <PlacentaProphet> it essentially just lets you override things like variable assignment and indexing and stuff.
01:01:27 <PlacentaProphet> because Perl kind of sort of doesn't make sense like that.
01:04:28 <PlacentaProphet> http://search.cpan.org/~lbrocard/Language-Functional-0.05/Functional.pm
01:05:49 <PlacentaProphet> http://search.cpan.org/~asg/List-Gen-0.974/lib/List/Gen/Haskell.pm
01:05:50 <elliott> WELCOME BACK IOCCC <3 <3 <3
01:06:08 <elliott> http://www.ioccc.org/2011/rules.txt
01:06:41 <evincar> Crap, I was gonna announce that. :(
01:06:43 <oerjan> i guess it really _is_ the end times.
01:07:25 <elliott> how can you announce something that happened two days ago.
01:11:13 -!- Vorpal has quit (Quit: ZNC - http://znc.sourceforge.net).
01:12:02 <evincar> You seem to have done it just fine.
01:12:06 <evincar> Besides, I just found out about it today on HN.
01:17:46 <elliott> oerjan: hi can i prod you with haskell data structure questions
01:19:18 <elliott> hi variable did i say variable
01:23:15 <oerjan> *WAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAH* elliott says i suck *WAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAH*
01:23:26 <elliott> oerjan: hi you won't suck if you answer my questioneitonstonis :DDD
01:26:29 -!- Darth_Cliche has joined.
01:26:31 <oerjan> well clearly the answer is to use a phantom type as a monad^Wapplicative transformer indexed over a general topos prepromorphism.
01:27:24 <elliott> oerjan: I want a tree map (I'd go for HashMap usually) from a small (a pair of integers from 0 to 15 (inclusive), i.e. 256 values in total) key to values
01:27:35 <elliott> and im just wondering if... there'd be a good
01:27:38 <elliott> way to structure this apart from the obvious
01:29:18 <oerjan> or wait, you want efficient modification?
01:29:28 <elliott> oerjan: yes, it will be modified semi-frequently
01:29:33 <elliott> although not as much as it's looked up
01:29:52 <elliott> oerjan: I suppose a vector would still be a decent choice, but it's 256*4 = 1024 bytes
01:30:00 <elliott> and copying a kilobyte on every modification doesn't sound like fun
01:30:04 <elliott> even if they are relatively infrequent
01:32:27 <elliott> oerjan: the keyspace might actually be more like 16,384
01:33:02 <elliott> oerjan: what I could do is a boxed vector of 128 unboxed vectors of 128 Int32s
01:33:24 <elliott> oerjan: that's reallocating 512 bytes for each modification
01:33:33 <elliott> while having cheap lookup (three pointer dereferences)
01:34:05 -!- derdon has quit (Remote host closed the connection).
01:34:07 <oerjan> this sounds like it needs profiling to find out what actually _is_ the most efficient branching...
01:34:29 <elliott> oerjan: well it'd be 128x128
01:34:32 <elliott> i.e. two coordinates of 0 to 127
01:34:37 <elliott> so there's not really any other reasonable branching
01:34:42 <elliott> it'd be pointless arithmetic
01:34:46 -!- derdon has joined.
01:34:58 -!- derdon has quit (Remote host closed the connection).
01:35:37 <evincar> You sound like you want a deque.
01:35:45 <oerjan> oh well then you have your answer then.
01:36:33 <lambdabot> Overlapping instances for GHC.Show.Show ([a] -> [t])
01:37:30 <oerjan> > foldr1 const [1,2,3,4]
01:37:41 <elliott> Gregor: Just use my secret exploit to hack your server to death hahahahahaha
01:38:24 <elliott> you can get any list function with foldr
01:38:34 <lambdabot> forall a b. (a -> b -> b) -> b -> [a] -> b
01:38:45 <PlacentaProphet> not without doing some kind of mangling beforehand, right?
01:39:32 <oerjan> no, foldr can return any type
01:39:56 <copumpkin> doing an unsafe tail seems tricky though
01:40:03 <copumpkin> safeTail is fairly straightforward
01:41:36 <oerjan> you probably need some mangling afterwards
01:41:59 <PlacentaProphet> I don't know how to say "dear foldr: ignore the first element but everything else is cool, k"
01:42:53 <copumpkin> > foldr (\x -> maybe (Just []) (Just . (x:))) Nothing [1..5]
01:43:11 <PlacentaProphet> foldr (\x -> maybe (Just []) (Just . (x:))) Nothing [1..5]
01:43:30 <PlacentaProphet> > fromJust $ foldr (\x -> maybe (Just []) (Just . (x:))) Nothing []
01:43:31 <lambdabot> *Exception: Maybe.fromJust: Nothing
01:43:53 <copumpkin> I meant more in the sense of not having to post-process it
01:44:04 <oerjan> that was init, not tail
01:44:06 <shachaf> copumpkin: Isn't that ignoring the last element?
01:44:14 <monqy> safe tail? is that anything like drop 1?
01:44:22 <elliott> monqy: no its [a] -> Maybe a
01:44:23 <PlacentaProphet> contrary to popular belief, I do not actually read anything.
01:44:29 <shachaf> monqy: No, that loses information.
01:44:42 <monqy> elliott: that looks like safe head...
01:45:09 <oerjan> it's fairly obvious that you _cannot_ do tail as a straight foldr over the list with no post- or preprocessing.
01:45:31 <oerjan> because the tail of the tail does not contain enough information to reconstruct the tail itself
01:46:16 <PlacentaProphet> lists are like animals but instead of normal animal tails they have TAILS THAT ARE ANIMALS.
01:46:22 <shachaf> The point of tail is that you don't have enough information to reconstruct the thing you tailed.
01:47:04 <oerjan> shachaf: if tail l = foldr f x l for some f and x, then ys = tail (y:ys) = f y (tail ys)
01:47:25 <elliott> hmph, Vectors need better type names
01:47:37 <oerjan> which is absurd because the rightmost expression does not contain the information of ys's first element
01:47:50 <elliott> hmm maybe I can use Data.Vector.Generic
01:48:03 <elliott> hmph, no specialize pragmas
01:48:04 <oerjan> so you cannot write tail that way.
01:48:14 <PlacentaProphet> there should be some kind of list where tail does not remove any information. I'll call it: a zipper
01:51:28 <oerjan> > snd $ foldr (\x (xs, txs) -> (x:xs, xs)) ([], undefined) [1,2,3,4]
01:52:45 <PlacentaProphet> I would safely conclude that snd does not count as "postprocessing"
01:53:05 <oerjan> erm i count it as such :P
01:54:04 <oerjan> btw this is similar to the trick for implementing decrement in lambda calculus with church numerals
01:54:47 -!- pkzip has joined.
01:55:04 <elliott> Deewiant: Which would you say is more common: Program accessing locations near (0,0), or programs accessing locations near the IP
01:55:14 -!- pkzip has left.
01:56:19 <elliott> pkzip is going to keep joining here forever
01:56:23 <elliott> and never figure out how to stop it autojoining
01:58:58 <oerjan> > let church n f x = iterate f x !! n; inc n f x = n f (f x); dec n f x = snd $ n (\(x, dx) -> (inc x, x)) (church 0, undefined) in dec (church 4) (+1) 0 -- i wonder if this types in haskell...
01:58:59 <lambdabot> Overlapping instances for GHC.Show.Show ((t -> t) -> t -> t)
02:00:30 <oerjan> > let church n f x = iterate f x !! n; inc n f x = n f (f x); dec n f x = snd $ n (\(y, dy) -> (f y, y)) (x, undefined) in dec (church 4) (+1) 0 -- i wonder if this types in haskell...
02:02:31 -!- PlacentaProphet has quit (Ping timeout: 255 seconds).
02:04:57 <SgeoN1> It can't hurt to practice making variadic functions by hand, can it?
02:05:16 <elliott> fizzie: Stop me from making the same mistake mcmap did, please.
02:05:16 <oerjan> SgeoN1: you might get rsi
02:05:46 <elliott> SgeoN1: let me help you out: never write, never use variadic functions
02:06:02 <elliott> there is exactly one variadic function anyone uses and it's printf, and even then most people avoid it, this is because it freaking sucks because it's dynamically typed
02:06:32 <SgeoN1> The dynamic typing has nothing to do with it being variadic, I thought
02:06:48 <elliott> SgeoN1: So you want variadic functions that take only one argument type? That wouldn't be dynamic.
02:06:50 <elliott> Let me tell you how to do that.
02:07:20 <SgeoN1> elliott, is playing around a sin in your world?
02:07:49 <elliott> Usually you "practice" something in order to be better at doing it so that you can do it for real later.
02:08:08 <SgeoN1> Also, Oleg has examples of strongly typed useful variadic functions, but I doubt I'd be able to write such
02:08:15 <oerjan> the dynamicity is only needed because the format string is a value not giving its natural type, it has nothing to do with the variable number of the rest of the arguments
02:08:56 <elliott> oerjan: yes, but can you come up with a useful, non-dynamic, non-single-argument-type variadic function?
02:10:09 <SgeoN1> elliott needs to read more Oleg. Although I'm not sure if Oleg ever said anything about usefulness
02:10:18 <elliott> I have read plenty of Oleg.
02:12:20 -!- tiffany has joined.
02:14:31 <shachaf> Didn't Oleg write an operating system once?
02:14:51 <shachaf> @ is surely superior, though.
02:15:57 <elliott> There's a C++ kernel thing on his site? I think it's just a toy though.
02:16:03 <SgeoN1> I have one variadic function I want to write
02:16:21 -!- CakeProphet has joined.
02:16:21 -!- CakeProphet has quit (Changing host).
02:16:21 -!- CakeProphet has joined.
02:16:36 <shachaf> An implemented toy is clearly far worse than an unimplemented toy. :-)
02:16:37 <SgeoN1> Not sure if I can, or, if it's doable, whether someone else already has
02:16:51 <elliott> shachaf: @ ISN'T A TOY TAKE THAT BACK OR I'LL KILL YOUUUUUUUUUUU
02:17:04 <shachaf> SgeoN1: Look up "idiom brackets".
02:17:19 <shachaf> http://www.haskell.org/haskellwiki/Idiom_brackets
02:18:02 <CakeProphet> bah, can't use tabs in gnome-terminal with irssi
02:18:34 <shachaf> CakeProphet: Disable that.
02:19:05 <SgeoN1> That's subtly different from what I was hoping for, although I guess there may be a reason. I didn't really look that closely
02:19:12 <elliott> shachaf: How's that relevant?
02:19:15 <elliott> Or do you know what SgeoN1 is trying to do.
02:19:37 <shachaf> elliott: It accomplishes more or less the same goal as liftAn (it just needs a terminator).
02:19:47 <elliott> shachaf: How do you know he wanted liftA#?
02:20:01 <shachaf> How do I know anything at all?
02:20:09 * shachaf is omniscient, that's how.
02:20:18 <SgeoN1> elliott, what else could I have meant by writing liftAn and not explaining further?
02:20:22 <CakeProphet> elliott: you raise some interesting philosophical questions.
02:20:46 <shachaf> SgeoN1: It could be "lift, but only for indefinite nouns that start with a glottal stop".
02:21:48 <SgeoN1> Why do idiom brackets need a terminator?
02:22:21 <shachaf> To know when the thing has terminated.
02:22:54 <SgeoN1> I should probably read the thing
02:23:41 <lambdabot> forall a. (Integral a) => a -> a -> (a, a)
02:23:50 <elliott> SgeoN1: Because otherwise it's ambiguous.
02:23:55 <elliott> Also, it'd be really ugly without a terminator.
02:26:05 <SgeoN1> Because usage of a terminator is ugly to me
02:26:46 <elliott> (| getFoo + getBar |) is perfectly nice.
02:28:11 <CakeProphet> SgeoN1: http://www.amateurtopologist.com/blog/2010/01/12/variadic-functions-in-haskell/
02:28:17 <shachaf> elliott: Challenge: A version of iI Ii that works with infix operators.
02:28:29 <elliott> shachaf: No, iI Ii is hideous.
02:28:51 <shachaf> (+) (iI fx) (fy Ii) -- OK, maybe not.
02:29:00 <SgeoN1> Hmm, that page has a use case that goes beyond liftAn. I wonder if that restricted the solution spsce
02:29:20 <elliott> http://personal.cis.strath.ac.uk/~conor/pub/she/idiom.html (OK, she's additions to idiom brackets may not actually make SgeoN1 think they're less ugly.)
02:29:28 <elliott> s/she's additions/the additions she makes/
02:30:22 -!- evincar has quit (Quit: ChatZilla 0.9.87 [Firefox 8.0/20111104165243]).
02:30:53 <SgeoN1> I don't see how they work, I guess that's in the paper?
02:31:00 <SgeoN1> Nestibility is good though
02:31:43 * shachaf wonders whether iI is nestable.
02:32:30 <oerjan> "Worse, for reasons I have never entirely understood, the type-class hackery doesn't allow these brackets to nest as they should."
02:33:40 -!- Darth_Cliche has quit (Quit: You are now graced with my absence.).
02:34:12 <oerjan> SgeoN1: terminator is necessary because liftAn f x y z is a legal complete use whenever liftAn f x y z w is. (each additional argument is just applied with <*>.)
02:35:42 <oerjan> :t \f x y z w -> (liftA3 f x y z, liftA4 f x y z w)
02:36:02 <oerjan> :t \f x y z -> (liftA2 f x y, liftA3 f x y z)
02:36:03 <lambdabot> forall a b (f :: * -> *) c d. (Applicative f) => (a -> b -> c -> d) -> f a -> f b -> f c -> (f (c -> d), f d)
02:37:04 <elliott> <oerjan> "Worse, for reasons I have never entirely understood, the type-class hackery doesn't allow these brackets to nest as they should."
02:37:14 <elliott> SgeoN1: oerjan: um the ones she has nest just fine
02:37:27 <elliott> the stupid typeclass hack on http://www.haskell.org/haskellwiki/Idiom_brackets that McBride disowned don't nest because they're awful :P
02:37:51 <shachaf> Does that mean it's there for the taking?
02:37:52 <oerjan> elliott: well those were what shachaf asked about
02:37:57 <elliott> "For a while, I had a cheeky typeclass hack, but it seemed like overkill, especially as it didn't nest. She now supports a notation which does the job."
02:37:59 <elliott> sounds like disowning to me!
02:38:17 <shachaf> oerjan: Well, it makes sense that they're not nestable.
02:38:33 <shachaf> Unless you use parentheses, that is. I'd be very surprised if they didn't nest even then.
02:39:07 <elliott> oerjan: oh noooooooo my zipper doesn't work
02:39:46 <oerjan> shachaf: i'd assume he meant they don't nest with parentheses
02:39:57 -!- CakeProphet has quit (Remote host closed the connection).
02:40:41 <oerjan> shachaf: presumably trying to infer all the right types goes haywire somehow when there is more than one nesting level
02:40:59 <oerjan> inner ambiguity or something...
02:42:13 <oerjan> perhaps type families might help >:P
02:42:32 <shachaf> oerjan: There's a translation of those things to tpe families somewhere on hpaste.
02:42:41 -!- CakeProphet has joined.
02:42:41 -!- CakeProphet has quit (Changing host).
02:42:41 -!- CakeProphet has joined.
02:42:43 <shachaf> I'd be surprised if it solves any of the actual problems, though.
02:50:55 <SgeoN1> This paper can'tbe right?!?!??! Apllicatives came after arrows?
02:51:08 <elliott> PANIC!?!??!!? FUCKING APNCI!?!?!?!?!?!?!? IIST IMSPOSBIBLE
02:52:20 <oerjan> why is APNIC panicking, they already _did_ run out didn't they?
02:55:04 <oerjan> elliott: is there a link connected to this nonsense?
02:55:17 <lambdabot> forall a. (Typeable a) => Dynamic -> a -> a
02:55:20 <oerjan> or are you just making random words
02:55:24 <lambdabot> forall a. (Typeable a) => a -> Dynamic
02:55:47 <CakeProphet> > [toDyn 2, toDyn True, toDyn 'h', toDyn "hello"]
02:55:48 <lambdabot> [<<Integer>>,<<Bool>>,<<Char>>,<<[Char]>>]
02:55:54 <elliott> oerjan: <SgeoN1> This paper can'tbe right?!?!??! Apllicatives came after arrows?
02:56:10 <monqy> don't even talk about python
02:58:16 <oerjan> elliott: darn, i was hoping for some actual interesting ip news :P
02:58:30 <elliott> i miss him and his robotic nature
02:58:51 <elliott> SgeoN1: anyway mcbride invented idioms (applicatives) in... was it 2006?
02:59:07 -!- Jafet has joined.
02:59:20 <elliott> hmm, http://www.soi.city.ac.uk/~ross/papers/Applicative.html introducing applicative functors is 2008, but I think the "idiom" name goes back to 2006
03:00:07 <SgeoN1> Does Haskell have an Applicative definition for all nomads?
03:01:17 <shachaf> "Applicative" isn't part of Haskell.
03:01:21 -!- CakeProphet has quit (Ping timeout: 245 seconds).
03:01:59 <SgeoN1> elliott, that's great, but is it a default in Haskell, or is the situation like Functors?
03:02:07 <elliott> SgeoN1: Functor is a superclass of Applicative.
03:02:12 <elliott> From this you can derive an answer.
03:02:21 <elliott> shachaf: I don't think it's wrong to consider the base standard library part of Haskell.
03:05:30 <Jafet> I don't think it's wrong to consider Glasgow Haskell Haskell.
03:06:01 <elliott> Jafet: base theoretically supports non-ghc compilers :)
03:06:29 <Jafet> In theory, yes. But only the Glasgow Haskell Compiler compiles Glasgow Haskell.
03:15:55 -!- pkzip has joined.
03:17:10 -!- pkzip has quit (Client Quit).
03:17:14 -!- pkzip has joined.
03:19:50 <SgeoN1> I think I see how to implement Dynamics, but
03:19:54 -!- pkzip has left.
03:20:04 <SgeoN1> .. I think it requires OverlappingInstances?
03:21:23 <SgeoN1> Two instances, one to say that fromDynamic returns Just whatever, and a more general instance to say it returns Nothing.
03:21:39 <SgeoN1> I may be approaching it wrong
03:21:50 <elliott> data Dynamic = forall a. (Typeable a) => Dyn a
03:21:59 <elliott> fromDynamic (Dyn a) = cast a
03:22:31 <SgeoN1> That's great, I'm saying if I were to try to implement it mysrlf
03:23:27 <SgeoN1> Without magic Typable, but a typeclass of my own construction
03:24:02 <SgeoN1> Although I'd guess that Typable isn't magic
03:24:08 <shachaf> SgeoN1: Are you going to be using a class isomorphic to Typeable?
03:24:38 <shachaf> The only magic bit about Typeable is that GHC will autoderive instances for you.
03:24:57 <SgeoN1> I don't ... think so? What does Typable provide, because I think I'd need less.
03:25:22 <elliott> SgeoN1: With any typeclass that isn't autoderived, Dynamic gives you unsafeCoerce.
03:25:25 <SgeoN1> Well, myvway would be annoying to write out by hand, yes
03:25:30 <elliott> (This is why people want hand-written Typeable instances banned.)
03:25:56 * shachaf wears a hand-written Typeable instances band!
03:26:10 <SgeoN1> But does Typable rely on overlapping instances internlally?
03:26:10 -!- GreaseMonkey has quit (Quit: The Other Game).
03:26:39 -!- GreaseMonkey has joined.
03:27:00 <elliott> cast, however, relies on unsafeCoerce.
03:27:12 <elliott> And OverlappingInstances does not let you do what you want.
03:32:34 <shachaf> Oleg can decided UndecidableInstances.
03:32:53 <shachaf> They are clearly not native English speakers.
03:32:56 -!- Aune has quit (Quit: Lmnar).
03:33:34 <SgeoN1> Or is it just that it can't be decided whether typechecking terminates?
03:33:39 <Jafet> I can only type native English.
03:40:52 <oerjan> now IncoherentInstances, on the other hand, is so evil i'm not even sure what it does.
04:14:15 -!- zzo38 has joined.
04:17:18 <zzo38> My Haskell package (as well as other Haskell packages that were lack generated document at that time) still has no generated documentation.
04:18:05 <zzo38> Actually, I found that one of them has a build failure log. Mine, however, has no log.
04:21:51 -!- copumpkin has changed nick to FUDPAcker.
04:29:08 -!- MDude has changed nick to MSleep.
04:29:32 <elliott> does haddock even support literate haskell
04:30:05 -!- FUDPAcker has changed nick to copumpkin.
04:32:43 <zzo38> I think I read its document it says that it does.
04:51:20 <Deewiant> elliott: If "near" is something like "within 128x128" then I'd say "near the IP"; most programs are smaller than that and in Mycology I try to avoid (0,0).
04:51:42 <elliott> Deewiant: It is pretty much "within 128x128", yes
04:51:48 <elliott> fungot is more closer to (0,0), isn't it?
04:51:49 <fungot> elliott: oh, the swamp of terror, in search of the golden citadel... " no secondary sources of their wealth and power, but i refused. so did the east of paris. made of plaster
04:52:53 <Deewiant> elliott: And re. that list of graphics cards; the guy stopped updating it (along with the whole site) in April.
04:54:27 <elliott> Rest in peace guy -- too cool for this world.
05:05:03 <lambdabot> forall s a. (s -> (a, s)) -> State s a
05:09:50 <SgeoN1> Don't do that, it won't work and also has a 99,98% chance of destroying the earth by summoning time-traveling zygohistomorphisms.
05:10:34 <SgeoN1> Oh, what I pasted is a quote
05:14:30 * SgeoN1 reads about why reactive-banana has no swicher
05:15:13 -!- oerjan has quit (Quit: ZZZZZZZZZZZZZZZZ).
05:16:35 <lambdabot> forall s (m :: * -> *) a. (s -> m (a, s)) -> StateT s m a
05:16:44 <elliott> @hoogle State s a -> StateT s m a
05:24:35 <zzo38> StateT . fmap return . runState
06:08:34 -!- pkzip has joined.
06:08:49 -!- pkzip has left.
06:15:36 -!- zzo38 has quit (Quit: Djinn and Tonic).
06:22:01 -!- elliott has quit (Remote host closed the connection).
06:23:17 -!- elliott has joined.
06:24:57 <elliott> Deewiant: Sweet, Shiro 2 has run into a roadblock as soon as it began! It's like that time when CCBI 2 was dormant for months because of a compiler bug!
06:29:58 -!- nys has quit (Quit: quit).
06:30:42 -!- SgeoN1 has quit (Quit: Bye).
07:17:58 <elliott> monqy!!! What a good thing that you are here HELP ME
07:19:42 <elliott> monqy: I need a zipper of a structure with n cursors help.
07:20:16 <olsner> isn't that just the n'th derivative of the type?
07:21:15 <elliott> olsner: yes. however i need an /arbitrary/ n
07:21:21 <elliott> Zipper1, Zipper2, ... is like a tuple
07:21:35 <elliott> because the number of cursors I need varies at runtime
07:22:07 <olsner> maybe you can make a zipper-zipper to navigate to the right zipper, if you manage to make automatic zipper construction in the type system
07:22:29 <elliott> olsner: you're kidding, right? :P
07:23:18 <olsner> but an infinite type of all zippers might be doable?
07:23:41 <elliott> hmm oleg's (hideous) multi-cursor zipper is done as just two zippers kept in sync
07:23:49 <elliott> except it's an uh higher-order zipper that keeps track of the path
07:29:04 <monqy> i do not know how :(
07:30:41 <shachaf> Real programmers use mutability instead of zippers.
07:31:16 <olsner> real programmers don't abstract away their work, they do it
07:31:37 <shachaf> "abstract" as in "give to someone else"?
07:31:42 -!- SgeoN1 has joined.
07:32:47 <elliott> shachaf: Honestly, I'm tempted just to return to the old style, which was really slow but really simple.
07:32:53 <SgeoN1> http://www.altocumulus.org/Fudgets/demoform.html please tell me these kinds of shenanigans don't work these days
07:33:48 <elliott> X is still a network-transparent protocol, yes.
07:34:29 <SgeoN1> But arbitrary computers shouldn't be able to do stuff without your permission
07:34:31 <elliott> Holy shit, the Fudgets website got updated in 2011.
07:34:45 <elliott> SgeoN1: Where does that site do anything without your permission?
07:35:28 <SgeoN1> It looks like it attempts to. Or, well, technically with permission but if it worked, then it could work without permission
07:36:09 <SgeoN1> Although on my phone, I got an error telling me to try running some command, which doesn't look like it deserves to be sufficient for granting permission
07:36:46 <elliott> If you actually tried it, you'd see that you just have to grant permission to the server.
07:37:09 <elliott> Of course, the website could also just open a popup; I still get them occasionally, so it's not like there's no way to circumvent popup-blockers.
07:37:16 <elliott> Being able to open a window is not a very exciting privilege.
07:37:47 <elliott> "skalman" will be a host on some university network, I suspect.
07:38:06 <elliott> So it probably only works/worked in the 90s for people at Chalmers. :p
07:38:13 <SgeoN1> It only says skalman, how is that enough to grant permission?
07:38:29 <olsner> http://en.wikipedia.org/wiki/Skalman
07:39:13 <olsner> the easy way is to just give the whole internet access to your X server
07:40:47 -!- Jafet1 has joined.
07:43:22 -!- Jafet has quit (Ping timeout: 244 seconds).
07:45:09 <pikhq> elliott: Real programmers stare the compiler down until it submits.
07:45:20 <pikhq> That's what you should do to get ZipperN.
07:45:44 <monqy> "compiler whats that" - real programmer
07:49:06 <SgeoN1> Is compilation really a necessary aspect of Haskell?
07:49:19 <pikhq> SgeoN1: Not even slightly.
07:49:47 <pikhq> It's just that the preferred implementation of Haskell, GHC, is a compiler.
07:49:49 <SgeoN1> (That was meant to elicit calls of me being an idiot, but I'd think that typechecking and compilation are different things)
07:50:16 <pikhq> Hugs, for instance, was a Haskell interpreter.
07:50:17 <SgeoN1> ....oh, so I'm just being a captain ovvious
07:51:05 <pikhq> Captain Ovious: Lord of All Sheep
07:51:28 <SgeoN1> elliott, I don't have to serve as a Notifier, right? And why did spellcheck caps Notifier?
07:51:47 <SgeoN1> And by spellcehck I mean autocorrect
07:58:22 <olsner> I wonder if you could make a haskell dialect that doesn't typecheck until runtime, essentially making haskell one of those "dynamically typed" languages
08:00:39 <elliott> olsner: i doubt it, how would you do things like typeclasses, polymorphic recursion...
08:00:53 <elliott> you could do it in batch at start-up
08:00:58 <elliott> but that's basically compilation :P
08:01:19 <olsner> after enough furious handwaving, surely it'll be trivial?
08:02:44 -!- monqy has quit (Quit: hello).
08:05:12 -!- SgeoN2 has joined.
08:05:12 -!- SgeoN1 has quit (Read error: Connection reset by peer).
08:06:34 <fizzie> Being able to open a (X) window is quite an exciting privilege because then you can monitor all keypresses.
08:09:05 <elliott> fizzie: Does that apply even after it's closed?
08:09:53 <fizzie> Yes. Or, well, you don't need to be able to open a window either, you just need to be able to connect to a display.
08:10:59 <elliott> So fizzie, about them n-zippers...
08:12:28 <fizzie> There's an "X SECURITY" extension, though, which blocks at least the XQueryKeymap polling, but I think that doesn't apply if you "xhost +" someone. (It's relevant for ssh's X client forwarding; it makes remote clients untrusted by default, unless you ssh -Y instead of ssh -X.)
08:12:35 <fizzie> I don't know anything about them n-zippers, sadly.
08:20:32 <Jafet1> elliott: you don't need type checking for that, only type inference
08:20:45 <elliott> that falls down with extensions, though :)
08:20:48 <Jafet1> How to implement type inference without type checking is hereby left as an exercise
08:20:50 -!- Jafet1 has changed nick to Jafet.
08:21:55 -!- Jafet has quit (Quit: Leaving.).
08:21:55 * shachaf maintains that type inference = type checking.
08:22:17 -!- derrik has joined.
08:22:28 <shachaf> > comparе "inference" "checking"
08:23:56 -!- pikhq_ has joined.
08:24:21 -!- pikhq has quit (Ping timeout: 252 seconds).
08:26:24 -!- CakeProphet has joined.
08:28:11 <olsner> git config shachaf.mad true
08:28:39 <shachaf> git conf ig-shachaf.mad true
08:29:37 -!- LadyJ has joined.
08:30:01 <olsner> but `git status -umad` could work too, there is a `git status -unormal` anyway
08:59:19 -!- derrik has quit (Quit: cursed).
09:01:01 <HackEgo> Welcome to the international hub for esoteric programming language design and deployment! For more information, check out our wiki: http://esolangs.org/wiki/Main_Page
09:01:15 * shachaf never got a warm welcome like that.
09:03:45 <elliott> shachaf: That's because we don't like you.
09:05:12 <elliott> eek, I just had a scapegoat breakthrough
09:05:15 <elliott> I'm not meant to be the one who has those
09:06:17 -!- hagb4rd has joined.
09:06:25 <elliott> shachaf is trying to tell us that he is Raymond Smullyan.
09:06:37 -!- elliott has left ("Leaving").
09:06:39 -!- elliott has joined.
09:13:45 <elliott> CakeProphet: Accept my inviation.
09:14:11 <CakeProphet> one second while I figure out how to do that.
09:15:04 <CakeProphet> why did you invite me to a channel when I don't need to be invited.
09:15:55 -!- SgeoN2 has quit (Quit: Bye).
09:16:54 <CakeProphet> where each branch is a possible result of the merger.
09:17:18 <CakeProphet> then you no longer have to worry about merging
09:17:34 <CakeProphet> you just change hundreds of branches en masse
09:21:09 <CakeProphet> reverting creates a cycle in the graph back to the original node, and then branches at that node!!!
09:22:12 <CakeProphet> because each node is one of millions of permutations, you can do all sorts of fine-grained adjustments when you revert. Also, everytime you branch it creates branches of /what could be/
09:22:43 <elliott> shachaf: Can you kill CakeProphet for me?
09:22:56 <shachaf> My IRC client doesn't support it.
09:23:00 <shachaf> I think you need to be an oper.
09:23:27 <elliott> shachaf: Well, become an oper then.
09:23:32 <CakeProphet> so what happens when you revert into the future?
09:23:50 <shachaf> CakeProphet: What if, like, stuff, dude.
09:24:12 <CakeProphet> branches make version control systems complete.
09:26:06 <CakeProphet> deleting a file is just reverting to a branch in which it was never created.
09:26:39 <CakeProphet> also branches could branch! so you can branch while you branch.
09:27:45 <CakeProphet> only complete binary trees are allowed to represent the branches though.
09:28:08 <CakeProphet> so that the tree can be implemented efficiently as an array.
09:28:37 <elliott> CakeProphet: But what if you removed that restriction???
09:29:50 <CakeProphet> what if instead of changesets you use categories.
09:30:46 <CakeProphet> THEN EVERYTHING IS JUST INHERITANCE YEAAAAAH
09:31:32 <elliott> What if... you used objects instead of heritance?
09:33:31 <CakeProphet> branches are the result of a noble offering an upper class subject domain in his nobledom.
09:34:02 <CakeProphet> reverting is the resulting of weird time shit or maybe kingly decrees
09:34:08 <CakeProphet> and merging is uh, well okay this isn't working.
09:34:22 <CakeProphet> back to Java objects and complete binary tree hash tables.
09:35:22 <CakeProphet> > var $ cycle "where time becomes a loop "
09:35:23 <lambdabot> where time becomes a loop where time becomes a loop where time becomes a lo...
09:36:57 <CakeProphet> like "okay I need these functions from this file at revision 200 merged with these functions from revision 300 and properly merged so that the code compiles and runs as expected."
09:38:40 <CakeProphet> copenhagen scapegoat could just pull revisions from other universes where the code has been merged correctly.
09:39:29 -!- copumpkin has quit (Ping timeout: 260 seconds).
09:39:53 <CakeProphet> it would find this universe by consulting the universe in which scapegoat can actually catalogue and efficiently search all universes.
09:39:54 -!- copumpkin has joined.
09:40:19 <CakeProphet> which it would just have conveniently. maybe that universe finds our universe and decided to help you out!
09:43:34 -!- Madoka-Kaname has quit (Ping timeout: 260 seconds).
09:50:12 -!- Madoka-Kaname has joined.
09:50:12 -!- Madoka-Kaname has quit (Changing host).
09:50:12 -!- Madoka-Kaname has joined.
10:20:35 -!- elliott has set topic: ioccc more like http://codu.org/logs/_esoteric/.
10:20:41 -!- elliott has set topic: http://codu.org/logs/_esoteric/.
10:20:45 <elliott> too bad even for my high quality standards
10:36:48 -!- derdon has joined.
10:53:02 -!- GreaseMonkey has quit (Quit: The Other Game).
11:03:43 <elliott> @hoogle (MonadPlus m) => Bool -> m a -> m a
11:03:44 <lambdabot> Control.Monad mplus :: MonadPlus m => m a -> m a -> m a
11:03:44 <lambdabot> Control.Monad unless :: Monad m => Bool -> m () -> m ()
11:03:44 <lambdabot> Control.Monad when :: Monad m => Bool -> m () -> m ()
11:21:15 -!- ais523 has joined.
11:21:55 -!- ais523 has set topic: The IOCCC is back on! http://www.ioccc.org | http://codu.org/logs/_esoteric/.
11:22:10 <elliott> ais523: heh, I just set an ioccc topic earlier
11:22:28 <ais523> I'm just aiming for an informative one
11:22:37 <ais523> and I have an IOCCC entry ready, at least
11:22:41 <elliott> ais523: so, umm, I had a scapegoat breakthrough (!), and then implemented some scapegoat code
11:22:42 <ais523> I just need to check it for portability
11:22:52 <ais523> given that it violates the Standard in a huge number of ways
11:24:06 <elliott> ais523 is unfazed by your human scapegoats.
11:24:53 <HackEgo> 251) [on Walter Bright] <nddrylliog> I went to chat with him after his talk at the ELC and he was like "hum, right - humans. How do they work again... oh, hi!" \ 260) <locks> who's walter bright and why is he so bright <nddrylliog> locks: he's to D what I'm to ooc <nddrylliog> locks: guilty \ 702) <ais523> Just about all females often feel that exactly why all Hollywood stars common maintain its brightness as Tom in
11:25:15 <ais523> that first one is great
11:26:09 <lifthrasiir> so they have managed to release the winning entries after *five* years?
11:26:31 <elliott> ais523: anyway, the scapegoat breakthrough was what I believe to be the One True Conflict Resolution system (!), and the code is another implementation of the basic apply model, plus some ideas and scraps about how to abstract away the "pointer comparison" that you need to apply changes fast (rather than recursively comparing them to figure out whether the change referenced is the right one)
11:26:37 <elliott> (if you use changes instead of references to them)
11:27:00 <ais523> go tell me, I have about 2 and a half hours to listen before I go off to do marking
11:27:38 <elliott> ais523: well, you know how your existing solution have been changes that do a sort of spooky action-at-a-distance to other changes? you include a change "use hash foo instead of bar", and all the other changes you're applying end up with that rewrite, etc. etc. etc.?
11:27:53 <elliott> (you can correct me if I've got your model wrong or whatever, but it doesn't matter much)
11:28:01 -!- Patashu has quit (Ping timeout: 245 seconds).
11:28:58 <ais523> yes; I wasn't happy with that, but it seemed like the only way to do things
11:28:59 <ais523> have you found an alternative?
11:29:35 <elliott> ais523: yes, but I'd like to summarise the few things I didn't like about that first, so I can show how I was lead to this one
11:30:03 <elliott> one: if a changeset is applicable, all its subsets should be applicable, because adding /more/ changes to a change can't make it "less conflicty"
11:30:22 <elliott> two: it's not really clear /which/ changes, exactly, feel the effects of the hash rewrite; it seems more like a syntactic mechanism than a semantic change
11:30:53 <elliott> ais523: so, here's the solution
11:30:57 <ais523> hmm… I'm not sure that one: is correct, adding instructions on how to resolve conflicts should make a set less conflicty
11:31:03 <ais523> tell me your solution, anyway
11:31:15 <elliott> ais523: nah, not really, because "instructions" aren't really a thing
11:31:22 <elliott> ais523: you apply changes by tsorting them, and then applying them in that order
11:31:27 <elliott> if any fails, the whole thing fails
11:31:40 <elliott> I suspect it breaks a /lot/ of nice properties by not having adding more changes not reverse a conflict
11:32:08 <ais523> hmm, how do you handle the case of making change A, reverting change A, later making change B that would conflict with case A?
11:32:24 <elliott> ais523: let's say you have c1 = {insert "foo" between cX and cY}, and c2 = {insert "bar" between cX and cY}
11:32:41 <elliott> and you want to make a change that "does both", by putting c1's line above c2
11:32:42 <ais523> yep, a simple example of a conflict
11:32:58 <elliott> ais523: we introduce a new type of change: FILECHANGE modulo FILECHANGECHANGE
11:33:07 <elliott> we've already introduced the concept of change-changes, so this isn't too surprising
11:33:14 <elliott> its semantics are, it does whatever the resulting change is, pretty much
11:33:16 <elliott> ais523: and here's how you use it:
11:33:32 <elliott> c12 = changeset {c1, c2 modulo {replace before-hash with c1}}
11:33:48 <elliott> (if the changechange fails to apply to the change, the change itself fails, etc.)
11:34:03 <elliott> it preserves the reference to c2, it can do arbitrarily complex resolutions
11:35:13 <elliott> ais523: it also scales: e.g. if you need to back out a single element of a changeset to make a resolution work, then you can do that too, because changechanges mirror the structure of changse
11:35:28 <elliott> you can basically do an arbitrary transformation on it
11:35:57 <elliott> and, ofc, you can resolve conflicts with /other merges/: you could change the "source-change" of a modulo change
11:36:00 <elliott> as part of a modulo change
11:36:12 <ais523> hmm, I think I have a few issues of this
11:36:23 <ais523> first, assume I have c2 in my repo already
11:36:36 <ais523> and want to pull someone else's repo which contains c1 and c2 modulo {replace before-hash with c1}
11:36:43 -!- zzo38 has joined.
11:36:48 <ais523> (this is not a hypothetical question at all)
11:36:50 <elliott> ais523: umm, nothing special? it doesn't /mutate/ c2
11:36:54 <elliott> c3 = c2 moduloe {replace before-hash with c1}
11:37:03 <ais523> elliott: so right, I have c2, and pull c1 and c3
11:37:06 <ais523> presumably I get a conflict?
11:37:17 <ais523> but I shouldn't, in any sane conflict resolution system
11:37:35 <elliott> ais523: you do, because it's part of a /resolution/
11:37:37 <elliott> ais523: the whole point is, e.g.
11:37:46 <elliott> your head branch can't contain c2, because it conflicts with the latest revision
11:37:50 <elliott> so instead of appending c2
11:38:00 <elliott> you append changeset {insert ..., c2 modulo blah}
11:38:07 <ais523> elliott: so in other words, if you make change c1 and I make change c2, then when you pull from me you resolve the conflict, then when I pull from you I also have to resolve the conflict?
11:39:10 <elliott> ais523: there /is/ a real conflict, because your branches /don't match up/, because a modulo change introduces changes _necessary_ to get things not to conflict, ergo there can't be compatibility; /but/ the merge strategy is obvious and automatic
11:39:23 <elliott> which is to simply drop c2 in favour of the resolution
11:39:31 <ais523> ah, so the conflict's automatically resolved via noticing that there's an edited version of c2, and replacing c2 with it?
11:39:57 <elliott> that isn't part of the apply algorithm itself, but plenty of useful merge tactics aren't; that's why there are additional ones on top
11:40:56 <elliott> if you have any other issues with it I'm happy to hear them
11:42:31 <ais523> I think it's pretty much equivalent to the previous version; except that instead of "for c2 read c3", you're writing "c3" and letting the merge process automatically figure out it should get rid of c2
11:43:16 <elliott> it's similar, except for preserving that property of changesets, and having a clear scope
11:43:20 <elliott> ais523: for instance, you can do
11:43:37 <elliott> changeset {c2 modulo {replace before-hash with abc}, c3 modulo {replace before-hash with def}}
11:43:41 <elliott> ais523: even if c2 and c3 have the same before-hash
11:43:46 <elliott> which, afaik, isn't possible with your system
11:44:13 -!- Vorpal has joined.
11:44:37 <ais523> well, that changeset inherently contains a conflict
11:45:12 <ais523> is the rule for automerging with this "if you pull a patch A modulo B, eliminate patch A from your tip"?
11:45:24 <ais523> elliott: it's trying to add two changes immediately after the same before-hash
11:45:35 <elliott> ais523: basically, yes; also, no it's not
11:45:43 <ais523> it's moved them both to different locations in the original
11:46:09 <elliott> incidentally, you can even just do cN modulo {make it into a nop}, but that makes future merging suck
11:46:20 <ais523> elliott: so what if you make c1, and I make c2, and you pull from me and find that the two changes look identical and your version is better
11:46:24 <elliott> (because you can't replace cN with another change and get hopes of getting relevant results)
11:46:27 <ais523> what does the conflict-resolved version look like?
11:46:38 <elliott> (which is possible with a proper changechange: consider replacing cN (changeset) with a larger changeset)
11:46:55 <ais523> (as in, c1 and c2 do the same thing, and you prefer to have just c1 and to get rid of c2)
11:47:03 <elliott> ais523: oh, in that case you simply have to pick one, which forces you to replace-by-nop the other
11:47:21 <ais523> right, so you have c2 modulo {nop}
11:47:22 <elliott> ais523: but that can be done automatically, and any future changes depending on c2 can simply be modulo'd so that /their occurrence of c2 is replaced by c1/
11:47:28 <elliott> which is where this operation shines
11:47:34 <ais523> that's the same operation I added!
11:47:46 <ais523> so I think they're both shining equally ;)
11:47:50 <elliott> ais523: no, it's not: yours was restricted to one level of hash modifications, and yours /didn't have a scope/
11:48:07 <ais523> its scope was "all repos containing both this hash and the hash this hash modifies"
11:48:20 <elliott> wait, it /mutated global state/?
11:48:30 <elliott> that's even worse, there's no way to resolve two changes containing the same hash in different ways
11:48:35 <elliott> ais523: yes it does, it just records it as a transformation
11:48:46 <ais523> the hashes still mean the same things
11:48:52 <ais523> it just changes the rules for resolving them
11:49:01 <ais523> (I'm not trying to claim my way's better, btw; just trying to compare)
11:49:12 <elliott> anyway, mine has absolutely no disadvantages compared to yours, keeps desirable properties, is more general, and allows more complicated merges :P
11:49:23 <elliott> yeah, I'm not ~mechanism fighting~ or anything
11:49:33 <elliott> I just think this way is pretty obviously the Right Thing for conflict resolution
11:49:41 <elliott> because it /looks/ like the rest of the changes
11:49:45 <ais523> elliott: hmm… so how would the fact that "references to c2 should be replaced with references to c1" be expressed in your modulo notation?
11:49:47 <elliott> "replace <change> with <string>", etc.
11:50:08 <ais523> perhaps it should be explicit, rather than implicit
11:50:13 <elliott> ais523: c2 {replace occurs of c2 with c1}, most likely; that's a sane operation for changechanges to have
11:50:22 <elliott> ais523: c3 modulo {replace occurs of c2 with c1}, most likely; that's a sane operation for changechanges to have
11:50:34 <ais523> as in, instead of {c2 modulo replace before-hash}, have {c2 modulo replace before-hash, remove c2}
11:50:57 <elliott> wtf is that supposed to mean...
11:51:32 <elliott> ais523: remove is delete-line, right?
11:51:40 <ais523> elliott: well, you're pulling c2-modulo, and eliminating c2 in the process
11:51:57 <elliott> ais523: what the hell is delete-hash?
11:52:02 <ais523> the idea is that if you pull a changeset with c2 modulo replace before-hash
11:52:14 <ais523> then you want to eliminate c2 from the changeset you're adding c2-modulo to, right?
11:52:34 <elliott> if "remove c2" is meant to be a changechange
11:52:39 <elliott> why are you putting it in the same set as a change?
11:53:17 <ais523> elliott: well, you're putting c2-modulo in a changeset; and that /implicitly/ has a delete-hash c2
11:53:33 <elliott> ais523: what? no it doesn't
11:53:35 <ais523> I'm saying you should make it explicit, as you have a change and an implicit changechange in the same hash atm
11:53:40 <ais523> elliott: you said it did earlier
11:53:53 <elliott> ais523: that's in the /layer above/, not the apply algorithm itself
11:53:54 <elliott> ais523: in fact, it's perfectly possible for a change and a modulo of it to coexist
11:54:15 <elliott> changeset {c2, c2 modulo {replace before-hash with some-other-line, replace after-hash with some-other-line-right-after-it}}
11:54:32 <elliott> it's just that, whenever C conflicts with C modulo BLAH, the latter wins, in the helpful auto-merging strategies
11:55:11 <ais523> I'm saying that making it depend on the hash being modulo'ed seems wrong somehow
11:55:37 <ais523> what about having the changeset as {c1, c3=(c2 modulo replace before-hash), mergehint(replace c2 with c3)}
11:55:47 <elliott> it's a semantic indication that it's a resolution
11:55:59 <elliott> ais523: mergehint? are you /trying/ to make this as inelegant as possible?
11:56:32 <ais523> elliott: OK, what about this: you edit a file twice, inserting a line each time (adjacent to each other); call the changes that add those lines x1 and x2
11:56:44 -!- sebbu2 has joined.
11:56:44 <ais523> I edit a file once, adding a single line x3 that does the same thing that x1 and x2 do together
11:56:48 <elliott> x2 having x1 as its before-hash, yes?
11:56:54 <ais523> (replace "line" by another semantic unit if you want)
11:57:10 <ais523> now you pull from me, and decide that my x3 is more elegant than your x1+x2
11:57:23 <elliott> I'm glad you acknowledge my superior taste
11:57:36 <ais523> wait, I think I may have screwed up my example
11:58:01 <ais523> perhaps the problem I thought I saw isn't real after all
11:58:29 <ais523> and I'm trying to find an example that does illustrate it, now
11:58:57 -!- elliott has quit (Remote host closed the connection).
11:59:26 -!- elliott has joined.
12:00:05 -!- sebbu has quit (Ping timeout: 260 seconds).
12:01:09 <elliott> ais523: incidentally, there's another two sg-thoughts I had, but they're less important than this one and can wait
12:04:55 <ais523> let's see… if, say, Vorpal pulls a repo that contains c1 and c2-modulo, but doesn't have either c1 or c2 yet, presumably the correct thing to happen is for him to just add c1 and c2-modulo as written, and if he ever pulls c2 in the future, discard it?
12:05:57 <elliott> ais523: I can't answer that question, because you're using "pull" ambiguously... you mean "merge into main branch", right? obviously it's impossible to /fetch/ c2-modulo without fetching c2, since that would result in a corrupt database
12:06:18 <ais523> by "pull" I mean "include into the set of changes I'm considering my repo", or "whitelist"
12:06:29 <ais523> I'm assuming that all mentioned hashes are fetched
12:06:43 <elliott> ais523: anyway, /maybe/, you're oversimplifying the logic a bit
12:06:47 <elliott> this is the exact merge rule:
12:07:20 <elliott> if there is a conflict between C and C modulo CC, CC modulo CC wins
12:07:33 <elliott> note that, if you have C modulo CC somewhere in the ancient history of the repo
12:07:40 <elliott> and then C gets pulled in for whatever reason
12:07:46 <elliott> then that's fine, it just works
12:07:57 <elliott> or if it conflicts with XYZAHASUIDHSAD, made twenty thousand years after C modulo CC
12:07:59 <elliott> then that's a real conflict
12:08:11 <elliott> it's /only/ when the conflict is between C and C modulo CC that the latter wins by default
12:08:25 <ais523> hmm... so let's call c2-modulo c3, as usual
12:08:37 <ais523> in this case, we have c3 depending on c1, and c1 conflicting with c2
12:08:59 <ais523> that counts as a conflict between c2 and c3, right?
12:09:14 <elliott> I take it depends on it because c3 looks like c2 modulo {replace before-hash with c1}, yes?
12:10:20 <ais523> good; then I think this definitely gives the expected behaviour in the simple case
12:11:10 <ais523> I'm trying to think of a case where it's possible that c and c-modulo don't conflict, and the only one I can think of is when a block of code is moved from one part of the code to another
12:11:16 <ais523> and using modulo changes there is dubious in the first place
12:11:31 <elliott> ais523: heh, the more relevant and important of my other two sg thoughts is about move changes
12:11:35 <elliott> maybe i should bring it up now
12:12:44 <elliott> ais523: move changes of the form "move (a,b) to (c,d)" are broken. they introduce /silent/ dependencies, because they make changes able to be applied without those changes depending on the move changes. why is this important? remember: changesets are applied by tsorting on dependencies, and then applying in that order
12:13:11 <elliott> with move changes as they are currently, it's possible for tsorting to produce a working or non-working ordering, depending on how the sorting algorithm works
12:13:16 <ais523> yep, I realised there was something wrong with them
12:13:28 <elliott> and the tsort ordering can fail while another ordering can work
12:13:35 <ais523> although, I can't think of a specific example for what you're saying
12:13:54 <elliott> ais523: you make a move so that c9 is above c7
12:13:56 <ais523> why would it matter whether code was edited before or after moving it? or am I missing something?
12:13:59 <elliott> and you have another change that inserts between c9 and c7
12:14:19 <elliott> changeset {cM,cQ} applies in order cM->cQ
12:14:27 <elliott> but cQ doesn't depend on cM, so tsort doesn't see this
12:14:28 <ais523> elliott: oh, the "anotehr change" would have to be "insert between cM and c7"
12:14:33 <ais523> not "insert between c9 and c7"
12:14:36 <ais523> because it depends on being after the move
12:14:47 <elliott> ais523: so you make the last line of the merge get the hash cM?
12:14:51 <elliott> ais523: what do you do with the first hash?
12:15:24 <ais523> elliott: last and first; either you give them different hashes, or you say that the first line is cM referred to from above and its old hash from below, and the last line is cM referred to from below and its old hash from above
12:15:44 <elliott> ais523: you cannot have two lines with the same hash!!!
12:15:51 <elliott> what the heck does "replace cM with blah" do? "delete cM"?
12:16:01 <ais523> err, right, good point
12:16:24 <ais523> hmm, weren't replaces and deletes meant to have context? as in, "delete c8 between c7 and c9"?
12:16:32 <elliott> the problem with the former solution is, hashes refer to changes, that's sg's strength, and there aren't two changes to go around
12:16:34 <ais523> or is that not needed?
12:16:39 <elliott> ais523: nope, that's a flaw
12:16:45 -!- LadyJ has quit (Quit: Rooms • iPhone IRC Client • http://www.roomsapp.mobi).
12:16:54 <elliott> ais523: code should be resilient against being moved around, in general
12:17:37 <ais523> so we call the first and last lines cM1 and cM2 for the purpose of any change that cares about their new location, and use their old names for the purpose of changes that would work in either location (and obviously, also for changes that would only work in the old location)
12:17:52 <elliott> ais523: crazy idea that doesn't work: implement move (a,b) to (c,d) by doing: changeset {a modulo {change before-hash to c}, b modulo {change after-hash to d}}; these now conflict with the original additions, but conflict resolution sorts it out automatically
12:17:55 <elliott> /please/ prove to me that doesn't work
12:18:19 <elliott> inserts don't work like that
12:18:33 <ais523> right, I was hoping that wouldn't work too
12:18:39 <elliott> ais523: re your solution: that's obviously not the Right Thing
12:18:47 <ais523> it does seem wrong, indeed
12:18:57 <ais523> but I'd like to hear why not, to help me come up with a correction ;)
12:19:04 <elliott> not a single thing has been improved by breaking the line->change mapping so far
12:19:12 <elliott> ais523: well, it involves numbers, and special cases
12:19:32 <zzo38> Have you seen the television show called "Weird or What?"
12:20:29 <ais523> elliott: notionally, I want the move to add two hashes that refer to zero-length lines just before and after the block of code moved
12:20:30 <elliott> ais523: I'm inclined to think that move changes themselves should change
12:20:36 <zzo38> Once they had someone say something about ghosts, about infrared and stuff; this is a testable hypothesis so why don't they test it?
12:21:39 <elliott> ais523: hmm... if you had {atomic : set of change -> change}, you could do: atomic {move a to after c, move b to before d}
12:21:41 <ais523> there's no reason we can't actually simply add those, I guess, but it seems wrong in another way
12:21:47 <elliott> ais523: atomic because, neither change can apply without conflicting, but if you do "both at once" it works
12:21:55 <elliott> and you have two subchanges which become the new hashes of a and b
12:22:01 <elliott> but, umm, that's ridiculous
12:22:05 <elliott> and I have no idea how to implment atomic at all
12:22:24 <ais523> just mark them as "equal" in your topological sort; it's not too hard to implement
12:22:31 <ais523> (there are tsort algos that can handle things being equal)
12:22:43 <elliott> ais523: that won't work, you /can't apply two changes/ at once
12:22:43 <ais523> (I know, because I wrote one for my PhD research)
12:22:46 <elliott> applying a change is the atomic thing
12:22:59 <elliott> i'm not writing some hideous interleaving algorithm for the sake of basically just doing a move change with a hack to make it have two hashes
12:23:15 <ais523> elliott: well, the order of the two changes itself would have to be irrelevant, which it is; it'd just be atomic because it'd force them to happen consecutively
12:23:26 <elliott> ais523: oh no, neither would apply without conflict
12:23:29 <ais523> but this thing seems ridiculous in other ways
12:23:35 <elliott> because it makes no sense, it causes a rupture in space-time
12:23:51 <elliott> it starts at c, goes on for five lines; the next line is d, but b's end-hash is still after q
12:23:57 <ais523> right, but as long as you don't check for space-time ruptures until after the atomic finishes, it's fine
12:24:01 <elliott> let's just forget about this, it's making my head hurt
12:24:26 <elliott> ais523: here's my implementation of Move, for no particular reason:
12:24:28 <elliott> apply (Move (FileRange srcS srcE) (FileRange dstS dstE)) = \xss -> do
12:24:28 <elliott> (beforeSrcS, afterSrcS) <- withZipper f xss
12:24:28 <elliott> (src, afterSrcE) <- withZipper g afterSrcS
12:24:28 <elliott> let beforeSrcS' = reverse beforeSrcS
12:24:28 <elliott> (++ afterSrcE) <$> withZipper (h src) beforeSrcS' <|>
12:24:29 <elliott> (beforeSrcS' ++) <$> withZipper (h src) afterSrcE
12:24:31 <elliott> where f z@(_, ys) = z <$ guard (isStart srcS ys)
12:24:33 <elliott> g z@(xs, _) = z <$ guard (isEnd srcE xs)
12:24:37 <elliott> | isStart dstS xs && isEnd dstE ys = Just $ fromZipper (xs, src ++ ys)
12:25:47 -!- Aune has joined.
12:26:55 <elliott> ais523: it's actually quite elegant, shame move changes are broken
12:27:30 <ais523> elliott: my current thoughts are tending along the lines of "everything should have a before-hash and an after-hash that are different"
12:27:47 <ais523> I think that preserves all the properties we need, while also making creating new files and move changes working correctly
12:28:00 <ais523> elliott: you'd just stick a or b on the end of the hash, I guess
12:28:22 <ais523> hmm, perhaps that doesn't help after all
12:28:45 <elliott> and it adds a lot of weird insert cases, like inserting between the "after" of one line and the "after" of another
12:28:53 <elliott> maybe we should ask Gregor :P
12:29:03 <ais523> that'd be incorrect, inserts would have to be between an after and a before
12:29:07 <ais523> as a type system level requirement
12:29:08 <elliott> he will clearly come up with the perfect solution!
12:29:11 <ais523> they're badly typed if they aren't
12:29:23 <elliott> ais523: ok, but doesn't that defeat the point of move changes making before/after hashes?
12:30:04 <ais523> no; the idea is that a move change would simply provide its hash as the before hash of the first line, and the after hash of the last line
12:30:28 <ais523> then everything works correctly, additions/deletions/replacements, I think
12:30:39 <elliott> I'm still knee-jerk against this but maybe I will see the light :)
12:31:13 <ais523> a delete hash would be "delete one line from before-hash to after-hash"; that way, deleting after a move is made doesn't conflict with the move, deleting before does (and should)
12:31:40 <ais523> and if before-hash and after-hash aren't consecutive lines for whatever reason, it conflicts
12:31:47 <Vorpal> ais523, elliott: is this "move a file" or "move a segment of text" or something more generic than that?
12:31:57 <ais523> in fact, this lets you do things like replacing a space with a newline without causing conflicts on changes to the line before or after
12:31:59 <elliott> although it's used for renames, too
12:32:41 <Vorpal> elliott, because handling renames seems to me like an easier problem than moving text blocks inside a file or between files. Beside for the later case how would you even detect that was what happened?
12:32:51 <ais523> which is definitely a desirable property; it makes sg independent of what is and isn't a line
12:32:58 <Vorpal> unless you hook into the clipboard handling or something crazy
12:33:05 <ais523> Vorpal: the user would indicate it was a move
12:33:11 <elliott> Vorpal: I don't really feel like explaining scapegoat to you so that you have enough knowledge to understand this, but what is an easier problem or not is irrelevant
12:33:13 <ais523> perhaps in response to a question from sg itself asking
12:33:15 <elliott> ais523: nah, moves can be mostly auto-detected
12:33:36 <elliott> Vorpal: you can't detect filesystem renames either, anyway
12:33:39 <elliott> which is why you just guess instead
12:34:17 <ais523> elliott: actually, perhaps it's just simplest to give every line in the move a new hash; in that case, a move would always conflict with an edit to the code before it was moved, which is sometimes desirable and sometimes undesirable
12:34:30 <elliott> ais523: that's the same as not having move
12:34:33 <ais523> the reason I'm thinking along those lines is, what if code is /copied/ rather than moved
12:34:34 <elliott> and just deleting and reinserting every line
12:34:37 <ais523> elliott: well, right, it is
12:34:44 <Vorpal> <elliott> Vorpal: you can't detect filesystem renames either, anyway <-- well, several currently existing version control systems have move commands for that
12:34:47 <elliott> it also means you can't do things like, split a file into two
12:34:49 <ais523> if you copy code, you want to be able to edit one copy without changing the other
12:34:51 <Vorpal> some have copy to track a common source of a file
12:34:54 <elliott> and a missed rename completely breaks the world
12:34:59 <elliott> ais523: basically no, we need move changes :P
12:35:05 <ais523> hmm, OK, this is a good case for move changes existing
12:35:14 <ais523> it's also a good case for them not being introduced silently, though, I think
12:35:28 <ais523> perhaps we should just mention they were introduced and give the user a chance to change that
12:35:38 <elliott> move changes never really hurt anything
12:35:49 <ais523> elliott: because a move is not equivalent to a copy followed by a delete
12:36:00 <Vorpal> how do you track copying then?
12:36:07 <elliott> ais523: sure it is, if it's done in-between invocations of sg
12:36:22 <ais523> elliott: suppose you copy-and-paste some code, while someone else edits the original
12:36:24 <elliott> copying isn't worth tracking
12:36:27 <elliott> since you can't share hashes, full stop
12:36:36 <ais523> should the edit be applied to the old location, or the new location, or both, or something else?
12:36:44 <elliott> ais523: copy-and-paste, not cut-and-paste?
12:37:06 <elliott> the original, since it's just a copy; the solution to this being bad is to not copy-and-paste code
12:37:07 <ais523> I'm trying to work out desired behaviour so I can work out the correct semantics in sg
12:37:13 <elliott> sg can't make you abstract properly
12:37:37 <ais523> "the original" is what every VCS in existence does; the intended solution is probably "both" but I agree with you that doing that would be utterly insane
12:37:38 <elliott> if you, e.g. move all of a file but two functions into another file as part of a refactoring
12:37:42 <elliott> and someone else does bugfixes in the meantime
12:37:44 <ais523> and I think the /correct/ answer is "conflict"
12:37:49 <elliott> then it shouldn't spuriously conflict if it can detect a move
12:38:00 <ais523> because we can't know if the edit should happen in the new location, the old location, or both
12:38:03 <elliott> basically, if sg is confident enough that a move has taken place, it _really should_ automatically add a move change
12:38:39 <ais523> elliott: hmm, example: let's say we have a C function that uses only library functions from stdio.h
12:38:45 <elliott> ais523: conflict is ridiculous, you'd have to break sg's model to do that
12:38:46 <ais523> and it's in a file that includes both stdio.h and string.h
12:38:50 <elliott> as in, the fundamental model
12:38:54 <elliott> it's basically action at a distance
12:39:04 <elliott> inserting some text in another file caused conflicts in a different one
12:39:15 <Vorpal> elliott, how do you handle a cut-and-paste + change some lines of code. Like if I move something I might need to change a implicit reference to the current module to an explicit reference to another module
12:39:22 <ais523> now, let's say that someone moves that code to another file, which includes just stdio.h
12:39:37 <ais523> and independently, someone else edits the original to call functions in string.h
12:39:47 <elliott> Vorpal: please, I've already said you don't understand sg at all for me to be able to reasonably communicate with you about this
12:40:11 <elliott> ais523: it'll merge properly, and then fail to compile
12:40:12 <ais523> with your current sg move semantics, person 1's version compiles, person 2's version compiles, there are no conflicts if you merge them together, but the resulting code doesn't compile
12:40:19 <elliott> ais523: we've already established that sg /will/ break code
12:40:26 <elliott> and it's theoretically impossible for it not to
12:40:41 <ais523> I'd just like a little warning message letting people know that this is one of the less safe cases
12:40:51 <elliott> ais523: in this case, the compile error will lead to a simple solution, and the user can commit a perfect merge
12:40:55 <elliott> also, this /isn't/ less safe!
12:41:12 <ais523> actually, /can/ the user commit a perfect merge?
12:41:14 <elliott> I mean, it only seems less safe because you picked an example where it fails now
12:41:18 <elliott> as opposed to all the other ways merges can break
12:41:24 <ais523> the fix would be to add #include <string.h> to the second file, right?
12:41:28 <elliott> which you aren't considering
12:41:34 <ais523> but that doesn't have a dependency on the addition of the function
12:41:35 <Vorpal> couldn't the code end up compiling in some cases but in the wrong way
12:41:36 <elliott> it's enough that "sg diff" shows there's a move being made
12:42:11 <elliott> ais523: well, it'd be a merge without there being an actual conflict
12:42:14 <ais523> Vorpal: possibly, but I imagine such examples would be contrived, and equally likely to be caused by human error than by sg eagerness
12:42:29 <elliott> ais523: which is a perfectly plausible action
12:42:38 <Vorpal> ais523, if, in the example here, there is the same function name (but doing different things) from different sets of headers. I guess it could happen if the header files come from different libraries and are macros
12:42:40 <ais523> elliott: I guess in an ideal world, things like #include lines would be generated automatically
12:42:48 <Vorpal> err the functions in question are macros that is
12:43:05 <elliott> ais523: yep; you're free to help me figure out how to implement @ if you want @sg :)
12:43:24 <ais523> I think this is more an issue of getting the right internal representation of languages
12:43:47 <ais523> e.g. for OCaml, instead of writing "open List", followed by "sort" later on, it'd be stored internally as "{implicitly List}.sort"
12:44:03 <elliott> ais523: you should lower your expectations slightly :)
12:44:15 <ais523> hey, we can get sg working first, then do this sort of thing later
12:44:22 <ais523> actually, this sort of thing is independent of sg
12:44:29 <ais523> as it'd work with other VCSes too
12:44:33 <ais523> perhaps I should work on it
12:45:02 <ais523> a sort of "diffable transform" of code, that's designed to remove issues related to things like indentation and header files
12:45:38 <elliott> ais523: I think I can show your worries about unsafe moves contrived
12:45:52 <elliott> at the same time, someone writes some code in foo.c
12:46:01 <elliott> and it merges cleanly because what the hell is the point of a mv otherwise
12:46:10 <ais523> and the code depends on the file's filename being foo.c?
12:46:10 <elliott> the build system compiles bar.c differently to foo.c!!!
12:46:22 <elliott> that's not even /that/ contrived, you could add it in the same commit as the mv
12:46:28 <ais523> I think the argument here's about the principle of least surprise
12:46:33 <elliott> and file-specific CFLAGS are not that uncommon
12:46:47 <elliott> ais523: (note that git auto-detects renames)
12:46:50 <ais523> as in, what people will blame for a mistake when it happens
12:46:54 <elliott> (I just used hg to show because it has an explicit mv)
12:47:16 <elliott> ais523: it's unreasonable to expect things to always work perfectly after a merge
12:47:16 <ais523> hmm, should sg also have rewrite changes?
12:47:21 <elliott> that's why you do things like test the code
12:47:29 <elliott> nobody said sg solves collaboration :)
12:47:41 <elliott> ais523: I don't think so; a rewrite should conflict with any modification to the file, pretty much
12:47:48 <elliott> and if you rewrite, you'll change enough hashes that that happens automatically
12:47:53 <ais523> that's the conclusion that I was coming to
12:48:02 <elliott> I suppose someone could add an #include or something, but they'll change something lower down if they're doing that
12:48:17 <ais523> I think you could argue that a rewritten file shouldn't conflict with changes to its old version
12:48:18 <elliott> if an actual change gets through without conflicting, well, it wasn't a total rewrite then
12:48:23 <ais523> but I don't think that's a correct viewpoint
12:49:23 <Vorpal> <elliott> I suppose someone could add an #include or something, but they'll change something lower down if they're doing that <-- actually it happened that I only added an #include. Someone had forgot an #include in some project I was working on, and didn't have -Wall on (ugh), so it got the implicit declaration thingy of C. Which happened to work there.
12:50:19 <elliott> unused #includes don't typically break code, so even that getting through would be a really really minor failing of sg :P
12:52:19 -!- tiffany has quit (Ping timeout: 276 seconds).
12:52:33 <elliott> ais523: OK, here's an idea that just might be stupid enough to work:
12:54:43 <elliott> ais523: a new change type: "cut (a,b)". this removes all lines from a to b. another two change types, "paste start of cN after c", "paste end of cN before d". cN must be a cut change; their start and end lines are recreated after/before the given lines, with the paste changes becoming the new hashes. and finally, "fill in (c,d)"; this restores all lines "in the middle" between the two changes, which must be pastes of the same cut; their hashes are
12:55:32 <ais523> what if c and d aren't consecutive?
12:56:33 <elliott> ais523: ok, in response to this legitimate complaint, allow me to make it stupider
12:57:03 <elliott> ais523: there's no "paste end", just "paste start", and it takes d as well as c (so it's "between" instead); fill fills in the last line as well, and the fill change becomes the last line's new hash
12:57:42 <ais523> why are paste and fill separate changes? so they can have separate hashes?
12:58:15 <elliott> ais523: yep! that is the one and only reason.
12:58:24 <elliott> i think you will agree that it is, indeed, /impressively/ stupid.
12:58:45 <elliott> oh, you don't even need the cut part. but you do, because that makes it even stupider!
12:58:48 <ais523> I think it's simple enough to have more than one hash for one change if required; we're already doing that with "new file"
12:59:09 <elliott> ais523: those aren't hashes in my latest model
12:59:13 <elliott> they're special end points
12:59:18 <elliott> and can only appear at the correct side of ranges
12:59:22 <elliott> so, they're not changerefs at all
12:59:25 <ais523> the main problem with just changing the hash for the first and last line is that you then get a conflict if you insert between the first and second lines of what you moved, when there's no reason to do so
12:59:29 <elliott> (although SOF/EOF both /contain/ a dirchangeref)
12:59:47 <elliott> ais523: ooh, maybe it should be based on adding a new "subfile" somehow to reuse the SOF/EOF... i'll stop, this is too silly
13:00:15 <elliott> ais523: hmm, maybe we should make a concept of "textless lines"
13:00:21 <elliott> SOF/EOF would become one, and so would SOMove/EOMove
13:00:33 <ais523> yep, I mentioned that before, and it's increasingly seeming like a good idea
13:01:18 <elliott> ais523: although i don't really like that, because a lot of things are nonsense
13:01:19 <ais523> there is an issue here, actually, which I want to explain by example
13:01:22 <elliott> you can't delete SOMove, you can't move SOMove
13:01:30 <elliott> it only makes sense in ranges
13:02:12 <ais523> suppose that the code initially starts "a b c d e f g"; I edit it to "a b e f c d g", then again to "a b e f h c d g"; meanwhile, you edit it to "a b i c d e f g"
13:02:17 <ais523> what should be the correct result after merging?
13:02:37 <elliott> ais523: is each word a line?
13:03:11 <elliott> umm, let's try duplicating this so my brain gets it
13:03:16 <elliott> aaa bbb ccc ddd eee fff ggg
13:03:21 <elliott> aaa bbb eee fff ccc ddd ggg
13:03:27 <elliott> aaa bbb eee fff hhh ccc ddd ggg
13:03:34 <elliott> aaa bbb iii ccc dd eee ff gg
13:03:43 <elliott> ais523: is the second-last line being longer intentional?
13:03:55 <ais523> actually, the last is also longer
13:03:59 <ais523> you just typoed it shorter
13:04:06 <ais523> aaa bbb iii ccc ddd eee fff ggg
13:04:55 <elliott> i can't get my brain to parse these letters properly :P
13:05:34 <elliott> ais523: I suspect the answer is "conflict, but a practical system will duplicate c"
13:08:24 <ais523> actually, I think the correct answer is "conflict no matter what", as there are three plausible locations for i in the result
13:08:42 <elliott> ais523: no, I mean, it should conflict, but there's no reasonable way for the system to conflict
13:08:47 <elliott> i had a hard time parsing it
13:08:57 <ais523> [13:05] <elliott> ais523: I suspect the answer is "conflict, but a practical system will duplicate c"
13:08:59 <ais523> [13:05] <ais523> actually, I think the correct answer is "conflict no matter what", as there are three plausible locations for i in the result
13:09:23 <ais523> oh, did it reconnect all by itself?
13:09:28 <ais523> I had a network outage for a couple of minutes there
13:09:37 <elliott> <elliott> i can't get my brain to parse these letters properly :P
13:09:37 <elliott> <elliott> ais523: I suspect the answer is "conflict, but a practical system will duplicate c"
13:09:38 <elliott> <elliott> ais523: but i dunno
13:09:38 <elliott> <ais523> actually, I think the correct answer is "conflict no matter what", as there are three plausible locations for i in the result
13:09:39 <elliott> <elliott> ais523: no, I mean, it should conflict, but there's no reasonable way for the system to conflict
13:09:44 <elliott> <elliott> i had a hard time parsing it
13:09:59 <ais523> but misspelled /reconnect
13:09:59 <ais523> and it seems that the IRC system figured it out on its own
13:10:34 <ais523> hmm, I think a move change itself should be "move from a to b between c and d to between e and f"
13:10:49 <ais523> [CTCP] Received CTCP-PING reply from ais523: 10 seconds.
13:11:17 <ais523> If you want to adopt a kid outside the US, you will have to abide by international law.
13:12:22 <ais523> observed during spam cleanup
13:13:13 <elliott> we should give them a special place on the wiki to donate their works
13:14:12 <Vorpal> don't we have a captcha thingy?
13:14:43 <elliott> but it's a really bad captcha
13:15:08 <Vorpal> should have for account creation too
13:16:06 <ais523> the spambot we've been getting lately knows how to break it
13:16:19 <elliott> ais523: bots!!! they're people too!!
13:16:49 <Vorpal> ais523, need a more advanced captcha then
13:17:01 <ais523> yes, but it's hard to persaude Graue to change it round
13:17:18 <ais523> the obvious fix to the current spam surge is requiring someone's first edit to be made outside userspace
13:17:34 <ais523> which is a trivial requirement for a human to obey (they can just edit the sandbox or something)
13:18:02 <ais523> what I'd /really/ like is the AbuseFilter extension, so I don't have to bug Graue to change the settings each time there's a new spambot attack
13:18:13 <ais523> but I'm not sure it'd be compatible with the version of MediaWiki used on Esolang
13:18:25 <Vorpal> so time to update mediawiki then?
13:18:30 <elliott> We should really just require email confirmation of registrations. Nobody but zzo would mind. :p
13:18:48 <ais523> it wouldn't surprise me if the spambots could do that too
13:19:00 <elliott> zzo doesn't have an email address, and doesn't like having to use an email address to do things.
13:19:15 <ais523> elliott: just allow confirmation over gopher too
13:20:17 <elliott> Vorpal: why are you acting surprised?
13:20:47 <Vorpal> well, it is a major impairment. When you are looking for jobs people usually ask you to email your CV and so on.
13:20:54 <Vorpal> I forgot how old zzo was
13:21:00 <Vorpal> maybe that is no problem to him
13:22:08 <ais523> Vorpal: it's trivial to email someone your CV without an email address
13:22:15 <ais523> the issue is receiving, not sending
13:22:37 <Vorpal> ais523, well you usually get replies by email too
13:22:56 -!- Jafet has joined.
13:42:33 -!- elliott has set topic: The IOCCC is back on! http://www.ioccc.org | "Wittgenstein and Turing similarly agreed that it’s bad for a bridge to fall and kill people." | http://codu.org/logs/_esoteric/.
13:52:17 -!- ais523_ has joined.
13:58:23 <ais523_> heh, I'm reading through the solutions to "sort by first occurrence"
13:58:37 <ais523_> and the four Perl answers each used a different algo
13:59:48 <ais523_> I don't get why the first one works at all, actually (I can mentally work through what it does but it seems it'd produce the wrong answer, so I think I'm missing something)
13:59:52 <ais523_> oh no, I've just realised why it works
13:59:56 <ais523_> that's beautifully hideous
14:00:07 <ais523_> <tails> print$$_ for map$$_.=$_,<>
14:01:03 <ais523_> it's hard to fit how awful that algo is from a maintenance point of view in my mind, it's that bad
14:01:12 <ais523_> and yet, it's beautifully short
14:06:23 -!- MSleep has changed nick to MDude.
14:10:22 <Vorpal> <ais523_> it's hard to fit how awful that algo is from a maintenance point of view in my mind, it's that bad <-- what does it do?
14:10:36 <Vorpal> it is basically gibberish to me
14:25:50 <Deewiant> Vorpal: 'heh, I'm reading through the solutions to "sort by first occurrence"'
14:41:46 <Deewiant> Vorpal: 2011-11-14 15:58:18 ( ais523_) heh, I'm reading through the solutions to "sort by first occurrence"
14:42:03 <Vorpal> Deewiant, better question: how does it do it?
14:54:22 <fizzie> "map $$_ .= $_, <>" does for each line -- let's say containing "foo\n" -- the equivalent of 'append "foo\n" to variable called "foo\n"' and then returns the result. So if you have a file containing the lines "a", "b", "a", it will return "a\n", "b\n", "a\na\n" while setting the variable "a\n" to "a\na\n" and "b\n" to "b\n". Then it tries to print all variables "a\n", "b\n", "a\na\n" -- the first one will print two lines of a, the second one one line of b, and t
14:59:20 <fizzie> Cf. http://sprunge.us/deHR
15:09:31 -!- copumpkin has quit (Quit: Computer has gone to sleep.).
15:17:53 -!- Zuu has quit (Ping timeout: 240 seconds).
15:30:48 -!- ais523 has quit (Read error: Operation timed out).
15:34:19 -!- copumpkin has joined.
15:38:13 -!- ais523_ has quit (Quit: Page closed).
15:40:44 -!- ais523 has joined.
15:42:49 <ais523> Vorpal: Deewiant: the way the code works is to effectively use the entire space of possible variable names as a dictionary; each time it comes across a line of input, it concatenates that line to the variable with the same name, and records the resulting value; then afterwards, it interprets each of the resulting values as variable names in sequence, outputting what's there
15:43:22 <ais523> the only ones that will have nonempty values are the ones consisting of exactly one occurrence of the input lines, i.e. the first time they were encountered
15:45:48 <ais523> it's always nice when the winning entry in a golf competition is heavily obfuscated just because that's the shortest way to do it
15:50:13 <Gregor> <elliott> maybe we should ask Gregor :P
15:50:14 <lambdabot> Gregor: You have 1 new message. '/msg lambdabot @messages' to read it.
15:50:21 <Gregor> elliott: MAYBE YOU SHOULD M---actually I'll read this first.
15:50:52 <Gregor> OK, Cake babbles incoherently.
15:51:02 <Gregor> elliott: MAYBE YOU SHOULD MAKE TRANSACTIONAL HACKBOT WORK LOLOLOL
15:54:08 <Gregor> Subject of a spam email: "Playboy Playmate revealed!"
15:57:04 <ais523> quintopia: sort by first occurrence
16:00:10 -!- Phantom_Hoover has joined.
16:00:56 <ais523> http://golf.shinh.org/p.rb?sort+by+first+occurrence
16:01:11 <ais523> I submitted it; I came across it at work and thought it was a really interesting question
16:01:31 <ais523> and after seeing the answers, still maintain that it's a really interesting question
16:03:43 <quintopia> your expl makes somewhat more sense now :P
16:05:52 <ais523> quintopia: the best Perl solution
16:06:10 <ais523> cat /usr/share/dict/words | egrep '^[abcdefghijklm]+$' - | ./a.out
16:06:22 <ais523> if I add in n as well, it segfaults
16:06:59 <ais523> it's my IOCCC submission, that I've been working on for ages
16:08:32 <quintopia> something funky in the words list?
16:08:32 <ais523> heh, running under valgrind, it spews errors but doesn't segfault even with n added
16:08:53 <ais523> no, the program's just that insane
16:09:07 <ais523> it contains no statements, and calls no memory allocation functions, and uses no VLAs
16:09:19 <ais523> ERROR SUMMARY: 15475827 errors from 15 contexts (suppressed: 12 from 7)
16:09:37 <ais523> calculates the winner of a Single Transferable Vote election to elect one candidate
16:11:13 <ais523> aha, I think it's segfaulting due to exhausting memory
16:12:17 <ais523> hmm, I need to remember how this program actually works before the submission date
16:15:03 <Phantom_Hoover> <ais523> it's my IOCCC submission, that I've been working on for ages
16:15:03 <lambdabot> Phantom_Hoover: You have 2 new messages. '/msg lambdabot @messages' to read them.
16:15:28 <ais523> Phantom_Hoover: see topic
16:23:44 <ais523> I start two variables uninitialized; if I initialize them to 0, it makes the program segfault
16:24:36 <ais523> they're uninitialized deliberately because they're being used as part of a stack-smash
16:30:05 -!- Ngevd has joined.
16:31:28 <ais523> I'm going to see if I can tweak this to fit the whole of /usr/share/dict/words into the 1.5GB stack space I extended the stack to
16:32:19 <Ngevd> I've been thinking about a functional Piet-like language
16:33:39 <ais523> I've got words containing a-s to run
16:33:44 <ais523> although adding t, there will be a lot more
16:33:46 <ais523> I'm trying that run now
16:35:33 <ais523> Vorpal: do you know where to download the Intel C compiler (for Linux) from?
16:37:38 -!- Phantom__Hoover has joined.
16:37:41 <ais523> hmm, compiling it with clang it gets into an infinite loop growing the stack until it segfaults due to inability to expand the stack
16:38:26 <Deewiant> ais523: http://registrationcenter-download.intel.com/irc_nas/1959/l_ccompxe_ia32_2011.0.084.tgz
16:38:48 <Deewiant> Based on the arch linux user package
16:38:49 <Ngevd> If you use the websafe palate rather than the Piet palate, that gives you 215 possible commands
16:39:09 -!- Phantom_Hoover has quit (Ping timeout: 240 seconds).
16:39:15 <ais523> Deewiant: and a non-direct link?
16:39:24 <Deewiant> ais523: Somewhere there http://software.intel.com/en-us/articles/intel-compilers/
16:43:57 -!- ais523 has quit (Ping timeout: 240 seconds).
17:05:07 -!- monqy has joined.
17:19:18 <Gregor> Speaking of IOCCC ....
17:19:29 <Ngevd> Sopio is a fun game
17:19:31 <Gregor> I seem to have a tweetable interpreter for a near-TC programming language ...
17:19:53 <Ngevd> C isn't turing-complete
17:20:17 <Gregor> Phantom__Hoover: See: Ngevd
17:20:40 <Gregor> The language is conceptually TC, but since the interpreter is its definition, it's not.
17:21:48 <Gregor> char*a,b[9999];main(){gets(a=b);while(*a)a+=(a[*a]-=a[a[1]])?3:a[2];puts(b);}
17:22:01 <Gregor> Calling it non-compliant makes no sense, the language is defined by the interpreter.
17:22:17 <Gregor> That's the wrong one ...
17:22:24 <Gregor> Good lord you're stupid
17:22:28 <Ngevd> It's over-specified
17:22:41 <Gregor> b[9<<20],*a=b;main(){while(scanf("%d",a++)>0);for(a=b;*a;)a+=(a[*a]-=a[a[1]])?3:a[2];while(*++a)putchar(*a);}
17:22:48 <Ngevd> Spec for the language?
17:22:50 <Phantom__Hoover> It's either not TC, or the interpreter doesn't interpret the language. I fail to see what I'm missing.
17:22:56 <Gregor> The only thing that makes it non-TC is "9<<20"
17:23:22 <Gregor> Phantom__Hoover: You're missing applying any reasonable, intelligent thought to the problem instead of going "lol not TC therefore sux"
17:24:10 <Gregor> <Phantom__Hoover> "Near"-TC? <Phantom__Hoover> That's what's also known as non-TC. <-- this implies it quite loudly, what with the "haha I refuse to acknowledge the notion of being near-TC"
17:24:46 <Gregor> Because it includes things such as COMPUTERS.
17:25:01 <Ngevd> C has more states than anyone can see in a hundred life-times
17:25:32 <Ngevd> Well, it's a linear-bounded automaton
17:26:04 <Gregor> FSM is not a very useful way of saying that either.
17:26:13 <Gregor> Since it includes everything from "A->halt" to computers.
17:26:17 <Ngevd> You can make an unbounded amount of arrays, you just need to define them all
17:26:24 <Ngevd> I've never actually used C
17:27:07 <Phantom__Hoover> Not to mention that you'd still have bounded memory if you just defined loads of arrays.
17:27:32 <Phantom__Hoover> But ultimately, C's TCness is essentially a matter of trawling through minutiae in the spec.
17:34:12 <Gregor> !c printf("%d", -1 || 42);
17:34:24 <Gregor> I thought || passed through the actual true value.
17:36:59 -!- augur has quit (Remote host closed the connection).
17:40:55 -!- Ngevd has quit (Ping timeout: 276 seconds).
17:46:59 -!- Ngevd has joined.
17:48:11 <Ngevd> Today's Gunnerkrigg Court is pretty funny
17:48:13 <Gregor> Well, either way, my tiny interpreter is about 25% of the way to a IOCCC competitor.
17:48:53 <Ngevd> Is the spec for the interpreted language anywhere?
17:49:11 <Phantom__Hoover> I think today may have had the most dismal afternoon I've experienced.
17:53:21 <Ngevd> That's because you're in Edinburgh, and the UK has predominantly Easterly winds, and Glasgow is West of Edinburgh and I get the feeling that East and West etc. shouldn't be capitalized.
17:53:30 <monqy> that sounds amazing; the sun bothered rising here and it's king of lame
17:53:43 <monqy> kind of lame, I mean
17:53:50 <monqy> it is probably not king of lame
17:53:51 <Gregor> Here it's an amazing combination of overcast and humid. There's no sun and yet I'm sweaty and it's miserable.
17:54:02 <Ngevd> It's actually pretty nice here
17:58:33 <monqy> unless by pretty nice you meant warm and blue skies; I hate that
17:58:54 <monqy> sounds pretty nice
17:59:16 <monqy> I have to turn on the fan to get the cold but once I do it's fine
18:00:34 -!- Ngevd has quit (Quit: FOOD).
18:12:30 <Phantom__Hoover> <monqy> that sounds amazing; the sun bothered rising here and it's king of lame
18:13:26 <Phantom__Hoover> It's just that by 3 o'clock or so, heavy cloud cover and school lighting conspired to make the single most depressing light level physically possible.
18:13:53 <Phantom__Hoover> Night would have been *welcome*; instead, there was just this pervasive greyness everywhere.
18:14:08 -!- augur has joined.
18:14:52 <Phantom__Hoover> I think we've had about two days like that, which is a pity because they're my second favourite.
18:15:45 <CakeProphet> Americans did not lose their British accents. Rather, the British gained their accents in the last few hundred years, thanks in part to public (private) schools teaching children "received pronunciation."
18:16:00 <CakeProphet> Jerks, horribly disfiguring a nation's speech for no reason.
18:16:20 <Phantom__Hoover> *English, I think you'll find, although I have an RP accent for reasons unclear to basically everyone.
18:16:41 <Gregor> It's especially odd since he's Flemish.
18:16:45 -!- Nisstyre has quit (Ping timeout: 240 seconds).
18:18:36 -!- Nisstyre has joined.
18:19:21 <CakeProphet> though I have an almost non-existent accent despite being a southern American.
18:20:24 <Gregor> "Non-existent accent" is an artificial concept.
18:20:52 <Gregor> One propagated primarily by people with one of the most fringe accents in existence ...
18:21:21 <CakeProphet> I didn't mean /literally/ that I have no accent, for fucks sake
18:22:06 <CakeProphet> The phonetician Jack Windsor Lewis frequently criticises the name "Received Pronunciation" on his blog: he has called it "invidious",[20] a "ridiculously archaic, parochial and question-begging term"[21] and argued that American scholars find the term "quite curious".[22] He used the term "General British" [to parallel "General American"] in his 1970s publications of A Concise Pronouncing Dictionary of American and Briti
18:22:35 <Gregor> I'm from the west coast, and yet my accent is practically identical to those from Indiana! AMAZING
18:22:55 <CakeProphet> Gregor: yes clearly we both have fucking super powers.
18:23:48 <Gregor> CakeProphet: Also I went to a foreign country once and I could understand them, just like they were speaking the same language. It's like I have a natural born ability to speak and understand Canadian without even knowing it.
18:24:19 <CakeProphet> see when I hear English people talk it just sounds like a bunch of jerks.
18:24:32 <CakeProphet> can't understand anything, I'm too distracted by the douchebaggery.
18:24:54 <Gregor> CHIM-CHIMINEE-CHIM-CHIMINEE-THIS-IS-'OW-OLL-BRITONS-TOKK
18:26:17 <Gregor> Really, nobody's going to smack me for that?
18:27:37 * CakeProphet would like to visit Scotland and Ireland, but thinks England is for JERKS.
18:27:57 <CakeProphet> I have no opinion of things on ISLANDS, sheesh
18:28:17 <Gregor> .................................
18:29:51 <Gregor> I would make some snarky comment about foreigners' understanding of the location of US states, but I'm not sure if any failure could top the Isle of Wales.
18:31:24 <Phantom__Hoover> Gregor, um, most of the people I know could roughly place most states, and definitely state which one is composed of islands.
18:31:40 <Gregor> Phantom__Hoover: Hence why it couldn't top the Isle of Wales.
18:32:09 <CakeProphet> but seriously Wales seems like a cool place to visit.
18:32:10 <Phantom__Hoover> It still doesn't beat Sgeo's astonishing failure to know where Scotland is.
18:33:04 <CakeProphet> apparently when I type things they magically become Serious today.
18:35:23 <Phantom__Hoover> @tell elliott Seen on confirmation form for computerons: "Product Desc. e-Scan Anti-Virus ES-AV-1". ???
18:37:15 <CakeProphet> http://en.wikipedia.org/wiki/File:BenNevis2005.jpg
18:38:11 <Gregor> Yup, that one's on the Island of Blackpool.
18:38:42 <CakeProphet> http://en.wikipedia.org/wiki/File:Denali_Mt_McKinley.jpg
18:39:18 <Gregor> http://en.wikipedia.org/wiki/File:Everest_kalapatthar_crop.jpg
18:40:21 <CakeProphet> Gregor: this is US vs. UK don't bring Nepal into this shit.
18:40:55 <Gregor> http://en.wikipedia.org/wiki/File:Olympus_Mons_alt.jpg
18:41:49 <CakeProphet> http://en.wikipedia.org/wiki/File:Census-2000-Data-Top-US-Ancestries-by-County-1396x955.png
18:42:00 <CakeProphet> in my county they don't even try to classify my ancestery
18:42:57 <fizzie> Our highest point is 1324 metres; apparently we lose even to UK, if only by 20 metres.
18:43:24 -!- ais523 has joined.
18:43:41 <Gregor> lol @ Puerto Rico: Puerto Rican
18:44:09 <CakeProphet> fizzie: yeaaaaah sucka. whatchu gonna do about all these landmass we got up in this shit?
18:44:13 <Gregor> Also: Germans are EEEEEEVERYWHERE
18:46:28 <CakeProphet> Phantom__Hoover: maybe you should have conquered bigger islands, asshole.
18:46:45 <ais523> yay, my IOCCC entry now works in clang
18:46:54 <ais523> I wonder if I can get it to work with optimization turned on?
18:47:09 <Gregor> Also, Britain has the longest coastline in the world; it's actually many times the circumference of the Earth.
18:47:50 <Gregor> ais523: What's yours do?
18:47:56 <Phantom__Hoover> Gregor, given that coastlines are actually-fractal (as opposed to popscience-fractal) that's not terribly meaningful.
18:48:02 <Gregor> ais523: I'm thinking about converting my tiny interpreter into something, but need more amusement in it.
18:48:08 <Gregor> Phantom__Hoover: BA-DUM MOTHERFUCKING TISH
18:49:00 <ais523> Gregor: it counts votes for the single transferable vote
18:49:09 <ais523> hopefully, I won't have to get it working in each compiler in existence separately
18:50:28 <Gregor> ais523: My usual tact is to get it working on platforms that are completely distinct in three axes: Compiler, OS and architecture. I find that doing my native dev on x86_64+gcc+GNU/Linux then porting to i86+openwatcom+DOS and ARM+gcc+GNU/Linux satisfies these needs and usually makes portable code. Not sure it's a good strategy for IOCCC though.
18:52:02 <ais523> Gregor: well, I'm trying to do something massively nonportable and make it portable anyway
18:52:18 <ais523> breaking the C standard in preference to not breaking it
18:52:59 <ais523> while trying to avoid compiler warnings even on the highest warning settings
18:53:31 <ais523> gcc still gives three warnings, but I can't tell why
18:56:30 <ais523> Deewiant: wow, Intel want people to fill in a bunch of information to get the noncommercial version of icc
18:56:53 <ais523> but then how would I know what the license was?
18:57:01 <Deewiant> I presume it's included inside the tarball
18:57:49 <Gregor> ais523: Come ooooooooooon, you know you want to try openwatcom.
18:57:55 <Gregor> It's just like being in the 1990's again~
18:57:55 * ais523 wonders why Intel renamed "Intel C++ Compiler" to "Intel C++ Composer"
18:58:21 <Gregor> DJGPP is just GCC over a shitty OS.
18:58:22 <ais523> and even Borland C++ 4 for Windows 3.1, although not on this computer
18:58:42 -!- pkzip has joined.
18:58:46 <Gregor> OpenWatcom has the advantage that you can run it on modern Linux, but target ancient DOS.
18:59:06 <ais523> how does this tarball come to half a gigabyte?
19:00:25 -!- pkzip has quit (Remote host closed the connection).
19:01:48 <Phantom__Hoover> Argh, I still need to visit Maplins for cables and stuff and I've left it too late today.
19:02:06 <Phantom__Hoover> I guess I can wait till the parts arrive and then actually know what cables I need?
19:04:21 <ais523> no, that's the tarball itself
19:04:28 <ais523> I haven't downloaded it full yet, so haven't tried to decompress it
19:05:21 <Deewiant> ais523: Oh, also, note that that was the i386 version, there's a separate one for x86-64
19:05:33 <Gregor> ais523: Give us a nice `du -bx * | sort -n | curl -F 'sprunge=<-' http://sprunge.us` when it's extracted kthx?
19:05:42 <ais523> Deewiant: i386 is correct, luckily
19:06:08 <ais523> Gregor: what about tar tf?
19:06:15 <ais523> that'd save actually having to extract it
19:06:27 <Gregor> ais523: Does that show directory summaries? I figured you were going to extract it anyway ...
19:06:44 <ais523> I don't want to have to extract the whole thing, if I can help it
19:09:02 * Gregor stares at his nearly-empty 3TB hard disk.
19:09:09 <Gregor> Truly a thing of beauty.
19:10:04 <CakeProphet> quick! backups! then porn! then random torrents!
19:10:19 <ais523> then intel c++ composers!
19:10:25 <ais523> seriously, "composer"?
19:11:06 <fizzie> ais523: TI's C compiler for for their DSP chips is called "Code Composer Studio".
19:11:23 <ais523> this is as bad as the series/season thing on TV
19:11:42 <ais523> also, my system has caught serial process crashing issues again
19:11:54 <fizzie> On the third hand, Metrowerks CodeWarrior.
19:12:02 <ais523> where Firefox froze, then my terminal froze
19:12:36 <ais523> oh, and now they're all back to normal
19:12:41 <fizzie> I don't think I have ever used any of the CodeWarrior tools, but I'm pretty sure they have a "Battle" menu in the IDE where others have a "Build" menu. (Okay, not really.)
19:14:21 <fizzie> There's also Sun Studio (now Oracle Solaris Studio; formerly this and that); the "Studio" term seems popular too.
19:14:58 <ais523> Gregor: the file was so big I failed to download it
19:15:13 <ais523> Firefox eventually decided it had finished around halfway through
19:15:19 <ais523> and the resulting file didn't decompress
19:22:17 <Gregor> Hmmm, maybe I can make a simple JIT for IOCCC. I assume that's been done?
19:23:40 <Deewiant> 1996 august Subset of C compiler and byte code interpreter
19:23:56 <Gregor> Doesn't sound like a JIT to me.
19:24:31 <ais523> what would it JIT? Java bytecode?
19:24:43 <ais523> >jqvzuxbfiwpkoahmclnyrgdtes
19:24:43 <Gregor> To be determined. Definitely not Java :P
19:24:50 <ais523> ==17720== ERROR SUMMARY: 1099046944 errors from 15 contexts (suppressed: 12 from 7)
19:25:17 <ais523> of course, I should have expected s to win
19:25:29 <Deewiant> Okay, it's just an interpreter; so no JIT, apparently
19:25:44 <Gregor> Deewiant: Hence "Doesn't sound like a JIT to me."
19:25:57 <Deewiant> Gregor: It could've been a JIT based on that description
19:26:05 <Deewiant> I checked the full .hint file: it's not
19:26:17 <Gregor> Deewiant: And yet, it "[didn't] sound like a JIT to me." X-P
19:26:33 <Deewiant> Gregor: Sheesh, I just confirmed it :-P
19:27:29 <Gregor> Anyway, I suspect I could make a (very!) simple JIT.
19:27:36 <Deewiant> (And "so no JIT, apparently" referred to all submissions thus far, in case that wasn't clear.)
19:28:28 <ais523> Gregor: well, it has to be obfuscated, as well as being golfed
19:31:02 <Gregor> "and excluding any ; { or } immediately followed by whitespace or end of file" does this mean that I save myself a byte by adding a space after every ;???
19:31:44 <ais523> that trick's been known for years
19:31:53 <ais523> as has writing lookup tables as "{ ; } ; ; { { }" etc
19:31:59 -!- Zuu has joined.
19:32:27 <ais523> use both spaces and tabs for added effect
19:32:29 <Gregor> (You can tell I haven't investigated IOCCC too much :P )
19:32:37 <ais523> (I don't think C lets you put vertical whitespace inside strings)
19:37:32 <Gregor> Any opinions on the best counter for these rules?
19:37:38 <Gregor> There must be an IOCCC one :)
19:37:54 -!- CakeProphet has quit (Ping timeout: 240 seconds).
19:40:25 <ais523> there's a counter linked from their website, or always used to be
19:46:45 <ais523> >jqvzuxbfiwpkoahmclnyrgdtes
19:46:52 <ais523> ==27192== ERROR SUMMARY: 1099046944 errors from 15 contexts (suppressed: 12 from 7)
19:46:52 -!- myndzi has quit (Ping timeout: 258 seconds).
19:47:22 <ais523> it's fun to see the single-transferable-vote ordering of letters in words (where words are considered more inclined to vote for letters towards the end)
19:49:57 <coppro> what's with the valgrind?
19:51:24 <ais523> I wanted to see what its reaction would be
19:51:31 <ais523> also, I get a segfault without it, with large input
19:51:46 -!- Patashu has joined.
19:51:56 <ais523> I think it's to do with extending the stack
19:52:06 <ais523> $ cat /usr/share/dict/words | egrep '^[abcdefghijklmnopqrstuvwxyz]+$' - | valgrind --error-limit=no --main-stacksize=1500000000 ./a.out
19:52:27 <ais523> the default main-stacksize is too low
20:04:08 -!- Ngevd has joined.
20:14:19 -!- Ngevd has quit (Ping timeout: 276 seconds).
20:16:53 <Gregor> Urrrrgh, I know I can make a portable golf JIT >_<
20:19:35 <Gregor> The real tricky part is jumping ...
20:25:07 -!- tiffany has joined.
20:26:49 -!- oerjan has joined.
20:28:00 <oerjan> <elliott> @hoogle State s a -> StateT s m a
20:28:26 <oerjan> once the state function is made into a method as planned, state . runState should work
20:28:42 <oerjan> runState doesn't actually exist
20:28:48 <lambdabot> forall s a. State s a -> s -> (a, s)
20:29:02 <oerjan> erm, it does. it's just not a field anymore, i guess.
20:29:26 <oerjan> ...elliott idle for six hours?
20:29:39 <oerjan> something must be wrong
20:31:45 <oerjan> <elliott> "skalman" will be a host on some university network, I suspect.
20:32:05 <oerjan> swedish comic/cartoon character.
20:34:31 -!- Ngevd has joined.
20:34:42 -!- GreaseMonkey has joined.
20:36:58 <zzo38> I made a code that does that, yesterday, to make State s a -> StateT s m a but find what helped better for you in case
20:37:25 <ais523> help my mouse pointer's gone crazy
20:37:29 <ais523> (this touchscreen doesn't like getting wet)
20:38:27 <ais523> so it's busy teleporting the mouse pointer around a bunch
20:38:58 <Ngevd> Will Wheaton plays Minecraft!?
20:41:03 <oerjan> Ngevd: knowing that he is a redditor, i'd say that was inevitable.
20:41:34 <Ngevd> How long till Sheldon off the Big Bang Theory is playing it?
20:44:09 <Ngevd> I have a tendency to double consonants at the end of three-letter shortened forms of people's names
20:45:27 <Gregor> Think -1 will semi-portably be acceptable for all protection modes for mmap?
20:46:51 <tswett> Django's database half looks pretty nice. It's, like, you can treat tables as objects! And you can interact with them!
20:47:01 <tswett> (Database interaction is exactly half of Django, right?)
20:47:58 -!- Vorpal has quit (Ping timeout: 252 seconds).
20:56:14 <oerjan> it's what Dja is abbreviating
20:57:53 <tswett> Hey, this is funny. The server Django running on is called Remy. It turns out those are both characters from Ratatouille.
20:58:15 <Gregor> I am now 88% confident that I can make a semi-portable JIT for a language that's fundamentally usable within all the requirements.
20:58:24 <oerjan> tswett: Database JnterAction, duh
20:58:37 <tswett> And as everyone knows, J is just another way of writing I.
20:58:46 <tswett> That's why they're next to each other in the alphabet.
21:03:19 <Gregor> Hmm, is there a valid CPP equivalent of #define O O--
21:03:27 <Gregor> That is, decrement the value of a #define? I don't think so...
21:04:08 <Gregor> I'll have to find another convoluted way to do this then :P
21:04:37 <tswett> Is there a way to make the CPP only process lines that start with ##?
21:04:59 <tswett> Because maybe you can use two CPP passes, so that the first pass determines what happens in the second pass.
21:05:12 <Gregor> Naw, that ain't my style even if it did work.
21:05:30 <tswett> Why are you in #esoteric if that's not your style?
21:05:40 <tswett> Come to think of it, have you ever even created an esolang?
21:05:55 <tswett> ...give me a minute, let me try to think up a good, accusatory word for someone who doesn't belong...
21:10:38 <olsner> ooh, quark and martok appear as humans in this back-in-time parallel-fantasy-universe episode
21:11:41 * olsner 's riveting retelling of DS9 in one-line episode summaries continues
21:11:51 * tswett ponders how easy it would be to share a semaphore over TCP.
21:12:12 <Phantom__Hoover> olsner, BtW, no satisfactory answer is ever given as to WTF was going on in that episode; HTH.
21:12:46 <Gregor> What's going on is a rather severe blow to the head :P
21:12:53 <olsner> Phantom__Hoover: it must be a ... temporary anomaly
21:13:40 <Gregor> I'm trying to figure out a way of, for all values from (say) 0 to 1024, defining a function oX(...) { f[X](); } for that X.
21:13:46 <Gregor> They have to be separate functions for JIT reasons.
21:14:28 <Phantom__Hoover> olsner, also dude, you missed the shockingest of all: Odo without makeup.
21:14:58 <Gregor> What about Worf without forehead and voice modification? I think it's the only in-universe time he appears human.
21:15:18 <olsner> Phantom__Hoover: nah... quark, martok and gul dukat were much more shockingest so far
21:15:31 <olsner> odo was just a bit more boring :)
21:17:20 <olsner> yes, in the first scene in the office martok was showing sketches (of DS9, among other things)
21:19:41 <Gregor> lifthrasiir: Well, f[X] is accessing an array, so yes.
21:20:46 <olsner> Phantom__Hoover: Weyoun? you mean Commander Shran :)
21:20:55 <lifthrasiir> how about this?: #define O(x) o##x(...) { f[*#x-'a'](); } \n O(a)O(b)O(c)O(d)
21:21:24 <olsner> what, he's Brunt *too*?
21:22:04 <Gregor> lifthrasiir: O(a)O(b) blows out all my bytes (i.e. is too big), I was trying to find a way to do crazy CPP loops for it ...
21:22:32 <lifthrasiir> Gregor: no, you need just five levels of such macros.
21:22:38 <Gregor> Ohhhhhhhhhhhhhhhhhhhhhhh
21:23:09 -!- Taneb has joined.
21:23:10 <Gregor> ... hmmm, it could work ...
21:23:27 <lifthrasiir> Gregor: should the pointers to o... things be stored in some array?
21:23:27 <Gregor> I'd just need to name them aaaaa aaaab aaaba aaabb etc
21:23:31 <elliott> Gregor: What are you doing, just use chaospp
21:23:31 <lambdabot> elliott: You have 1 new message. '/msg lambdabot @messages' to read it.
21:23:41 <olsner> oh, he's played *nine* different characters, that's about 7 more than I've noticed yet
21:23:46 <Gregor> lifthrasiir: Naw, you've given me another idea.
21:26:56 -!- Ngevd has quit (Ping timeout: 258 seconds).
21:31:55 -!- Taneb has quit (Ping timeout: 258 seconds).
21:34:25 <elliott> Gregor: More like OGC!!!!!!
21:34:31 -!- Ngevd has joined.
21:34:32 <zzo38> Is this how the function to load DVI file should be? withDVI :: FilePath -> s -> (s -> Page -> IO (s, t)) -> IO [t]; You can make different idea if you have other idea please. Maybe this is not best way; I don't know for sure
21:37:16 <elliott> ais523: did you have any more sg thoughts?
21:37:17 <oerjan> zzo38: perhaps -> IO (Maybe (s, t)) so you have a way to halt?
21:38:36 <zzo38> oerjan: O, yes, OK; it can have a way to halt.
21:38:45 <elliott> ais523: I think my other sgthought still makes sense, although it depends on sg itself making sense, so hopefully merge changes can be fixed :P
21:38:58 <zzo38> withDVI :: FilePath -> s -> (s -> Page -> IO (Maybe (s, t))) -> IO [t];
21:39:10 <ais523> I'm currently happy with your current plan, because it seems, at worse, equivalent to the old plan
21:39:22 <elliott> ais523: hmm, I have a move plan?
21:39:28 <elliott> or do you mean the conflict resolution plan
21:40:05 <ais523> I'm pretty sure that a move patch should be "move a..b from between c,d to between e,f"; the problem is I'm not sure what it should leave as the hashes afterwards
21:40:29 <ais523> come to think of it, does it work just to leave the hashes of every line the same?
21:40:43 <ais523> the really simple stupid solution
21:40:54 <oerjan> zzo38: hm oh or is it implicitly halting when it's running out of Pages, i didn't realize that at first. in which case doesn't this look like a kind of iteratee?
21:40:55 <ais523> I can't think of an obvious counterexample; quick, find one to prove I'm not mad
21:41:21 <elliott> ais523: umm, that's the one I showed broken
21:41:28 <elliott> ais523: it breaks tsorting, remmber?
21:42:01 <elliott> ais523: yes; changeset {move (a,b) between (c,d), insert "hi" between (c,a)}
21:42:09 <elliott> ais523: second change needs to be applied after the first but has no dependency on it
21:42:30 <ais523> elliott: oh, the dependency isn't explained in the hash names, I see
21:42:42 <elliott> ais523: yep, which is one of sg's major strengths
21:42:48 <ais523> the dependency's still there in "that's the only thing that could put c next to a", but the problem is that that isn't explicit at all
21:42:49 <elliott> the order to apply a changeset in is trivially determined
21:42:54 <ais523> which I agree is a valid problem
21:43:35 <elliott> ais523: we could /probably/ hack it up by just shifting the ordering around a bunch when move changes are involved, but I refuse to implement that
21:43:45 <olsner> ooh, are you working on spacegoat again?
21:43:46 <ais523> yes, we want a nonhackish version
21:43:56 <ais523> olsner: deliberate typo?
21:43:58 <elliott> the only mars-capable version controls ystem
21:44:02 <HackEgo> 655) <fizzie> Spacegoat is the network-operations-optimized-for-latency-of-minutes-or-hours-due-to-light-speed-limits variant of scapegoat, to be used when you need to check out some code from the Mars colony. <fizzie> (I'm pretty sure we'll have established a Mars colony by the time scapegoat rolls out.)
21:44:17 <olsner> ais523: yes, better name :)
21:44:45 <zzo38> Finally, the Haddock documentation for Data.Monoid.Plus now works.
21:45:16 <elliott> zzo38: iirc hackage building broke for a while recently
21:45:58 <zzo38> elliott: O, well it seem to work now. That might be why mine and other not mine packages were not working before
21:46:10 <elliott> ais523: I can tell you about the last sgthought if you're interested, although it's not so much part of sg itself as much as taking advantage of its strengths
21:48:12 <elliott> ais523: basically, it's an idea for a patch management system based on top of sg to solve a lot of workflow problems I have with existing VCSes, with some ideas taken from the quilt patch management system originally by Andrew Morton for Linux stuff
21:48:21 <elliott> (I suppose git was basically Linus' own version of that to start with, actually)
21:48:39 <ais523> quilt's confusing; it somehow manages to not be a VCS despite acting like one
21:48:45 <ais523> what VCS features is it missing?
21:48:57 <elliott> I'm not sure exactly, I've never /used/ it, only read about it >:)
21:49:07 <elliott> I know hg has its own version of quilt integrated as an extension
21:49:11 <pikhq_> I wouldn't say git is particularly friendly for the patch-based workflow, though. Simply because it doesn't have the idea of a "patch".
21:49:48 <elliott> ais523: anyway, here's the basic idea:
21:49:50 <Ngevd> I need to avoid TVTropes
21:50:31 <Phantom__Hoover> Ngevd, just use my method, i.e. the fact that it's crap these days.
21:50:54 <ais523> after a few minutes I tend to open less than one page on average from each TV Troeps page nowadays
21:51:00 <ais523> so the problem resolves itself
21:51:20 -!- variable has quit (Quit: I found a 1 /dev/zero).
21:52:08 <zzo38> How do you make Haddock include instances defined in this program of classes defined in the other library?
21:56:18 <Ngevd> That is a very good plan
21:56:36 <Ngevd> Now I just need to abandon here, IWC, and MSPA
21:56:57 <monqy> except when it isn't
21:57:02 <Ngevd> And all the free time will be mine!
21:57:22 <elliott> Phantom__Hoover: It didn't stop.
21:57:42 <Phantom__Hoover> It stopped updating, and it's not like the new annotations are big time-sinks.
21:58:00 <Ngevd> Yeah, but I'm a regular on the forums
22:00:42 <elliott> ais523: It manages a set of patches (named with short-names, like-this) without them being committed (my current implementation idea has it nesting another scapegoat repository inside +scapegoat that it managse automatically; from the point of view of the repo itself, you're just fiddling around with your working tree). You create these patches mainly by doing the equivalent of "darcs record": you select a bunch of hunks, give them a short-name, a
22:00:43 <elliott> nd the sg change is added to the set under that name (without doing anything to your working tree). The power comes from "joins": (or should it be "joint", or ...) they're named like some-patch/another-patch, or patch-one/patch-two/patch-three (the ordering is irrelevant), including the slashes. What they do is provide /compatibility/: say you have a patch that rewrites the source code to use a new naming scheme for types (rename-types), and anoth
22:00:43 <elliott> er code that adds some features (including new types; new-feature). You would create a patch rename-types/new-feature, which would be a combination of both, renaming the types in the new feature appropriately, and replacing references to the old types. But instead of storing the whole diff from current head to rename-types/new-feature, it would just store the diff from /both rename-types and new-future/. basically, it'd look like: changeset {renam
22:00:48 <elliott> e-types, new-feature modulo {...}, ...}. but the power here is that the reference to rename-types and new-feature isn't to a specific hash, it's to their /names/, so whenever you update their patches, rename-types/new-feature gets the changes. (of course, you still have to keep it updated :)) now, the interesting thing is that you can "shadow" patches from your working tree: you can say, I don't want rename-types any more. rename-types/new-feature
22:00:53 <elliott> will automatically get shadowed too, obviously, and you could work some more on other patches (including new-feature), re-enamble rename-types, and it'd automatically enable rename-types/new-feature. (it'll probably fail to apply after changes
22:00:57 <elliott> to new-feature, but that's okay, because you can amend rename-types/new-feature to fix it.) there might be another patch, new-callbacks, that changes the callback mechanism used in the program. you might have new-callbacks/new-feature to make new-callbacks shorter using code from new-feature, and to make other parts of new-feature use the new callback mechanism. if you have rename-types, new-feature, and new-callbacks enabled, then rename-types/ne
22:01:02 <elliott> w-feature _and_ new-callbacks/new-feature will be enabled. it's possible that these will conflict due to changing the same part of code, which means you make -- you guessed it -- rename-types/new-callbacks/new-feature. you can also commit a set of patches as a repository commit; it'll remember which named patches made up that commit. so this basically eliminates the problem of doing a bunch of work at the same time, and having to untangle it slowl
22:01:07 <elliott> y every time you want to tell the VCS about some of it.
22:02:21 <elliott> ais523: and, of course, when you pull from elsewhere, you can merge it with each patch separately, rather than having to do a merge with your complete working tree and then splitting it back up into the parts that are relevant for each patch.
22:02:34 <Ngevd> Who wants to do an esolang collaboration taking the form of a Piet-like language utilizing the entire web-safe colour range?
22:02:36 <ais523> is this a bit like having separate branches, but much more lightweight?
22:02:50 <elliott> ais523: yep, because the merging is a first-class object
22:02:53 -!- variable has joined.
22:02:53 -!- variable has quit (Changing host).
22:02:53 -!- variable has joined.
22:02:58 <olsner> (DS9) aah, there it comes: It's REEEEEEAL
22:03:07 <Ngevd> I'm more of a Voyager fan
22:03:12 <olsner> just waiting for that episode where it's FAAAAKE
22:03:13 <elliott> ais523: and you don't have to decide wh-
22:03:18 <Ngevd> In that I've watched a bit of an episode once
22:03:23 <elliott> ais523: -ich branches you want up-front, before making changes
22:03:35 <Ngevd> elliott, what am I being dotted at for?
22:03:52 <elliott> Ngevd: Voyager is an impressively bad piece of television.
22:04:28 <Ngevd> Hey, I enjoyed the Thor film.
22:04:28 <elliott> ais523: and you can treat e.g. a branch as a named patch, so that you can have compatibility patches with another branch; you could then commit some changes to the main branch, and merge it in to a branch you have compatibility patches for automatically
22:04:49 <ais523> naming patches is going to be useful anyway
22:05:00 <elliott> ais523: oh, this isn't a regular naming mechanism
22:05:10 <elliott> this has to be separate from the sg repo, because it's insanely mutable
22:05:14 <elliott> which is the opposite of what history is meant to be
22:05:25 <ais523> no, tags would be naming changesets; or even (immutable)repos, I guess
22:05:27 <elliott> in fact, it's based upon the idea of mutating one thing causing everything else to mutate :)
22:05:33 <elliott> ais523: changesets are just types of changse
22:05:38 <elliott> which are the same thing as patches
22:05:58 <ais523> but what I mean is, that they go all the way back to infinity, rather than being relative to something else
22:05:58 <Phantom__Hoover> Ngevd, watch DS9, I watched it and it was the best waste of...
22:06:26 <elliott> ais523: but yeah, you've seen me fumble about by doing crazy git workflows like "stash, pull pieces out, modify, commit, restash"
22:06:41 <ais523> you pretty much have to do that in git
22:06:45 <elliott> ais523: that isn't specifically a git problem, no VCS is good at separating independent strands of work right now, you have to declare them up-front
22:07:09 <ais523> as usual, darcs is better than its rivals without being perfect
22:07:16 <elliott> the idea with this is that you can start with a bunch of modifications, split them out in a really light-weight manner, and then have a coherent /interface/ to managing them
22:07:30 <elliott> it also makes working trees less fragile, because they'll be recorded in the patchset data
22:07:45 <elliott> so you don't have to worry about copying your working tree elsewhere before doing a merge or whatever (!)
22:07:51 <elliott> (yes, I have to do that in git occasionally)
22:08:01 <elliott> (stashes sort of help, but they're just a thin veneer around cp :))
22:08:36 <olsner> hmm, TV characters musing about their whole existance just being imagination
22:09:35 <olsner> ... if only they knew, they *are* just some script writer's imagination
22:09:53 -!- Taneb has joined.
22:10:08 <ais523> elliott: we're working on a project in svn at the moment at work; I'm using git-svn, but some of the other people are sorting out conflicts by backing up their own copy, choosing resolve-other, then merging them together separately
22:11:18 <olsner> that's a viable merge strategy in CVS too
22:11:27 <ais523> the worrying part is, /it is actually sane in context/
22:11:41 <olsner> or just an update-from-server strategy if your local changes are nontrivial
22:12:03 <elliott> ais523: hmm, maybe sg should have foo/bar branches itself
22:12:22 <elliott> ais523: branches that automatically pull from foo and bar, so you can resolve conflicts in them and the like
22:12:31 <ais523> elliott: I'd treat that as a repo definition
22:12:34 <elliott> it seems like a useful concept even outside of this patch management thing
22:12:35 <ais523> in terms of other repos
22:12:46 <olsner> complex merges in CVS can be done by a CVS transplant: produce the correct source tree in a copy, move all the files except the CVS metadata into a target working copy checked out on the right branch, commit :)
22:12:47 <ais523> I agree it's a useful concept, but I think it can be done with existing concepts
22:12:58 <elliott> ais523: yes, but (a) you need to insert your own fix changes, (b) a platonic sg tool would be slow and unusably general :P
22:13:06 <elliott> I'm not saying we don't have concepts for it
22:13:09 <olsner> ... sometimes that's the *convenient* way of doing it
22:13:10 <elliott> I just mean, maybe we should expose them
22:13:30 -!- Ngevd has quit (Ping timeout: 240 seconds).
22:14:31 -!- Taneb has quit (Ping timeout: 256 seconds).
22:17:07 <Gregor> lifthrasiir: Your craaaazy solution definitely will work >: )
22:17:17 <Gregor> pikhq_: I'm making a semi-portable JIT for the world's worst language :)
22:17:36 <lifthrasiir> well i'm also thinking of possible IOCCC submissions that are doomed to be rejected...
22:18:40 <Gregor> lifthrasiir: I'm just hoping that I can squeak by within their portability requirements >_>
22:19:02 <lifthrasiir> woah, what does limit the portability of your submission?
22:19:14 <pikhq_> Gregor: They seem to just barely permit things that are nonportable *by necessity*.
22:19:44 <Gregor> pikhq_: My portability restrictions should be rather silly things, not "is x86"
22:19:57 <pikhq_> Oh. That's just fine then. :)
22:20:00 <Gregor> lifthrasiir: It's a JIT :P
22:20:42 <Gregor> pikhq_: By rather silly right now I mean, for instance, that the C stack is as it has been for the past billion years and grows down, and (weird one) that if you say int a; int b; at the global scope it will put b after a.
22:20:45 <lifthrasiir> ...but without involving any kinds of assembly or something?
22:20:50 <Gregor> That latter one I hope I can avoid.
22:20:53 <Gregor> lifthrasiir: No assembly at all.
22:21:09 <elliott> ais523: Here's my sg code scraps, FWIW: http://sprunge.us/NebW
22:21:13 <Gregor> lifthrasiir: Yeah, it'll be a template JIT.
22:21:24 <elliott> <Gregor> pikhq_: My portability restrictions should be rather silly things, not "is x86"
22:21:28 <elliott> Gregor: That OS got in *shrugs*
22:21:29 -!- augur has quit (Remote host closed the connection).
22:21:51 <elliott> Also, I think that IA-64's satck grows upwards.
22:21:52 <Gregor> elliott: I think that ignoring all else, my JIT will be more impressive if it's more portable :P
22:21:54 <ais523> SOF/EOF are going to need an argument eventually, but I guess you knew that
22:22:02 <Gregor> elliott: That's too bad for all four ia64 users.
22:22:06 <lifthrasiir> Gregor: i think that would be fine given enough safety measures...
22:22:17 <Gregor> Phantom__Hoover: ... no.
22:22:21 <lifthrasiir> don't know how much measures needed to ensure the safety though.
22:22:26 <pikhq_> Gregor: Also, there's no *strict* requirement that it be portable, it's just strongly suggested.
22:22:28 <elliott> ais523: and I don't have changeset applying code yet, because I realised that tsort was broken :)
22:22:32 <Gregor> lifthrasiir: Safetylol.
22:22:41 <Gregor> Phantom__Hoover: You oughtn't to :P
22:22:46 <elliott> Gregor: Remember that they're rejecting things that need human intervention to compiler.
22:22:57 <pikhq_> I'd say if it functions on essentially every system people care about, then you're good.
22:23:03 <ais523> elliott: O(n^2) tsort is trivial; but I think it's possible to do better
22:23:12 <elliott> ais523: no, I meant, broken because of moves
22:23:24 <elliott> ais523: I'm just going to use fgl's tsort, probably
22:23:25 <lifthrasiir> pikhq_: if they did require that how can OTCC and x86 OS be accepted? :p
22:23:26 <ais523> I'm not sure if it's n log n or n that's the best possible
22:23:27 <Gregor> Believe it or not I have a cohesive and sensibleish plan.
22:24:03 <elliott> ais523: (fgl = functional graph library)
22:24:27 <ais523> hmm, does it have an algo for finding strongly connected components?
22:24:43 <elliott> ais523: it's a pretty long-lived codebase and the API isn't the most elegant thing, but it's better than the standard Data.Graph, I should think
22:24:46 <ais523> (that's a sort of "stronger tsort" problem there where you possibly have cycles, and want to find those and put them in the proper place)
22:24:55 <elliott> components :: Graph gr => gr a b -> [[Node]]Source
22:24:55 <elliott> noComponents :: Graph gr => gr a b -> IntSource
22:24:55 <elliott> isConnected :: Graph gr => gr a b -> Bool
22:25:04 <ais523> I ended up rolling my own in the compiler, with an algo copied off Wikipedia
22:25:05 <elliott> in the same module as tsort
22:25:54 <elliott> oh, right, Data.Graph forces you to use Int to identify vertices
22:26:00 <elliott> whereas, sg wants to use any reference type
22:26:16 <elliott> (I decided to abstract the whole store system so that algorithms can be generic on the type of reference/store0
22:26:29 <elliott> turns out it's easy: class Ref ref m a | ref -> m a where deref :: ref -> m a
22:26:57 <elliott> e.g. instance Ref FileChangeHash StoreM FileChange where deref = lookupInStore
22:27:30 <elliott> s/FileChange/(FileChange ref)/
22:27:36 <elliott> apply :: (Ref ref m (FileChange ref)) => ref -> File -> m (Maybe File)
22:27:45 <elliott> and recursion in FileChange is replaced by the ref argument
22:27:58 <elliott> you can easily make Identity a Ref type in the Identity monad, to do it the simple recursive way
22:28:24 <elliott> class (Eq ref, Monad m) Ref ref m a | ref -> m a where deref :: ref -> m a
22:29:52 <elliott> ais523: hmm, weboflies-related question: can you use a new filesystem namespace as a chroot?
22:30:36 <ais523> elliott: if you can mount over /, then yes
22:30:40 <ais523> or, hmm, probably pivot_root would be enough
22:30:50 <elliott> ais523: ah, so it doesn't let you do it without root :(
22:30:52 <ais523> but I've never dared call it from inside weboflies, because I'm not quite that crazy
22:30:56 <elliott> (or a bunch of capabilities)
22:38:13 <elliott> Gregor: I guess I should try and get Transactional HackEgo running???
22:40:44 <elliott> ais523: incidentally, I wonder if applying all patches in sequence to checkout might not be reasonably quick, if applying a single patch is fast enough
22:40:54 <elliott> I'm really bad at estimating the real-time algorithms will take to run, though
22:41:45 <ais523> I'd guess it'd be impractically slow for common operations, but OK for something that was only done occasionally
22:41:54 <shachaf> "who cares, it's just constant factors" -- elliott
22:42:12 <ais523> for a clone, I'd say it'd be fine
22:42:47 <elliott> ais523: hmm, if we always have a checkout of the tip stored in +scapegoat, then checking out a branch could just apply /inverse/ patches to the base of that branch, and then apply the branch's patches
22:42:56 <elliott> we really need to figure out the inversion algorithm...
22:43:02 <elliott> I suppose it's relatively simple
22:43:03 -!- Phantom__Hoover has quit (Quit: Leaving).
22:43:16 <elliott> but hashes make it more difficult
22:43:29 <ais523> elliott: hmm, worrying thought: don't deletion changes have the same trouble as move changes
22:43:32 <elliott> because the inverse of (delete blah) has to be blah itself, not something identical to blah
22:43:41 <elliott> although... that doesn't matter when applying patches, so hmm
22:43:45 <ais523> we'd have "delete b between a and c" and "insert d between a and c"
22:43:51 <ais523> with no obvious dependence of the second on the first, although there iso ne
22:43:58 <elliott> ais523: delete changes are just "delete a"
22:44:07 <ais523> well, OK, still no obvious dependence
22:44:09 <ais523> even less, in that case
22:44:21 <ais523> as the two patches don't even mention a common patch
22:44:38 <ais523> I think a) move patches should keep hashes the same, and b) the same solution should be used for moves and deletes, that we haven't yet decided on
22:44:50 <elliott> ais523: I sort of feel like saying "I guess we have to dump tsort then", but it's a really good property
22:44:56 <elliott> and it's completely unobvious how to order changesets without it
22:45:15 <elliott> I definitely don't want to make changesets ordered, that's awful and I think probably breaks tons of obvious properties
22:45:42 <ais523> a partial order exists, but we don't know what it is, is the problem
22:46:13 <ais523> elliott: test case I feel will be important: ab, acb, ab, adb
22:46:24 <elliott> ais523: your "before/after reference" idea is sort of compelling, but I think leads to pathologies
22:46:26 <ais523> (where letters represent lines, and that represents the history of the file)
22:46:32 <elliott> but... I don't know, I might be wrong
22:46:38 <elliott> ais523: OK, what about it?
22:46:54 <ais523> the last change is "add d between a and b"
22:47:06 <ais523> and that would apply to the first copy of ab
22:47:19 <ais523> as well as the second (the third entry in the history)
22:47:41 <ais523> hmm, what if deletions and moves both renamed the patches they were deleted between / moved between?
22:47:52 <elliott> ais523: the question is how to rename them
22:48:01 <elliott> but a move is just one change
22:48:03 <ais523> I assume we have no shortage of hashes
22:48:07 <elliott> but a move is just one change
22:48:09 <ais523> you can have more than one hash related to one change trivially
22:48:22 <elliott> because that breaks the current model
22:48:30 <elliott> at least do it formally with your before/after hash thing
22:48:36 <elliott> rather than just hacking it in with ridiculous things like that
22:48:48 <elliott> it's just changing some references to include a hash /and/ a bool
22:50:00 -!- pikhq_ has quit (Read error: Operation timed out).
22:50:18 <ais523> yep; I mean hash /and/ other identifier that goes with it, in general
22:50:25 <ais523> which might be a bool, or might more reasonably be an enum element
22:50:33 -!- pikhq has joined.
22:50:36 <ais523> that way, we can have a file, and a file-sof, and a file-eof
22:50:58 <elliott> file-sof would be a dir change, if references include a bool like that
22:51:09 <ais523> err, no? file-sof is a different type from file
22:51:25 <ais523> no type error in "the sof of a file change is a patch anchor"
22:51:34 <ais523> any more than there is in "the head of an int list is an int"
22:51:48 <elliott> well, how is this relevant to this? it does not affect the range model at all.
22:52:06 <elliott> startpoint = sof <dirchange> | line <filechange> {before|after}
22:52:25 <ais523> I don't think we're disagreeing there
22:53:38 <ais523> hmm, the original plan didn't involve tsorting, I think; it was that given "add b between a and c", "delete b", "add d between a and c", it'd apply the patches in that order as it's the only one that lead to no conflicts
22:53:42 <ais523> but that does break the tsort property
22:54:07 <elliott> ais523: the only way to figure out that ordering is brute-forcing
22:54:20 <ais523> I'm starting to see a shadow of an algorithm in my head
22:54:21 <elliott> also, it's ambiguous, since there can be multiple possible ways to apply a change
22:54:32 <ais523> well, an ambiguity would mean a conflict
22:54:39 <elliott> ais523: hmm, what if a dependency on X counted as a dependency on any other change that referenced X?
22:55:13 <ais523> my idea is, that the algo for composing patches is first to tsort, then apply the patches in an arbitrary order, /but/ allow the file to not be in a sane state temporarily as we go
22:55:26 <ais523> e.g. you could do "add b between a and c", "add d between a and c" in that order
22:55:33 <ais523> and then "delete b between a and c" would put everything back to normal
22:56:05 <elliott> sigh, I was (but shouldn't have been) expecting something less ugly
22:56:12 <elliott> I think my idea's better :-P
22:56:13 <ais523> if everything ended up violating the definition of a file, we'd have a conflict; /but/ we can actually show the user a sane representation of the resulting file
22:56:20 <ais523> I think this is actually beautiful, rather than ugly
22:56:46 <ais523> and it's O(n), much much better than brute force
22:56:49 <elliott> you've basically said "what if we made changes non-atomic, and removed their semantics, so that they only make sense in a jumble"
22:57:28 <ais523> no, we're extending the semantics to work even with conflicts
22:57:37 <ais523> and what do you mean with "non-atomic"?
22:57:48 <elliott> you can't apply each change as a separate, coherent step
22:57:56 <elliott> because you have to keep track of the ~nonsensosity~
22:57:58 <ais523> yes you can; in fact, you can now do so in any order
22:58:01 <ais523> which makes things even better
22:58:16 <elliott> it's not atomic, because changes don't become transformations from files to files
22:58:17 <ais523> oh, I think by "atomic" you mean "leading to a consistent state at any point in history"
22:58:19 <elliott> they're from files to goop
22:58:24 <ais523> elliott: they're from goop to goop
22:58:24 <elliott> ais523: that's what atomic /means/
22:58:33 <ais523> and the goop itself is useful
22:58:33 <elliott> you're /breaking compositionality/
22:58:43 <ais523> they're from /goop/ to /goop/, how is that not compositional?
22:59:10 <elliott> because you apply a changeset from file to file, not goop to goop
22:59:18 <ais523> well, "goop" here means "file or conflicted file"
22:59:26 <ais523> which means you don't need to special-case conflicts. AT ALL.
22:59:46 <elliott> let me know when you have an algorithm rather than an idea that amounts to "just make it not consistent"
23:00:07 <ais523> perhaps I'll have to implement it to show you how great it is
23:00:27 <elliott> that won't be necessary. a simple algorithm description will be
23:00:44 <elliott> so far you haven't even defined what the goop is
23:01:23 <ais523> with lines as vertices, and edges meaning "adjacent to" (with the direction meaning the direction)
23:02:04 <ais523> if each vertex but the first and last has one input and one output (and the first and last have one output/one input respectively), it represents a non-conflicted file; otherwise, a conflicted file
23:02:18 <elliott> ok, that sounds a little better. how do you apply a move as goop -> goop?
23:02:48 <ais523> disconnect three edges, connect another three edges
23:03:16 <ais523> actually, my current issue with this is "what if the edges aren't there to disconnect"
23:03:25 <ais523> my guess is that that means you're missing dependencies
23:03:43 <ais523> this works for additions, but not deletions
23:04:02 <ais523> oh, you have a count for how many times each edge is there, and let it go negative
23:04:09 <ais523> that way, you can represent "deletion of something that isn't there"
23:04:20 <ais523> err, hmm, maybe this doesn't work
23:04:54 <ais523> this deserves thought from me; but I need to be capable of thinking at the time
23:05:18 <elliott> <ais523> oh, you have a count for how many times each edge is there, and let it go negative
23:05:25 <elliott> can't you just use a multigraph or something, that's ugly
23:05:50 <ais523> elliott: the issue is that you have a file abc, and get two copies of "delete b"
23:05:59 <ais523> that's a conflict no matter what; how do you represent it in the resulting goop?
23:06:39 <ais523> in other words, this solves the tsort issue, but /doesn't/ solve deletions, which are the reason the tsort issue's there in the first place
23:06:45 <ais523> so it's, umm, kind-of pointless?
23:06:51 <elliott> ais523: don't? is there any way for that to happen in a non-conflicting whole changeset?
23:07:25 <ais523> because you want to be able to show the user what's conflicting, when there's a conflict
23:07:46 <ais523> also, because calculating the rest of everything, which doesn't conflict, becomes no longer O(n)
23:08:23 <elliott> ais523: I don't mind if conflicts just give a failure result; the program on top can figure out how to present it
23:09:10 <ais523> elliott: the original idea is that you resolved conflicts by making a change that just made them unconflict again
23:09:30 * elliott is not sure that's a good idea
23:09:45 <ais523> right; your x-modulo-y is a replacement for that
23:09:53 <elliott> ais523: here's an argument against goop:
23:10:01 <elliott> has different semantics from
23:10:01 <elliott> has different semantics from
23:10:16 <ais523> by "ab", you mean a and b?
23:10:18 <elliott> because there's a goop barrier between sg commands, obviously, to turn them into actual files
23:10:26 <ais523> it has exactly the same semantics
23:10:47 <ais523> the resulting goop ends up exactly the same
23:10:50 <elliott> ais523: because if it did, you could apply /every/ changeset that way
23:10:59 <elliott> which would make changes consistent at each stage
23:10:59 <ais523> yes, that's the entire point behind goop
23:11:09 <ais523> changes are consistent at each stage
23:11:16 <ais523> just in the goop, which might or might not represent a file
23:11:27 <elliott> and goop is converted from and to files on each actual operation
23:11:30 <ais523> if it doesn't, then presumably you put a conflicted version in the disk file, and let the user edit it to fix it
23:11:33 <elliott> therefore pull ab =/= pull a; pull b
23:11:56 <elliott> you're basically saying "we need to apply changesets by threading some intermediate state" while /also/ saying "applying changesets is just applying changes in an order"
23:11:57 <ais523> err, no? assume for the time being that the working copy is clean
23:12:17 <ais523> then the result of a pull doesn't depend on the working copy at all
23:12:24 <ais523> so after pull a; pull b (or else pull b; pull a)
23:12:36 <ais523> the working copy is calculated from the same set of information each time
23:12:58 <ais523> with the same deterministic algo
23:13:01 <elliott> ais523: oh, you want to operate on goops at all points? that means you have to cache them
23:13:01 <ais523> so how could it not be the same?
23:13:10 <ais523> yep, operate on goops at all point
23:13:23 <ais523> you don't, semantically, have to cache them, although you probably would for efficiency reasons
23:13:49 * elliott doesn't think this will work
23:14:45 <ais523> deletes definitely need a between with this method
23:14:55 <zzo38> In Super Smash Brothers Melee, my brother could write his entire name even though it was limited to 4 letters. In Brawl, the limit is raised to 5 letters however his name will no longer fit.
23:18:09 <elliott> Oh my god, the official plural of "Prius" is "Prii".
23:19:57 <elliott> http://blogs.cars.com/kickingtires/2011/02/plural-of-prius-prii-not-according-to-latin-experts.html
23:19:59 <elliott> "Before we could make up our minds, Toyota decided today that the plural form is “Prii” (pronounced PREE-eye). That decision was the result of a marketing campaign in which Toyota asked the public about the plural possibilities: “Prius,” “Priuses,” “Prii,” “Priem,” or “Pri.”
23:19:59 <elliott> “Prii” received 25%. “Prius” came in a close second with 24%."
23:20:11 <elliott> they should have gone with "pru"
23:23:09 <ais523> they should have declared "prius" the plural and went with "priu" for the singular
23:25:05 <monqy> all new toyota peru
23:25:21 <monqy> the all new toyota peru
23:26:51 <pikhq> elliott: I call bullshit.
23:27:41 <pikhq> *Clearly* the car is the プリウス, and thus the plural is also プリウス.
23:28:06 <pikhq> (puriusu, puriusu; hůriusu, hůriusu)
23:30:09 <pikhq> But seriously though, plurals can't/shouldn't be dictated by corporate fiate.
23:30:10 <oerjan> lessee, prius is neuter form of prior iirc
23:30:20 <pikhq> And "Prii" is particularly stupid.
23:30:20 <oerjan> so plural would be priora
23:32:46 <elliott> hey oerjan n-cursor zipper
23:33:22 <oerjan> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
23:34:11 <elliott> oerjan: no helpp...... i ned hepl
23:34:17 <elliott> that would be fnie........
23:34:43 <shachaf> elliott: Dude, what about a zipper where, like, everything is a hole. And there's, like, no actu data, man.
23:35:53 <oerjan> oh there's a small sense in which a list may be _harder_ than quadtrees: you don't have the holes at all the same level
23:35:59 <elliott> oerjan: hmm, just like a one-hole list zipper is before + element + after, maybe a two-hole one is before1 + element1 + after1before2 + element2 + after2
23:36:12 <elliott> then you can't have 2 after 1
23:36:52 <elliott> oerjan: I'll probably go straight to a k-d tree or something; the quadtree example is interesting only insofar as it has a similar tree structure compared to a list
23:37:25 -!- aloril has quit (Ping timeout: 260 seconds).
23:37:52 <oerjan> well the thing is i had a sort of conceptual idea of what an n-hole quadtree zipper should look like, even though immensely complicated, and that method simply does not work for a list...
23:38:26 <oerjan> because it depended on the type-balanced levels
23:38:30 <elliott> oerjan: would a bitree be easier? :p
23:39:27 <oerjan> hm this actually reminds me of some of the "solid set" stuff from some of my papers
23:40:24 <elliott> mmm bitrees sound super elegant
23:41:02 <shachaf> It's like a btree with an i.
23:41:09 <elliott> oerjan: well you know quadtrees and octtrees
23:41:12 <elliott> it's like that but only two!
23:41:17 <oerjan> do you mean like quadtrees, except for a 1d space
23:41:24 -!- Ngevd has joined.
23:41:57 <oerjan> hm you might be able to use that for a list zipper
23:42:19 <elliott> if quadtrees sound simpler to do then quadtrees it is
23:42:25 <oerjan> in such a way that you keep all elements at the same level
23:42:26 <elliott> but I don't see why it wouldn't generalise to ~bitrees~
23:42:38 <oerjan> yes, that's what i'm thinking about
23:43:07 <elliott> oerjan: i mean i don't actually have any lists to do this to.
23:43:11 <elliott> i was just trying to pick a simple structure
23:43:29 <shachaf> elliott: How about Bool? Make a zipper for Bool.
23:43:30 <oerjan> however, i expect no matter how you slice this, it will be immensely inefficient compared to a mutable structure
23:44:01 <elliott> oerjan: well... that sads me
23:44:02 <oerjan> simply because of all the maintenance to keep all the holes straight
23:44:21 <elliott> oerjan: I suppose the basic problem is that "multiple zippers changing the same structure" is basically only useful to implement mutability
23:44:25 -!- copumpkin has quit (Quit: Computer has gone to sleep.).
23:44:59 <Ngevd> http://a2.sphotos.ak.fbcdn.net/hphotos-ak-ash4/384346_10150936833620716_537230715_21844300_367012712_n.jpg
23:45:05 <elliott> oerjan: but ehh, the shiro 1 design was, fungespace was a big single hashmap, and IPs just modified that round-robin style
23:45:34 <elliott> oerjan: the zipper thing is useful because I can divide up space into smaller regions to make IP-local access etc. fast... it feels really weird that I'd make funge concurrency /slower/ by doing that
23:47:30 <elliott> oerjan: and ofc making it mutable will /not/ be good for one of my main goals for shiro 2, which is to move as much possible /out/ of my awful StateT HugeStateRecord IO monad
23:48:36 <elliott> feels like I'm making a trade-off between the code getting uglier and having no chance beating CCBI2 :P
23:48:54 <oerjan> well, to imagine how a cursor with n holes would work
23:49:28 <oerjan> first, you needed some kind of map to tell which holes go to the same thing on the next higher level
23:49:29 <Ngevd> Does there exist a combinator N such that Nx is true when x is a church numeral and false otherwise?
23:49:38 <elliott> Ngevd: I think Oleg did that
23:49:48 -!- ais523 has quit (Remote host closed the connection).
23:49:51 <oerjan> Ngevd: doubtful that it could always be false otherwise
23:49:56 <elliott> Ngevd: well, there's http://okmij.org/ftp/Computation/lambda-calc.html#bluff
23:49:58 -!- aloril has joined.
23:50:31 <elliott> "The gist of the problem is discriminating a Church numeral from some other term."
23:50:59 <elliott> but it doesn't distinguish it from /every/ other term
23:51:20 <elliott> oerjan: it feels like you shouldn't have to have duplication + a map
23:51:26 <elliott> I know that's not helpful though :P
23:52:51 <elliott> <oerjan> first, you needed some kind of map to tell which holes go to the same thing on the next higher level
23:52:55 <elliott> the duplication of holes, in some sense
23:53:39 <oerjan> i'm thinking of the case where you have some holes that are neighbors, so they are in the same level-1 quadtree
23:54:02 <oerjan> so they must share their cursor for going up to level 2
23:54:32 -!- Aune has left ("Lmnar").
23:55:01 <elliott> oerjan: are you sure bitrees aren't simpler >:)
23:55:06 <oerjan> we may assume that no holes are in the exact same spot except at the very first level
23:55:23 <oerjan> ...i have no idea how to apply bitrees to a 2d space
23:55:51 <oerjan> but with what i imagine, they have the exact same issues
23:56:44 <elliott> oerjan: who needs a 2d space :P
23:56:59 <Ngevd> Did anyone here watch El Nombre?
23:57:00 <oerjan> ...i thought this was something 2d you were implementing
23:57:01 <elliott> i'm not really planning to use quadtrees much /anyway/, i'm just trying to get a really simple n-cursor zipper to think about
23:57:18 <elliott> oerjan: i'm just thinking that it might be easier to formulate an n-cursor zipper on a simpler structure first...
23:57:30 <elliott> feel free to continue with quadtrees if you disagree :P
23:57:52 <elliott> Ngevd: how the fuck do i remember that
23:57:54 <oerjan> it doesn't matter much for my idea whether you look at quadtrees or bitrees.
23:58:27 <Ngevd> elliott, because El Nombre is awesome
23:59:06 <oerjan> it's about how to think of a multi-cursor at level n in terms of a multi-cursor at level n+1