| Age | Commit message (Collapse) | Author |
|---|
|
Add an rpc() method to the proxy to allow users to call remote
procedures, and route the proxy's own import registration via this
function.
Also, implement convenience functions for the RPC calls exported in the
IkiWiki::XML::RPC namespace.
Signed-off-by: martin f. krafft <madduck@madduck.net>
|
|
Hook functions now get the proxy object as first argument to be able to
use RPC via the proxy.
Signed-off-by: martin f. krafft <madduck@madduck.net>
|
|
Signed-off-by: martin f. krafft <madduck@madduck.net>
|
|
Instead of using the XML-RPC v2 extension <nil/>, which Perl's
XML::RPC::Parser does not (yet) support (Joey's patch is pending), we
agreed on a sentinel: {'null':''}, that is, a hash with a single key
"null" pointing to the empty string.
The Python proxy automatically converts None appropriately and raises an
exception if a hook function should, by weird coincidence, attempt to
return {'null':''}.
Signed-off-by: martin f. krafft <madduck@madduck.net>
|
|
|
|
This saves space, and stores the data under the right keys.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
MathML whitelists
|
|
|
|
During refresh of a wiki with 800 files, loadindex was using more total
time than any other function, and saveindex was also in the top ten.
Rewriting them to use Storable makes them three times as fast.
0.7 seconds is saved on my laptop in profiling mode.
|
|
About 12% of ikiwiki runtime was spent in pagespec_match. It was evaling
the same pagespec code over and over again. This changes pagespec_translate
to return memoized, precompiled functions that can be called to match against
a given pagespec.
This also allows getting rid of the weird variable scoping trick that had
to be in effect for pagespec_translate to be called -- the variables are
now just fed into the function it returns.
On my laptop, this drops build time for the docwiki from about 60 to 50
seconds.
|
|
|
|
|
|
|
|
|
|
Markdown is slow. Especially if it has to process an enormous page. The
most common enormous page is currently the recentchanges page, which gets
processed a lot, and contains very little actual markdown. Most of it is a
big <div>, which markdown skips ... slowly.
This is a rather sick optimisation to work around markdown's speed issues.
Now inline inserts a small, dummy div, allows markdown to quickly render
the actual page content, then replaces the dummy with the actual inlined
pages later.
Results: Rendering just a recentchanges page, with diffs included, dropped
from 4.5 seconds to 2.7 seconds on my laptop. Building the entire wiki
dropped from 46.6 seconds to 39.5 seconds.
(It would be better if inline were a *post*-processor directive.)
|
|
I had to move it to sanitize so all the markup is htmlized, so it can scan
for <pre> and <code>.
|
|
I'm suprised that the second m//g didn't seem to clobber @-, but I don't
want to rely on that, so preserve it beforehand.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
in templates
|
|
|
|
|
|
|
|
|
|
|
|
be automatically converted.)
|
|
|
|
This makes the CGI about .2 seconds faster when editing pages etc.
|
|
Same fix as in d7f1292c3134fd9464ca4005f48b9274be861c10
|
|
for consistentcy with getargv, which returns one
|
|
It was incorrectly setting the value to the number of items in @_, ie,
always 1.
|
|
|
|
xml rpc only allows functions to return a single value, no lists. So getargv
needs to return a list reference, which means that the caller will see an xml
rpc array.
|
|
|
|
portion (frontpage is not ikiwiki). Also, tweak the website title
|
|
is pretty.. dumb
|
|
|
|
|
|
I added a .gitignore file to plugins/ to ignore *.pyc files, and that
file is now being installed +x to /usr/lib/ikiwiki/plugins. This commit
prevents that by excluding all dot-files under plugins/ from the
install.
Signed-off-by: martin f. krafft <madduck@madduck.net>
|
