--- Log opened Wed Dec 30 00:00:03 2009
16:10 < McManiaC> mightybyte: i stole your salted hash implementation from your Auth module :D
16:11 < mightybyte> Expect a takedown notice shortly ;)
16:11 < McManiaC> why?
16:11 < mightybyte> Just kidding
16:11 < McManiaC> ^^
16:11 < mightybyte> Glad it was useful.
16:12 < mightybyte> Is there any reason you weren't able to just use the Auth module as-is?
16:12 < McManiaC> it would be too static for me
16:12 < mightybyte> Hmmm, in what way?
16:13 < McManiaC> i want more flexibility on what my users "are"
16:14 < mightybyte> You want to associate more information than just uid and username?
16:14 < McManiaC> + i already got most if it implemented
16:14 < McManiaC> ;)
16:14 < McManiaC> yeh kinda
16:15 < mightybyte> You could just create another "table" associating uids with whatever information you want.
16:19 < mightybyte> That's typically what I do in my apps.
16:19 < McManiaC>     No instance for (Data.Generics.SYB.WithClass.Basics.Data
16:19 < McManiaC>                        DefaultD SaltedHash)
16:19 < McManiaC> hmmmm
16:19 < McManiaC> mightybyte: yeh, but my whole login, registration etc part is slightly different
16:21 < mightybyte> Well, the only reason I ask is that I think it should be possible for the vast majority of applications to use a pre-built module for auth, and not have to reinvent things.
16:22 < mightybyte> I certainly don't claim that my module is at that point, but I like to understand what types of needs aren't being met.
16:23 < mightybyte> Do you have "instance Version" and "deriveSerialize"?
16:24 < stepcut> making auth not suck is something else that has been suggested for 0.5
16:24 < mightybyte> ...as well as Typeable and Data instances.
16:24 < stepcut> the new hackage server has some useful code for that as well...
16:24 < mightybyte> Yeah, I looked at that awhile back.
16:24 < mightybyte> Wait, for auth or for deriving typeable and data?
16:25 < stepcut> the new hackage server has some useful auth code...
16:25 < mightybyte> Code that wasn't there before?
16:25 < stepcut> as does happstack-extra -- and the much of the code is nearly identical... indicating it should probably be in happstack itself ;)
16:26 < stepcut> before what?
16:26 < mightybyte> Never mind, I was misreading what you wrote.  Got it now.
16:26 < stepcut> odd, I am having problems accessing facebook from safari,but not from firefox
16:27 < mightybyte> I'd certainly be willing to help integrate auth into Happstack.
16:27 < McManiaC> mightybyte: yes i think so...
16:28 < McManiaC> http://npaste.de/9j/
16:30 < mightybyte> Weird.
16:30 < mightybyte> Are you running Happstack 0.4?
16:31 < McManiaC> yes
16:31 < McManiaC> latest darcs build
16:31 < mightybyte> I haven't compiled -auth against 0.4 yet.
16:31 < McManiaC> hmmm
16:31 < mightybyte> Don't know why that would be a problem though.
16:31 < McManiaC> =(
16:32 < mightybyte> So what would the auth package have to have to get you to use it?
16:35 < McManiaC> hmmmm
16:36 < McManiaC> I'm even considering it :O
16:36 < McManiaC> ^^
16:36 < McManiaC> as long as it compiles... ;)
16:36 < mightybyte> Heh
16:38 < McManiaC> + I think I'll have to use H.D.IxSet
16:38 < McManiaC> :S
16:38 < mightybyte> I guess I happstack-auth should really be in hackage.
16:38 < mightybyte> Although there's no point if we integrate it with 0.5
16:38 < McManiaC> hurrah for pastedb version 6
16:39 < McManiaC> ^^
16:40 < mightybyte> What's wrong with IxSet?
16:41 < McManiaC> nothing
16:41 < McManiaC> its just another state change
16:41 < McManiaC> ^^
16:41 < mightybyte> Oh, heh.
16:41 < mightybyte> How many users does npaste.de get?
16:43 < McManiaC> no idea
16:43 < McManiaC> ^^
16:44 < McManiaC> currently ~ 700 pastes
16:45 < McManiaC> entries @< (Updated t1) @= (Author "john@doe.com")
16:45 < McManiaC> thats kinda cool
16:45 < McManiaC> :)
16:46 < mightybyte> Yeah
16:48 < McManiaC> sounds just like what I need
16:48 < McManiaC> :D
16:49 < McManiaC> what is calcs?
16:50 < mightybyte> It allows calculated values to be used as indices.
16:51 < McManiaC> any example somewhere?
16:52 < McManiaC> ah there is one, nevermind
16:58 < McManiaC> what type is "entries" then?
16:58 < McManiaC> Entry?
16:58 < McManiaC> IxSet ?
16:58 < McManiaC> IxSet Entry ?
17:04 < McManiaC> hmmm could someone paste such a IxSet being used in a state module?
17:04 < mightybyte> Sure
17:04 < mightybyte> One moment
17:05 < McManiaC> k
17:05 < McManiaC> th
17:05 < McManiaC> x
17:05 < mightybyte> Auth has an example
17:06 < McManiaC> with inferIxSet?
17:07 < mightybyte> Yeah
17:07 < mightybyte> That TH code creates the type UserDB
17:07 < mightybyte> which can then be used anywhere in a state structure.
17:10 < McManiaC> hmmmmmmmmmmmm
17:12 < McManiaC> how would you migrate such an IxSet if you ever have to change it? ^^
17:14 < mightybyte> Migrations that don't affect the structure of the IxSet are just like normal migrations.
17:14 < mightybyte> Migrations that affect the structure can be done as a migration of the enclosing type.
17:15 < McManiaC> migrate UserDB where...?
17:16 < stepcut> McManiaC: no, you just add migration types for the underlying types and IxSet migrates automatically
17:16 < stepcut> McManiaC: aka, for, IxSet MyType, you just need instance Migrate MyType here
17:16 < stepcut> where, type MyTypeDB = IxSet MyType
17:16 < McManiaC> hmmmm
17:16 < McManiaC> hmmmmmmmmm
17:17 < stepcut> majick!
17:17 < McManiaC> hmmmmmmmmmmmmmmmmmmmmmmmmmmm
17:17 < McManiaC> ^^
17:18 < McManiaC> but you need all those newtype definitions since you need a type to be able to index MyType?
17:18 < mightybyte> McManiaC: That's because IxSet is serialized as [Entry].
17:19 < stepcut> McManiaC: yeah.. I am working on an alternative for IxSet that doesn't require all those newtypes, but haven't had much time to work on it
17:19 < McManiaC> okay
17:19 < McManiaC> $(inferIxSet "PasteDB" 'noCalcs [''ID])
17:19 < McManiaC>     Couldn't match expected type `Language.Haskell.TH.Syntax.Name'
17:19 < McManiaC>            against inferred type `[a]'
17:19 < McManiaC> ?
17:19 < McManiaC> :O
17:20 < stepcut> you are missing an argument
17:20 < stepcut> $(inferIxSet "PasteDB" {type to store in the IxSet} 'noClacs [''ID])
17:20 < McManiaC> aaah wait
17:20 < McManiaC> kay
17:23 < McManiaC> this gonna get ugl
17:23 < McManiaC> y
17:23 < McManiaC> :D
17:24 < stepcut> :(
17:25 < stepcut> mightybyte: how do I clone the remove-xml-monad branch.. git is too hard :)
17:27 < mightybyte> clone the whole repository with the command github gives you.
17:27 < mightybyte> Then...
17:28 < mightybyte> git checkout -b remove-xml-monad origin/remove-xml-monad
17:29 < mightybyte> That checks out the remote branch and creates a local branch of the same name for it.
17:30 < stepcut> ok
17:31 < stepcut> sweet
17:32 < mightybyte> My recommendation would be to create a github account and fork the repository.
17:32 < stepcut> oh ?
17:32 < mightybyte> Then you'll be able to commit your changes to github and when you're done you can issue a pull request to me.
17:32 < mightybyte> Then I can pull the changes directly into the main repo.
17:33 < stepcut> ok
17:33 < mightybyte> But if you don't want to go to that trouble you can just give me a patch.
17:33 < stepcut> git send ?
17:34 < mightybyte> Not sure
17:34 < mightybyte> I've never used patches.
17:35 < McManiaC> stepcut: do the fields of my data have to be newtype or just any state type?
17:35 < stepcut> http://github.com/stepcut/formlets
17:35 < stepcut> McManiaC: neither...
17:36 < stepcut> McManiaC: well, perhaps any state type
17:36 < stepcut> McManiaC: the newtypes in IxSet are usually needed because the indices are 'type indexed' so you need a way to differentiate between different values that would normally be the same type (such as fields that are all String)
17:37 < stepcut> but you don't actually have to do that in the type itself
17:37 < stepcut> if you had, data Foo = Foo { a :: String, b :: String }, and you wanted an IxSet Foo, with indices for 'a' and 'b'
17:37 < stepcut> you could do:
17:38 < McManiaC> but I can also use a "data Foo = Foo | Bar" instead of "data Foo = Foo | Bar; newtype XFoo = XFoo Foo" ?
17:38 < stepcut> sure
17:38 < McManiaC> continue please :)
17:39 < stepcut> newtype A = A a ; newtype B = B b ; calcs :: Foo -> (A, B) ; calcs (Foo a b) = (A a, B b) ; $(inferIxSet "FooDB" ''Foo 'calcs [''A, ''B])
17:39 < McManiaC> hmmmmmmmmmmm
17:39 < stepcut> (and use the existing, data Foo = Foo { a :: String, b :: String }, instead of data Foo = Foo { a :: A, b :: B })
17:40 < McManiaC> I see
17:41 < McManiaC> so calcs works like a convertation
17:41 < aavogt> stepcut: do you mean   newtype A = A String?
17:42 < stepcut> aavogt: yes
17:42 < stepcut> aavogt: sorry about that
17:42 < McManiaC> stepcut: in that way, a single migration of Foo would be enough when in need of a migration?
17:43 < stepcut> that's why I use a type checked language :)
17:43 < McManiaC> hehe
17:43 < stepcut> McManiaC: depends on your situation
17:43 < McManiaC> if I put those newtype in a seperate file of course
17:44 < stepcut> what do you mean by 'single migration' ?
17:44 < McManiaC> well I'm kinda scared of having to migrate all those newtypes
17:45 < McManiaC> everytime I change something of Foo
17:45 < stepcut> the newtypes that are 'inside' Foo would not need to be migrated
17:45 < stepcut> only newtypes which contain Foo..
17:46 < stepcut> so, it may save you some migrations. But not in the example I outlined.
17:46 < stepcut> if you had, newtype XFoo = XFoo Foo, then it might save you a migration
17:47 < stepcut> though I am not positive that would always require an explicit migration instance.. depends on how you organize your state files I think
17:48 < McManiaC> hmmm
17:48 < McManiaC> lets say
17:48 < McManiaC> I have two files... one with the Foo data in it and one with the newtype A and newtype B
17:48 < McManiaC> what will I have to do if I add a c :: String to Foo?
17:49 < McManiaC> migrate A and B too or only Foo?
17:49 < stepcut> what does the declaration for newtype A look like?
17:49 < McManiaC> the same as your example above
17:49 < stepcut> newtype A = A String?
17:50 < McManiaC> ja
17:50 < McManiaC> *yes
17:50 < McManiaC> ^^
17:50 < stepcut> even if all the types are in one file, you just need, instance Migrate Foo where migrate (Old.Foo a b) = (Foo a b (defaultValue :: String))
17:51 < McManiaC> hmmm okay
17:51 < McManiaC> and if I had a newtype Bar = Bar Foo in some other state file... this would get migrated too?
17:52 < mightybyte> McManiaC: If your types are well-separated into separate modules, then IxSet migration is pretty easy in practice.
17:52 < McManiaC> ok
17:52 < mightybyte> McManiaC: You only have to migrate the types that are changing.
17:52 < McManiaC> ok cool
17:52 < McManiaC> and where do I put the inferIxSet?
17:53 < McManiaC> or is it best to do this instance stuff by hand regarding migrations?
17:53 < stepcut> Bar would probably be migrated automatically.
17:53 < mightybyte> I usually put it either in the file that contains Entry, or the file that contains the enclosing type.
17:54 < McManiaC> ok
17:54 < McManiaC> but every newtype needs a version and serialize thingy?
17:54 < McManiaC> ^^
17:54 < stepcut> yes
17:56 < McManiaC> http://npaste.de/9l/
17:56 < McManiaC> so this would be ok?
17:56 < stepcut> mightybyte: why does 'plug' require (Monoid xml), when the function does not actually require that ?
17:56 < McManiaC> migration has to be done of course
17:57 < stepcut> McManiaC: I believe so
17:57 < stepcut> well..
17:57 < stepcut> you will run into an issue there I believ
17:58 < stepcut> the newtypes in PasteEntry, such as PUser, are different from the newtypes of similar name in PasteEntry5
17:58 < stepcut> aka, PasteEntry5.PUser /= PasteEntry.PUser
17:58 < stepcut> so you would have to migrate those
17:59 < McManiaC> yeh, but only once
17:59 < stepcut> if PasteEntry.PasteEntry used the newtypes from PasteEntry5, then you would not have that problem
17:59 < stepcut> only once?
18:00 < McManiaC> a 6 -> 7 migration wont have that issue, will it?
18:00 < stepcut> depends
18:00 < stepcut> if will PasteEntry7 import the newtypes from PasteEntry6 and use them to define the type PasteEntry7.PasteEntry?
18:01 < stepcut> or will PasteEntry7 look like PasteEntry6 with the newtypes declared locallly?
18:01 < McManiaC> ok, so I'll put the newtypes in a seperate file
18:01 < McManiaC> ^^
18:01 < McManiaC> it should use the same newtypes
18:01 < stepcut> yeah..
18:02 < stepcut> if it uses the newtypes imported from the same file as the old version, you do not need migration. But if you move the newtypes to a different file, then you do need migration.
18:02 < stepcut> that is purely to make the type checker happy
18:03 < stepcut> the migration code itself wouldn't know if the difference if you could actually get it to type check
18:03 < stepcut> I do not really know the best way to handle migrations... it seems more complicated that it should be. And every approach I have tried has one or more major drawbacks
18:04 < McManiaC> yup
18:04 < McManiaC> thats how I keep all my other state files too
18:07 < stepcut> migration in happstack 'works' but it could hopefully be made nicer. Or maybe someone just needs to figure out the right way to use the existing technology and then document it
18:09 < McManiaC> its pretty complicated, jup :S
18:14 < McManiaC> I'm trying to migrate two dependend states at once
18:14 < McManiaC> I hope this works :S
18:14 < stepcut> McManiaC: what could possibly go wrong!
18:14 < McManiaC> ;D
18:14 < McManiaC> nothing!
18:14 < McManiaC> but I'm definitly gonna do a backup before running it :O
18:16 < stepcut> :)
18:17 < McManiaC> Ok, modules loaded:
18:17 < McManiaC> woot
18:17 < McManiaC> ^^
18:18 < stepcut> :)
18:21 < McManiaC>     No instance for (Eq PasteDB)
18:21 < McManiaC>     No instance for (Ord PasteDB)
18:21 < McManiaC> thats the IxSet filetype
18:22 < stepcut> yeah, that is true
18:22 < stepcut> you can't order an IxSet
18:23 < McManiaC> so how do I use this inside my state?
18:24 < McManiaC> http://npaste.de/9m/
18:26 < stepcut> don't derive Eq and Ord for your Paste type
18:27 < stepcut> or define Eq and Ord instances by hand for PasteDB if you must
18:28 < McManiaC> I thought this is necessary
18:28 < McManiaC> okay
18:29 < stepcut> nope
18:30 < McManiaC> Ok, modules loaded:
18:30 < McManiaC> wooot
18:30 < McManiaC> lets test this
18:30 < McManiaC> :O
18:30 < McManiaC> ah damn
18:31 < McManiaC> of course this cannot work with everything else using the old data ^^
18:31 < stepcut> ?
18:31 < McManiaC> all my state functions will have to get "migrated" too ;)
18:31 < McManiaC> to the new IxSet type
18:31 < stepcut> ah, yes that would be true.
18:34 < McManiaC> OK, now I need to understand how this actually works
18:34 < McManiaC> :D
18:35 < McManiaC> and if I add/remove a index field to PasteDB theres no need for migration?
18:36 < stepcut> right
18:36 < McManiaC> cool
18:36 < McManiaC> ok
18:37 < McManiaC> just curious, how efficient is IxSet compared to Data.Map?
18:38 < stepcut> not very
18:39 < stepcut> though, that is never been tested.
18:39 < McManiaC> and compared to regular lists?
18:40 < stepcut> dunno, really depends on the operations you are doing
18:40 < McManiaC> kk
19:04 < stepcut> mightybyte: what is the purpose of FormResult and NotAvailable?
19:10 < stepcut> mightybyte: I believe the purpose is so that things still 'work' even for controls which are not sent at all if they are not activated
19:11 < stepcut> for example, if you have a list of checkboxes, and none are checked, then the 'name' for those checkboxes will not appear in the submitted form data at all, and that caused things to break
19:12 < McManiaC> let seeeee... *hopes*
19:12 < stepcut> our solution was to introduce a new function like, generalInput :: Monad m => (String -> Maybe String -> xml) -> Form xml m (Maybe String)
19:13 < stepcut> which is similar to input' but allows the initial value and return value to be optional
19:13 < mightybyte> stepcut: Yeah, I've had issues with that too.
19:13 < stepcut> you can build input' and optionalInput on top of generalInput, or use generalInput directly..
19:13 < mightybyte> I'm not exactly sure what NotAvailable is for.
19:13 < stepcut> NotAvailable is only used internally..
19:13 < stepcut> is that something Chris added then?
19:15 < mightybyte> Yeah.  It looks like he added that in July.  I'm not sure what the intent was.
19:16 < stepcut> hmm
19:16 < stepcut> I'll have to stare at it for a while and see how it compares to generalInput
19:17 < stepcut> I have another function, generalInputMulti that is needed if you want to do something like a multi-select input box
19:17 < stepcut> because you need to be able to specific a list of initial values, not just a single value
19:17 < stepcut> and you get back a list of results, not just a single result
19:18 < mightybyte> Yeah, that sounds like a nice improvement.  I've not yet needed it in my use of formlets.
19:19 < stepcut> merging it is tricky, because I don't understand the true purpose of FormResult yet
19:19 < mightybyte> Hmmm, it may have been related to error reporting.
19:20 < mightybyte> To distinguish between invalid input and non-existant input.
19:24 < stepcut> mightybyte: it looks like all that would be affected is the String in the Failing return value?
19:26 < McManiaC> Listening on port 80
19:26 < McManiaC> yay \o/
19:26 < McManiaC> no state errors
19:26 < stepcut> mightybyte: the generalInput based version says, "not in the data" when the value is not in the data, not sure if the old version did as well
19:28 < mightybyte> Yes, we've had problems with that.
19:28 < stepcut> hmm
19:29 < stepcut> I am tempted to use the generalInput version, because it seems cleaner, and provides some additional capabilities. But I can't help but wonder if I am missing some other useful feature of the FormResult solution
19:29 < stepcut> I think it should be an API compatible change..
19:29 < stepcut> I'll have to look at it tomorrow though. done for today.
19:29 < stepcut> once I get this resolved, the other two patches are trivial
19:31 < stepcut> oh, I see you emailed Chris. All the more reason to wait ;)
19:32 < McManiaC> getPasteById id = ask >>= return . getOne . (@= id)  . pasteDB
19:32 < McManiaC> why is this getting Nothing? :(
19:33 < stepcut> could (@= id) be matching on more than one result?
19:33 < stepcut> what other indices does your PasteDB have?
19:34 < McManiaC> User ID Date Md5Hash Hide and Tags
19:35 < stepcut> does every PasteEntry contain a User?
19:35 < McManiaC> oh I'm stupid
19:35 < McManiaC> forgot the newtype thing
19:35 < McManiaC> yes
19:35 < stepcut> ah a type error
19:35 < McManiaC> although hmmm
19:36 < stepcut> another reason I do not like IxSet
19:36 < McManiaC> hehe
19:36 < stepcut> alas, my alternative is even less useful so...
19:36 < McManiaC> yay everything is working again
19:43 < McManiaC> hmmmm
19:43 < McManiaC> how do you check if an IxSet is empty?
19:43 < McManiaC> empty == myIxSet @* [...] -- will complain because of missing Eq instance
19:44 < stepcut> IxSet.null
19:45 < McManiaC> ah
19:49 < stepcut> I wrote that, cuz I had the same problem ;)
19:49 < stepcut> the alternative was do to do, List.null (IxSet.toList ixset), which did not seem very good
19:49 < mightybyte> stepcut: Not sure how long it will take him to respond, but hopefully it will be soon.
19:52 < McManiaC> i had "size (ix @* [...]) == 0" ^^
19:53 < McManiaC> phew... migration did work out perfect
19:53 < McManiaC> <3
19:53 < McManiaC> thx stepcut & mightybyte
19:54 < mightybyte> McManiaC: Great.  Migrations usually go pretty well for me.
19:55 < McManiaC> yeh but this one was kinda tricky
19:55 < McManiaC> since I migrated two states at once
19:56 < McManiaC> so I had to tell all previous states of type 1 to use the old state of type 2 and then migrate type 2 by hand into new type 1
19:56 < McManiaC> ^^
20:00 < McManiaC> so now I can concentrate on adapting that .Auth module
20:01 < McManiaC> :D
20:47 < koeien> h_buildbot: status
20:47 < h_buildbot> Paused.
20:47 < koeien> h_buildbot: resume
20:47 < h_buildbot> Resumed.
20:47 < stepcut> go go gadget build bot!
20:51 < h_buildbot> Build for ghc-6.8.3 failed. Check http://buildbot.happstack.com/ for details.
20:53 < h_buildbot> Build for ghc-6.10.2 OK. Test suite build failed. Check http://buildbot.happstack.com/ for details.
--- Log closed Thu Dec 31 00:00:04 2009