Recent Posts

Subscribe to Recent Posts 326 posts found

posted almost 3 years ago
distler 77 posts

Forum: Instiki – Topic: Bugs

Are you using the current revision of Instiki? ‘Cuz that’s not the behaviour I see, when I follow the steps above.

 
posted almost 3 years ago
Andrew Stacey 118 posts

edited almost 3 years ago

Forum: Instiki – Topic: Bugs

Looking at the log, what I see is the following:

Processing WikiController#save (for 2001:700:300:1470:862b:2bff:fe9b:c741 at 2011-09-21 14:32:27) [POST]
  Parameters: {"_form_key"=>"809867e64bcc18bbdd650af99b67f93dd935dfad", "content"=>"A load of content",
"alter_title"=>"1", "new_name"=>"norm for continuous functions on the interval", "author"=>"Andrew Stacey",
"web"=>"mathsnotes", "id"=>"continuous functions on the interval"}
Reading page 'continuous functions on the interval' from web 'mathsnotes'
Page 'continuous functions on the interval'  found
2001:700:300:1470:862b:2bff:fe9b:c741
Reading page 'continuous functions on the interval' from web 'mathsnotes'
Page 'continuous functions on the interval'  found
Maruku took 0.002904876 seconds.
Maruku took 0.002353689 seconds.
Maruku took 0.310123551 seconds.
Maruku took 0.301577887 seconds.

At that point, I get lots of Expired fragments, all of which refer to the new page name (or to lists). Then at the end, I see:

Redirected to http://mathsnotes.math.ntnu.no/mathsnotes/show/norm+for+continuous+functions+on+the+interval
Completed in 789ms (DB: 18) | 302 Found [http://mathsnotes.math.ntnu.no/mathsnotes/save/continuous+functions
+on+the+interval]

Seconds later, I go back to the tab with the original page in it and click “reload” to get:

Processing WikiController#show (for 2001:700:300:1470:862b:2bff:fe9b:c741 at 201
1-09-21 14:32:39) [GET]
  Parameters: {"web"=>"mathsnotes", "id"=>"continuous functions on the interval"}
Reading page 'continuous functions on the interval' from web 'mathsnotes'
Page 'continuous functions on the interval' not found
Cached fragment hit: views/mathsnotes/show/continuous+functions+on+the+interval (0.1ms)
Filter chain halted as [#<ActionController::Filters::AroundFilter:0x00000003585248
@kind=:filter, @method=#<Proc:0x00000003585680@/home/stacey/current/others/instiki/vendor/rails/actionpack/
lib/action_controller/caching/actions.rb:64>, @identifier=nil, @options={:only=>#<Set: {"show", "published",
"authors", "tex", "s5", "print", "recently_revised", "list", "file_list", "source", "history", "revision",
"atom_with_content", "atom_with_headlines"}>, :if=>#<Proc:0x00000003585888@/home/stacey/current/others/
instiki/app/controllers/wiki_controller.rb:13>, :unless=>nil}>] did_not_yield.
Completed in 3ms (View: 0, DB: 1) | 200 OK [http://mathsnotes.math.ntnu.no/mathsnotes/show/
continuous+functions+on+the+interval]

In other words, the cached version is there.

(Edit: “A load of content” is a substantial amount.)

 
posted almost 3 years ago
Andrew Stacey 118 posts

Forum: itex2MML – Topic: Bugs

Once again: thank you very much!

 
posted almost 3 years ago
distler 77 posts

Forum: Instiki – Topic: Bugs

I’m not so sure I understand.

  1. I created a page, “Foo”.
  2. I edited the page, “Foo”, and changed the name to “Bar”.
  3. I removed the [[!redirects Foo]] directive, and saved the page.

All instances of “Foo” were successfully removed from the Cache.

What am I missing?

 
posted almost 3 years ago
admin 57 posts

edited almost 3 years ago

Forum: itex2MML – Topic: Bugs

