2010-01-14:
[8:20] <emilis_info> I'm releasing my Helma NG site to the public today :-) It's a website for tracking lithuanian parliament and goverment news: http://kaveikiavaldzia.lt/[9:05] <oberhamsi> minor inconvinience in ng:[9:05] <oberhamsi> when i write to a textstream it always append a \n at the end of file.[9:06] <oberhamsi> and the native json parser doesn't like newlines at the end of a json string :|[9:06] <oberhamsi> so i trim()[9:11] <zumbrunn> emilis_info: I added kaveikiavaldzia.lt to http://helma.org/wiki/Sites+using+Helma/ :-)[9:15] * zumbrunn wonders what exactly botic meant regarding the mailing list search being broken[9:15] <zumbrunn> was there a problem that went away somehow?[9:17] <oberhamsi> don't know works for me[10:23] <hannes_> oberhamsi: the json issue has been sorted out in rhino recently[10:23] <hannes_> so it will be fixed with the next rhino update4[10:24] <hannes_> the textstream issue sounds like a bug[10:24] <hannes_> you may want to report an issue.[10:24] <emilis_info> zumbrunn, thanks :-)[10:47] <oberhamsi> hannes_: thx for the info. added issue for \n http://github.com/hns/helma-ng/issues/#issue/30[16:01] <earl> oberhamsi: hm, seems the bug is in read(), not in write()[16:01] <earl> 00000000 66 6f 6f 20 62 61 72 |foo bar|[16:02] <earl> that's what hd gives me after writing, so no newlines around[16:08] <oberhamsi> earl: you're right, didn't occur to me. will fix issue[16:13] <earl> the remaining issue is questionable[16:13] <earl> not sure if that's not "behaviour as expected" :)[16:14] <earl> i.e. if when opening a file in text mode it's always a list of lines, lines terminated by the platform's line terminator[16:14] <earl> then adding the missing trailing line sep is what'd be expected[16:15] <earl> and if you need the original data verbatim, use 'rb'[16:18] <earl> but i think that'd be rather annoying, so yes, imho read() should not add such a trailing line sep even for text files[16:21] <earl> but to fix that we'd have to either escape to java[16:23] <earl> or change TextStream's semantics to more closely align with java's BufferedReader[16:23] <earl> BufferedReader#readLine won't allow us to find out wether a line was actually terminated by a line sep or by eof[16:25] <earl> so either fall back to lower-level java stuff, or get rid of the line seps in TextStream#readLine, readLines as well[16:36] <oberhamsi> earl: readLine() i understand why it would return \n[16:36] <oberhamsi> readLines() returns an array of lines?[17:55] <earl> oberhamsi: yes, readLines() returns an array of lines, each line with '\n'
In the channel now:
Logs by date: