MoinMoin: MoinMoinChat/Logs/moin-dev/2006-06-08

2006-06-08T00:16:16  <ThomasWaldmann> mvirkkil: from MoinMoin.security.antispam import SecurityPolicy (see CHANGES)
2006-06-08T00:31:42  <mvirkkil> ThomasWaldmann: The problem is that I synced with trunk.
2006-06-08T00:32:01  <mvirkkil> ThomasWaldmann: And that made the moves
2006-06-08T00:32:23  <mvirkkil> ThomasWaldmann: But the wikiconfig on the testserver assumes it's the old directory layout.
2006-06-08T00:32:49  <mvirkkil> ThomasWaldmann: so docbook.wikiwikiweb.de no longer works :/
2006-06-08T00:33:47  <mvirkkil> So either that configuration needs to be fixed, or I need to revert my sync with trunk.
2006-06-08T00:33:52  <mvirkkil> ThomasWaldmann: Which one?
2006-06-08T02:46:26  <nwp_> I've put up http://moinmoin.wikiwikiweb.de/MoinDev/MoinAuth re. the auth stuff I was talking about before.
2006-06-08T02:46:55  <nwp_> would be good if ThomasWaldmann & co could have a look and see if it makes sense to them :-)
2006-06-08T08:39:41  <ThomasWaldmann> mvirkkil: syncing with trunk is no problem, but a thing you should do regularly :)
2006-06-08T08:40:06  <ThomasWaldmann> oh, I'll fix the test wikis
2006-06-08T08:44:07  * ThomasWaldmann fixed all SOC student test wikis to work with current 1.6/moin code. please merge the current 1.6 code if you didnt do already.
2006-06-08T09:00:30  <mvirkkil> ThomasWaldmann: The MailTo macro is broken: It uses the mail module to decode the antispam e-mail, but the mail module moved and it can't find it
2006-06-08T09:01:12  <mvirkkil> MoinMoin/macro/__init__.py  line 467 "from MoinMoin.util.mail import decodeSpamSafeEmail"
2006-06-08T09:01:44  <ThomasWaldmann> thanks, i fix it
2006-06-08T09:01:58  <mvirkkil> though your line might be different, as I have changed that part of the code to fix it to use the formatter properly
2006-06-08T09:02:16  <mvirkkil> really trivial fixes though, shouldn't cause problems merging.
2006-06-08T09:06:24  <ThomasWaldmann> fixed
2006-06-08T09:07:38  <mvirkkil> ThomasWaldmann: Hmm.. Still broken on docbook.wikiwikiweb.de Do I need to resync with trunk or should it work?
2006-06-08T09:08:58  <ThomasWaldmann> yes
2006-06-08T09:09:09  <ThomasWaldmann> i fixed it in main branch
2006-06-08T09:09:45  <mvirkkil> ThomasWaldmann: I just came to work, and I'm going to be away from my computer ~12h, so I won't be able to resync in quite a while.
2006-06-08T09:10:27  <mvirkkil> ThomasWaldmann: I could just remove the macro for the time being, so that the wiki won't appear broken.
2006-06-08T09:11:16  <mvirkkil> ThomasWaldmann: or if you have the time, I wouldn't mind if you wanted to resync it?
2006-06-08T09:13:41  <ThomasWaldmann> i dont think anyone except you and maybe some other moin devels will use the test wiki
2006-06-08T09:13:57  <ThomasWaldmann> so just merge when you are back
2006-06-08T09:15:15  <mvirkkil> ThomasWaldmann: actually, some people from ubuntu and fedora have tried it out to see where it stands.. I commented out the macro, will resync when I get home.
2006-06-08T09:19:51  <mvirkkil> Was the unittests for the mail module removed from trunk?
2006-06-08T09:20:40  <mvirkkil> nevermind, they seem to have been just moved
2006-06-08T09:22:04  <ThomasWaldmann> yes
2006-06-08T09:55:41  <xorAxAx> mvirkkil: of course keeping compatiblity of the antispam module name is totally unpossible :)
2006-06-08T09:55:45  <xorAxAx> s/unp/imp/
2006-06-08T09:56:24  <mvirkkil> xorAxAx: hmm.. not sure what you are referring to
2006-06-08T09:56:39  <xorAxAx> mvirkkil: the problem you had with the test wiki
2006-06-08T09:56:45  <xorAxAx> mvirkkil: not your fault of course :)
2006-06-08T09:59:44  <ThomasWaldmann> xorAxAx: i dont want to have compatibility stubs all over the place
2006-06-08T10:00:26  <xorAxAx> ThomasWaldmann: why not? they can be separated and be removed in the version after they have been introduced
2006-06-08T10:00:42  <ThomasWaldmann> but I'll add some end user note how to change configs
2006-06-08T10:01:05  <ThomasWaldmann> this only leads to people having problems when we remove the stubs
2006-06-08T10:01:30  <xorAxAx> it allows the people to have a seamless migration
2006-06-08T10:01:40  <ThomasWaldmann> this only leads to people having problems when we remove the stubs
2006-06-08T10:02:12  * mvirkkil is keeping clear from this debate
2006-06-08T11:03:27  <mvirkkil> ThomasWaldmann: Is it a bug or an undocumented feature, that using Include for generating the heading, the heading gets linked to the included page
2006-06-08T11:03:30  <mvirkkil> ?
2006-06-08T11:04:34  <mvirkkil> And it seems the examples on help in macros think that if I write
2006-06-08T11:04:35  <mvirkkil> [[Include(WikiEngine, )]]
2006-06-08T11:04:50  <mvirkkil> it would get automagically a first level heading, which it doesnt.
2006-06-08T11:05:30  <mvirkkil> Nor does [[Include(WikiEngine, , 2)]] create a second level heading.
2006-06-08T11:07:08  <mvirkkil> I'm is this a bug in the Include macro or in the documentation?
2006-06-08T11:11:54  <ThomasWaldmann> mvirkkil: Include macro is a big mess and I rarely use it
2006-06-08T11:13:11  <mvirkkil> ThomasWaldmann: Argh.. Don't say that. I was planning on basing my whole "make docbook book by including wikipages as chapters" funtionality on it :(
2006-06-08T11:14:23  <mvirkkil> ThomasWaldmann: But then again, I wasn't going to copypaste anything, just use it, so if it gets rewritten, hopefully my code would be easy to fix. The magic happens in the formatter anyway.
2006-06-08T11:15:35  <ThomasWaldmann> I just can't comment on Include as I rarely use and rarely hack it.
2006-06-08T11:15:46  <mvirkkil> ThomasWaldmann: Who should I talk to?
2006-06-08T11:18:10  <ThomasWaldmann> maybe look in annotate who substantially hacked it :)
2006-06-08T11:20:37  * mvirkkil is looking and noticing that almost every line starts by "tw-public@0" :)
2006-06-08T11:22:02  <mvirkkil> But the copyright bore more clues...
2006-06-08T11:22:40  <mvirkkil> Jürgen Hermann seems to have been working on it up until '04..
2006-06-08T11:23:50  <xorAxAx> mvirkkil: then you have to annotate the 1.3 branch
2006-06-08T11:24:00  <xorAxAx> they are not connected because the converter doesnt suppoert branches
2006-06-08T11:24:11  <xorAxAx> and if you have the same result there, annotate the 1.3 branch
2006-06-08T11:24:14  <xorAxAx> 1.2 even
2006-06-08T11:24:52  <mvirkkil> xorAxAx: Ahhh.. ok.
2006-06-08T11:25:19  <xorAxAx> but it wont help much ...
2006-06-08T11:25:57  <xorAxAx> the include macro violates all design principles of the moin component model
2006-06-08T11:26:10  <xorAxAx> it parses pages on its own etc.
2006-06-08T11:27:46  <mvirkkil> xorAxAx: I agree that it could use a rewrite, but it works and is rich in functionality. And will be really useful for generating large docbooks.
2006-06-08T11:28:44  <xorAxAx> muhahaha, it works for wiki.py pages, yes :)
2006-06-08T11:28:54  <xorAxAx> except for anchor generation etc.
2006-06-08T11:28:58  <xorAxAx> there are many known bugs
2006-06-08T11:29:51  <mvirkkil> xorAxAx: Hmm...
2006-06-08T11:30:03  <mvirkkil> xorAxAx: I could write a "simpleinclude"
2006-06-08T11:30:24  <mvirkkil> xorAxAx: which wouldn't have the from-to -funtionality
2006-06-08T11:30:45  <mvirkkil> xorAxAx: I can't see how to implement the from-to in moin.
2006-06-08T11:31:18  <mvirkkil> and I'm not sure I could make anchors work anyway...
2006-06-08T11:32:10  <xorAxAx> from to is a problem, yes
2006-06-08T11:32:33  <xorAxAx> but it could have a fallback mode for those parameters
2006-06-08T11:33:00  <mvirkkil> but right now I don't have the time. I'll just make my DocbookChapter(pagename) not rely on from to.
2006-06-08T11:33:49  <mvirkkil> So that if another better Include macro comes along, even one that doesn't support all the features, my macro can be easily changed to using that.
2006-06-08T11:44:47  <xorAxAx> if nobody writes it, there wont be another one
2006-06-08T11:45:01  <xorAxAx> so dont expect it :)
2006-06-08T11:46:14  <mvirkkil> xorAxAx: I won't hold my breath, but the from->to part is impossible to implement without either the parsers support, or some weird hack in the formatter.
2006-06-08T11:46:28  <xorAxAx> mvirkkil: that is correct
2006-06-08T11:47:36  <mvirkkil> Hmmm. Actually, we could just do it in the formatter.
2006-06-08T11:47:54  <xorAxAx> the formatter doesnt see the source
2006-06-08T11:47:55  <mvirkkil> Each formatter would need to special case the handling of that macro though.
2006-06-08T11:48:31  <mvirkkil> xorAxAx: Nope, but they see the text as it rushes by..
2006-06-08T11:48:43  <xorAxAx> the parser could have a parameter
2006-06-08T11:48:50  <xorAxAx> mvirkkil: but from/to is used to match comments
2006-06-08T11:48:55  <xorAxAx> in most cases
2006-06-08T11:49:05  <mvirkkil> aah. didn't know
2006-06-08T11:49:14  <xorAxAx> i.e. its dirty
2006-06-08T11:49:19  <mvirkkil> well, putting it in the parser is better anyway.
2006-06-08T11:49:33  <mvirkkil> from an architectural pow
2006-06-08T11:50:10  <xorAxAx> one could use a filter-parser that is used instead of the std. parser
2006-06-08T11:50:12  <mvirkkil> I just happen to know formatters a lot better than parsers. Oh and I think parser should pass the comments along to formatters really..
2006-06-08T11:50:44  <xorAxAx> and the filter parses contains te default-parser and filters the lines
2006-06-08T11:51:33  <mvirkkil> xorAxAx: That's a neat idea, but one filterparser would need to be created for each contenttype
2006-06-08T11:51:41  <xorAxAx> nope
2006-06-08T11:51:50  <mvirkkil> xorAxAx: hmm.
2006-06-08T11:51:53  <mvirkkil> you're right.
2006-06-08T11:52:41  <mvirkkil> Well, except if you take in to account that I want the from starting at the heading which has the text "About MoinMoin" and till the beginning of the next same level heading.
2006-06-08T11:53:12  <mvirkkil> No, wait..
2006-06-08T11:53:21  <mvirkkil> That would work too with the filterparser.
2006-06-08T11:53:29  <mvirkkil> Just matching on a lower level.
2006-06-08T11:53:41  <mvirkkil> I think the idea of a filter parser is pretty great.
2006-06-08T11:54:33  <xorAxAx> of course ;-)
2006-06-08T11:54:36  <mvirkkil> As long as there is no need to separate if the match should be inside some block, but the current version doesn't suport that either
2006-06-08T11:55:09  <mvirkkil> Good stuff xorAxAx
2006-06-08T11:55:27  <xorAxAx> hehe
2006-06-08T11:55:31  <mvirkkil> So writing a better include macro could be relatively simple :)
2006-06-08T11:55:47  <mvirkkil> Without losing backwards compatability with the old one.
2006-06-08T11:56:01  <mvirkkil> And it would be a lot shorter.
2006-06-08T11:57:15  <xorAxAx> yep
2006-06-08T11:57:34  <xorAxAx> and the heading links should be generated in the formatter
2006-06-08T11:57:37  <xorAxAx> s/links/ids/
2006-06-08T11:58:56  <mvirkkil> xorAxAx: I don't know really, but probably yes...
2006-06-08T11:59:17  <xorAxAx> and the formatter would need a list of headings
2006-06-08T11:59:26  <xorAxAx> like it knows already which links are there
2006-06-08T12:00:22  <mvirkkil> xorAxAx: Hmm.. It might be good to document this strategy somewhere so that it can be used later as a reference.
2006-06-08T12:00:45  <mvirkkil> xorAxAx: Perhaps start a bug called "Re-implement a cleaner Include-macro"?
2006-06-08T12:01:30  <mvirkkil> xorAxAx: I'm not going to take the bug at this point, as I don't feel confident enough regarding my own project.
2006-06-08T12:01:59  <xorAxAx> mvirkkil: yeah, you could make a kind of meta bug page
2006-06-08T12:02:43  <mvirkkil> xorAxAx: Hehe :) I was thinking that you as a senior moin-dev would want to do it so it would get properly done ;)
2006-06-08T12:03:05  <xorAxAx> mvirkkil: i will change it afterwards :)
2006-06-08T12:03:31  <mvirkkil> xorAxAx: Ahh, heck.. I'll do it then.
2006-06-08T12:16:47  <mvirkkil> xorAxAx: Can I pass an existing formatter instance to a parser so that it won't create a new one?
2006-06-08T12:17:29  <mvirkkil> Because IIRC it usually takes just the class..
2006-06-08T12:17:49  <xorAxAx> the parser doesnt create the formatter
2006-06-08T12:19:36  <mvirkkil> xorAxAx: no, you are righ. The Page does.
2006-06-08T12:19:45  <mvirkkil> xorAxAx: But it's still the same problem.
2006-06-08T12:20:05  <mvirkkil> Page(request, pagename, formatter=formatterType)
2006-06-08T12:20:38  <xorAxAx> why are you asking?
2006-06-08T12:54:10  <mvirkkil> xorAxAx: never mind, I'm stupid ;)
2006-06-08T12:55:54  <mvirkkil> xorAxAx: http://moinmoin.wikiwikiweb.de/MoinMoinBugs/ReImplementCleanerIncludeMacro
2006-06-08T12:56:32  <mvirkkil> I've probably forgot some stuff, and some details might be wrong. A review would be appreciated.
2006-06-08T13:00:57  <xorAxAx> mvirkkil: look at the page again :)
2006-06-08T13:04:34  * xorAxAx updated it again
2006-06-08T13:04:36  <ThomasWaldmann> include for 1.6+ should handle mimetype
2006-06-08T13:06:00  <mvirkkil> ThomasWaldmann: In what way?
2006-06-08T13:06:34  <ThomasWaldmann> we'll have generic items soon, not only pages
2006-06-08T13:07:06  <mvirkkil> oh, ok.
2006-06-08T13:07:18  <mvirkkil> xorAxAx: How would the id
2006-06-08T13:07:25  <ThomasWaldmann> so include should be generic, too, not only handling text/moin-wiki and text/*, but */*
2006-06-08T13:07:25  <mvirkkil> xorAxAx: How would the ids generation work?
2006-06-08T13:07:27  <xorAxAx> SyntaxError :)
2006-06-08T13:07:42  <xorAxAx> mvirkkil: simply have a function that returns always the same output for a given input
2006-06-08T13:07:55  <xorAxAx> mvirkkil: currently it is using a prefix and an sha hash
2006-06-08T13:08:01  <xorAxAx> but thats stupid
2006-06-08T13:08:05  <mvirkkil> xorAxAx: Ok, sha.. But I mean how would everything be called?
2006-06-08T13:08:08  <xorAxAx> mitsuhiko has a closed source solution
2006-06-08T13:08:17  <xorAxAx> mvirkkil: called?
2006-06-08T13:08:29  <ThomasWaldmann> so include can also show an image/jpeg item at the place you call it
2006-06-08T13:08:33  <mvirkkil> I mean what functions will be called and from where
2006-06-08T13:08:47  <mvirkkil> in respect to the id generation
2006-06-08T13:08:49  <mvirkkil> in tocs
2006-06-08T13:09:00  <xorAxAx> mvirkkil: include needs to call formatter.getHeadings() to gather the headings for the toc
2006-06-08T13:09:12  <ThomasWaldmann> and later, we will remove image link magic. a link will be a link, no more, no less.
2006-06-08T13:09:22  <xorAxAx> mvirkkil: and then it needs to call this central function instead of duplicating code
2006-06-08T13:09:46  <xorAxAx> this = the id-genearation code
2006-06-08T13:09:52  <mvirkkil> So if the heading appears twice in different places it will break?
2006-06-08T13:10:32  <xorAxAx> oh, it breaks quite often
2006-06-08T13:10:45  <xorAxAx> mvirkkil: that needs to be solved
2006-06-08T13:10:52  <xorAxAx> currently, nesting includes doesnt work at all with TOC
2006-06-08T13:11:00  <xorAxAx> i.e. the ids are wrong
2006-06-08T13:11:22  <mvirkkil> xorAxAx: but I'm not even talking about nested includes.
2006-06-08T13:11:25  <xorAxAx> mvirkkil: the function would get a pagename as well
2006-06-08T13:11:38  <xorAxAx> mvirkkil: then you can include it in the id
2006-06-08T13:11:58  <xorAxAx> hmm, not necessary
2006-06-08T13:12:11  <xorAxAx> IMHO duplicate names should yield multiple names
2006-06-08T13:12:19  <mvirkkil> xorAxAx: I mean if I have a page, with _no_ includes and I want a TOC, the TOC would be broken.
2006-06-08T13:12:29  <xorAxAx> umm, multiple tags with the same name
2006-06-08T13:12:34  <mvirkkil>  simply have a function that returns always the same output fora given input
2006-06-08T13:12:46  <mvirkkil> 14:07:42< xorAxAx> mvirkkil: simply have a function that returns always the same output for a given input
2006-06-08T13:12:49  <xorAxAx> mvirkkil: no, it would not be broken
2006-06-08T13:13:06  <xorAxAx> the user doesnt have a reason to have multiple headings with the same title :)
2006-06-08T13:13:10  <xorAxAx> on the same page
2006-06-08T13:13:18  <mvirkkil> xorAxAx: Thats rediculous.
2006-06-08T13:13:20  <xorAxAx> otherwise you need state logic
2006-06-08T13:13:24  <xorAxAx> then it goes into the formatter
2006-06-08T13:13:41  <xorAxAx> problem solved :)
2006-06-08T13:14:18  <mvirkkil> xorAxAx: Let's say I have a page wich describes three similar programs. For each program I would have the same subheadings quite naturally.
2006-06-08T13:14:26  <xorAxAx> mvirkkil: yep
2006-06-08T13:14:44  <mvirkkil> xorAxAx: Placing it in the formatter isn't a bad idea imho.
2006-06-08T13:14:55  <xorAxAx> its the only bearable solution with the current model
2006-06-08T13:15:08  <mvirkkil> but the formatter doesn't know what the toc will contain before it has generated the complete page.
2006-06-08T13:15:14  <xorAxAx> and the name would go MainHeading_SubHeading(_counter)
2006-06-08T13:15:30  <xorAxAx> mvirkkil: the formatter doesnt generate the toc
2006-06-08T13:15:42  <xorAxAx> the macro does
2006-06-08T13:15:55  <xorAxAx> and the macro has to spawn a new formatter of course
2006-06-08T13:16:10  <mvirkkil> ahh, you were talking about the id generation, when you said "then it goes into the formatter"
2006-06-08T13:16:22  <mvirkkil> I thought you meant the toc generation in general.
2006-06-08T13:17:20  <mvirkkil> but yeah, it should go in to the formatter.
2006-06-08T13:17:34  <mvirkkil> maybe...
2006-06-08T13:17:40  <xorAxAx> i  mean the toc generation
2006-06-08T13:17:44  <xorAxAx> but not explicitly
2006-06-08T13:17:54  <xorAxAx> the formatter would gather a list of headings
2006-06-08T13:18:07  <xorAxAx> the toc macro would need to query it
2006-06-08T13:18:30  <xorAxAx> after the processing of the page -> you could have a heading formatter as well
2006-06-08T13:18:41  <xorAxAx> if you always plan to have this second pass
2006-06-08T13:18:45  <mvirkkil> xorAxAx: that would mean we would have to parse and format the whole page twice.
2006-06-08T13:18:51  <xorAxAx> yes!
2006-06-08T13:19:06  <mvirkkil> urgh...
2006-06-08T13:19:07  <xorAxAx> moin doesnt support anything else currently
2006-06-08T13:19:18  <mvirkkil> that's true..
2006-06-08T13:19:29  <mvirkkil> not that I like it..
2006-06-08T13:20:18  <mvirkkil> Luckily the docbook backend will never use a TOC, since it's specified that it should be generated by the docbook viewer.
2006-06-08T13:20:32  <mvirkkil> Hmm..
2006-06-08T13:21:08  <mvirkkil> How about intercepting the parsers calls for generating headings, and doing nothing on other formatting?
2006-06-08T13:21:15  <mvirkkil> That would make it fast.
2006-06-08T13:21:33  <mvirkkil> Then it would only need parsed, and the "formatter" would just be extremely simple...
2006-06-08T13:22:24  <mvirkkil> Just keeping state information for headings, and doing nothing on everyhing else.e
2006-06-08T13:23:04  <mvirkkil> + no changes to existing formatters or parsers.
2006-06-08T13:23:55  <mvirkkil> And would work with the include macro.
2006-06-08T13:25:05  <mvirkkil> Hmm. The basic problem with the include macro as it exists today is that it spawns a new formatter for every include. If it just use the parent's formatter, it wouldn't be so much of a problem.
2006-06-08T13:29:52  <xorAxAx> mvirkkil: your suggestion above is equivalent to mine.
2006-06-08T13:30:07  <xorAxAx> mvirkkil: it means having a "heading formatter"
2006-06-08T13:30:14  <mvirkkil> xorAxAx: Ahh, so you never ment the "real" formatter to be queried?
2006-06-08T13:30:17  <mvirkkil> ok..
2006-06-08T13:30:23  <xorAxAx> mvirkkil: for wiki pages, that increases the speed by ~ 30%
2006-06-08T13:30:24  <xorAxAx> not much
2006-06-08T13:30:38  <mvirkkil> xorAxAx: 30% is a lot.
2006-06-08T13:30:45  <xorAxAx> (as compared by generating byte code like in a caching scenario :))
2006-06-08T13:31:43  <mvirkkil> xorAxAx: For docbook if it would be needed the gains would probably be around 1000%-10000% (10-100 times faster) maybe more.
2006-06-08T13:31:54  <xorAxAx> mvirkkil: ?
2006-06-08T13:32:46  <mvirkkil> I mean if you used a special simple heading-collector-formatter instead of formatting it with the docbook formatter.
2006-06-08T13:33:17  <mvirkkil> ...what ever..
2006-06-08T13:33:34  <mvirkkil> Anyway, you seem to have a solid plan.
2006-06-08T13:33:43  <mvirkkil> Please document it ;)
2006-06-08T13:35:04  <xorAxAx> ah, expat + minor logic? %-)
2006-06-08T13:35:19  <xorAxAx> ok, adding some info
2006-06-08T13:36:28  <mvirkkil> xorAxAx: The dom-handling is _extremely_ slow compared to just outputting bits of strings like the html formatter does.
2006-06-08T13:37:28  <xorAxAx> mvirkkil: its cached
2006-06-08T13:37:34  <xorAxAx> nobody minds :)
2006-06-08T13:37:43  <mvirkkil> xorAxAx: But it might be that it's just memory intensive and not slow, but because I'm working on the code on a laptop with too little memory, it just gets amazingly slow.
2006-06-08T13:37:58  <mvirkkil> xorAxAx: How is it cached?
2006-06-08T13:38:03  <xorAxAx> 4suite xslt is memory-intensive
2006-06-08T13:38:18  <xorAxAx> mvirkkil: moin builds up a byte-code representation of every page
2006-06-08T13:38:43  <mvirkkil> xorAxAx: I'm not even using xslt, yet. Just basic dom manipulations like createElemenr, appendChild etc.
2006-06-08T13:38:50  <xorAxAx> hmm
2006-06-08T13:39:06  <xorAxAx> using which dom implementation?
2006-06-08T13:39:30  <mvirkkil> xorAxAx: A slow one (I've looked in to it and I should use another one).
2006-06-08T13:39:53  <xorAxAx> there are many written in c
2006-06-08T13:40:04  <xorAxAx> there is one on codespeak which claims to be the most-pythonic one
2006-06-08T13:40:05  <mvirkkil> xorAxAx: 4dom. Problem was that this one supports doctypes, and the domlette stuff didn't.
2006-06-08T13:40:28  <mvirkkil> And when I started this, it wasn't very clear which ones would get accepted.
2006-06-08T13:41:13  <mvirkkil> I've done dom manipulations in a lot of languages, so when I started it was easiest for me to pick one that would closely adhere to the w3c spec for dom-operations.
2006-06-08T13:41:21  <mvirkkil> accepted in to pyxml
2006-06-08T13:41:40  <mvirkkil> But I know 4DOM is old and slow.
2006-06-08T13:42:49  <mvirkkil> Testing different implementations and changing to a faster (but complete) -one is on my to do "when everything else is done, all bugs are fixed, everything is documented and has testcases" -list.
2006-06-08T13:43:36  <mvirkkil> But for now I'll use 4DOM because it works, and is widely available.
2006-06-08T13:43:37  <ThomasWaldmann> :w never.txt
2006-06-08T13:43:55  <mvirkkil> lol
2006-06-08T13:45:32  * ThomasWaldmann stores his in /dev/null
2006-06-08T13:48:33  <mvirkkil> ThomasWaldmann: I do almost the same thing, I decide that I'll have to remember to do that.
2006-06-08T13:48:56  <mvirkkil> hmm, that's not a good sentence.
2006-06-08T13:48:59  <mvirkkil> Oh, well.
2006-06-08T13:51:40  <mvirkkil> xorAxAx: how will the ids get passed in to the actual (final) formatter, to generate the anchor links?
2006-06-08T13:52:57  <mvirkkil> hmm, "anchor links" is a bit confusing, I mean the actual "anchors" the links point to, that need to be in every heading.
2006-06-08T14:15:01  <xorAxAx> mvirkkil: the formatter puts them into the headings
2006-06-08T14:15:08  <xorAxAx> the normal one
2006-06-08T14:15:13  <xorAxAx> (or should put)
2006-06-08T14:19:01  <mvirkkil> xorAxAx: But how does the formatter get them=
2006-06-08T14:19:04  <mvirkkil> =
2006-06-08T14:19:13  <xorAxAx> it generates them
2006-06-08T14:19:14  <mvirkkil> argh, I'll try the last third time: ?
2006-06-08T14:19:27  <mvirkkil> xorAxAx: ahh..
2006-06-08T14:19:56  <xorAxAx> so it needs state logic
2006-06-08T14:20:04  <mvirkkil> xorAxAx: So the idea is that the simple-heading-counting-formatter and the real formatter use the same logic and states for creating them?
2006-06-08T14:20:27  <xorAxAx> yes, or firstly just modify the formatterbase and then try to optimise it afterwards
2006-06-08T14:20:29  <mvirkkil> or at least interpret the states more or less the same
2006-06-08T14:20:57  <mvirkkil> Yeah, this should really be transparently done in formatterbase.
2006-06-08T14:22:56  <mvirkkil> or then another idea is to give the list of ids in the correct order, and then letting the formatter use those in the right order, if it wants to.
2006-06-08T14:23:34  <xorAxAx> %-)
2006-06-08T14:23:37  <mvirkkil> regarding "  this should really be transparently done in formatterbase", I mean by this==the generation part. The insertion part
2006-06-08T14:23:58  <mvirkkil> needs to be done in the actual formatter, naturally.
2006-06-08T14:41:30  <ThomasWaldmann> fpletz: how's it going? maybe give some signs of life :)
2006-06-08T14:45:01  <ThomasWaldmann> fpletz: if you have moin-related problems that keep you back, just ask here
2006-06-08T14:50:58  <ThomasWaldmann> fpletz: keep in mind that in last week of june mentors have to do "mid program evaluations"
2006-06-08T14:52:38  <ThomasWaldmann> fpletz: so near half of the time until mentors begin that is already over
2006-06-08T15:53:03  <fpletz> ThomasWaldmann: well, I got some problems.. I have been reviewing and partly rewriting the parser code since a few days but haven't got any means to test it because xapian doesn't seem to work here. I enabled it and show_timings in wikiconfig.py. furthermore, it seems no index is being built in the data_dir.
2006-06-08T15:53:08  <fpletz> my testwiki is working fine, though
2006-06-08T15:54:03  <richardb> Hi
2006-06-08T15:54:18  <richardb> Can you run the basic xapian tests.
2006-06-08T15:54:28  <fpletz> yeah, xapian works great
2006-06-08T15:54:44  <fpletz> but not the current integration into moinmoin
2006-06-08T15:55:31  <fpletz> my wiki never uses xapian for searching
2006-06-08T15:56:27  <richardb> Might be worth committing your current changes, so Thomas and I can take a look at it.
2006-06-08T15:56:41  <richardb> Or is this with the version as currently committed in your hg tree?
2006-06-08T15:57:25  <fpletz> yup, with the committed version
2006-06-08T15:57:56  <richardb> Hmm. I'll take a look at it on my system.
2006-06-08T15:58:30  <fpletz> did you test thomas' basic xapian integration?
2006-06-08T15:58:42  <fpletz> perhaps it's just my fault ;)
2006-06-08T16:02:20  <richardb> Do you perhaps have a default system installation of MoinMoin?
2006-06-08T16:02:32  <richardb> Which is getting used instead of your modified version?
2006-06-08T16:03:10  <fpletz> no, I haven't got another one installed.. I'm also setting sys.path manually
2006-06-08T16:08:43  <fpletz> ThomasWaldmann: there? ;)
2006-06-08T16:17:43  <richardb> Hmm.
2006-06-08T16:17:58  <richardb> I think the documentation for installing MoinMoin as a standalone server may be a little out of date.
2006-06-08T16:19:43  <fpletz> I'm using the fastcgi version, it's pretty straightforward setting that up and I can easily get debug output etc. (if it would work ;))
2006-06-08T16:23:53  <ThomasWaldmann> fpletz: did you enable xapian in wikiconfig ?
2006-06-08T16:24:02  <fpletz> yep, enabled
2006-06-08T16:24:06  <ThomasWaldmann> how?
2006-06-08T16:24:24  <fpletz> xapian_search = 1
2006-06-08T16:24:28  <ThomasWaldmann> ok
2006-06-08T16:24:34  <fpletz> looked at the source ;)
2006-06-08T16:24:49  <ThomasWaldmann> building the index worked?
2006-06-08T16:25:32  <ThomasWaldmann> you have to do that using the "moin" command, see MoinMoin/script/...
2006-06-08T16:25:37  <fpletz> no, the directory directories in cache/xapian are empty
2006-06-08T16:25:52  <ThomasWaldmann> this is why it doesnt use xapian for searching :)
2006-06-08T16:25:54  <fpletz> uh, okay, I'll have a look
2006-06-08T16:25:59  <fpletz> thanks ;)
2006-06-08T16:26:20  <ThomasWaldmann> i guess i also made some CHANGES entry about how to call the indexing run
2006-06-08T16:26:58  <ThomasWaldmann> which xapian version did you install and how?
2006-06-08T16:28:14  <ThomasWaldmann> fpletz: for testing and developping, cgi might be less trouble
2006-06-08T16:28:27  <fpletz> I used the debs on the webpage, version 0.9.6
2006-06-08T16:28:45  <richardb> How is MoinMoin/i18n/mo/__init__.py meant to get generated?
2006-06-08T16:28:48  <ThomasWaldmann> ok, so it is 0.9.6 unpatched. great.
2006-06-08T16:29:06  <richardb> It's not in the repository, and doesn't seem to get generated when I run setup.py
2006-06-08T16:29:32  <fpletz> richardb: it seems only to be generated if you do 'make dist'
2006-06-08T16:29:45  <ThomasWaldmann> richardb: for what do you need that?
2006-06-08T16:29:50  <fpletz> it did some symlinking to get it working right away ;)
2006-06-08T16:29:56  <richardb> To install.
2006-06-08T16:30:02  <fpletz> ThomasWaldmann: otherwise no pages can be opened
2006-06-08T16:30:17  <ThomasWaldmann> if it misses, what happens?
2006-06-08T16:30:31  <richardb> [Errno 2] No such file or directory: '/home/richard/pub/software/moin-fpletz/lib/python2.4/site-packages/MoinMoin/i18n/mo/en.MoinMoin.mo'
2006-06-08T16:30:34  <richardb> IOError
2006-06-08T16:30:49  <ThomasWaldmann> ehrm
2006-06-08T16:30:55  <richardb> being thrown in ...    /home/richard/pub/software/moin-fpletz/lib/python2.4/site-packages/MoinMoin/i18n/__init__.py
2006-06-08T16:31:07  <ThomasWaldmann> the *.mo files are missing
2006-06-08T16:31:12  <richardb> self.translation = gettext.GNUTranslations(file(filename, "rb"))
2006-06-08T16:31:46  <ThomasWaldmann> copy them there manually until i fixed setup
2006-06-08T16:32:36  <ThomasWaldmann> btw, you also can run MoinMoin without using setup after each change
2006-06-08T16:32:59  <ThomasWaldmann> just modify sys.path to find your MoinMoin directory in your hg workdir
2006-06-08T16:37:33  <fpletz> ThomasWaldmann: where is _util? ;)
2006-06-08T16:37:38  <fpletz>     from MoinMoin.script import _util
2006-06-08T16:37:45  <fpletz> in MoinMoin/script/index/build.py
2006-06-08T16:38:18  <ThomasWaldmann> likely in script/__init__.py, but let me look
2006-06-08T16:39:36  <fpletz> got the problem.. fixing it
2006-06-08T16:40:33  <fpletz> seems someone did some refactoring ;)
2006-06-08T16:43:02  <ThomasWaldmann> yeah, i moved lots of stuff around :)
2006-06-08T16:43:13  <ThomasWaldmann> looks much cleaner now :)
2006-06-08T16:53:01  <fpletz> hmm, the mo files again..
2006-06-08T16:53:44  <ThomasWaldmann> looks like setup.py rejects to copy non-.py stuff as a package
2006-06-08T16:57:32  <richardb> fpletz: Can you commit your fixes for _util?
2006-06-08T16:57:33  <ThomasWaldmann> fpletz: run it from workdir until i fixed that
2006-06-08T16:59:36  <fpletz> richardb: yes, will do it
2006-06-08T16:59:56  <fpletz> ThomasWaldmann: well, I can run moin but the moint script doesn't work
2006-06-08T17:00:10  <fpletz> the mo files are copied into MoinMoin/i18n/mo properly
2006-06-08T17:00:27  <fpletz>   File "/home/fpletz//soc/moin-1.6-xapian-fpletz/MoinMoin/macro/__init__.py", line 88, in Macro
2006-06-08T17:00:30  <fpletz>     for lang in i18n.wikiLanguages().keys():
2006-06-08T17:00:33  <fpletz> AttributeError: 'NoneType' object has no attribute 'keys'
2006-06-08T17:05:59  <xorAxAx> 16:17:58 < richardb> I think the documentation for installing MoinMoin as a standalone server may be a little out of date.
2006-06-08T17:06:04  <xorAxAx> richardb: what exactly?
2006-06-08T17:06:20  <richardb> It was the .mo files not getting installed.
2006-06-08T17:06:25  <xorAxAx> richardb: use MMDE if its too troublesome
2006-06-08T17:06:26  <richardb> Thomas seems to be on the case.
2006-06-08T17:06:34  <richardb> MMDE?
2006-06-08T17:06:36  <xorAxAx> richardb: ah, thats a setup bug, yes
2006-06-08T17:06:42  <xorAxAx> MoinMoin:DesktopEdition
2006-06-08T17:08:03  <richardb> I was installing to test fpletz's development tree... So I don't think I can use that.
2006-06-08T17:08:09  <richardb> Interesting pointer though, thanks.
2006-06-08T17:08:35  <xorAxAx> indeed
2006-06-08T17:29:54  <fpletz> finally.. indexing seems to work..
2006-06-08T17:30:06  <fpletz> let's see if we can get the search running
2006-06-08T17:30:23  <ThomasWaldmann> fpletz: hg pull for mo fix
2006-06-08T17:30:35  <ThomasWaldmann> and use python2.4 for installing
2006-06-08T17:30:56  <fpletz> which fix? my traceback from above?
2006-06-08T17:31:02  <ThomasWaldmann> *.mo
2006-06-08T17:31:12  <fpletz> ok, great
2006-06-08T17:31:17  <fpletz> I fixed the other one
2006-06-08T17:32:16  <ThomasWaldmann> distutils has the needed functions starting from 2.4. if we dont require 2.4 for next release, we still need a solution for 2.3.
2006-06-08T17:32:25  <fpletz> all my fixes are in your xapian code so they needn't go into mainline
2006-06-08T17:32:32  <fpletz> ok
2006-06-08T17:45:15  <ThomasWaldmann> fpletz: please commit to your repo any time you have reached some "better than before" state
2006-06-08T17:46:05  <ThomasWaldmann> (to you hg.thinkmo.de repo, to be exact :)
2006-06-08T17:46:49  <fpletz> ThomasWaldmann: it's better now, but searching still doesn't work and I think my parser-work will break everything anyway
2006-06-08T17:47:07  <fpletz> I'm now going to eat something and then continue working
2006-06-08T17:47:27  <fpletz> sometime this evening I hope everything will be sorted out
2006-06-08T17:49:45  <ThomasWaldmann> xorAxAx: as you have added xmlrpc attachment functions, what sense do they make with items?
2006-06-08T17:56:28  <xorAxAx> ThomasWaldmann: they will make the same sense that they are making now.
2006-06-08T17:56:35  <xorAxAx> you will be able to add items
2006-06-08T17:56:40  <xorAxAx> and download them
2006-06-08T17:57:28  <ThomasWaldmann> so what will they list then, for example?
2006-06-08T17:57:29  *** irc.freenode.net sets mode: +o ChanServ
2006-06-08T17:58:05  <xorAxAx> ThomasWaldmann: the same thing that athe AttachmentList macro is listing currently :)
2006-06-08T17:58:50  <xorAxAx> which might be all items that are not text/* below a particular page
2006-06-08T17:59:26  <ThomasWaldmann> and text/* attachments?
2006-06-08T17:59:44  <ThomasWaldmann> or items :)
2006-06-08T18:00:00  <xorAxAx> no idea, thats to be defined
2006-06-08T18:01:07  <ThomasWaldmann> it think those functions are simply the wrong way
2006-06-08T18:01:22  <ThomasWaldmann> they are nice for 1.5.x maybe, but not for what's planned
2006-06-08T18:01:59  <ThomasWaldmann> for doing what they should do, we just need listItems, get and putItem, extended for mimetypes
2006-06-08T18:03:20  <ThomasWaldmann> and maybe listSubItems for some more comfort
2006-06-08T18:16:25  <xorAxAx> we dont have a final item api
2006-06-08T18:16:32  <xorAxAx> but we have a final attachment api
2006-06-08T18:17:10  <xorAxAx> and as long as 1.6 is not released, we can remove the listattachments one again
2006-06-08T18:17:14  <xorAxAx> and the other 2 as well
2006-06-08T18:19:42  * ThomasWaldmann added an unstable api warning there
2006-06-08T18:20:27  <ThomasWaldmann> exactly that was the reason why I said that it is the wrong time now :)
2006-06-08T18:21:32  <xorAxAx> ThomasWaldmann: its called agile development :)
2006-06-08T18:22:08  <ThomasWaldmann> I will quote that back to you next time you speak about broken apis :)
2006-06-08T18:23:17  <ThomasWaldmann> where's fabi all the time?
2006-06-08T18:23:43  <ThomasWaldmann> xorAxAx: your mentor needs activation :))
2006-06-08T18:24:16  <xorAxAx> ThomasWaldmann: you always break apis that are in use, this one isnt used yet
2006-06-08T18:24:38  <xorAxAx> no idea, he said that he is available via ffesti at office times
2006-06-08T18:24:53  <xorAxAx> he didnt like the idea of public meetings
2006-06-08T18:25:38  <ThomasWaldmann> i guess it is used at least by its developer
2006-06-08T21:00:46  <mvirkkil> ThomasWaldmann: Can't log in because of errors due to the moving of the mail module.
2006-06-08T21:01:13  <mvirkkil> ThomasWaldmann: MoinMoin/userform.py line 11 "from MoinMoin.util import web, mail, timefuncs"
2006-06-08T21:01:36  <mvirkkil> --> "cannot import name mail"
2006-06-08T21:02:24  <ThomasWaldmann> wait
2006-06-08T21:02:54  * mvirkkil is wathing 4400, so no hurry :)
2006-06-08T21:06:33  <ThomasWaldmann> hg pull
2006-06-08T21:07:12  <ThomasWaldmann> (that import was rather superfluous. maybe the reason why i didnt find it)
2006-06-08T21:08:09  <ThomasWaldmann> mvirkkil:
2006-06-08T21:08:20  <mvirkkil> ?
2006-06-08T21:08:30  <ThomasWaldmann> it is fixed
2006-06-08T21:08:48  <mvirkkil> ThomasWaldmann: ok, ok :) I'm working on it.. I'm not very fast with hg.
2006-06-08T21:10:02  <mvirkkil> ThomasWaldmann: done
2006-06-08T21:26:00  <Kepplar> moib
2006-06-08T21:43:24  <Kepplar> hehe, got my marks for my placement from my employer
2006-06-08T21:43:27  <Kepplar> 86% \o/
2006-06-08T21:43:36  <Kepplar> (70% is first class in the UK)
2006-06-08T21:45:44  <ThomasWaldmann> percentage of what?
2006-06-08T21:46:19  <ThomasWaldmann> 100% = rocket scientist? :)
2006-06-08T21:51:25  <Kepplar> 100% = perfect employee
2006-06-08T21:51:55  <Kepplar> percentage of the marks for the module
2006-06-08T21:54:39  <Kepplar> im building up a big list of questions and issues i have with the current code, which ill tell upload at the weekend
2006-06-08T21:55:00  <Kepplar> while you get the time to answer them i'll do more on the new flatfile module (which ive now started (not commited))
2006-06-08T21:55:04  <Kepplar> and then the adapter
2006-06-08T21:55:17  <Kepplar> (you may have guessed this should put me ahead of schedule)
2006-06-08T21:55:37  <Kepplar> (although there is always test cases to do after the basics!)
2006-06-08T22:25:43  <xorAxAx> of course the module should be able to read the current format :)