It’s a matter of the precedence rules that you expect not being respected by itex2MML

 \lim_{n\to 0}

is set with an <munder>. But, when you type

\displaystyle \lim_{n\to 0}

the precedence of the ”_” is not treated as being higher. The above is treated as equivalent to

{ \displaystyle \lim }_{n\to 0}

which is set with an <msub>. Putting in the grouping explicitly:

\displaystyle { \lim_{n\to 0} }

gives you what you were expecting.

I think this is confusing. Probably, you were expecting \displaystyle to behave more like \color{red} does (compare the definitions of COLOR and of DISPLAY, respectively, in itex2MML.y).

Update:

Let’s see: lim n01n=0

lim n01n=0\textstyle \lim_{n\to 0} \frac{1}{n} = 0

Yup. itex2MML 1.4.8 works as you’d expect.

 
posted almost 3 years ago
Andrew Stacey 118 posts

Forum: Instiki – Topic: Bugs

Talking about cache bugs (nlab thread), I think I just came up against another incarnation of The Dreaded Cache Bug of Bexhill on Sea. I was reorganising pages on my course wiki. I had a page that used to be a single page and now I wanted to split it into several. The stuff on that page was to go on one of the sub-pages, so I renamed that page. But I wanted to use the original page name as the main page. So I removed the automatically inserted redirect. Then I saved the page. The original page was still in the cache. As I wanted to create that page anyway, I manually entered the “new/page name” URL and that worked (“edit/page name” did not).

 
posted almost 3 years ago
Andrew Stacey 118 posts

Forum: itex2MML – Topic: Feature Requests

Here’s an anti-feature request. itex2MML should never implement \newcommand (or any of its variants). Here’s my reasoning:

  1. If done properly, it leaves one open to the \newcommand{\a}{\a}\a bug. If that isn’t allowed, then it won’t be close to LaTeX’s \newcommand and people will get trapped by the difference.

  2. It would make it harder to truly collaborate. Every page with more than one editor is going to require reading the preamble just to find out what the local conventions are and that’s going to make it harder to edit something that someone else started.

 
posted almost 3 years ago
Andrew Stacey 118 posts

Forum: itex2MML – Topic: Bugs

(Repost from the other discussion as this looks bug-like to me.)

Okay, let’s try this here. Compare and contrast:

How it ought to look:

lim n01n=0\lim_{n\to 0} \frac{1}{n} = 0

With a \displaystyle at the start. In LaTeX, this is to ensure that the subscript to \lim is underset.

lim n01n=0\displaystyle \lim_{n\to 0} \frac{1}{n} = 0

Now with a bit of grouping to help.

lim n01n=0\displaystyle { \lim_{n\to 0} \frac{1}{n} = 0 }

Somehow, the <mstyle displaystyle="true"> is getting inside the \lim processing, turning the <munder> in to a <msub>.

 
posted almost 3 years ago
Andrew Stacey 118 posts

Forum: Instiki – Topic: nlab

No, no! Thank you. Let’s see if this makes Urs a little happier!

 
posted almost 3 years ago
distler 77 posts

Forum: Instiki – Topic: nlab

Given the number of links that Urs has on some of the nLab pages…

It’s the number of inbound links that matters, but yeah.

If the page name doesn’t change, surely then you don’t have to expire any of the pages that refer to it?

You do, for a newly-created page… but not, I agree, for a revision of an existing page. I was, somewhat crudely, not distinguishing between those cases. It occurs to me that I can use an after_create hook to distinguish between those cases.

Thanks.

 
posted almost 3 years ago
Andrew Stacey 118 posts

Forum: Instiki – Topic: nlab

I want it all (hey-yeah)
I want it all (hey-yeah)
I want it all
And I want it now!

Given the number of links that Urs has on some of the nLab pages then I think this might well be a case for optimisation. If the page name doesn’t change, surely then you don’t have to expire any of the pages that refer to it? So it’s not a “don’t have to expire twice”, it’s a “don’t have to expire once”, isn’t it? Or am I missing something.

 
posted almost 3 years ago
distler 77 posts

