00:10:29 <McManiaC> what do you mean?
00:13:55 <HugoDaniel> im not able to output proper utf-8 files, im using hstringtemplates (that are in .st files in utf8 encoding)
00:14:12 <HugoDaniel> and everything just shows up filled with ?, except for the values i fetch from DB (which are also utf-8)
00:16:10 <McManiaC> for readFile etc you need to either use ghc 6.12 or something like Codec.Binary.UTF8.Light(.readUTF8File)
00:16:29 <McManiaC> ghc 6.10 has some issues with utf8 IO
00:17:23 <McManiaC> and then you should define a meta-tag for your html output
00:17:31 <McManiaC> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
00:17:32 <HugoDaniel> i have the meta tag
00:17:36 <McManiaC> ok
00:17:51 <HugoDaniel> and the .st files are utf-8
00:18:05 <McManiaC> then try ghc 6.12 or use that lib
00:19:10 <HugoDaniel> ok, ill go for the lib
00:19:21 <HugoDaniel> thanks
00:19:51 <McManiaC> just make sure you replace your readFile / writeFile / putStr etc with the utf8 versions
00:19:59 <HugoDaniel> i dont have those
00:20:03 <HugoDaniel> im using hstringtemplate
00:20:07 <HugoDaniel> which probably uses those
00:20:12 <McManiaC> oh
00:20:14 <McManiaC> okay…
00:20:44 <HugoDaniel> ill try to patch it, or find a workaround, in order to use those
00:21:04 <McManiaC> updating to 6.12 is not that hard…
00:21:05 <McManiaC> ;)
00:21:20 <HugoDaniel> i dont have the time right now :/
00:21:32 <HugoDaniel> and i would need to do it also on the server
00:22:43 <McManiaC> yeh ok
00:22:52 <McManiaC> updating ghc is always a pain
00:23:04 <McManiaC> but in case of utf8 compatibility it was worth it imo
00:28:37 <HugoDaniel> ok
00:28:39 <HugoDaniel> The Glorious Glasgow Haskell Compilation System, version 6.12.1
00:28:41 <HugoDaniel> done
00:28:48 <HugoDaniel> (in my dev machine only... yet)
00:29:15 <HugoDaniel> now its time to cabal all the stuff...
00:32:54 <McManiaC> I'd remove the whole /usr/lib/ghc-* directories
00:33:05 <McManiaC> had some weird problems with cabalized packages until I did that
00:38:12 <HugoDaniel> ok, done
00:38:49 <McManiaC> :)
00:38:50 <McManiaC> good luck
00:39:00 <HugoDaniel> happstack installed fine
00:39:29 <McManiaC> http://npaste.de/snowman/ my happstack-app with utf8
00:39:29 <McManiaC> ;D
00:40:24 <HugoDaniel> allright :)
00:55:13 <stepcut> HugoDaniel: happstack itself should work fine with utf-8
00:55:38 <stepcut> HugoDaniel: internally and String that happstack gives you will already be utf-8 decoded and contain proper unicode characters
00:56:13 <stepcut> if HStringTemplate is giving you issues, make sure that the ToMessage instance for HStringTemplate is properly encoding the String as utf-8 when it converts it to a ByteString
00:57:10 <stepcut> and also make the ToMessaeg instance is setting the charset
00:57:28 <stepcut> and make sure your html includes the line McManiaC mentioned
00:58:05 <stepcut> I don't use HStringTemplate, so I have never checked that it does the right thing
00:58:24 <stepcut> but I know HSP does, so you can look in happstack/happstack/src/Happstack/Server/HTML/HSP.hs I think
01:01:25 <mightybyte> stepcut: I'm having trouble installing urlt because of conflicting quickcheck dependencies.
01:03:04 <stepcut> mightybyte: oh ? you should be able to have multiple versions of quickcheck installed, right?
01:03:27 <HugoDaniel> stepcut: im using HtmlString on the stringtemplate output
01:03:34 <stepcut> mightybyte: what is causing the conflict... everything installs for us
01:03:52 <HugoDaniel> and i think the HtmlString code is doing a pack on it
01:04:03 <mightybyte> stepcut: The conflict was on cabal install urlt.
01:04:25 <stepcut> mightybyte: urlt itself only depends on quickcheck 2, yes?
01:04:25 <mightybyte> Says happstack-util requires quickcheck < 2
01:04:32 <mightybyte> Yes
01:04:58 <stepcut> hmm. well I think happstack-util in head uses quickcheck 2 now
01:05:05 <stepcut> not sure why you can't have both installed though
01:05:11 <stepcut> did it give you an error or just a warning?
01:05:20 <McManiaC> did you update ghc recently?
01:05:32 <mightybyte> Not sure
01:05:47 <mightybyte> McManiaC: Yes.  Just today I updated my arch packages and got 6.12
01:05:50 <McManiaC> I had to remove /usr/lib/ghc-* and ~/.ghc ~/.cabal to get everything working again
01:06:15 <mightybyte> stepcut: I also got this
01:06:15 <McManiaC> after that everything installed just fine
01:06:21 <mightybyte> Warning: URLT.cabal: Unknown fields: build-type (line 17)
01:06:31 <McManiaC> I had version errors too
01:06:41 <stepcut> HugoDaniel: in happstack/happstack/src/Happstack/Server/HStringTemplate.hs, it looks like ToMessage just does L.pack.. that won't work
01:06:55 <McManiaC> and after fixing them by manually saying which version to use I had "module ... not found" errors
01:07:23 <stepcut> HugoDaniel: it needs to use Data.ByteString.Lazy.UTF8.fromString. look at, happstack/happstack/src/Happstack/Server/HSP/HTML.hs
01:08:02 <HugoDaniel> ah
01:08:07 <HugoDaniel> that explains...
01:08:09 <HugoDaniel> but...
01:08:24 <HugoDaniel> ...it works with the data from the DB
01:08:28 <HugoDaniel> which is utf-8
01:09:02 <HugoDaniel> now i just trashed my dev machine with ghc 6.12.1
01:09:04 <HugoDaniel> :/
01:09:18 <McManiaC> trashed?
01:09:36 <HugoDaniel> cabal doesn't work its giving me strange error messages
01:09:41 <HugoDaniel> ghc-pkg check just outputs trash
01:09:51 <HugoDaniel> ...so im guessing i should just rm -rf /*
01:10:02 <McManiaC> update cabal-install and rm those directories
01:10:29 <McManiaC> (then reinstall ghc, of course)
01:10:54 <McManiaC> I dont know why GHC is such a pain to update…
01:11:55 <stepcut> mightybyte: that build-type warning is harmless, but fixed in darcs now
01:12:08 <stepcut> mightybyte: what did you think of the formlets changes?
01:12:37 <HugoDaniel> argh, reinstalling cabal and ghc didnt work
01:12:39 <HugoDaniel> bah
01:12:56 <mightybyte> stepcut: I'm still trying to get my app to build.
01:13:03 <McManiaC> what OS are you working on?
01:13:03 <stepcut> mightybyte:  oh :)
01:13:05 <mightybyte> Been busy with some other things
01:13:17 <HugoDaniel> arch linux
01:13:29 <McManiaC> arch linux should have everything you need
01:13:32 <McManiaC> run as root:
01:13:38 <stepcut> mightybyte: yeah, no rush.
01:13:53 <stepcut> mightybyte: it's not like I didn't spend a month getting them merged :p
01:14:11 <McManiaC> pacman -Rd ghc cabal-install && rm -r /usr/lib/ghc* ~/.cabal ~/.ghc && pacman -Sy ghc cabal-install
01:14:14 <McManiaC> ^^
01:14:40 <mightybyte> stepcut: I'm been procrastinating getting gitit working in my app.
01:15:02 <mightybyte> Any plans to get more of your package infrastructure in hackage?
01:15:25 <mightybyte> McManiaC: The rm -r /usr/lib/ghc* part scares me
01:15:51 <stepcut> mightybyte: heh. Do you care about the GPL issues involved with using gitit in your app?
01:16:28 <stepcut> mightybyte: you mean like updated versions of URLT and stuff ?
01:16:35 <mightybyte> mightybyte: Yes to the second.
01:16:47 <mightybyte> Oops, s/mightybyte/stepcut/
01:17:23 <stepcut> mightybyte: I would like to. But I am kind of waiting on formlets because I think happstack-extra depends on formlets, and most other things depend on happstack-extra
01:17:34 <mightybyte> stepcut: Hadn't noticed that gitit was GPLd
01:17:55 <stepcut> mightybyte: gitit and pandoc are .. bunch of jerks ;)
01:18:24 <McManiaC> mightybyte: I know but I found it to be the only way to get ghc 6.12 working again
01:18:35 <McManiaC> I spent a whole day on this
01:18:35 <McManiaC> ^^
01:18:44 <mightybyte> McManiaC: Ok, I'll keep that in mind.
01:18:56 <McManiaC> done it on my local machine and server and everything works fine again
01:19:01 <stepcut> McManiaC: yeah, that is why we build *everything* as debian packages at work :)
01:19:31 <stepcut> McManiaC: makes upgrades a lot easier (though still requires hacking around sometimes)
01:19:31 <McManiaC> you could remove all the haskell-* packages with pacman first
01:19:57 <McManiaC> stepcut: I only had problems with debians haskell packages
01:20:29 <McManiaC> thank god I can finally run arch linux on my servers
01:20:31 <McManiaC> :D
01:22:44 <mightybyte> McManiaC: I'm going to try without deleting the lib stuff.
01:22:51 <mightybyte> McManiaC: But thanks for the tip.
01:23:03 <McManiaC> good luck
01:23:06 <McManiaC> it didnt work for me
01:23:07 <McManiaC> :)
01:23:19 <mightybyte> What failed?
01:23:27 <mightybyte> So far I've been able to build happstack
01:23:34 <McManiaC> and I havent heard of anyone not having any problems
01:24:22 <McManiaC> mightybyte: at first I had problems installing happstack because it wanted some old version of package xy
01:24:37 <McManiaC> after fixing that by hand ghc couldnt find System.Log.Logger
01:24:57 <McManiaC> and a couple of other packages just couldnt get found
01:25:06 <McManiaC> although they were definitly installed with cabal
01:25:28 <McManiaC> after removing the lib directories everything works out of the box
01:25:29 <McManiaC> :)
01:27:02 <mightybyte> Who installs those /usr/lib directories?  Is that cabal or arch haskell packages?
01:27:15 <McManiaC> arch haskell packages
01:27:23 <McManiaC> as long as you run cabal as user
01:28:39 <McManiaC> mightybyte: you could also just rename the /usr/lib/ghc- directory, test if everything works and than remove/restore it ;)
15:54:41 <mightybyte> stepcut: Still having problems compiling urlt
16:04:57 <stepcut`> mightybyte: hmm
16:07:25 <stepcut`> apparently I did not push the patch that updates happstack to quickcheck 2
16:08:06 <stepcut`> it is pushed now
16:20:45 <mightybyte> Hmmm, just pulled and re-built, but I'm still getting the same problem.
16:21:21 <stepcut`> :-/
16:21:45 <stepcut`> the new happstack-util explicitly says:
16:21:47 <stepcut`> QuickCheck >= 2 && < 3,
16:21:59 <stepcut`> has the error message changed at all?
16:22:11 <mightybyte> Yep, I see that.
16:22:27 <mightybyte> Doesn't look like it.
16:22:41 <stepcut`> how did you install the updated happstack ?
16:22:46 <mightybyte> cabal: cannot configure happstack-util-0.4.1. It requires QuickCheck <2
16:22:46 <mightybyte> For the dependency on QuickCheck <2 there are these packages: QuickCheck-1.0,
16:22:58 <stepcut`> ./bin/build-install-all.sh ? or some other method?
16:23:03 <mightybyte> bin/build-install-all.sh
16:23:34 <stepcut`> and then how did you try to install URLT?
16:23:39 <mightybyte> cabal install
16:24:08 <stepcut`> when you do, ghc describe happstack-util, what version of QuickCheck does it list under depends?
16:24:29 <stepcut`> also, does it list more than one version of happstack-util?
16:24:36 <mightybyte> <command line>: does not exist: describe
16:24:42 <stepcut`> ghc-pkg list happstack-util
16:24:58 <mightybyte> happstack-util-0.4.1
16:25:09 <stepcut`> only one match?b
16:25:16 <mightybyte> Yeah
16:25:27 <stepcut`> in the global package index, or your home directory?
16:25:32 <mightybyte> Home directory
16:26:07 <stepcut`> ghc-pkg describe happstack-util
16:26:11 <stepcut`> what version of QuickCheck ?
16:26:36 <mightybyte> QuickCheck 1.2
16:27:10 <mightybyte> Let me blow away ~/.cabal and ~/.ghc again and reinstall now that I have the updated head.
16:27:32 <mightybyte> I'll be back in half an hour or so with the results of that.
16:27:36 <stepcut`> hmm
16:27:45 <stepcut`> that seems awfully aggressive
16:27:58 <mightybyte> I've done it several times already.
16:28:04 <stepcut`> :)
16:28:11 <mightybyte> And happstack is the only thing I've installed since the last time I did that.
16:28:12 <stepcut`> and it hasn't helped yet :p
16:28:17 <mightybyte> True
16:28:30 <stepcut`> ./bin/clean-all.sh
16:28:37 <stepcut`> ./bin/build-install-all.sh
16:28:39 <stepcut`> that should do it
16:28:40 <mightybyte> Ok
16:28:58 <stepcut`> just check that the happstack-util.cabal in that directory really says QuickCheck 2
16:29:35 <mightybyte> Ok
16:29:58 <mightybyte> Yep, it's right.
16:30:12 <mightybyte> Rebuilding...
16:30:26 <mightybyte> I have to step out.  Be back in 30 minutes or so.
16:30:40 <stepcut`> ok
16:49:25 <mightybyte> stepcut: Same problem.
16:51:46 <mightybyte> You think cabal is somehow checking the quickcheck dependency for the hackage version of happstack-util instead of my local version?
17:00:31 <stepcut> no, but perhaps it is installing the hackage version of happstack-util instead of the local version
17:00:43 <stepcut> look carefully at your logs..
17:01:12 <stepcut> or do, runhaskell Setup configure --user && runhaskell Setup build && runhaskell Setup install, to avoid any chance of looking at hackage..
17:07:18 <mightybyte> Hmmm, it works when I do the runhaskell for urlt
17:07:21 <mightybyte> But it gives me a warning
17:07:30 <mightybyte> Configuring URLT-0.13...
17:07:30 <mightybyte> Warning: This package indirectly depends on multiple versions of the same
17:07:30 <mightybyte> package. This is highly likely to cause a compile failure.
17:07:30 <mightybyte> package happstack-util-0.4.1 requires QuickCheck-
17:07:30 <mightybyte> package URLT-0.13 requires QuickCheck-
17:08:04 <mightybyte> But it seems to compile fin.
17:08:05 <mightybyte> fine
17:08:07 <stepcut> yes
17:08:15 <stepcut> that is actually what I expected to happen
17:08:21 <stepcut> apparently cabal is more militant about it
17:08:26 <mightybyte> I guess so
17:08:37 <stepcut> except, you shouldn't have any version of happstack-util on your system which requires QuickCheck 1
17:08:43 <stepcut> so something funny is gonig on there
17:08:55 <mightybyte> Yeah
17:09:14 <stepcut> in the buildbot, we have seen a case where cabal install will download a library from hackage even though it is already installed locally
17:09:18 <stepcut> I wonder if that is happening to you
17:09:31 <mightybyte> Maybe
17:09:42 <mightybyte> It seems that it's something like that.
17:10:08 <mightybyte> ghc-pkg describe happstack-util still tells me quickcheck 1.2
17:10:39 <stepcut> right, you would have to look at your build results for ./bin/build-install-all.sh and see if you see happstack-util being installed twice
17:10:55 <stepcut> once from the local directory, and once when it is trying to resolve dependencies for another package
17:11:03 <mightybyte> Ok, let me try that.
17:13:45 <mightybyte> Is there a way to redirect both stdout and stderr to the same file?
17:14:39 <stepcut> yes
17:14:49 <stepcut> in bash?
17:14:53 <mightybyte> Yeah
17:15:15 <stepcut> foo > out.log 2&>1 I think
17:15:22 <stepcut> there is a shorcut cut though...
17:15:25 <stepcut> let me double check
17:15:43 <stepcut> I usually just run everything in emacs and do M-x shell
17:15:43 <stepcut> ;)
17:16:22 <stepcut> foo &> log.txt
17:16:36 <mightybyte> Ok
17:18:24 <HugoDaniel> http://hpaste.org/fastcgi/hpaste.fcgi/view?id=16273#a16275
17:18:26 <HugoDaniel> how can i fix this ?
17:18:58 <HugoDaniel> is it possible that HtmlString is breaking stuff ?
17:20:45 <stepcut> HugoDaniel: unless you patched the ToMessage instance, HtmlString is definitely breaking stuff
17:21:14 <mightybyte> stepcut: Yes, it does happstack-util twice.
17:21:26 <mightybyte> ...in immediate succession.
17:21:29 <HugoDaniel> oh
17:21:32 <HugoDaniel> how do i fix that ?
17:21:59 <HugoDaniel> ill define a HtmlUTF8String
17:23:07 <stepcut> HugoDaniel: in happstack/happstack/src/Happstack/Server/HStringTemplate.hs it needs to use Data.ByteString.Lazy.UTF8.fromString instead of L.pack
17:23:16 <stepcut> look at, happstack/happstack/src/Happstack/Server/HSP/HTML.hs
17:23:22 <stepcut> and then submit a patch :)
17:23:49 <HugoDaniel> oh, okey, thanks... you told me that yesterday but i lost the logs
17:24:04 <stepcut> yeah, I still have the buffer open, so I copied and pasted ;)
17:24:45 <stepcut> however, we do have channel logs: http://happstack.com/irc-logs/
17:24:51 <HugoDaniel> oh nice :)
17:25:11 <stepcut> the empty files are the days nobody said anything :p
17:25:30 <stepcut> e.g., the 14th
17:25:40 <mightybyte> stepcut: It would be nice if cabal would tell you whether it was getting the package locally or from hackage.
17:25:42 <HugoDaniel> so, i should add a HtmlUTF8String to happstack-helpers, and also try to add support for utf8 in hstringtemplate
17:26:57 <stepcut> ?
17:27:51 <stepcut> what is the difference between HtmlString and HtmlUTF8String ?
17:28:27 <HugoDaniel> uses Data.ByteString.Lazy.UTF8.fromString instead of L.pack
17:28:52 <stepcut> HtmlString should be using fromString not L.pack.. it's broken
17:29:55 <HugoDaniel> its using L.pack, and B.pack, where B is Data.ByteString.Char8, and L is Data.ByteString.Lazy.Char8
17:33:45 <mightybyte> This is weird.  I just ran ghc-pkg list and it showed all the happstack packages at 0.4.1
17:34:01 <mightybyte> Then I built happstack-auth with "cabal install"
17:34:18 <mightybyte> And it rebuilt happstack-0.4.1
17:34:49 <mightybyte> And now URLT is showing up red in "ghc-pkg list"
17:36:09 <stepcut> mightybyte: I blame dcoutts.. what version of GHC ?
17:37:00 <HugoDaniel> hmm
17:37:19 <mightybyte> 6.12.1
17:37:26 <HugoDaniel> so, ive done a quickfix in happstack-helpers
17:37:32 <HugoDaniel> how do i create and send a patch ?
17:37:55 <stepcut> HugoDaniel: um..
17:38:43 <HugoDaniel> im getting "HTTP request failed with: <socket: 11>: hLookAhead: resource vanished (Connection reset by peer)  "
17:38:55 <stepcut> HugoDaniel: why did you patch anything in happstack-helpers?
17:39:12 <HugoDaniel> HtmlString is from happstack-helpers
17:39:32 <HugoDaniel> bummer, it still doesn't work
17:40:11 <stepcut> HugoDaniel: oh, HtmlString is not the same as StringTemplate..
17:40:16 <stepcut> one moment
17:43:26 <stepcut> HugoDaniel: anyway if you add:
17:43:37 <stepcut> import qualified Data.ByteString.Lazy.UTF8 as L
17:43:41 <stepcut> to Common.hs
17:43:49 <stepcut> and change the instance to:
17:43:50 <stepcut> instance ToMessage HtmlString where
17:43:50 <stepcut>   toContentType _ = B.pack "text/html;charset=utf-8"
17:43:50 <stepcut>   toMessage (HtmlString s) = L.fromString s
17:43:53 <stepcut>  
17:43:57 <stepcut> I think it should work
17:44:58 <HugoDaniel> okey
17:45:03 <HugoDaniel> i forgot the charset=utf-8
17:45:52 <HugoDaniel> its also necessary to add utf8-string to the .cabal file
17:46:28 <stepcut> yes
17:47:34 <HugoDaniel> ok, i keep having the same problem...
17:47:48 <HugoDaniel> Apenas poder�o entrar os professores de ci�ncia
17:48:34 <stepcut> if you do, HtmlString "°", where ° is a unicode character of your choice, does that work?
17:48:42 <HugoDaniel> let me try it...
17:50:07 <stepcut> also, what browser?
17:51:23 <HugoDaniel> yes, it works
17:51:35 <HugoDaniel> opera, with forced UTF-8 encoding
17:51:47 <HugoDaniel> (the automatic also recognizes utf-8 as the encoding)
17:51:51 <stepcut> so, it seems like the source your are reading the data from is where it is getting corrupted now
17:51:59 <HugoDaniel> hmm
17:52:17 <HugoDaniel> $ enca -L none login.st
17:52:19 <HugoDaniel> Universal transformation format 8 bits; UTF-8
17:52:28 <stepcut> yeah
17:53:27 <HugoDaniel> it displays fine in kwrite
17:53:51 <stepcut> I am not really clear how, do { c <- UTF.readFile fp ; return $ toResponse $ HtmlString c }, could go wrong
17:54:40 <stepcut> does, do { c <- UTF.readFile fp ; UTF.putStrLn c }, work ?
17:56:14 <HugoDaniel> let me try it
17:57:26 <HugoDaniel> how do i import qualified in ghci ?
17:58:25 <stepcut> HugoDaniel: you can't, you just have to specify the full path
17:58:36 <HugoDaniel> ah, yes, i did that
17:58:40 <HugoDaniel> it works fine in ghci
17:58:50 <HugoDaniel> the file shows up properly with the proper characters
17:59:02 <HugoDaniel> konsole is using UTF-8 as the default charset
17:59:23 <HugoDaniel> ill try to kill opera... perhaps is the cache or whatnot
18:05:17 <HugoDaniel> ok
18:05:32 <HugoDaniel> it works fine in konqueror if i specifically set the encoding to be UTF-8
18:05:38 <HugoDaniel> the automatic encoding doesn't work
18:05:43 <HugoDaniel> in opera, still doesn't work
18:05:48 <stepcut> hmm
18:06:37 <HugoDaniel> i noticed this on the opera request: HeaderPair {hName = "accept-charset", hValue = ["iso-8859-1, utf-8, utf-16, *;q=0.1"]})
18:07:36 <stepcut> yes, that seems fine
18:07:55 <stepcut> do you have the <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> tag in the <head> ?
18:07:56 <HugoDaniel> konqueror request has instead: HeaderPair {hName = "accept-charset", hValue = ["utf-8, utf-8;q=0.5, *;q=0.5"]}
18:08:19 <HugoDaniel> stepcut, i do
18:08:29 <HugoDaniel> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" ></meta>
18:09:32 <HugoDaniel> now konquerer stoped working with utf-8, it displays the same as opera (which is ? instead of the correct char)
18:09:45 <HugoDaniel> and i haven't done anything... just a few refreshes
18:09:57 <stepcut> sweet!
18:10:12 <HugoDaniel> ah
18:10:16 <HugoDaniel> i know
18:10:17 <stepcut> maybe that character just isn't in the font ?
18:10:34 <stepcut> is this public visible on the Internet ?
18:10:44 <HugoDaniel> if i do a refresh i konqueror it displays the ? instead of the character, i then have to manually switch the charset to utf-8, and it stays fine...
18:11:27 <HugoDaniel> stepcut: no, but i can make it available... w8 a sec
18:17:17 <HugoDaniel> (im just patching up the happstack helpers on the server)
18:22:01 <HugoDaniel> http://serv.fcsh.unl.pt/a3es/
18:22:08 <HugoDaniel> it works fine now :/
18:22:19 <HugoDaniel> in the server it works fine...
18:22:30 <HugoDaniel> something tells me my linux instalation is completly messed up
18:23:29 <stepcut> :)
18:25:04 <HugoDaniel> i should definetly switch to freebsd
18:26:12 <stepcut> :p
18:26:46 <stepcut> anyway, that patch to the ToMessage instances is certainly required..
18:26:57 <stepcut> so you should submit a patch to the maintainer of that library
18:27:14 <HugoDaniel> happstack-helpers ? aint that you ?
18:27:19 <stepcut> nope
18:27:34 <stepcut> http://hackage.haskell.org/package/happstack-helpers
18:27:40 <stepcut> thomas hartman I believe
18:27:50 <stepcut> I don't know how my name got on it :-/
18:27:54 <HugoDaniel> thats the author, the maintainer is creighton hogg
18:27:56 <HugoDaniel> ill mail him
18:35:02 <HugoDaniel> done
18:47:44 <HugoDaniel> in ArchLinux, UTF-8 encoding is identified by "utf8" instead of "UTF-8"
18:47:51 <HugoDaniel> i guess this might have something to do with it...
19:03:29 <stepcut> hmm
19:13:32 <HugoDaniel> http://hpaste.org/fastcgi/hpaste.fcgi/view?id=16279#a16279  here is the fixed function, using hstringtemplate with utf8, if anyone cares...
19:15:02 <stepcut> HugoDaniel: so what was wrong besides the ToMessage instance?
19:17:52 <HugoDaniel> im not sure, i didn't test it, i guess ToMessage was the only thing
19:18:01 <HugoDaniel> i dont know if hstringtemplate reads utf8 properly or not...
19:19:24 <stepcut> ah
19:22:30 <HugoDaniel> ok, i tested it, reads the files correctly
19:22:38 <HugoDaniel> ToMessage was the only thing...
19:23:15 <stepcut> spiffy
22:27:10 <HugoDaniel> i usualy feel the need for a url mapper in happstack
22:27:24 <HugoDaniel> is there such a thing ? im stuck to using dir and other kind of functions...
22:38:33 <stepcut> HugoDaniel: I have a url mapper of sorts, http://hackage.haskell.org/package/URLT
22:39:03 <stepcut> probably need the darcs version, http://src.seereason.com/urlt/
22:39:38 <stepcut> but you could easily write your own different url mapper..
22:40:28 <HugoDaniel> hmm yes
22:42:00 <stepcut> URLT is really more than a url mapper..
22:42:23 <stepcut> I have a write up on it here, http://src.seereason.com/~jeremy/SimpleSite1.html
22:42:41 <stepcut> how would your ideal url mapper work?
22:42:55 <HugoDaniel> oh, this is cool
22:43:06 <HugoDaniel> hmm
22:43:44 <HugoDaniel> my url mapper would match url sections and pass them as inputs to the functions it mapped
22:43:55 <stepcut> match in what way?
22:44:51 <HugoDaniel> something like ("teacher-$id$/$day$-$month$-$year$", myfunc)
22:45:28 <HugoDaniel> and myfunc would be something like :: Int -> Int -> Int -> Int -> Stuff
22:45:57 <stepcut> what would the type of, ("teacher-$id$/$day$-$month$-$year$", myfunc) be?
22:47:24 <HugoDaniel> i haven't thought about it yet.. i dont know if using a tuple might be the best thing to do...
22:47:41 <HugoDaniel> probably (String, Args -> Stuff)
22:48:06 <stepcut> I assume you want to have more than one case to match on ?
22:48:19 <HugoDaniel> and args could be [Either Int String]
22:48:32 <HugoDaniel> yes
22:48:39 <HugoDaniel> so [(String, Args -> Stuff)]
22:49:04 <stepcut> where, type Args = [either Int String] ?
22:49:11 <HugoDaniel> yes, something like that
22:49:49 <HugoDaniel> i dont see great use to pass around other data types, but im not sure... people can find very strange things to pass around in url's
22:50:07 <mightybyte> stepcut: dcoutts says to bump the version for happstack-util head to force cabal to use it
22:50:39 <stepcut> mightybyte: but it's already installed, why does it want to install another version?
22:51:05 <mightybyte> Not sure of the details, but it interprets same version as interchangeable.
22:51:12 <dcoutts> stepcut: the thing you have to realise is that sometimes it is necessary to rebuild packages, so as to achieve consistent deps
22:51:30 <dcoutts> cabal will try to use the installed version where possible
22:52:07 <dcoutts> but if the consistent install plan it comes up with assigns different deps to a package than is provided by the installed instance, then we cannot use the installed instance
22:52:15 <dcoutts> at some point we might add support for --constraint="foo installed"
22:52:34 <HugoDaniel> well, time to sleep now... thanks for all the support
22:52:42 <dcoutts> to commit earlier to picking the installed one, which might then cause other decisions to be taken, or might end in failure with a suitable explanation
22:53:04 <dcoutts> given that it does sometimes need to rebuild, it has to work on the assumption that foo-1.0 is just as good as foo-1.0
22:53:20 <mightybyte> Yeah, that makes sense.
22:53:28 <dcoutts> so best practise is if you've got non-trivial changes in the dev version, to bump the versino
22:53:36 <dcoutts> esp if there are changes in the dependencies
22:53:39 <mightybyte> And the whole point of version numbers in the first place is to disambiguate.
22:53:56 <stepcut> dcoutts: so what is happening is that we do cabal install 'a' and something good gets intalled. But then we do cabal install 'b', and we realize the choices that were made for 'a' don't work for 'b', so we upgrade 'a' so that it is compatible with the choices for 'b'?
22:54:07 <dcoutts> since that's exactly what would cause the deps of the installed instance to not match the expected/required deps assigned in the install plan
22:54:25 <dcoutts> stepcut: rebuild 'a' (not upgrade), yes.
22:55:17 <dcoutts> and if you've got an installed instance for 'a' that you really wanted to use then this is annoying
22:55:35 <dcoutts> as I mentioned, we might add --constraint="foo installed"
22:55:49 <dcoutts> but it's a better idea just to go with the flow and use version numbers sensibly
22:56:15 <stepcut> dcoutts: ok, so let's say I cabal install 'a' and I add some -f flags to get certain behavior. Then I cabal install 'b', and it decides to rebuild 'a'.. but it does not build them with the same flags, nor does it even make it entirely forthcoming that it rebuilt a unless I am looking closely.. that seems a bit dodgey
22:56:40 <dcoutts> stepcut: it's not like we have a lot of choice in the matter
22:56:59 <dcoutts> of course rebuilding is a bit dodgey, but failing to build at all is worse
22:57:16 <dcoutts> --dry-run -v shows what it will rebuild, and some indication of why
22:57:23 <dcoutts> in particular, changed deps
22:57:25 <stepcut> well, when I do, runhaskell Setup configure --user &&  runhaskell Setup build && runhaskell Setup install, it works with out failure
22:57:35 <dcoutts> stepcut: you're lucky
22:57:42 <dcoutts> it could just as well fail
22:58:07 <stepcut> so, let's move on to the thing I am willing to do something about
22:58:08 <dcoutts> stepcut: does it warn about using multiple versions of dependent packages?
22:58:12 <stepcut> yes
22:58:15 <dcoutts> there you go
22:58:21 <stepcut> but it's just a warning :)
22:58:30 <dcoutts> the fact that it happens to work is your good luck
22:58:37 <dcoutts> cabal cannot know that it would have worked
22:58:44 <dcoutts> it must make a conservative assumption
22:58:46 <stepcut> it's not luck, I would have fixed it if it doesn't work :p
22:58:56 <dcoutts> that's no good for end users
22:59:07 <stepcut> but, let's move onto the thing I am willing to fix
22:59:10 <dcoutts> and it's not necessarily something you can fix in your package
22:59:12 <dcoutts> yes, ok
22:59:55 <stepcut> ok, let's say I just made a stable release of happstack 0.4.1 and uploaded it to hackage
23:00:01 <stepcut> now I want to do some work on the dev branch
23:00:43 <stepcut> should I immediately bump my version numbers to 0.4.2 ? and make all the modules depend on 0.4.2 or higher?
23:01:18 <dcoutts> the two questions are independent of course
23:01:27 <stepcut> ok
23:01:30 <dcoutts> a version number identifies an interface
23:01:35 <mightybyte> stepcut: <aside>Changing happstack-util to 0.4.2 solves the problem</aside>
23:01:43 <stepcut> yes
23:02:09 <dcoutts> during a dev cycle through one doesn't need to be quite so festidious in version bumps as in released code
23:02:10 <mightybyte> stepcut: I'm now getting some other build problems, but they don't involve happstack.
23:03:06 <stepcut> but let's say 0.4.2 fixes a bug and does not change the interface. But 0.4.1 is on hackage. I don't want installing happstack-data to cause happstack-util 0.4.1 to be downloaded from hackage a rebuilt instead of the happstack-util 0.4.2 I just built
23:03:19 <dcoutts> stepcut: so it's a choice for you as to whether you bump immediately or not
23:03:33 <dcoutts> if the versions are exactly the same, then yes, cabal assumes they have the same interface
23:04:06 <dcoutts> as for the dependencies, if they still work with the released 0.4.1 then of course there's no need to change the version constraints
23:04:07 <stepcut> well, I didn't bump anything immediately, and mightbyte ended up with the old version from hackage instead of the new version he just installed.. we noticed it becasue it broke the build.. but let's say it didn't
23:05:02 <stepcut> right now we have the case that people get the latest source from darcs, and they run cabal install in each directory and they end up with source from hackage instead of the source they thought they got from darcs
23:05:06 <dcoutts> if the deps do not work with the dev "0.4.1" then that's an excellent indication that the dev version number is not right
23:05:45 <stepcut> but forget about the dependency resolution for a second..
23:05:51 <dcoutts> stepcut: personally I would give it a different version simply to stop users getting confused
23:05:59 <stepcut> I care more about the case where everything actually builds ok, but they ended up with source from hackaeg instead of the local directory
23:06:15 <dcoutts> if they report they have v 0.4.1, then knowing that can only have been a released version is rather useful info
23:06:24 <stepcut> right
23:06:44 <mightybyte> Seems to me that the solution is to bump dev immediately.
23:06:47 <stepcut> so it would be sensible to bump everything in darcs to 0.4.2 right after 0.4.1 is upload to hackage?
23:06:55 <dcoutts> stepcut: it probably would
23:07:09 <stepcut> but, what version do I upload to hackage next? 0.4.2? or do I bump again and upload 0.4.3 ?
23:07:29 <dcoutts> I would use an odd-even system
23:07:38 <stepcut> odd for dev, even for release?
23:07:48 <dcoutts> that's traditional
23:08:01 <stepcut> linux kernel used that, right?
23:08:10 <dcoutts> yep
23:08:19 <dcoutts> you can also use extra version components
23:08:20 <stepcut> now it's some wild crap shoot or something
23:08:25 <dcoutts>
23:08:40 <dcoutts> I appreciate there are more robust methods for installing a bunch of related packages
23:08:45 <dcoutts> which are not releases
23:08:52 <dcoutts> are / should be
23:09:00 <stepcut> seems like releasing 0.4.2 and making dev 0.4.3 is better because we can release a minor patch to stable as with out confusion?
23:09:08 <dcoutts> indeed
23:09:46 <stepcut> ok, so for the 0.5 release candidates, what would the version number be?
23:10:10 <dcoutts> there are two choices
23:10:17 <dcoutts> 0.4.9.rev
23:10:36 <dcoutts> or 0.5.1.rev and make 0.5.2 the first release
23:10:44 <stepcut> I guess if they are true release candidates then I could make them.,,, as well?
23:10:58 <dcoutts> true
23:11:07 <stepcut> in cabal land, does 0.5 == ?
23:11:11 <dcoutts> no
23:11:20 <stepcut> is greater?
23:11:20 <dcoutts> it's Ord on [Int]
23:11:34 <stepcut> ok, so it's not like debian where, 0:0-0 and 0 are the same
23:11:42 <dcoutts> > [0,5,0,0] `compare` [0,5]
23:11:43 <lambdabot>   GT
23:11:50 <stepcut> ah
23:12:08 <dcoutts> it's the simplest to explain
23:12:09 <stepcut> as long as is > than 0.5.0, then I am fine
23:12:25 <dcoutts> > [0,5,0,1] `compare` [0,5,0]
23:12:26 <lambdabot>   GT
23:12:59 <stepcut> ok, so this should unwedge the buildbot for GHC 6.10 as well
23:13:16 <dcoutts> I don't know what was wrong, so can't say
23:13:43 <dcoutts> for a system like happs, which consists of multiple related packages that are versioned more or less in sync, we really want a better system for building them in a batch
23:13:54 <stepcut> ok, so one more question. If I changed the dependencies from QuickCheck 1 to QuickCheck 2, and I want to make a new stable release then the version should change from 0.4.x to 0.5.x, because that affects the API?
23:14:16 <dcoutts> and making sure we select the specific local ones, rather than building each independently in the context of other older instance from hackage
23:14:44 <dcoutts> stepcut: it affects the API if you export QC instances
23:14:52 <stepcut> dcoutts: the buildbot failed because we broken a different rule, (we change the API when compiling with -ftests), and cabal install happstack-data -ftests was pulling happstack-util from hackage and building it without the -ftest flag
23:14:54 <dcoutts> if it's a private dependency then it doesn't
23:15:14 <dcoutts> right, flags are presumed not to affect the exported API
23:15:28 <stepcut> dcoutts: we export the quickcheck instances, but also some wrappers for turning QC into HUnit -- so it's a real API change
23:15:38 <dcoutts> ok
23:16:17 <stepcut> anway, I am fine with bumping the verison of the -dev branch to 0.4.3
23:16:33 <stepcut> but I am still uncertain about something
23:17:00 <dcoutts> stepcut: so for some future improvement in cabal I'd like to be able to 1) have multiple .cabal files in one dir, 2) for packages in separate dirs, have a way to indicate "this is a 'source' repository consisting of these packages"
23:17:25 <dcoutts> so that one can use those bundles as targets when constructing install plans
23:17:44 <dcoutts> partly so you can do it in one step, but also so you get better control of the package environment
23:17:58 <stepcut> if I have happstack-util 0.4.3 installed, and happstack-data 0.4.3 can not be installed with out rebuilding happstack-util, and happstack-util 0.4.1 is on hackage.. will happstack-util be downgraded if happstack-data does not explicitly require >= happstack-util 0.4.3
23:18:43 <dcoutts> ACTION thinks
23:19:01 <dcoutts> it may just fail
23:19:05 <stepcut> ok
23:19:13 <dcoutts> it's not very clever with backtracking
23:19:18 <stepcut> :)
23:19:36 <dcoutts> but don't rely on that behaviour, it may will get cleverer
23:19:51 <dcoutts> though I hope also to make it warn if it's not using "preferred" versions of packages
23:20:01 <stepcut> ok, I will also make sure that the 0.4.3 packages also require their deps to be 0.4.3 or greater
23:20:10 <dcoutts> if that's the truth then do it
23:20:41 <stepcut> it's the truth, because I don't want to tell people its fixed in head, and then have them end up with non-head code on their machine :)
23:21:05 <dcoutts> stepcut: are they actually completely versioned in sync?
23:21:55 <dcoutts> might you be best of having happstack-blah depend on happstack-core == 0.5.0.*
23:26:49 <stepcut> dcoutts: they are right now.. I think it will be less confusing to keep them that way, even if nothing changes but the version number
23:28:45 <stepcut> dcoutts: thanks! I'll get this straightened out tomorrow
23:29:12 <dcoutts> sorry it's all a bit confusing
23:33:44 <stepcut> oh since you are here :)
23:34:08 <stepcut> I heard that the base4 flag doesn't actualy exist... it just created out of thin air if setting it True makes things install ?