12:51:45 <rostayob> is there any way to show the result of the hsp preprocessor?
13:23:19 <stepcut> rostayob: you can run it by hand and send the output to a temp file
13:33:43 <rostayob> stepcut: right, trhsx
13:33:45 <rostayob> thanks
13:34:09 <stepcut> it takes three arguments.. I forget the exact order
13:34:24 <stepcut> but there is the input file, some name to use it error mesages, and an output file
13:34:46 <rostayob> Usage: trhsx <infile> [<outfile>]
13:36:04 <stepcut> When invoked, the cmd pre-processor is given at least three arguments on its command-line: the first argument is the name of the original source file, the second is the name of the file holding the input, and the third is the name of the file where cmd should write its output to.
13:36:38 <stepcut> rostayob: ah.. maybe you can just run trhsx as the 'Usage' suggests
13:38:40 <rostayob> stepcut: yeah that's what I'm doing (:
13:38:48 <stepcut> cool
13:39:01 <rostayob> stepcut: I'd expect hsp to be quite slow, right?
13:39:07 <rostayob> also considering that i'm using Strings
13:40:34 <stepcut> I think it's not too shabby actually
13:40:42 <stepcut> but I have not done any recent benchmarks
13:41:38 <rostayob> ok, it shouldn't be an issue anyway
15:04:55 <Lemmih> stepcut: What are your plans for happstack-server?
15:09:17 <stepcut> Lemmih: the next big change is to remove the currently low-level HTTP stuff and use Warp instead
15:09:59 <stepcut> Lemmih: why?
15:11:03 <rostayob> can someone help me with HJScript? it has nothing to do with hsp, I want to use it in another context
15:11:28 <stepcut> rostayob: what do you want to do with HJScript ?
15:11:36 <rostayob> I've read something about HJScript in the thesis of the author, but it seems to have changed since 2006
15:11:46 <rostayob> stepcut: I simply want to write map/reduce functions with it
15:12:18 <rostayob> but like
15:12:19 <stepcut> rostayob: I have found HJScript to be more trouble than it is worth.. except for using as an FFI to pass values to javascript code
15:12:41 <rostayob> stepcut: ok.. so your suggestion in that context is to simply write the function as a string?
15:12:50 <rostayob> is there some other js DSL?
15:13:09 <stepcut> I just put the javascript in an external .js file
15:13:26 <stepcut> there is also jmacro, but I have never used it
15:13:49 <rostayob> stepcut: yeah but in my case I can't do that (the external file thing)
15:13:54 <Lemmih> stepcut: Would you be open to the idea of removing ServerPartT? Or at least providing a specialized interface by default?
15:14:17 <rostayob> oh, JMacro doesn't seem to bad. thanks.
15:14:41 <rostayob> quasi quoting ehe
15:14:58 <stepcut> Lemmih: sure?
15:15:12 <stepcut> Lemmih: for what reason ?
15:15:55 <Lemmih> Simplicity.
15:16:22 <stepcut> Lemmih: what would be left ?
15:16:52 <Lemmih> ServerPart. Although I'd very much like to rename that thing.
15:17:25 <Lemmih> ircc, I gave it that name way back when.
15:17:27 <stepcut> so you want only ServerPart but no ServerPartT ?
15:18:07 <Lemmih> Yes.
15:18:15 <stepcut> how is that better?
15:18:52 <Lemmih> I don't think ServerPartT is worth the complexity it adds to types that could otherwise look almost friendly. (:
15:19:53 <stepcut> most happstack-server functions  should now have the types like,  (Happstack m) => String -> m Response
15:20:03 <stepcut> getting rid of ServerPartT would not actually change that..
15:20:04 <HugoDaniel> how about just "Server" ?
15:20:25 <Lemmih> Oh, neat. Haven't looked into that.
15:21:54 <stepcut> actually, I think they still have the more complicated (ServerMonad m, MonadPlus m) => String -> m Response. But the Happstack class does exist, and the type signatures could be updated
15:22:18 <Lemmih> Also, it doesn't really make sense for functions such as 'dir' or 'path' to use continuations any more, I believe.
15:22:29 <stepcut> oh ?
15:23:38 <Lemmih> This would be a more reasonable signature, I believe: path :: (FromReqURI a, Happstack m) => m a
15:23:52 <stepcut> and it just calls mzero if it does not match ?
15:23:58 <Lemmih> Right.
15:24:23 <Lemmih> Which it does already.
15:24:44 <siracusa> stepcut: Speaking of ServerPart, could you change the definition of it to "type ServerPart = ServerPartT IO"? This would make defining custom types a bit shorter.
15:24:47 <stepcut> it could work.. I am not sure if it is more or less confusing that way
15:25:36 <stepcut> siracusa: instead of, type ServerPart a = ServerPartT IO a ?
15:25:43 <siracusa> Yes
15:26:08 <stepcut> siracusa: perhaps.. there are some cases where that causes trouble.. but I don't remember when
15:26:16 <stepcut> siracusa: ServerPart could also be a newtype
15:26:18 <Lemmih> stepcut: It would be more consistent. Some functions work like 'dir' and 'path', others like 'readCookieValue' and 'method'.
15:26:33 <stepcut> Lemmih: yes.. I am not a fan of that inconsistency
15:27:31 <stepcut>  Lemmih: what about, ok, notFound, etc?
15:28:24 <stepcut> Lemmih: they just add a filter which sets the response code, they don't actually do anything with the argument except pass it to 'return'
15:28:46 <stepcut> though, in that sense, they are an enhanced version of 'return' which makes sense..
15:29:06 <Lemmih> I must say, I find them somewhat confusing.
15:29:41 <stepcut> is, do ok ; return "foo", less confusing ?
15:30:26 <stepcut> right now we have, dir "foo" $ dir "bar" $ ok "you are at foo/bar".
15:30:48 <stepcut> we could just as well have, do dir "foo" ; dir "bar" ; ok ; return "you are at foo/bar"
15:30:58 <stepcut> but somehow the second version seems more magical?
15:31:57 <Lemmih> Maybe 'setResponseType ok' or something. I really don't know.
15:32:05 <siracusa> I prefer the first, since it is more functional.
15:32:48 <stepcut> in the first one, it is more 'obvious' that 'dir "foo"' guards the rest of the line. Where-as in the second version, it is not as clear which functions might cause the rest of function to be skipped ?
15:33:25 <stepcut> of course, we already have things like, methodM..
15:34:23 <Lemmih> Leverage people's familiarity with parsec-style guards?
15:34:44 <stepcut> also, the whole use of mzero is suspect anyway..
15:34:53 <Lemmih> Yeah.
15:35:13 <stepcut> much of the time when you call mzero, nothing else is going to match anyway
15:37:40 <stepcut> like, if you have, msum [ dir "foo" $ dir "bar" $ mzero,  dir "cat" $ ok "hello"] once you have matched on dir "foo", it is unlikely that any other branch is  going to match. While you can construct cases in theory, it seems that is usually not the case in practice
15:38:59 <stepcut> so, dir "foo" ; int <- path ; ok (show int), would be very parsec-ish
15:40:47 <stepcut> and, along those lines, perhaps it should be like parsec, where once dir "foo" matches, it won't backtrack past that unless you explicity have 'try' ?
15:43:07 <Lemmih> Is performance really a concern?
15:43:08 <stepcut> it could certainly be done. There is also the routes command from snap. I wonder if that is a better alternative ?
15:43:53 <stepcut> Lemmih: I would hope not
15:44:41 <Lemmih> 'try' in parsec is purely there for performance reasons.
15:44:48 <stepcut> true
15:45:46 <Lemmih> I'm not a fan of 'route' in snap, btw.
15:45:54 <stepcut> sweet!
15:46:08 <stepcut> I have never used it.. but it seemed easy enough to support
15:47:00 <stepcut> personally, I use web-routes. But we definitely need something lightweight too
15:47:31 <rostayob> stepcut: lightweight as in what?
15:47:48 <stepcut> Lemmih: do you have any ideas on how to create a better performing version of IxSet ?
15:48:23 <stepcut> rostayob: easier to understand, simple to use, less boilerplate to get started
15:48:54 <rostayob> stepcut: less boilerplate = no dedicated data type? so a non type safe routing, but without all the dir and path?
15:48:56 <Lemmih> stepcut: Yeah, I do.
15:49:25 <stepcut> rostayob: non-type safe routing. But maybe just altered versions of dir and path.
15:49:42 <stepcut> Lemmih: Have you seen any of the kdtree stuff we were playing with ?
15:49:44 <Lemmih> The lax typing of IxSet is my biggest peeve, though.
15:50:09 <stepcut> Lemmih: right. The kdmap/kdtree stuff I came up with fixes that issue
15:50:30 <stepcut> Lemmih: though the fact that queries are done by types is still a bit of an oddity
15:53:16 <HugoDaniel> :P
15:53:43 <stepcut> Lemmih: the kdtree code in this darcs repo: http://darcs.monoid.at/kdtree
15:54:33 <stepcut> Lemmih: defines an interface similar to IxSet, but when you do, kdtree @= someIndex, the type checker actually checks that someIndex is really an indexed type of that kdtree
15:55:31 <stepcut> Lemmih: but, there are two unknowns regarding that kdtree code: (1) can the tree be rebalanced efficiently (2) is it possible to efficiently return values from the set sorted by a specific (indexed) key
15:57:10 <stepcut> the other 'wishlist' item for IxSet (or something similar) would be a way to store the keys in RAM, but the values on disk.
15:57:34 <stepcut> I gotta run, but I will be around later if you want to discuss more ideas. I will add some bugs to the bug tracker regarding the things we have discussed so far
15:59:36 <Lemmih> See ya later.
15:59:42 <Lemmih> ACTION heads to bed.
16:00:12 <Lemmih> Memory usage is my biggest concern. That and type-safety. But mostly memory usage.
16:00:36 <stepcut> Lemmih: one reason I like ServerPartT is that if I do, ServerPartT (SomeMonad IO), I can still use the existing class instances for ServerPartT
16:00:45 <Lemmih> But using mmap + binary serialization seems to work wonders.
16:01:13 <Lemmih> stepcut: How often is that done?
16:01:15 <stepcut> if I have to do, SomeMonadT ServerPart Response, then I have to recreate all the instances that ServerPart has for SomeMonadT.
16:01:21 <stepcut> Lemmih: I do it in all my applications
16:01:38 <stepcut> for more instances I can use newtype deriving
16:01:52 <Lemmih> What does your monad do?
16:01:53 <stepcut> but newtype deriving does not work with type families, which causes issues
16:02:12 <Lemmih> ACTION is so tired he can hardly read anymore.
16:02:33 <Lemmih> Let's continue some other time. I'd really like to talk more about IsSet with you.
16:02:43 <stepcut> newtype StoryPrompts a = StoryPrompts { unStoryPrompts :: (RouteT StoryPromptsURL (ServerPartT (ReaderT WebConf IO))) a }
16:02:43 <stepcut>     deriving (Applicative, Functor, Monad, MonadPlus, MonadIO, ServerMonad, FilterMonad Response, WebMonad Response, HasRqData, Happstack)
16:03:12 <stepcut> Lemmih: yeah, IxSet is my (personal) current focus for happstack development at the moment -- so good timing :)
16:04:45 <stepcut> Lemmih: the kdtree code uses less RAM than IxSet and it has support for multicore
16:05:01 <stepcut> Lemmih: but, as I mentioned -- the rebalancing issue and sorted results issues could be fatal
16:05:35 <stepcut> ACTION is out the door now