Forum: Instiki – Topic: nlab

It seems to be the list and recently_revised ones that get expired several times in a row.

That would be a consequence of

  1. When a page is saved, expire all pages that reference that page.
  2. When you expire a page, also expire the corresponding “index pages’ (list, recently-revised, atom feeds).

The first is further-complicated by the facility for renaming pages. That means we need to expire all the pages that refer to the old page and all the pages that refer to the new page.

I guess that could be optimized better for the case where the page doesn’t change names, as we don’t have to expire the same pages twice. I think the current procedure was motivated by complaints (from y’all) that, in some circumstances, pages were not being expired when they should.

 
posted almost 3 years ago
Andrew Stacey 118 posts

Forum: Instiki – Topic: nlab

On occasion an expiration takes longer than 0.2ms, and when the number is in the thousands then the likelihood of that happening increases considerably, so 10 5 is an overestimate. The largest number that I see in my slightly refined test is about 6000. That takes about 3s normally. In this log run, I had one taking 7s with 1400 expirations.

What are the rules for which pages need fragments expiring when a page is saved? I’m getting a heck of a lot of expired fragments in the logs. Looking a little further then the above figures are underestimates because they don’t take into account the fact that the logs might be split over several files, or be separated by the logs for other requests.

I have one log file consisting of 16876 lines. 15581 of them are ‘Expired fragment’s. There appear to be quite a lot of duplicates as well: In that lot, then views/nlab/list/people gets expired 28 times in a row. It seems to be the list and recently_revised ones that get expired several times in a row.

 
posted almost 3 years ago
distler 77 posts

edited almost 3 years ago

Forum: Instiki – Topic: nlab

On my machine, each Expired fragment takes 0.1-0.2 ms. So to get 10-20 s, you’re talking about expiring ~10 5 fragments?!

Wow! That’s impressive.

 
posted almost 3 years ago
Andrew Stacey 118 posts

Forum: Instiki – Topic: nlab

Okay, so I just did a crude time count. I do have some lists totalling in the order of seconds. I get one at 20s, three at 10s, and about 30 over 1s. (Usual caveats that I can’t tell that all of these are from the same request. They occur concurrently in the logs.)

 
posted almost 3 years ago
Andrew Stacey 118 posts

edited almost 3 years ago

Forum: Instiki – Topic: Bugs

Just saw the following in the logs:

ActionView::TemplateError (can't convert nil into String) on line #25 of app/views/wiki/atom.rxml:
22:       else
23:         xml.content('type' => 'xhtml', 'xml:base' => url_for(:only_path => false, :web => @web_name,
                       :action => @link_action, :id => page.name) ) do
24:           xml.div('xmlns' => 'http://www.w3.org/1999/xhtml' ) do
25:             |x| x << rendered_content(page)
26:           end
27:         end
28:       end
 
posted almost 3 years ago
admin 57 posts

Forum: Instiki – Topic: nlab

The “Expired fragment” log-entries all have times (in ms) attached to them, so you would be in a better position than I to tell how long they took to execute.

But, yes, when you ask for new features (like source views for every revision), that means more pages to expire, when an edited page is saved.

 
posted almost 3 years ago
Andrew Stacey 118 posts

edited almost 3 years ago

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).

 
posted almost 3 years ago
distler 77 posts

Forum: Instiki – Topic: Bugs

I’m a little baffled. It should work. Sometimes it does (saving the file triggers the cache sweeper); sometimes it doesn’t. I can’t see what the difference is.

Will have to investigate further …

 
posted almost 3 years ago
Andrew Stacey 118 posts

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.

 
posted almost 3 years ago
Andrew Stacey 118 posts

Forum: Heterotic Beast – Topic: Bugs

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

 
posted almost 3 years ago
Andrew Stacey 118 posts

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”.

 
posted almost 3 years ago
distler 77 posts

edited almost 3 years ago

