Forum: Instiki – Topic: nlab

If you can’t remember, then I’ll experiment with taking it out and see who complains, and about what.

Forum: Instiki – Topic: nlab

Ah. I see. I was deceived by your example

+-- {: .num_theorem}
###### Theorem ######
This is italic text.  But [this is not](#top){: style="font-style: normal;"}.
=--

In general, the more specific CSS selector wins, and there was some circumstance where inheritance from .num_theorem was not sufficient. I needed the more specific .num_theorem *. But, for the life of me, I can’t recall the details.

Forum: Instiki – Topic: Bugs

Great! I’ll apply those tomorrow morning.

(And I learnt a new word. Doubt I’ll be able to get it in to Boggle, though.)

Forum: Instiki – Topic: nlab

It’s about inheritance. Let me do my example again.

+-- {: .num_theorem}
###### Theorem ######
This is italic text.  *This is normal, but [this is not](#top).*{: style="font-style: normal;"}.
=--

The link should inherit the font-style: normal; from the span but it doesn’t because it matches the CSS rule .num_theorem *.

Forum: Instiki – Topic: nlab

Works for me.

was generated by

+-- {: .num_theorem}
###### Theorem ######
This is in italics. *This is normal.*{: style="font-style: normal;"} And this is italic, again.

This whole paragraph is normal.
{: style="font-style: normal"}

This paragraph is in italics.
=--

Aside from the kludgy bit about applying styles to spans, I have no idea what your issue is.

Forum: Instiki – Topic: Bugs

Thanks for the report. Fixed in Revision 742.

I think this bug was a long-standing one. The other, fixed in that Revision, was completely iatrogenic.

Oh, and your double-escaping bug is fixed in Revision 743.

Forum: Instiki – Topic: nlab

(Not so much a bug, but also not a feature request, so gets put here.)

Is there a reason why the italic style in theorems is done via:

.num_theorem * {
   font-style: italic;
}

rather than:

.num_theorem {
   font-style: italic;
}

The * makes it very hard to override the italic selection. For example, something like:

<p style="font-style: normal;"><a href="somewhere">link</a></p>

will come up as italic, I think. Actually, I can test it here:

Yes, it did. So the normal CSS inheritance is effectively bypassed by the * selector. To override it, I need to put another * selector in place but I can only do that in the web CSS and not in the style on a div.

I’m generally reluctant to modify stuff that you’ve put in place! Is there a reason for the *, or can it be dropped?

Forum: Instiki – Topic: Bugs

Okay, next one. I’m recording the error message first. It’ll take me a few minutes to track down exactly what is causing it.

#<ActionView::TemplateError: 
ActionView::TemplateError (undefined method `children' for nil:NilClass) on line #15 of
app/views/wiki/page.rhtml:
12:     </p>
13:     <%= @renderer.display_diff %>
14:   <%- else -%>
15:     <%= @renderer.display_content %>
16:   <%- end -%>
17: </div>
18: 

Actually, didn’t take long at all. The last line of the document was * (the previous line had been a list item as well) so presumably maruku was looking for the rest of the item, couldn’t find it, and gave up in disgust.

I guess that getting a more sensible error (this causes smoke) would involve hacking maruku more than you’d like.

Forum: Instiki – Topic: Bugs

I originally thought that this one was due to old browsers, but I’m now using FF6.0 so it can’t be that. Anyway, when I create a new page, the “Page X does not exist” is getting escaped once too often and I see:

Page &quot;Proper Homotopy Theory&quot; does not exist.<br/>
Please create it now, or hit the &quot;back&quot; button in your browser.

Forum: Instiki – Topic: Bugs

Thanks! I’ve updated the nLab and Azimuth Project. That’s great.

Forum: Instiki – Topic: Bugs

Fixed in Revision 736.

Forum: Heterotic Beast – Topic: Bugs

Long lines (of code?) make the posts a bit wide. Currently, my view on http://golem.ph.utexas.edu/forum/forums/instiki/topics/bugs#post_77 has all the posts reaching in to the grey region on the right-hand side.

Forum: Instiki – Topic: Bugs

Maruku doesn’t like starting bold text with bizarre unicode symbols, or named entities (presumably these are converted to unicode symbols). Example **∞-gerbe**.

This causes a crash in instiki:

#<ActionView::TemplateError: 
ActionView::TemplateError (invalid byte sequence in UTF-8) on line #15 of
app/views/wiki/page.rhtml:
12:     </p>
13:     <%= @renderer.display_diff %>
14:   <%- else -%>
15:     <%= @renderer.display_content %>
16:   <%- end -%>
17: </div>
18: 

PS: This showed up after I installed the latest version of instiki.

Forum: itex2MML – Topic: Feature Requests

What should itex2MML do, that it doesn’t, currently?

Forum: itex2MML – Topic: Bugs

Discuss bugs in itex2MML.

Forum: Heterotic Beast – Topic: Bugs

No it doesn’t.

Deleting the only post in a topic, also deletes the topic. Possibly, the redirect (which normally goes to topic#show but, in this case, should go to the forum#show because the topic no longer exists) is incorrect.

Fixed.

Forum: Instiki – Topic: nlab

Thinking about Recently Revised and All Pages, you suggested (somewhere) taking them out of the sweeper as a way of stopping them being regenerated every time a page is edited (I don’t know if this was one of you “If you’re going to do something crazy, here’s a way of limiting how crazy you’re going to be” suggestions or if you thought this was actually a good idea).

The former. You’re trading off workload on the server for stale data. Since computers are supposed to serve humans, rather than the other way around, the question is: does this improve the user experience?

Say you implement the above suggestion. On the one hand, the user always (or almost always, depending on implementation) receives the cached page, i.e. gets a quick response. On the other hand, the data is invariably stale.

Leaving these alone, the user is guaranteed to receive fresh data, but there could be a significant delay, if the page has to be regenerated. What percentage of requests for these pages hit the cache?

A better solution is to pull in the will_paginate gem, and paginate the data returned. That makes the request $O(1)$, again, instead of $O(N)$. So the user gets both a quick response AND up-to-date data.

As to moving away from Maruku, to some peg-markdown-based clone, note that

1. This will benefit Heterotic Beast as well.
2. The task I’m asking of your guys is not “programming,” per se. It involves writing a formal PEG grammar for Maruku’s extended Markdown syntax (starting with the existing PEG grammar, already in peg-markdown).
3. On the other hand, if there were someone handy in C, that would be most appreciated, too, because I am crappy at C. Hooking in itex2MML would take mere minutes for a competent C-programmer.
4. I imagine that a such a fork of peg-markdown (as it’s written in C), would be useful in your other projects, as well.

Forum: Heterotic Beast – Topic: Bugs

Deleting the first post in a topic leads to a “page does not exist” error.

Forum: Instiki – Topic: nlab

Bother. I can’t count. I saw that the last log file was numbered 23 and assumed that that meant I hadn’t missed any log files. Sadly not. So my logs aren’t complete. Ah well. Incidentally, why name them numerically? Why not name them by a date-and-time stamp? Then they wouldn’t have to all be renamed when the next one is created.

Thinking about Recently Revised and All Pages, you suggested (somewhere) taking them out of the sweeper as a way of stopping them being regenerated every time a page is edited (I don’t know if this was one of you “If you’re going to do something crazy, here’s a way of limiting how crazy you’re going to be” suggestions or if you thought this was actually a good idea). Then I’d have to manually regenerate them every, say, hour by deleting the cached copy so that the next hit recreated it. It occurred to me that the same cron job that deleted the cache could also hit the page in the server to force the regeneration. It then occurred to me that it was silly having that go via the webserver when it was on the same machine as the program.

With my current knowledge of instiki, what I thought of for getting round this was to have an instiki process running invoked “from the command line” and listening on, say, port 2500. I block that port from all outside traffic and use it only for localhost. Then the cron job hits that port, avoiding the webserver. The alternative would be to have it so that I could call instiki nlab/recentlyrevised on the commandline, whereupon instiki fires up, renders the page, and disappears in to the ether again.

Forum: Instiki – Topic: nlab

Did a lot of profiling this weekend, and produced a few tweaks to Maruku’s parsing, which speeded it up a little.

Unfortunately, the main discovery was that (with that test page as input), 3/4 of Maruku’s time is spent in the #to_html output method; only 1/4 is spent in parsing the original input. Thus, my efforts, which maybe improved the parsing speed by 5%, contributed at best a 1% speedup in the total Instiki processing time, i.e something you would never notice.

I hope that one of your guys finds formal grammars sufficiently “categorical” to be worthy of a small bit of their attention.

Forum: Instiki – Topic: nlab

Pretty much everything beyond the standard Markdown syntax needs to be written, though some folks in the peg-markdown network seem to have included Michel Fortin’s Markdown-Extra extensions (albeit, along with some of their own, incompatible, extensions).

Presumably, this fork of peg-markdown would be directly linked to the itex2MML functions which process inline and display equations (ie, it would not use the Ruby bindings provided by the itextomml gem). So there’s a little bit more to do than write the peg grammar. But not a lot more …

As to whether you want to ask someone to do this, I’ve already explained my desire to replace Maruku (for licensing reasons). Here’s another motivation, from efficiency. Instiki’s performance does genuinely suck, in this instance.

The question is, are they (your nlab colleagues) willing to do anything about improving it?

Feel free to point them to this discussion, and to the previous one on Markdown alternatives.

Forum: Heterotic Beast – Topic: Bugs

May I suggest ”Other users online: XYZ”.

Okay, that’s odd. I suggested the above having seen the “Users online: distler” message, and not seeing my own name. Now I click back to the forums list and I am listed there this time. So either it got it wrong first time, or you’re playing with the code and I should shut up and let you get on with it.

Forum: Instiki – Topic: nlab

Now that I see the break-down, I agree with you that it’s a waste of time optimising the wikilinks for now. That’s an astonishing amount of time for maruku to take! I wonder how much of that is itex; I guess I can test that for myself by running maruku on a few files on my machine here, with and without itex.

I could ask on the nForum about volunteers for writing a PEG grammar. That sounds like a good, specific task that someone might just be willing to do. Shall I ask?

Do you have a clear idea of which bits of maruku’s syntax are missing, or would the task involve determining that?

Forum: Instiki – Topic: nlab

On golem (the iMac on my desk), rendering a copy of that page takes

Completed in 27588ms (View: 27356, DB: 192)

Note that it does spend (what I consider to be) a significant amount of time querying the database, but it is totally dwarfed by the rendering time. (I don’t know why yours is spending an order of magnitude longer querying the database. Seems like something’s very wrong, there, even though the conclusion is the same.)

The page, of course, contains a number of markup errors, like

... [[transversal map]s ...

which sent Maruku into convulsions. Surprisingly, correcting those errors did not appreciably affect the rendering time (the above-reported time is after making the relevant markup corrections).

On my laptop, a typical time was

Completed in 48775ms (View: 48635, DB: 77)

SQlite3 is faster than MySQL, but the machine itself is significantly slower than the iMac.

Of those 49 seconds, spent rendering the page, 43 of them were spent in Maruku (for obscure reasons, Maruku has to be run twice, so really, we’re talking about 22 seconds to process the 175KB source).

Maruku doesn’t particularly care about the number of WikiLinks, so that has nothing to do with why it takes so long render this particular page.

Of the remaining 6 seconds, 4 seconds were spent in the Instiki Sanitizer. I don’t think there’s much to optimize there.

The remaining 2 seconds were, largely, spent in the Chunk-Handler – the thing that processes Wikilinks (and, presumably, cares about how many of them there are). 2 seconds is still a long time, but it’s not surprising. Doing on the order of ${10}^3$ RegExp substitutions (5360 chunk-masking and 686 chunk-unmasking operations, to be precise) on a 175KB string, takes significant time. Using Regexps to process long strings sucks.

I have looked at various optimizations of the Chunk-Handler code, but nothing I can do will contribute much to the speedup of rendering this page, which is dominated by Maruku.

Now, if one of your nLab folks were to volunteer to write a PEG grammar for Maruku’s extended Markdown syntax, …

Update:

Now, if one of your nLab folks were to volunteer to write a PEG grammar for Maruku’s extended Markdown syntax, …

Since I’m not gonna hold my breath for that to happen, I decided to spend some time (alas, more than I expected) making Maruku faster. The new rendering times for that page are

Completed in 13228ms (View: 13024, DB: 198)

on golem and

Completed in 21666ms (View: 20979, DB: 83)

on my laptop. Roughly a factor of 2 improvement in the total rendering time, in both cases.

Still not great, but it’s the best that I am going to achieve.

Forum: Heterotic Beast – Topic: Bugs

Vanilla stores some information in the user database, including the last comment in each discussion that you read.

Forum: Heterotic Beast – Topic: Bugs

Incidentally, if you want to get a feel for what Vanilla looks like but don’t want to sign on to the nForum, I have a test forum set up: http://www.math.ntnu.no/~stacey/Mathforge/Test/. I can easily add any plugins from the nForum that you might want to play with.

Forum: Instiki – Topic: nlab

The “print” view wasn’t much faster: 71303ms.

Forum: Instiki – Topic: nlab

Okay, let’s take http://ncatlab.org/nlab/show/smooth%20infinity-groupoid%20--%20structures which, according to grep, has the order of 409 wikilinks. (Actually, it has 409 hits for the string [[.) On first load, it was already cached and produced the following figures: 169ms first time, 62ms second. I got 0.026s for “time to first byte” and 0.663s for “from click to complete display”.

Now I delete it from the cache, and try again. A cup-of-tea later, and I get the following: 74074ms (View 72773, DB: 1276). On the receiving end, I get 82s and 87s for the delivery times. Second time, similar figures.

The time this gets a bit annoying is when editing a page, since then it has to regenerate it each time. That’s a fair wait if you’ve only changed a couple of spelling mistakes.

Forum: Heterotic Beast – Topic: Bugs

It would be more sensible if it took me to the point where I last read up to (which I presume it knows).

How does Vanilla keep track of what posts you’ve read?

Forum: Instiki – Topic: nlab

One thing that I am pretty sure that slows down a page load is if the page has a lot of wikilinks on it. I don’t know how it checks all the links, but is there some way that that could be speeded up?

Could you compare (by deleting the cached page and reloading ) how long it takes to build a wikilink-heavy page, versus a “normal” one?

I’m particularly interested in the database-lookup times. As I said via email, the WikiReferences model uses a lot of raw SQL queries (which, therefore, do not benefit from ActiveRecord caching). But I am a little skeptical that is the cause of much of a slowdown.