--- Log opened Mon Nov 16 00:00:52 2009
01:54 < Lemmih> fxr: Yes.
02:05 < h_buildbot> Build for ghc-6.8.3 failed. Check http://buildbot.happstack.com/ for details.
02:07 < h_buildbot> Build for ghc-6.10.2 OK. Test suite ran. 14/89 test cases failed. Check http://buildbot.happstack.com/ for details.
02:08 < h_buildbot> Build for ghc-6.12.1rc1 failed. Check http://buildbot.happstack.com/ for details.
08:05 < McManiaC> happstack: too few bytes. Failed reading at byte position 72057594037928112
08:05 < McManiaC> wtf
08:05 < McManiaC> i *hate* migrating data
08:10 < McManiaC> happstack: Prelude.Enum.Bool.toEnum: bad argument
08:10 < McManiaC> wtf
08:13 < McManiaC> http://npaste.de/3v/ can anyone see a problem with the migration at line 140?
08:13 < McManiaC> is there anything special about ByteStrings and happstack?
08:14 < mightybyte> McManiaC: I haven't found it too onerous.
08:15 < McManiaC> :S
08:16 < mightybyte> There was one time when I couldn't figure out a migration error.
08:16 < mightybyte> I thought through everything and couldn't understand why I was getting an error.
08:16 < mightybyte> Then I decided to just try the migration again with the same code...and it worked.
08:17 < mightybyte> Very strange
08:18 < mightybyte> I think that problem may have been rooted in the fact that it's very difficult to ensure that no more update events get written to the log after you write your checkpoint file, but before the program exits.
08:18 < mightybyte> It doesn't happen often, but that may have been one of the rare cases when it did.
08:19 < mightybyte> So if you're migrating the state for an app running live on the internet, you might retry the migration with a newly generated checkpoint.
08:20 < McManiaC> the last time I tried to migrate my data I had to remove _local and re-read every file from harddisk
08:20 < McManiaC> this time doesnt really look any better :S
08:20 < mightybyte> That would be unacceptable for me because I've got live user data.
08:21 < McManiaC> yeh
08:21 < mightybyte> I keep my deployment directory tree in a git repository.
08:21 < McManiaC> this time its unacceptable for me too
08:21 < mightybyte> And periodically I'll create a checkpoint and commit it to the repository.
08:22 < McManiaC> maybe something is wrong with my StateOld? http://npaste.de/3w/
08:22 < mightybyte> This way I can always revert to a last-known-good state even in the catastrophic case that I can't migrate properly.
08:22 < McManiaC> mightybyte: this is what I do
08:23 < McManiaC> but I want to migrate anyway ;P
08:23 < McManiaC> I wish stepcut would be here ^^
08:23 < mightybyte> What is what you do?  Version control your state?
08:24 < McManiaC> I just wanted to add that md5hash field to PasteEntry
08:24 < McManiaC> it works like a charm on a "blank" system with no current state, but migration fails =(
08:24 < mightybyte> That should be pretty straightforward.
08:25 < mightybyte> I've done that numerous times.
08:25 < mightybyte> What does your new state code look like?
08:25 < McManiaC> http://npaste.de/3v/ line 140
08:26 < mightybyte> Ohhh, I've never had migration code that complex.
08:26 < mightybyte> Ok, your first problem is that you have all your state in one file.
08:26 < McManiaC> well basicly its just "take the old one and add a "BS.empty" to the md5hash field"
08:26 < mightybyte> So when you change one thing, you have to change everything.
08:27 < McManiaC> ok?
08:27 < McManiaC> one state = one file?
08:27 < mightybyte> I would suggest that you put the code for ID, Content, PasteEntry, and Paste into separate files.
08:27 < McManiaC> hm okay
08:28 < McManiaC> will I have to migrate this too?
08:28 < McManiaC> ^^
08:29 < mightybyte> We might be able to avoid a migration
08:29 < mightybyte> Here's my suggestion.
08:29 < mightybyte> 1. Throw away your new state code.
08:29 < mightybyte> (Well, don't throw it away, you can still use it later.  But start over with a clean slate that works with your current state files.)
08:30 < McManiaC> ok
08:30 < mightybyte> 2. Modularize your state.
08:30 < mightybyte> This shouldn't require a migration if you're working with the same code as your current, running state.
08:32 < mightybyte> So you will probaby want all 5 data declarations inside the deriveAll to go in separate files
08:32 < mightybyte> ID and IDType might be able to go in the same file.  You can decide which way to go on that one.
08:33 < mightybyte> Don't think about migrating until you have the modularized code working.
08:34 < McManiaC> kay
08:34 < mightybyte> Then, your migration instance will look something like this:
08:34 < mightybyte> instance Migrate Old.PasteEntry PasteEntry where
08:35 < mightybyte>   migrate (Old.PasteEntry u i d c f) = PasteEntry u i d c f BS.empty
08:37 < mightybyte> Does that make sense?
08:44 < McManiaC> yup
08:44 < McManiaC> already working on it :)
08:44 < mightybyte> Ok.  Let me know how it goes.
08:44 < mightybyte> When it comes to happstack state migrations, modularization is the key.
08:45 < McManiaC> Ok, modules loaded: ...
08:45 < McManiaC> ^^
08:46 < McManiaC> perfect
08:46 < McManiaC> okay
08:46 < McManiaC> gonna try to migrate ;)
08:51 < McManiaC> hmmm
08:51 < McManiaC> Module imports form a cycle for modules:
08:51 < mightybyte> Yeah....
08:51 < mightybyte> That's the thing you have to look out for.
08:52 < mightybyte> Your state is divided into a bunch of source files...
08:52 < mightybyte> Let's say you're migrating just one of these files...
08:52 < mightybyte> Call it A.hs
08:53 < mightybyte> That means that you have an Old/A.hs and A.hs
08:53 < mightybyte> A.hs will have the Migrate instance.
08:53 < mightybyte> And therefore it will have to import Old/A.hs
08:53 < mightybyte> So your state should be designed so that Old/A.hs does not have to import A.hs
08:55 < McManiaC> hmm actually it shouldnt...
08:56 < fxr> Lemmih: I sent you a mail about Network.FastCGI.
08:56 < McManiaC> dang, I imported A.hs instead of Old/A.hs ^^
08:57 < mightybyte> Ahh, good...easy fix.
09:00 < McManiaC> damn
09:00 < McManiaC> happstack: too few bytes. Failed reading at byte position 72057594037928113
09:00 < mightybyte> Did you try executing the code just before the migration to make sure everything still works?
09:00 < McManiaC> http://npaste.de/3x/
09:00 < McManiaC> yes
09:01 < mightybyte> Let me see the code for PasteEntryOld
09:02 < mightybyte> (and I can guess the URL)
09:02 < McManiaC> http://npaste.de/3y/
09:02 < McManiaC> ^^
09:02 < mightybyte> Ahh, there's your problem.  Old has version 1
09:02 < mightybyte> So the new one needs to have version 2
09:03 < McManiaC> oh wow
09:03 < McManiaC> :)
09:03 < McManiaC> thx a lot!
09:04 < McManiaC> it works
09:04 < McManiaC> :)
09:04 < mightybyte> Excellent.
09:05 < fxr> :)
09:05 < Lemmih> fxr: I'm not quite sure how to respond.
09:08 < fxr> Lemmih: hmm, haven't you received and bug report before?
09:08 < McManiaC> btw: is there a way to *force* a linebreak with HSP XML?
09:08 < fxr> /and/any
09:09 < mightybyte> McManiaC: No clue.  I haven't used HSP.
09:10 < mightybyte> McManiaC: In summary, if you are disciplined about putting your state data structures into separate files, most migrations are fairly simple.
09:10 < McManiaC> mightybyte: I guess, yup
09:10 < McManiaC> :)
09:11 < McManiaC> thx for the hint
09:11 < mightybyte> McManiaC: Although there are times when I have to do some extra work to make sure there are no cyclic dependencies.
09:11 < McManiaC> jup
09:11 < Lemmih> fxr: Oh, I see now. The haddock documentation for fastcgi lists me as the maintainer.
09:12 < fxr> Lemmih: :( but you're not ha?
09:12 < mightybyte> I think GHC has a way of handling cyclic dependencies, but I've decided not to stay away from that for simplicity's sake.
09:12 < Lemmih> fxr: Bjorn Bringert took over that package.
09:12 < McManiaC> mightybyte: its kinda tricky
09:12 < fxr> Lemmih: okay thanks, I'll send a mail to him.
09:12 < McManiaC> most of the time its easier to just use a "Types.hs" or similar
09:12 < mightybyte> Yeah
09:13 < McManiaC> but of course
09:13 < McManiaC> module Foo where
09:13 < McManiaC> import Foo
09:13 < McManiaC> will always give you an error :o)
09:13 < mightybyte> Heh
09:15 < fxr> sent.
09:59 < McManiaC> is there a way I can *merge* two datas in one migration? :D
10:01 < mightybyte> McManiaC: Example?
10:02 < McManiaC> module Old where [...] newtype F = F { foo :: String }; newtype B = B { bar :: String } [...] -> module New where [...] data FooBar = FooBar String String
10:04 < mightybyte> I don't think a normal migration would do it.
10:05 < McManiaC> hmm
10:05 < McManiaC> is it possible to *delete* states?
10:06 < mightybyte> I think it's similar to the situation I saw stepcut talking about recently where there is a standalone "migration" program that reads one state and writes another one.
10:07 < mightybyte> Migrations handle anything representable by migrate :: Old -> New
10:07 < McManiaC> yeh
10:07 < mightybyte> ...which does have the ability to express deletion
10:08 < McManiaC> () ?
10:09 < mightybyte> Well, you can keep working up the chain.
10:10 < mightybyte> At some point you will get to the enclosing data...Foo a b c...which can then be migrated to NewFoo a c
10:19 < stepcut> McManiaC: did you get migration working?
10:19 < McManiaC> yup
10:20 < stepcut> McManiaC: why do you need to force a line break?
10:22 < McManiaC> if you compare http://npaste.de/40/ to http://npaste.de/40/hs you will see there is no empty line at the top of the plain text paste
10:23 < McManiaC> and it would be nice to have clickable line numbers, but I cant seem to get <a href...> tags into that pre tag
10:23 < McManiaC> ^^
10:28 < McManiaC> <pre><% "\n" ++ text %></pre>
10:28 < McManiaC> ^^
10:30 < McManiaC> something like this: http://npaste.de/41/ will result in: www.n-sch.de/clickable.png
10:30 < McManiaC> and I can't add a <br /> or something since this will break the EmbededAsChild-rule
10:33 < McManiaC> I guess adding a "\n" to the line numbers is the easiest solution
10:34 < McManiaC> but an \n *after* the a tag would be prettier :)
10:38 < McManiaC> http://npaste.de/42/#n147 :)
10:42 < stepcut> the plain-text and haskell versions look exactly the same to me...
10:43 < McManiaC> i just uploaded a patch ;)
10:43 < stepcut> ah
11:57 < Lemmih> patch-tag.com is down?
12:03 < stepcut> Lemmih: perhaps temporarily. It seems up now ?
12:16 < Lemmih> stepcut: Ah, indeed.
14:27 < McManiaC> noch 2,5 gb
14:27 < McManiaC> ^^
14:27 < McManiaC> wrong chan
14:27 < McManiaC> :P
15:23 < McManiaC> hmmm
15:24 < McManiaC> what header contains the IP adress of a user? If I do something like "askRq >>= ok . toResponse . show" it lists up as "rqPeer", but a getHeaderM "rqPeer" will always give me Nothing
15:24 < stepcut> :-/
15:30 < stepcut> Host ?
15:31 < stepcut> getHeaderM "host"
15:31 < McManiaC> host is like "localhost" oder "foo.com"
15:32 < McManiaC> askRq >>= ok . toResponse . show . fst . rqPeer
15:32 < McManiaC> ^^
15:32 < stepcut> oh wait
15:34 < stepcut> it does not come from any header
15:34 < McManiaC> okay
16:10 < h_buildbot> Build for ghc-6.8.3 failed. Check http://buildbot.happstack.com/ for details.
16:12 < h_buildbot> Build for ghc-6.10.2 OK. Test suite ran. 14/89 test cases failed. Check http://buildbot.happstack.com/ for details.
16:13 < h_buildbot> Build for ghc-6.12.1rc1 failed. Check http://buildbot.happstack.com/ for details.
16:15 < h_buildbot> Build for ghc-6.8.3 failed. Check http://buildbot.happstack.com/ for details.
16:17 < h_buildbot> Build for ghc-6.10.2 OK. Test suite ran. 14/89 test cases failed. Check http://buildbot.happstack.com/ for details.
16:18 < h_buildbot> Build for ghc-6.12.1rc1 failed. Check http://buildbot.happstack.com/ for details.
16:28 < stepcut> ok. I think we just need working sendfile support for 6.12 and 6.8 now. 6.8 is easy --  we just change the build depends on base to allow base 3. 6.12 requires more work, because they changed the IO system. Though, not much... I have a patch that fixes sendfile for 6.12, but breaks it for 6.10 and 6.8 :(
16:44 < fxr> isn't it possible to declare if ghc == 6.8.* then sendfile 0.5 else ...?
16:44 < fxr> stepcut: me too patched sendfile for 6.12 but got no response from the author
16:47 < stepcut> fxr: actually that *is* the patch
16:47 < McManiaC> hmmm
16:47 < stepcut> fxr: if you can add some #ifdefs so that it works on 6.10 too I can apply it
16:47 < McManiaC> how do I run a Update Foo () from a Happstack.Util.Cron job?
16:48 < fxr> stepcut: well I couldn't even communicate with the author
16:48 < stepcut> fxr: meeting, ttyl
16:49 < fxr> stepcut: the problem is that the api should change between major releases of ghc
16:49 < fxr> since there's no way to get a handler's fd on 6.12
16:50 < stepcut> fxr: right, there is where the CCP macros come in..
16:51 < fxr> stepcut: also there is a missing close in sendfile'
16:51 < stepcut> fxr: ah
16:51 < stepcut> fxr: anyway, I can get commit access to sendfile if I don't already have it
16:51 < fxr> stepcut: it would be great
16:52 < stepcut> fxr: mae sent me your patch, it's just been backlogged until now
16:52 < stepcut> fxr: in part because neither of us have 6.12 installed yet :) And his wife just had a baby
16:52 < fxr> oh lovely :)
16:55 < fxr> stepcut: otoh, I'm trying to get in contact with fastcgi maintainer to fix runFastCGIConcurrent' bug.
16:55 < McManiaC> stepcut: is there something like Happstack.Util.Cron for state functions ( Update Foo () )
16:55 < McManiaC> ?
16:55 < stepcut> McManiaC: can't you just call update/query?
16:55 < stepcut> metting, bbl
16:56 < fxr> McManiaC: do you need something like maintainSessions?
16:56 < McManiaC> ?
16:56 < fxr> McManiaC: http://npaste.de/45/
16:56 < McManiaC> stepcut is probably right again... a update/query would be easier & more relyable ^^
16:57 < fxr> use it like: http://npaste.de/46/
16:57 < fxr> yes it's an update also.
16:58 < fxr> but runs every 1 hour for example.
--- Log closed Tue Nov 17 00:00:54 2009