09:02:08 <Palmik> Guys, what is your opinion (again in regerds to higgsset) on using unsafeCoerce under the hood? I would use it to cast between existintially quantified types (wrapped in GADT) that I know are infact the same.
09:04:27 <Lemmih> I think that is OK.
09:04:57 <Lemmih> unsafeCoerce just puts the proof obligation on you instead of the compiler.
09:07:25 <Palmik> Yes, I agree. :)
15:03:14 <stepcut> Palmik: I'm thinking Dynamic uses unsafeCoerce under the hood? So, it's not inherently more evil than IxSet already is :p
15:04:10 <Palmik> Yes it does http://hackage.haskell.org/packages/archive/base/latest/doc/html/src/Data-Typeable.html#cast
15:12:26 <stepcut> I'm not worried at all about unsafeCoerce
15:19:34 <Palmik> OK. By the way, I'm probably going for simething like this (at least for now) as far as the uniqueness/autoincrementing goes: http://hpaste.org/75450 that means that in the initial version it will probably not be possible to combine uniqueness and autoincrement and it will not be possible to supply your own value for autoincrement dimension. Anyway, I'm always open to new ideas.
15:21:39 <stepcut> so you pass in a lazy, infinite list to the first two constructors?
15:23:05 <dcoutts> Lemmih, stepcut: any idea what could cause this, when I've started from a clean slate
15:23:07 <dcoutts> This method is required but not available: "ReplaceUserDb". Did you perhaps remove it before creating a checkpoint?
15:23:30 <Palmik> stepcut, this is how it's used http://hpaste.org/75451
15:23:48 <dcoutts> I've blown away the state, made a new db, done a checkpoint, shutdown, and then opened it again
15:24:03 <dcoutts> point is, no code changes or old checkpoint files
15:24:13 <stepcut> right
15:24:19 <stepcut> using acid-state 0.8.0 ?
15:25:21 <dcoutts> stepcut: oh, hmm, using 0.6, lemme try 0.8
15:25:39 <stepcut> ah
15:26:29 <stepcut> there were some issues with the way show worked on Typeable that could give an error like that.. but I don't see how that would happen with the situation you described
15:27:15 <stepcut> still. I am not going to look at the changelogs for 0.7 - 0.8 to see what could have broken if you are only using 0.6 :p
15:27:23 <dcoutts> stepcut: remember when you helped us port to acid-state and did it by simulating the monolithic global state component?
15:27:31 <dcoutts> I've been breaking that up into per-feature ones
15:27:34 <stepcut> dcoutts: yes
15:27:53 <dcoutts> and I seem to have done something wrong, since after doing it for the user state I hit this
15:28:04 <dcoutts> but yes it could just be the version I'm using
15:28:07 <dcoutts> ACTION is updating...
15:28:22 <stepcut> do you have more than one ReplaceUserDb function?
15:28:41 <stepcut> hmm, that error would be different though
15:29:17 <dcoutts> my first though is that I changed the order of initialising the state components
15:29:25 <dcoutts> but I don't yet see how that would matter
15:29:30 <stepcut> i wouldn't think that would matter
15:36:09 <dcoutts> oh, hmm, interesting
15:36:14 <dcoutts> now I get a lock error
15:36:26 <dcoutts> hackage-server: state/db/Users/open.lock: resource busy
15:36:33 <dcoutts> looks like I'm trying to open it twice
15:37:22 <dcoutts> ah!
15:38:02 <dcoutts> ok, saved by locking
15:38:14 <dcoutts> yes, typo
15:38:27 <dcoutts> one component was opening the wrong named state
15:38:37 <stepcut> ah
15:38:48 <stepcut> that would make sense
15:38:53 <dcoutts> stepcut: thanks for the suggestion to update
15:38:58 <stepcut> :)
15:38:59 <dcoutts> Lemmih: thanks for doing proper locking :-)
15:40:11 <dcoutts> ok, so the method didn't exist, because it opening & reading the checkpoint file from the was the wrong state component
15:40:33 <stepcut> right
15:40:54 <stepcut> well, the checkpoint file won't include events
15:40:59 <dcoutts> (erm, reordering clauses in a sentence to make it read better doesn't work if you do it blindly)
15:41:01 <dcoutts> :-)
15:41:04 <stepcut> so it must have been reading the events for some reason
15:41:23 <dcoutts> stepcut: ah yes, we don't actually make a checkpoint when we initialise a clean hackage-server
15:41:25 <stepcut> but, when there were no events to replay, then you didn't get an error
15:41:54 <dcoutts> since there's only going to be a few events in an empty server state
17:30:20 <dcoutts> stepcut: does happstack-server use persistent http connections?
17:30:42 <dcoutts> ACTION is trying to work out what's going on with a client that's using the Haskell HTTP package
17:31:01 <stepcut> yes
17:31:15 <dcoutts> hmm, even more perplexing then
17:31:20 <stepcut> but there is a patch I just got to day to fix a bug related to if-modified-since..
17:31:48 <stepcut> what seems to be the issue?
17:32:23 <dcoutts> stepcut: oh the HTTP package's browser module is reporting:
17:32:29 <dcoutts> hackage-import: <socket: 4>: resource vanished
17:32:49 <dcoutts> it keeps a cache of connections, and has some issue to do with recycling them if it finds they're closed
17:33:03 <dcoutts> but that's only supposed to go wrong for servers that don't use persistent connections
17:33:22 <stepcut> I just forwarded a patch to you that sounds related
17:34:49 <dcoutts> stepcut: looks unrelated, I'm not using if-modified-since here
17:34:51 <dcoutts> but thanks
17:35:00 <dcoutts> ACTION suspects the HTTP lib
17:35:44 <stepcut> it affects more than just 304
17:35:59 <dcoutts> here I'm just doing ordinary PUT requests
17:35:59 <stepcut> but it could also just be happstack-server timing out the connection if nothing happens for more than 30 seconds
17:36:07 <dcoutts> no, this is all instant
17:36:41 <dcoutts> ah, hold on
17:36:43 <dcoutts> Connection: close
17:37:10 <dcoutts> it is responding with connection close
17:37:17 <stepcut> the server is ?
17:37:32 <dcoutts> yes
17:37:35 <dcoutts> Debug: Recovering connection to admin:admin@localhost:8080
17:37:35 <dcoutts> Debug: Received:
17:37:35 <dcoutts> HTTP/1.1 204 No Content
17:37:35 <dcoutts> Connection: close
17:37:35 <dcoutts> Content-Type: text/plain
17:37:37 <dcoutts> Date: Fri, 28 Sep 2012 15:59:57 GMT
17:37:39 <dcoutts> Server: Happstack/7.0.4
17:37:41 <dcoutts> that's the log from the client
17:38:44 <stepcut> so, that patch I sent looks for response code 204
17:39:05 <stepcut> +    isNoMessageBodyCode code = (code >= 100 && code <= 199) || code == 204 || code == 304
17:39:38 <dcoutts> ah
17:40:00 <dcoutts> ACTION wonders why that's related to close vs keep-alive, but decides not to investigate
17:40:04 <stepcut> it seems to use that predicate as part of a test to see if it should keep-alive
17:41:12 <stepcut> I'll apply this patch and upload a new happstack-server
17:41:21 <dcoutts> stepcut: ok, explains why this all worked fine with happstack and the HTTP package before, I wasn't using 204 responses
17:41:47 <stepcut> cool
17:42:05 <dcoutts> so HTTP package is still wrong :-)
17:42:26 <dcoutts> but I can still live with it
18:07:45 <stepcut> $ cabal install cabal-install
18:07:45 <stepcut> Resolving dependencies...
18:07:47 <stepcut> cabal: Couldn't read cabal file "warp/1.3.1.2/warp.cabal"
18:07:47 <stepcut> >:(
18:08:17 <dcoutts> stepcut: gimme a sec...
18:12:36 <stepcut> no problem
18:12:44 <stepcut> once I test that this still builds I can upload the new happstack-server
18:18:17 <dcoutts> stepcut: ok, cabal update
18:18:41 <dcoutts> note that if you actually have to install those versions of warp, then it'll still fail when it tries to build them
18:18:49 <dcoutts> but not during the dependency planning phase
18:19:22 <stepcut> works!
18:19:26 <stepcut> suck it snoyman!
18:19:40 <stepcut> what is the problem anyway? old cabal doesn't understand the new format?
18:19:54 <dcoutts> it's a bug in some old cabal versions
18:20:04 <dcoutts> $ cabal configurecabal: warp.cabal:59: The 'type' field is required for test suites. The
18:20:04 <dcoutts> available test types are: exitcode-stdio-1.0
18:20:09 <stepcut> ah
18:20:14 <dcoutts> is the error you get if you configure it locally
18:21:14 <dcoutts> the error is reported as a result of an explicit check
18:21:19 <dcoutts> a check that was wrong
18:21:23 <dcoutts> and because it was an error in the parsing stage, then it causes no end of trouble
18:21:45 <stepcut> alas, I still can not install cabal install because of this error, The following packages are involved in a dependency cycle text-0.11.2.3, test-framework-0.6.1, xml-1.3.12, test-framework-hunit-0.2\
18:21:45 <stepcut> .7, test-framework-quickcheck2-0.2.12.3
18:21:46 <dcoutts> and people using newer cabal versions of course don't notice, so they upload packages that break with older cabal
18:21:59 <stepcut> I figured out how to get around that once, but forgot already :p
18:22:07 <dcoutts> turn off the testsuite
18:22:19 <stepcut> ah yes
18:23:23 <dcoutts> that is a tricky problem
18:23:41 <dcoutts> that packages like text and bytestring want to depend on the nice test frameworks and benchmarking libs
18:23:49 <dcoutts> which then does indeed cause cycles
18:26:31 <stepcut> I tried,  cabal install --disable-tests cabal-install, but it still wants to install test-framework-*
18:28:05 <stepcut> ACTION tries runhaskell Setup.hs instead
18:28:17 <dcoutts> ACTION cannot reproduce that
18:28:42 <dcoutts> and I don't have test-framework installed
18:29:04 <dcoutts> stepcut: cabal install --enable-tests cabal-install --dry
18:29:08 <dcoutts> what does it say ^^ ?
18:29:17 <dcoutts> or with --disable-tests
18:29:39 <dcoutts> btw, I'm using the old version here,
18:29:42 <dcoutts> $ cabal --version
18:29:42 <dcoutts> cabal-install version 0.10.2
18:29:42 <dcoutts> using version 1.10.1.0 of the Cabal library
18:29:57 <dcoutts> ie the one that has the trouble with warp.cabal etc
18:30:56 <stepcut> doesn't matter if i use enable or disable, says the same thing:  cabal: cannot configure test-framework-quickcheck2-0.2.12.3. It requires....
18:31:34 <dcoutts> what version of cabal is that?
18:31:59 <stepcut> $ cabal -V
18:31:59 <stepcut> cabal-install version 0.9.5
18:32:01 <stepcut> using version 1.10.0.0 of the Cabal library
18:32:16 <stepcut> oh.. I am dumb
18:32:18 <dcoutts> oh, try using a released version
18:32:27 <stepcut> i think that is what came with platform
18:32:33 <dcoutts> no
18:32:43 <stepcut> I realize now that I actually built this already and installed it in ~/.cabal/bin.. but that is just not in my PATH
18:32:47 <dcoutts> the platform always uses a release
18:32:50 <stepcut> ACTION fixes the real problem
18:34:33 <stepcut> fixed
18:34:35 <stepcut> sorry about that
18:58:23 <stepcut> dcoutts: upload happstack-server-7.0.6
18:58:56 <dcoutts> cool
19:09:35 <stepcut> 7.0.7 coming soon :)
19:12:18 <stepcut> done. waitForTermination catches lostConnection now
19:24:47 <dcoutts> stepcut: what prompted 7.07?
19:25:06 <dcoutts> ACTION was just playing with 7.0.6
19:25:06 <stepcut> waitForTermination now catches lostConnection :)
19:25:25 <dcoutts> ok, no idea what that means :-)
19:25:27 <stepcut> I was closes the bugs for 7.0.6 and saw that I forgot about that easy bug
19:25:40 <dcoutts> stepcut: so my problem earlier, solved with 7.0.6
19:25:41 <dcoutts> yay
19:25:48 <dcoutts> can now import data fine
19:26:20 <dcoutts> ACTION just imported all the existing hackage accounts into the new server
19:26:23 <stepcut> it means that waitForTermination is more likely to shutdown the system correctly when the HANGUP signal is received
19:26:28 <stepcut> ooo
19:26:39 <stepcut> how's the new server looking ?
19:26:47 <dcoutts> stepcut: better :-)
19:26:51 <stepcut> nice :)
19:27:05 <stepcut> how's ram usage these days? Still terrible? Or just bad?
19:27:26 <dcoutts> it's currently ok but only because we're currently parsing .cabal files on demand :-)
19:27:52 <dcoutts> I was doing some experiments last weekend to get the amount of data in memory down
19:27:53 <stepcut> does that affect checkpoint reloading time at all ?
19:28:07 <dcoutts> stepcut: shouldn't do
19:28:30 <stepcut> my theory was that one reason the checkpoint took a long time to load is that it was trying to parse every since .cabal file ever uploaded on startup
19:29:00 <dcoutts> it's not impossible, but I don't think it was
19:29:02 <stepcut> my hypothesis
19:29:23 <dcoutts> the binary instance would get the .cabal file bytestring, and do the parse lazily
19:29:39 <stepcut> that would be the nice way
19:29:47 <dcoutts> that's what it used to do
19:29:57 <stepcut> for some reason I thought it was checking for parse errors as well
19:29:58 <dcoutts> now it doesn't store it at all, always parses on demand
19:30:17 <stepcut> but it still takes forever to load?
19:30:18 <dcoutts> so in a sense the change is that now there's no memoisation :-)
19:30:31 <dcoutts> stepcut: I've not been testing that, I don't think it's the top priority
19:30:43 <stepcut> yeah
19:30:55 <stepcut> it's a priority in the sense that it makes people not want to hack on hackage2
19:31:30 <dcoutts> stepcut: oh memory is an issue (if you want to import all the old data) but I don't think load times are a problem
19:31:49 <dcoutts> stepcut: also, Lemmih has implemented a way in acid-state for us to catch up to the last checkpoint while the existing server instance is still running
19:31:49 <stepcut> I heard it was taking 5 minutes to startup with a complete package DB
19:31:59 <dcoutts> so that means we can do switchovers with less downtime
19:32:08 <stepcut> yeah, that is good for switching live, but doesn't help with dev-cycle time
19:32:20 <stepcut> anyway, still not the highest priority :)
19:32:29 <dcoutts> true, but it's easy enough to test with smaller package dbs
19:32:42 <dcoutts> --state=./test/
19:33:01 <stepcut> actually, creating a striped down package db from the full package db was non-trivial as well :-/
19:33:38 <stepcut> anyway, still not important at this time :)
19:34:23 <dcoutts> :-)
19:34:28 <dcoutts> ACTION disappears for the evening
19:34:49 <dcoutts> stepcut: btw, one can do it with the mirror client: tell it to import just certain named packages
19:34:58 <stepcut> oo
19:35:06 <dcoutts> ACTION really disappears
20:55:37 <donri> fpcomplete emphasizes functional programming, well-typed emphasizes strong types. someone should do a startup with tekmo emphasizing category laws ;)
20:57:14 <stepcut> :)
20:57:52 <stepcut> and functors
20:58:32 <donri> i wonder if there's any "purely typed programming language", such that the whole program is inferred djinn-style from the types, which have to be very specific (more so than most agda programs even)
20:58:39 <donri> stepcut: i meant category theory laws in general
20:58:40 <stepcut> The Law Firm of Category, Functor, and Tekmo
21:01:49 <donri> the categorical lawyer :D
21:10:09 <stepcut> pipes is categorically, the best IO library around!
21:11:59 <donri> pipes: not a pipe dream
21:18:59 <sm> you guys are killing me, pipe down
21:21:03 <stepcut> ACTION wonders what the pipes-dream package would do
21:34:20 <sm> lol
21:37:31 <donri> i'm reminded of the sinatra website http://www.sinatrarb.com/