Forum: Instiki – Topic: nlab

Urs is complaining about slow times again …

Looking at the logs, I see a heck of a log of “Expired fragment”s. Do these add to a page’s rendering time? Or does the cache sweeper act non-synchronously (or whatever it’s called)?

For example, in the logs I see 815 lines saying “Expired fragment:” and the request that it seems to be a part of (can’t be totally sure due to several processes running simultaneously) takes about 6s to render. A more systematic search of the logs shows it’s not guaranteed, but often the case that the following request is slow - and the times when it isn’t could be due to it being a parallel process (would need a more sophisticated search).

Forum: Instiki – Topic: Bugs

I’m on the latest version (758) on my course wiki and this still didn’t work (I thought that it did work just recently, though, did you undo something?). I uploaded a few files, then reloaded the page, and it had the greyed-out-with-question-mark look again.

Forum: Heterotic Beast – Topic: Bugs

This place just remembered who I am. So that seems to be working now.

Forum: Instiki – Topic: Feature Requests

It would still just be one entry in the database. But it would mean that there actually was an entry in the database if “Foo” only links to an anchor on “Bar”. Having to do it via hyperlinks would mean that the pages weren’t officially linked.

My idea (no idea how practical) would be:

1. Strip off the anchor from [[Bar#baz]] and store it temporarily
2. Process [[Bar]] as before
3. Put back the anchor at the end of the resulting link

So then at the point of sorting out the database, instiki doesn’t care about the anchors and just registers the link to page “Bar”.

Forum: Instiki – Topic: Feature Requests

Here’s something I’d find useful: allowing for anchors in wikilinks. So that I could type [[homework+2011+2#question_three_5]]. Since missing anchors at least take one to the right page, I wouldn’t check that the anchor itself exists.

I feel that there is a qualitative difference between a wikilink and a hyperlink, and links to anchors on particular pages should be in the wikilink category.

Forum: Instiki – Topic: Bugs

New bug! I think that the page view is not getting “expired” (is that the right term?) when a file is uploaded. Here’s the “steps to reproduce”:

1. Edit a page to include a file upload whatsit.
2. Upload the file. Upon upload, the page looks fine and the question-mark link has been replaced by a link to the file.
3. Reload the page. Then it reverts to the previous view and the question-mark link is back again.
4. Next time the page is edited, it looks correct.

Because of that last, my guess is that the pre-upload version is still in the cache, but that the page shown when the file is uploaded doesn’t read the cache version.

So long as the cache hasn’t been expired, you can see this at http://ncatlab.org/doriath/show/uploads+and+caches. If you click on the question mark, you should get a copy of the Snake Lemma.

Forum: Instiki – Topic: Bugs

Of course they are different.

I reserve the right to be stupid!

Forum: Instiki – Topic: Bugs

I’m afraid I’m not very well informed on the differences between XHTML and HTML. I probably ought to be (I found the w3c page on it which was useful). So <a> </a> is actually different to <a></a>, then. But it seems as though when rendered then the extra space has no actual effect. (Let’s try: a a and aa. Though my actual use case has them on lines by themselves:

Text

Forum: Instiki – Topic: Bugs

Yet again: thanks!

Though I dispute the “equally useless”. I was using the empty anchor tag to put an anchor at a particular place on the page when there wasn’t an obvious thing to “hang” it on. Of course, I could always find something to put it with, but it was coming from my automatic LaTeX-to-iTeX package and it’s much easier to have an empty anchor than try to figure out automatically where it can be put.

Forum: Instiki – Topic: Bugs

Next bug. For some strange reason, empty anchors mess up wikilinks:

<a id="anchor"></a>

Here's a [[wikilink]]

means that Instiki does not process the wikilink. If I put text in the anchor, then it’s fine. If I replace the a tag by p or div then it’s fine (didn’t test other tags). The problem persists for a bit, and then starts working again (not quite figured out the rule for when it does, sometimes it seems to be in the middle of a paragraph).

This does feel a bit like a “when I bang my head on the wall then it hurts” bug, but still it is strange behaviour particularly given the tag-dependence.

(See http://ncatlab.org/nlab/show/Sandbox for some experiments.)

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: 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

(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: 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: 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: 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: 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

When I click on a discussion/whatever then it takes me to the top of the page. It would be more sensible if it took me to the point where I last read up to (which I presume it knows).

Forum: Instiki – Topic: nlab

Right, so on the crashing then I’m just watching the new system and waiting to see what it does and how it responds. I’ll keep a hold of all the logs for statistical purposes (not that I’ve any real idea about statistics …).

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? Urs has some pages with loads and loads of links, and there’s talk of having some pages where everything possible is linked (with CSS to lessen the visual impact).

Forum: Instiki – Topic: nlab

Yes, I was thinking that 1Mb was a bit low. When the googlebot hit last night then it was creating a new log file every 20 minutes or so!