--- Log opened Fri Feb 20 00:00:12 2009
--- Day changed Fri Feb 20 2009
00:00 < thomashartman1> anyone got advice for happs / happstack namespace overlap? http://hpaste.org/fastcgi/hpaste.fcgi/view?id=1560#a1560
00:01 < thomashartman1> is the sanest thing to do to hide happs when using happstack? or is it common to work with both exposed?
00:02 < mae> thomashartman1: might just wanna hold out for 0.2
00:02 < mae> march 4 is release date :)
00:03 < mae> but uhm, yeah you have to hide happs
00:03 < mae> if you wanna
00:04 < Saizan> thomashartman1: alternatively you can :set -package happstack-server-0.1
00:11 < mae> gah
00:16 < thomashartman1> bah
00:40 < mae> dsrogers: fyi i am working on the ipv6 problem, but have to make it build on non-ipv6 places first.
00:40 < dsrogers> thanks matt.
00:41 < dsrogers> I'm working on making this improved cookie parser rfc complient and adding some easier to use functions.
00:41 < dsrogers> including ones that don't throw an ISE when cookie parsing fails.
00:46 < dsrogers> .
00:51 < mae> Saizan: can you help with this one? I don't understand why this does not compile:
00:51 < mae> http://moonpatio.com:8080/fastcgi/hpaste.fcgi/view?id=1487#a1488
00:52 < mae> replace 24:8 with 37:8 (line)
00:52 < Saizan> mae: you miss a "do" or an "in"
00:52 < mae> : \
00:53 < mae> return?
00:54 < Saizan> inside the [| .. |] i mean
00:54 < mae> Saizan: if that were the problem, wouldn't i get a type error? I mean i think this is something with layout
00:54 < mae> hmm
00:54 < mae> Saizan: but these are pure expressions
00:56 < mae> OH DUH
00:56 < mae> i get it
00:56 < mae> its not in a do block
00:56 < mae> and so i have to use in or where
00:56 < Saizan> the problem is that you need to have a proper expression inside [| .. |]
00:56 < mae> so I can drop let peer
00:57 < mae> and put that outside?
00:57 < Saizan> and "let x = .. in" isn't onw
00:57 < Saizan> yes, exactly
01:34 < mae> ok
01:34 < mae> pushed ipv6 patch
01:34 < mae> please try it dsrogers
01:34 < mae> i'm testing a windows build now
01:34 < dsrogers> ok
01:34 < dsrogers> I'm not buildable at the moment.
01:35 < mae> k
01:35 < mae> no worries, at your leisure
01:35 < mae> :)
01:35 < dsrogers> ok.
01:37 < h_buildbot> Build for ghc-6.8.3 failed. Check http://buildbot.happstack.com/ for details.
01:38 < mae> hm
01:38 < mae> didn't build on windows
01:38 < mae> supportsIPv6 didn't work
01:39 < mae> Saizan: any idea why this would not be working? I will list the relevant files:
01:39 < mae> http://patch-tag.com/publicrepos/happstack/happstack-server/src/Happstack/Server/HTTP/SocketTH.hs
01:39 < mae> http://patch-tag.com/publicrepos/happstack/happstack-server/src/Happstack/Server/HTTP/Socket.hs
01:39 < mae> here is the compile error:
01:39 < h_buildbot> Build for ghc-6.10.1 failed. Check http://buildbot.happstack.com/ for details.
01:41 < mae> http://moonpatio.com:8080/fastcgi/hpaste.fcgi/view?id=1489
01:43 < mae> buildbot smoking the crack gain
01:43 < mae>         magic number mismatch: old/corrupt interface file?
01:44 < mae> can you define an ifdef in haskell? :)
01:45 < mae> Saizan_:
01:45 < mae>         magic number mismatch: old/corrupt interface file?
01:45 < mae> <mae> hm
01:45 < mae>  didn't build on windows
01:45 < mae>  supportsIPv6 didn't work
01:45 < mae>  Saizan: any idea why this would not be working? I will list the relevant files:
01:45 < mae>  http://patch-tag.com/publicrepos/happstack/happstack-server/src/Happstack/Server/HTTP/SocketTH.hs
01:45 < mae>  http://patch-tag.com/publicrepos/happstack/happstack-server/src/Happstack/Server/HTTP/Socket.hs
01:45 < mae>  here is the compile error:
01:45 < mae> <h_buildbot> Build for ghc-6.10.1 failed. Check http://buildbot.happstack.com/ for details.
01:45 < mae> <mae> http://moonpatio.com:8080/fastcgi/hpaste.fcgi/view?id=1489
01:45 < mae> I think it is because it reify's the expression even if it is not using it
01:45 < mae> how do we stop that?
01:45 < dsrogers> rfc compliant cookie parser ftw.
01:45 < Saizan_> mae: heh, yeah, sorry
01:45 < dsrogers> with the cookie fix in it.
01:46 < Saizan_> mae: the problem is that quoting checks if the things are in scope
01:46 < Saizan_> mae: we need to construct the expressions by hand
01:47 < dsrogers> but ... cookie parsing failure shouldn't break the entire app.
01:47 < dsrogers> so I'm going to fix that too.
01:48 < mae> Saizan_:  bummer, that will be messy
01:48 < mae> or will it? :)
01:49 < mae> Saizan_: can you patch or pastebin a fix?
01:49 < Saizan_> mae: i can
01:50 < mae> Saizan_: will you? :)
01:50 < mae> (are we having the can or will discussion? )
01:50 < Saizan_> i'm in sleep deprivation mode so my talking skills are very limited
01:51 < Saizan_> i meant that i'm going to fix it, anyhow ;)
01:51 < mae> ok
01:51 < mae> hope its not too hard
01:51 < mae> hmm, this would probably be cleaner if you could do an ifdef in TH
01:52 < mae> but not sure if ifdefs show up in AST
01:52 < mae> (thats a pass before right?)
01:52 < Saizan_> (right)
01:55 < dsrogers> when is url decoding done on URLs or headers in happstack?
01:59 < mae> good Q
02:08 < mae> h_buildbot:
02:08 < mae> h_buildbot: help
02:08 < h_buildbot> Use: build, status, pause, resume, ping
02:08 < mae> h_buildbot: status
02:08 < h_buildbot> Idle.
02:08 < mae> h_buildbot: build ghc-6.8.3
02:08 < h_buildbot> Build for ghc-6.8.3 started. If one was running, no new one is started.
02:10 < h_buildbot> Build for ghc-6.8.3 failed. Check http://buildbot.happstack.com/ for details.
02:13 < mae> stepcut: what do you think about this issue: http://code.google.com/p/happstack/issues/detail?id=60&q=label:0.2 ?
02:16 < mae> this one is kind of a bitch (unit tests for multimaster replication)
02:16 < mae> http://code.google.com/p/happstack/issues/detail?id=38&q=label:0.2
02:16 < mae> we can't really use quickcheck because the tests will involve 'the outside world'
02:23 < mae> afk
02:33 < mae> Saizan_: I'm gonna hit the hay, if you can submit a patch for that, I would be much obliged (it doesn't have to be today). I will test the windows build when that happens.
02:33 < mae> night all
02:34 < dsrogers> I'm going to bed too.
02:34 < dsrogers> Though I have a RFC compliant cookie parser that fixes that bug.
02:35 < dsrogers> and I fixed a bug in the gzip thingy too.
02:35 < Saizan_> mae: just pushed
02:35 < dsrogers> I need tests for both of these, then I can test and commit.
02:35 < dsrogers> 'night all
02:35 < Saizan_> if someone can test it on windows..
02:35 < mae> i'll test it
02:36 < mae> k
02:37 < h_buildbot> Build for ghc-6.8.3 failed. Check http://buildbot.happstack.com/ for details.
02:37 < mae> yep
02:37 < mae> it builds on windows
02:37 < mae> gj :D
02:38 < Saizan_> thanks :)
02:39 < h_buildbot> Build for ghc-6.10.1 failed. Check http://buildbot.happstack.com/ for details.
02:46 < h_buildbot> Build for ghc-6.8.3 failed. Check http://buildbot.happstack.com/ for details.
02:48 < h_buildbot> Build for ghc-6.10.1 failed. Check http://buildbot.happstack.com/ for details.
05:27 < cognominal> happstack server has an apparently nice http client package, but I can't figure how to use it : :m HAppS.Server.HTTPClient.HTTP
05:27 < cognominal> Could not find module `HAppS.Server.HTTPClient.HTTP':
05:27 < cognominal>   it is hidden (in package happstack-server-0.1)
05:28 < cognominal> hum, may be should I use the main package instead if it reexports the names
05:39 < koeien> mae: the ipv6 support fails to compile on the buildbot. any package i should install ?
10:11 < oshyshko> How to tell "fileServe" to send "Pragma: no-cache" header, so files will not be cached by browser?
10:19 < stepcut> oshyshko: try, addHeaderM "Pragma" "no-cache" >> fileServe [] "whee"
10:46 < stepcut> Saizan: worked!
10:46 < oshyshko> stepcut: I use HAppS installed via cabal. And I don't have addHeaderM, but addHeader only. Which module I have to import?
10:47 < stepcut> oshyshko: oh, addHeaderM is new..
10:47  * stepcut ponders
11:57 < stepcut> hrm, this ixset migration stuff seems like it will be trouble again the next time IxSet changes
12:01 < HugoDaniel> hello happstackers
12:01 < stepcut> hello
13:24 < mkrogh> dddd
14:20 < mae_work> cognominal: You probably have the HAppS packages installed also, there is most likely a namespace overlap, you need to either hide the HAppS packages during compilation or explicitly tell ghc to use the happstack packages
14:20 < mae_work> koeien: I'm not sure why it fails to build, I need to see the output.
14:20 < mae_work> stepcut: any ideas on how to handle the ixset migration in the future?
14:21 < stepcut> mae_work: maybe
14:21 < stepcut> mae_work: There are two cases to worry about, (1) The IxSet data-type itself changes (2) the name of the IxSet data changes (for example, if it gets moved to Data.IxSet, that counts as a name change)
14:22 < mae_work> koeien: hmm ok so this is the problem right? Loading package happstack-server-0.1.9 ... linking ... ghc: unable to load package `happstack-server-0.1.9'
14:22 < cognominal> yes, I have the HAppS package installed.
14:22 < stepcut> for case (1), I think we just copy Happstack.Data.IxSet to Happstack.Data.IxSet_001 and Happstack.Data.IxSet.Internal to Happstack.Data.IxSet.Internal_000, and use the normal Migrate/Version stuff
14:24 < stepcut> for case 2, we just copy Happstack.Data.IxSet and Internal to, Data.IxSet and Internal, but leave the old modules in the package and provide migration instances
14:24 < cognominal> mae_work, the two packages have modules with the same names, so a happs module is loaded so the error?
14:24 < mae_work> stepcut: koeien i think i know why its broken
14:24 < stepcut> mae_work: when we leave the old modules in the package, they don't have to be exposed, they can just go under other-modules
14:25 < cognominal> with cabal, can I deactivate a package like with the mac port installer?
14:25 < stepcut> mae_work: and, we can also opt to drop support for migration to older versions at some point in the future, if we want
14:26 < mae_work> cognominal: if you are compiling with ghc you just do -hide-package HAppS-Server for instance
14:27 < stepcut> there is also syntax in ghc 6.10 to select the package in the import statement
14:32 < koeien> mae_work: ghc-6.8.3: /home/buildbot/.cabal/lib/happstack-server-0.1.9/ghc-6.8.3/HShappstack-server-0.1.9.o: unknown symbol `__stginit_happstackzmserverzm0zi1zi9_HappstackziServerziHTTPziSocketTH_'
14:33 < mae_work> koeien: yeah i'm working on it
14:36 < h_buildbot> Build for ghc-6.8.3 OK. Test suite build failed. Check http://buildbot.happstack.com/ for details.
14:37 < stepcut> mae_work: I am about to commit a patch that will fix migrations from HAppS.Data.IxSet -> Happstack.Data.IxSet, but will cause data loss for apps that have already switched to Happstack.Data.IxSet
14:37 < stepcut> mae_work: do you think that is a problem? Seems like support 0.1 -> 0.2 migration is more important than 0.2-dev -> 0.2-stable?
14:38 < mae_work> stepcut: um, that doesn't sound very nice.
14:38 < stepcut> mae_work: well, I do not know how a solution that works for both 0.1 -> 0.2 and 0.2-dev -> 0.2-stable
14:38 < mae_work> stepcut: so your saying it will cause data loss because of the version #
14:38 < mae_work> ?
14:39 < stepcut> it will cause data loss, because the patch moves the IxSet data type declaration into, Happstack.Data.IxSet.Internal
14:39 < mae_work> ok...
14:39 < stepcut> when the checkpoint tries to reload, it will look for it in, Happstack.Data.IxSet and not find it
14:39 < mae_work> so this affects people who have been building off of head (as opposed to 0.1) right?
14:39 < stepcut> so, it just ignores it, and throughs out the data
14:40 < stepcut> right, it fixes it for 0.1 people and breaks it for current 0.2 people. Though, hopefully this won't happen again in the future
14:40 < mae_work> stepcut: so by moving it to internal this will prevent it in the future?
14:40 < stepcut> IxSet is particularily tricky in this regard
14:40 < mae_work> because we can control the data migrations?
14:41 < stepcut> moving 'data IxSet = ...' into Internal was the only way to support migrations from HAppS.Data.IxSet with out causing a circular dependency or worse
14:42 < mae_work> stepcut: ok, I am fine with you submitting that patch, but you need to add release notes which explain the caveats
14:42 < mae_work> and we really need to figure out a decent way to handle that problem in general in the future
14:43 < h_buildbot> Build for ghc-6.10.1 OK. Test suite ran. 15/69 test cases failed. Check http://buildbot.happstack.com/ for details.
14:43 < mae_work> because api changes happen, and the current impl of state is kind of brittle in this regards.
14:43 < mae_work> stepcut: release notes go in RELEASE_NOTES :)
14:44 < stepcut> mae_work: I have working on an in-depth guide & policy for dealing with migration, though I have a ways to go
14:45 < stepcut> mae_work: so far, I have dissected the format of checkpoint files
14:45 < stepcut> mae_work: I am sort of understand exactly what happens when a checkpoint file is loaded from the disk
14:46 < stepcut> mae_work: I do not yet have any idea how upgrading your cluster one machine at a time is going to work, but supposedly that is possible
14:46 < mae_work> stepcut: an in depth guide sounds great :) but make sure you still summarize the important points in the file RELEASE_NOTES so people don't get bit, I'll also make a mention when i put up the blog post up for the 0.2 release
14:47 < stepcut> mae_work: yes, those to things are unrelated
14:47 < mae_work> stepcut: allright then, I am glad that someone is delving into the state system more
14:48 < stepcut> mae_work: the in-depth guide is for the "we need to figure out a decent way to hand that problem in the general in the future" part
14:48 < mae_work> stepcut: I am wondering if we can simplify some of -state using typeclasses instead of TH for some parts
14:48 < stepcut> mae_work: the TH is creating the type classes...
14:48 < stepcut> well type class instances
14:49 < mae_work> stepcut: regarding policy, we should should provide an example migration path in the example app, and a recommended file structure for organizing this
14:49 < mae_work> i.e. DataModule001.hs
14:49 < mae_work> DataModule002.hs
14:50 < mae_work> is one possibility
14:50 < stepcut> mae_work: yes. I have some of that outlined at: http://nhlab.blogspot.com/2008/12/data-migration-with-happs-data.html
14:50 < mae_work> stepcut: yep, good article :)
14:50 < stepcut> mae_work: a key piece is setting up the system so that when someone edits DataModule, they know if they need to add new migration instances or not
14:51 < mae_work> stepcut: right
14:51 < stepcut> mae_work: unfortunately, that article does not include the additional issues that happstack-state introduces
14:56 < Saizan> we might change -state so it doesn't save (typeOf x) but something more robust
14:57 < Saizan> though the same exact declaration in different modules give rise to different types.. (like IxSet)
14:59 < stepcut> Saizan: have you though about what will happen next time IxSet changes and we need another migration instance?
15:00 < stepcut> Saizan: also, this patch will cause data loss for existing 0.2 users, since IxSet moved into Internal. But I don't see a good way around that, do you?
15:06 < Saizan> well, we could leave the definition for the new IxSet in Happstack.Data.IxSet and export the Version/Migrate instances from somewhere else
15:08 < Saizan> next time i think we can just define the new type in .Internal1
15:21 < stepcut> Saizan: I was thinking we would copy the existing Internal to Internal1, and then update Internal. (And also copy .IxSet to .IxSet1)
15:26 < Saizan> but Interal is where the IxSet type is defined, if you rename it the TypeRep will change no? isn't that the same problem with HAppS vs. Happstack?
15:34 < Saizan> i start to think that migrations shouldn't be handled at the datatype level, but lower
15:36 < Saizan> on some kind of AST for binary representations
15:51 < stepcut> Saizan: yes, the typerep of the version in the renamed file will change. But the version in the new IxSet will have the same name, but be one version number higher, and will extend to the IxSet1 version.
15:51 < stepcut> so when checkpoint looks up the Happstack.Data.IxSet it will find a match and do the migration
15:52 < Saizan> ah, the TypeRep only needs to match with the most recent version?
15:52  * Saizan is a bit confused now
15:52 < stepcut> Saizan: It depends on what level your are talking about
15:53 < stepcut> Saizan: normally the names of the type and the constructors are not encoded in the serialized data at all
15:54 < Saizan> "normally" you mean for events?
15:54 < stepcut> Saizan: as long as two data types have the same shape you can serialize data as one type and deserialize it as another. Meaning that simply renaming a data type is no big deal.
15:54 < stepcut> Saizan: that assumes you are just using Happstack.Data.
15:55 < stepcut> Saizan: when you bring happstack-state in to the picture, you find that in the checkpoint files, the names of the Components *are* stored in the checkpoint file. And that is why IxSet migration can be problem.
15:55 < stepcut> Saizan: I have the Happstack.Data only serialization stuff explained here: http://nhlab.blogspot.com/2008/12/data-migration-with-happs-data.html
15:56 < stepcut> Saizan: I know, but have not yet documented the checkpoint file format yet
15:56 < stepcut> Saizan: though the checkpoint file format is really very simple, it is just the name of the component (as returned by typeOf) followed by a serialized version of its value
15:58 < stepcut> Saizan: basically, type Checkpoint = [(ComponentName, L.ByteString)]. When you restore a checkpoint, it does a, lookup componentName, for each component in the app and sees if there is a saved value in the checkpoint file, if not, it just uses the initialValue
15:59 < Saizan> ah, so we will trick happstack-state in thinking the types match, and then the Serialization/Migration mechanism will see the version and be able to recognize the right one?
15:59 < stepcut> yeah
15:59 < stepcut> though, checkpoint has its own magic as well
15:59 < Saizan> it also tries older versions?
16:00 < stepcut> for a given component, it walks the version chain, and finds all the names that the type has had, and will try looking for any of those names
16:01 < Saizan> ok
16:02 < stepcut> so in the current case, when trying to load the component, (Happstack.Data.IxSet.Internal.IxSet Contact), it walks to chain and finds that it could also be called, (HAppS.Data.IxSet Contact). It then interates over the list of possible names and tries looking each one up in the checkpoint file until it finds a match. After it finds a match it deserializes the match and performs any require migrations to bring the deserialized v
16:02 < stepcut> to the current type.
16:02 < stepcut> I gotta run, bbl.
16:03 < stepcut> oh, so the advantage of renaming IxSet to IxSet001, and updating IxSet, instead of creating a new IxSet001, is that you don't have to update your apps to import the type from the new location...
16:03 < dsrogers> do I have to export a symbol from a module in order to write a test against that piece?
16:04 < Saizan> yes
17:15 < thetallgu1> So it seems that the current version of happstack breaks haddock?
17:16 < thetallgu1> Or is there a newer version of haddock that works?
17:16 < dsrogers> you need ghc/haddock head.
17:16 < dsrogers> it's a known bug in haddock
17:16 < thetallgu1> ah, good.
17:16 < dsrogers> Saizan managed to build the documentation.
17:16 < thetallgu1> do you have a reference for the bug?
17:17 < dsrogers> Saizan does.
17:17 < dsrogers> not sure he'll be awake right now though
17:17 < dsrogers> (she'll?) *shrug*
17:17 < Saizan__> (he)
17:17 < thetallgu1> history gave it to me.
17:19 < dsrogers> (noted)
17:34 < thetallgu1> anyone else having trouble pulling patches from patch-tag?
17:36 < dsrogers> yes
17:36 < dsrogers> just try a few times
17:37 < thetallgu1> okay.
22:14 < stepcut> grr
22:56 < thomashartman1> hey mae told me there were some complaints of pushing to happstack. I just tested this myself and seems to work.
23:02 < thomashartman1> there was a period today where I was making the (hopefully) last step to converting all patch-tag users to a jail, eliminating the possibility of ssh hanky panky
23:02 < thomashartman1> really sorry if this caused anyone inconvenience. hopefully things will be much smoother going forward, if not commplain on the googlegroup!
23:07 < Axman6> thomashartman1: you responsible for patch-tag?
23:20 < dsrogers> how do I run the happstack-server tests?
23:20 < stepcut> dsrogers: cabal configure -f tests
23:20 < stepcut> cabal build
23:21 < stepcut> that should produce a binary, happstack-server-tests
23:21 < stepcut> or, just go into the tests directory and run, make local
23:21 < stepcut> will which run the tests against the working directory
23:32 < mae> Axman6: thomas and I
23:32 < mae> is anyone still having issues?
23:32 < Axman6> ah right, well i stuck my AVar stuff on there the other day :)
23:32 < mae> neat :)
23:33 < Axman6> seems quite nice... now i need to learn how to use darcs properly
23:34 < mae> takes a little time, but its pretty user friendly!
23:44 < Axman6> yeah. i just need to write some more code to do it really
--- Log closed Sat Feb 21 00:00:22 2009