00:40:50 <HugoDaniel> i like this article
00:40:52 <HugoDaniel> http://thenextweb.com/apple/2010/04/20/apps-replacing-websites-death-of-the-website/
00:41:04 <HugoDaniel> its a nice point of view
07:31:07 <Entroacceptor> !help
14:59:20 <HugoDaniel> w00t formlets!!
14:59:22 <HugoDaniel> :)
14:59:55 <mightybyte> What's the occasion?
15:03:31 <Entroacceptor> w00t
15:03:46 <Entroacceptor> have you done the djangoesque admin stuff yte? ;-P
15:11:41 <HugoDaniel> is it better ?
15:11:47 <HugoDaniel> is it teh best ?
15:15:01 <HugoDaniel> it its teh best, then lets do better :)
15:15:06 <HugoDaniel> *much* better
15:15:23 <HugoDaniel> besides, last time i checked, lambda support in python really sucked...
15:15:57 <HugoDaniel> plone guys are moving to "dexterity" to define their "types" (read: forms), in plone 4
15:16:41 <HugoDaniel> http://www.martinaspeli.net/articles/dexterity
15:16:56 <HugoDaniel> as usual, xml config file is necessary
15:17:07 <HugoDaniel> i mostly see this as a lack of good lambda support
15:17:58 <HugoDaniel> xmonad style configurations, like dyre, are overall a better option
15:33:01 <Entroacceptor> HugoDaniel: lambda aside, the Django admin backend is really nice
15:33:06 <Entroacceptor> easy to use and set up
17:03:58 <siracusa> Hi!
17:05:06 <siracusa> Is Hamlet for HTML templates only?
17:11:35 <stepcut> yes
17:32:32 <bonobo> stepcut: I sent you a patch, again :)
17:32:55 <stepcut> sweet!
17:33:35 <stepcut> not here yet :(
17:39:48 <stepcut> now it is ;)
17:40:12 <stepcut> bonobo: if you set he build type to Simple then it won't do the check for trhsx
17:40:17 <stepcut> you really hate that check don't you ?
17:40:37 <bonobo> well, my windows machine breaks on this check anyway :)
17:41:00 <bonobo> stepcut: we set Build-depends: hsx
17:41:10 <bonobo> and trhsx comes with package hsx these days
17:41:15 <stepcut> but hsx is a library, not an executable
17:41:32 <bonobo> trhsx is alongside there in it
17:41:40 <bonobo> let me check once again
17:42:01 <stepcut> not always.. on debian the trhsx binary is provided in a separate package than the hsx library
17:42:04 <bonobo> http://hackage.haskell.org/packages/archive/hsx/0.6.2/hsx.cabal
17:42:47 <bonobo> anyway doing 'cabal install' while build-type: simple is much faster, as it does not try to compile and use Setup.hs
17:43:23 <stepcut> only faster if your build doesn't fail due to a missing trhsx :)
17:43:39 <bonobo> well, I get you point :)
17:44:14 <bonobo> but then if you change back to Build-type: Custom, please incorporate my if !os(windows) Build-tool: trhsx
17:44:15 <stepcut> anyway, given the non-obviousness of checking for the trhsx binary, I think maybe it is valuable to show how it is done, and let people disable it if they don't like it ?
17:44:22 <stepcut> k
17:44:23 <bonobo> this one is a bug in cabal I think
17:44:29 <stepcut> yeah
17:45:12 <stepcut> the fact that the executable is not linked againsts the libraries that were just built is a 'missing feature' of cabal as well :(
17:45:25 <stepcut> eventually that is supposed to be fixed
17:46:01 <bonobo> everything will be fixed... eventually :)
17:46:14 <stepcut> I hope so!
17:48:48 <stepcut> I think I will apply the rest of the patch though.. I guess most people aren't going to structure their apps as a library + executable, even though they should ;)
17:50:46 <stepcut> ok, I pushed your patch, and a patch that sets the build-type back to custom
17:50:55 <stepcut> your patch for !os(windows) should be in there
17:51:18 <bonobo> Actually it seems to me that making a lib out of an exe is quite easy
17:51:27 <bonobo> one of the things that Cabal got right
17:51:46 <bonobo> stepcut: next patch on the wire! :)
17:52:02 <stepcut> bonobo: I am very dubious of treating ByteStrings as utf-8
17:52:32 <bonobo> as close to ANSI ASCII as you can get these days
17:54:08 <bonobo> if somebody knows better they should use Text library, I think
17:54:09 <stepcut> bah, ASCII is dead. long live ASCII
17:54:31 <stepcut> indeed
17:54:45 <stepcut> you can avoid a lot of problems by only using String / Text in your application
17:54:52 <bonobo> utf-8 seems to be kind of sensible default
17:55:10 <bonobo> have you tried to use <% mtByteString %> in your code?
17:55:33 <stepcut> I think if you are doing that, then you are doing it wrong :)
17:55:38 <bonobo> GHC spits some really strange message for line numer 0 (zero) in the file where this happens
17:55:49 <stepcut> why do you have mtByteString that represents text in the first place ?
17:55:58 <bonobo> why not?
17:56:14 <stepcut> because that is how encoding issues happen :)
17:57:42 <stepcut> you should do, newtype ASCII = ASCII { ascii2bs :: ByteString }
17:57:58 <stepcut> or something
17:58:13 <stepcut> then you won't accidently try to embed image data is a string or something silly
17:58:32 <bonobo> all my ByteStrings are utf-8 :)
17:58:39 <bonobo> my images are also utf-8 :)
17:58:46 <stepcut> bonobo: lame
18:01:40 <stepcut> anyway, Data.ByteString.Char8 would be closer to ascii than Data.ByteString, yes ?
18:02:17 <bonobo> nope
18:02:24 <stepcut> oh ?
18:02:42 <stepcut> "More specifically these byte strings are taken to be in the subset of Unicode covered by code points 0-255. This covers Unicode Basic Latin, Latin-1 Supplement and C0+C1 Controls."
18:02:54 <stepcut> "The Char8 interface to bytestrings provides an instance of IsString for the ByteString type, enabling you to use string literals, and have them implicitly packed to ByteStrings. "
18:03:49 <bonobo> string literals in GHC are utf-8 encoded, AFAIK
18:04:07 <bonobo> and Char8 just takes that as binary data and just does not care
18:04:42 <bonobo> also these days we produce "content-type: text/html; charset=utf-8"
18:05:13 <bonobo> and that means every data you reveive back whether url-encoded or multipart/form-data will be utf-8
18:05:24 <stepcut> what do you mean by 'Char8 just takes that' ?
18:05:42 <stepcut> takes what from where ?
18:05:59 <bonobo> string literal "abc" is really a (fromAddr# "abc") in GHC
18:06:19 <bonobo> and that "abc" is just a char * in C sense
18:06:26 <stepcut> no..
18:08:28 <stepcut> the string literal "abc" in a .hs file will be converted into a [Char] where a Char is a unicode code point.. the .hs are utf-8 encoded, but the compiler decodes them before compiling them
18:10:14 <bonobo> and then they are treated as Char8? so what happens with code points above 255?
18:10:34 <stepcut> no, they are treated as Char
18:10:47 <stepcut> if you convert them to Char8, then they are truncated to 8-bits
18:10:55 <bonobo> just great
18:11:01 <stepcut> so you best not do that if you have any characters above 255 :)
18:11:21 <bonobo> most of my characters are above 255 :(
18:11:57 <stepcut> then you don't have ASCII and should use a type like Text or String which supports unicode ?
18:12:42 <bonobo> well, I could write a rant against Text also, but wont do this
18:13:05 <bonobo> I have fought many encoding wars and the only solution is utf-8 :)
18:13:21 <stepcut> what don't you like about Text ?
18:13:31 <bonobo> Text is 16bit, so does not cover full Unicode 1million chars range
18:13:50 <bonobo> you get the same truncation issues as with Char8, instead you get Char16
18:14:20 <stepcut> are you certain?
18:14:26 <bonobo> the author does not state if Text is UTF-16 or UCS-16, and that is a bad sign
18:14:53 <bonobo> I'm certaing that Text is 16bit and Unicode needs about 1000000 code points
18:15:19 <Zao> bonobo: Data.Text is an efficient storage for arbitrary code points.
18:15:20 <bonobo> if Text is UTF-16, then you get simillar encoding as UTF-8, just uses words instead of bytes
18:15:39 <bonobo> but length text is not really length in code points
18:16:13 <Zao> Data.Text.length gives you the number of characters.
18:16:18 <bonobo> if Text is UCS-16 then you get either not full range or you get some other artificial difficulties like surrogate pairs and whatever
18:16:18 <stepcut> bonobo: I am fairly certain that it supports the full Unicode set. The internal encoding is never specified because it is not accesible to the user anyway
18:16:23 <bonobo> Zao: I hope so
18:16:25 <Zao> What package are you talking about?
18:16:41 <Zao> bonobo: It exposes a nice friendly interface. The internal storage does not escape.
18:16:54 <bonobo> Zao: so how does package text represent code points above 65535?
18:17:02 <Zao> bonobo: Internal magic.
18:17:31 <bonobo> Zao: :) you mean like utf-8? :)
18:17:44 <Zao> bonobo: No.
18:17:46 <Zao> "A time and space-efficient implementation of Unicode text using packed Word16 arrays."
18:17:55 <bonobo> Zao: Data.ByteString.UTF8.length also returns number of code points :)
18:18:22 <bonobo> UTF8: "A time and space-efficient implementation of Unicode text using packed Word8 arrays."
18:18:24 <bonobo> :)
18:18:35 <Zao> Why the FUD against Data.Text?
18:18:50 <Zao> "it can represent non-BMP, lol"
18:18:54 <Zao> *can't
18:18:57 <bonobo> "internal magic" does not convince me much
18:19:19 <Zao> You cannot accidentally grab half a code point out of a Text.
18:19:39 <bonobo> Zao: that is better, true
18:19:53 <Zao> You have no access whatsoever (except Foreign) to code units.
18:23:46 <bonobo> Zao: reading the source right now
18:23:58 <bonobo> Zao: looks like it is utf16 internally
18:24:59 <stepcut> bonobo: can you give me an example where you think Text might return the wrong value for 'length' ?
18:25:15 <stepcut> bonobo: or anything else..
18:25:44 <bonobo> nope
18:25:55 <bonobo> it is good
18:26:08 <stepcut> yay!
18:26:26 <bonobo> I just dont see any advantage of UTF16 over UTF8
18:26:43 <stepcut> it's not an issue of UTF8 or UTF16
18:26:58 <bonobo> and actually could imagine same guaranties as Data.Text has over ByteString.UTF8
18:27:00 <stepcut> it is an issue of dealing with an encoded string vs dealing with unicode
18:27:06 <bonobo> with a new library
18:27:50 <stepcut> what would that new library do ?
18:28:29 <bonobo> nothing, ByteString.UTF8 is good enough for me
18:28:52 <Zao> bonobo: All you need to know is that the documentation tells you it's Word16 internally.
18:28:53 <stepcut> where does ByteString.UTF8 come from ?
18:29:01 <Zao> bonobo: Internal implementation detail is irrelevant to the public interface.
18:29:25 <Zao> bonobo: UTF-16 has less storage overhead for CJK scripts.
18:29:36 <bonobo> Zao: me being scared comes from the Windows land, where wchar_t is 16 bit and there are issues this this
18:29:37 <Zao> And could be argued has less processing and conversion costs.
18:29:59 <bonobo> so, ok, text got this right :) cool :)
18:30:12 <Zao> Trust the documentation.
18:30:35 <bonobo> Zao: from web I get strings as UTF8, so could argue with changing to utf16 is worthwhile
18:30:47 <stepcut> bonobo: both String and Text got it right. Which is why it is nice that your apps can just use String / Text, internally, and only convert to an encoded format when crossing an I/O boundary (such as writing to disk, network, database, etc)
18:31:12 <bonobo> Zao: doc says 16bit, could say more for scared souls like me
18:31:38 <Zao> bonobo: If you need to process it as whole code units, you need some kind of fancy string type.
18:31:45 <Zao> May it be Text, String, or whatever.
18:31:53 <stepcut> only converting to the encoded format at the IO boundary makes it easier to use different encodings at different IO boundaries. People have had the unfortunate case of needed to use happstack on systems that used utf-8 for the html, but a different encoding when reading from a SQL database
18:31:59 <Zao> ByteString on the other hand, is a sequence of bytes, with no concept of code units.
18:32:12 <Zao> Internally you should use a proper string type.
18:32:34 <Zao> Data.Text has encoding/decoding functions from all the transformation formats.
18:33:20 <bonobo> ok, going back to topic
18:34:01 <bonobo> I think happstack should have reasonable 'embed bytestring inside xml' instances
18:34:29 <bonobo> and put something there, otherwise error given by GHC is really scary and does not say anything
18:34:33 <stepcut> Zao: exactly. If you had a system where you had to use utf-8 to talk to one source, and some latin-1 for a different source, and you treated them both as ByteString, I think you would run into no end of mixups. But if you always converted to Text, then you would stay sane..
18:34:47 <bonobo> seems like GHC bug/limitation too
18:35:05 <stepcut> bonobo: there is no reasonable embed bytestring instead xml because a bytestring can be anything. A better error would be nice though
18:35:19 <bonobo> stepcut: true
18:35:52 <bonobo> error is really bad, mostly because it point to the beginning of file (line zero) instead of the line it all happened
18:36:17 <stepcut> yeah, that is an annoying habit of GHC
18:39:41 <bonobo> are there embed as xml instances for Data.Text?
18:41:31 <stepcut> bonobo: dunno. But there should be.
18:42:19 <bonobo> stepcut: so what about my patch? either it goes to happstack or I need to have those instances in my own project, until I convert to Data.Text :)
18:42:35 <stepcut> won't go in happstack :)
18:43:05 <bonobo> ok :)
18:43:48 <bonobo> then who is going to fix GHC?
18:44:19 <stepcut> simon
18:45:13 <Zao> If you want arbitrary data in XML, there's always CDATA, isn't there?
18:45:48 <stepcut> Zao: hmm. I am pretty sure that is what people want to happen about 0% of the time
18:46:23 <Zao> stepcut: I find it quite rare that any schema would mandate "and here, arbitrary binary dung".
18:46:32 <stepcut> :)
18:46:33 <Zao> At least encode it in say base64 or something equally friendly.
18:46:49 <Zao> It's XML, it's not supposed to be efficient.
19:12:55 <stepcut> instance (EmbedAsChild m String) => EmbedAsChild m Text.Text where
19:12:56 <stepcut>     asChild text = asChild (Text.unpack text)
19:48:31 <stepcut> that is a bit bogus though :-/
21:39:57 <HugoDaniel> hello there