Forum: Instiki – Topic: Feature Requests

I feel that there is a qualitative difference between a wikilink and a hyperlink

Indeed, there is. And that’s why there are no anchors allowed.

If page “Foo” has multiple WikiLinks to [[Bar]], there’s still only one corresponding entry in the database. That could no longer be true if “Foo” could link to [[Bar]] and to [[Bar#baz]].

What you want is a hyperlink, and Markdown provide a syntax for hyperlinks which permits anchors.

Update:

On reflection, I suppose that allowing the presence of anchors doesn’t strictly conflict with having just one entry in the database. I should think some more …

 
posted almost 3 years ago
Andrew Stacey 118 posts

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.

 
posted almost 3 years ago
distler 77 posts

edited almost 3 years ago

Forum: Instiki – Topic: Bugs

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.

You’re probably correct. The rule is that pages with Flash messages on them (like the one that tells you that the file was successfully-uploaded) are not cached. So you get to see the correct page once, but if the incorrect one wasn’t deleted from the cache, that’s what you’ll see the second time.

Fixed in Revision 756 Revision 757.

 
posted almost 3 years ago
Andrew Stacey 118 posts

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.

 
posted almost 3 years ago
distler 77 posts

edited almost 3 years ago

Forum: Heterotic Beast – Topic: Rails 3.1.0

I upgraded Heterotic Beast to Rails 3.1.0. Despite all my prior testing, the process didn’t go as smoothly as I would have liked, and this forum was pretty disrupted for most of Friday.

Should be back to normal now. But leave a comment here, if something’s still broken for you.

The main new feature is the Asset pipeline, which supposedly speeds the delivery of static files (CSS, javascript, and images). Unfortunately, the result seems buggy.

  • The reference

    "#{asset_path('something.png')}"

    sometimes turns into (the correct)

    "/forum/assets/something-5c4374aa4b1911ebbabb73883b3cd5c0.png"

    and sometimes it turns into (the incorrect)

    "/assets/something-5c4374aa4b1911ebbabb73883b3cd5c0.png"

    I’m using some Apache-fu to redirect the latter, but that shouldn’t be necessary.

  • I had to switch to Sass (from .css.erb) to get URLs for background images to include the fingerprint. I.e., within a .css.erb file, the above generates

    "/assets/something.png"

Other minor bugs include:

  • The acts_as_state_machine gem uses some deprecated methods, which generate a warning in the User model. There’s a Rails 3.1 fork which fixes the problem. But it’s unclear when, if ever, that will be released as a gem.

  • Prototype 1.7.0 generates a Javascript error

     Error: mismatched tag. Expected </link>.
     Source File:
     <div xmlns="http://www.w3.org/1999/xhtml"><link></div>

    The problem is in the LINK_ELEMENT_INNERHTML_BUGGY function, where you could replace <link> with <link/> to silence the error. This was not a problem in Prototype 1.6.x.

 
posted almost 3 years ago
Andrew Stacey 118 posts

Forum: Instiki – Topic: Bugs

Of course they are different.

I reserve the right to be stupid!

 
posted almost 3 years ago
distler 77 posts

Forum: Instiki – Topic: Bugs

Of course they are different.

  • <a> </a>” is an ”a” element with a single child node, which is a text node, containing ” “.
  • <a></a>” is an ”a” element with no children.

In X(HT)ML, the latter is equivalent to ”<a/>”.

The short-tag construction does not exist in HTML and all browsers interpret the latter as the opening tag, ”<a>”, of an ”a” element (which is not what you want).

 
posted almost 3 years ago
Andrew Stacey 118 posts

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

Text

Text

Text)

The reason why I’m using these is that in a LaTeX document, whenever a counter is stepped then hyperref inserts a bookmark in to the PDF. As there’s no actual text at that point, there’s no way to figure out what that bookmark should be attached to so I made it in to an empty anchor. But maybe I need to suppress it altogether and suppress implicit anchors, only inserting anchors that correspond to actual labels.