Recent Posts

Subscribe to Recent Posts 342 posts found

posted almost 3 years ago
Andrew Stacey 118 posts

Forum: itex2MML – Topic: Bugs

The optional argument syntax for extensible arrows doesn’t swallow spaces correctly. If I type \xrightarrow [a]{b} then in LaTeX, this is equivalent to \xrightarrow[a]{b} because spaces are automatically swallowed after commands. However, in iTeX then they are not equivalent:

[a]bab\xrightarrow [a]{b} \xrightarrow[a]{b}
 
posted almost 3 years ago
Andrew Stacey 118 posts

Forum: Instiki – Topic: Bugs

Thanks! That’s great.

On another topic, is there any progress on cache bugs? With the file uploading, then it doesn’t work at all. When I upload a file to a page then that page doesn’t get expired. We’re also seeing it with renaming pages on the nLab. We’re trying to keep a record of it in case it’s of use to you: http://www.math.ntnu.no/~stacey/Mathforge/nForum/comments.php?DiscussionID=3168

 
posted almost 3 years ago
admin 57 posts

Forum: Instiki – Topic: Bugs

D’oh!

 
posted almost 3 years ago
Andrew Stacey 118 posts

edited almost 3 years ago

Forum: Instiki – Topic: Bugs

I just updated my course installation to the latest one, did the ruby bundle and touch tmp/restart.txt as well. Then I tried to edit the stylesheet and kept getting Internal Application Error. Here’s what the log said:

RuntimeError (Instiki could not create directory to store uploaded files. Please
 make sure that Instiki is allowed to create directory /home/stacey/current/others/instiki/webs/
mathsnotes/files/0 and add files to it.):
  app/models/web.rb:169:in `rescue in create_files_directory'
  app/models/web.rb:161:in `create_files_directory'
  app/models/wiki.rb:32:in `edit_web'
  app/controllers/admin_controller.rb:59:in `edit_web'

There’s no reason why Instiki can’t create that directory, but I’m a bit at a loss as to why it is trying to do so.

I restarted the web server and got the same error.

 
posted almost 3 years ago
admin 57 posts

edited almost 3 years ago

Forum: Heterotic Beast – Topic: Rails 3.1.0

Now on Rails 3.1.1.

 
posted almost 3 years ago
admin 57 posts

Forum: Instiki – Topic: Bugs

This one’s possibly the most obscure yet!

Not terribly obscure at all. But it does highlight how overloaded the WikiLink mechanism is. Ugly as sin!

This is probably not the right fix. But it’s a fix.

 
posted almost 3 years ago
Andrew Stacey 118 posts

edited almost 3 years ago

Forum: Instiki – Topic: Bugs

New one for you. This one’s possibly the most obscure yet!

The wiki doesn’t like ampersands in file names; that is, in the [[file|filename :file]] syntax (or whatever the right syntax is). This feels a bit like a “my head hurts when I hit it with a hammer” bug! Obviously, no sane person would put an ampersand in a file name. I did so by accident and it threw “Internal application error” in my face. It was only by looking at the logs that I realised what I’d done. The logs have:

ActionController::RoutingError (No route matches {:controller=>"file", :web=>"mathsnotes",
 :action=>"file", :id=>"lecture.annotations.2011-10-0&.pdf"}):
  lib/url_generator.rb:83:in `file_link'
  lib/url_generator.rb:43:in `make_link'

(and a whole load more “in XYZ”s - I presume that the whole trace isn’t necessary)

 
posted almost 3 years ago
admin 57 posts

Forum: Instiki – Topic: Bugs

Indeed.

 
posted almost 3 years ago
admin 57 posts

Forum: Instiki – Topic: nlab

I suppose there is a marginally higher probability that a ‘merge’ will succeed with some lines commented-out, instead of deleted.

But I expect that it’s a small effect; hardly worth obsessing-over.

 
posted almost 3 years ago
Andrew Stacey 118 posts

Forum: Instiki – Topic: Bugs

This is probably related to that last one. Is the black square inserted at the end of a proof also done by javascript? If so, that might be worth thinking about whether or not it makes the same assumption. In particular, if a proof ends with a bit of displayed maths then the square gets inserted into the containing div which is centred. This looks a little odd.

 
posted almost 3 years ago
Andrew Stacey 118 posts

Forum: Instiki – Topic: nlab

Back on the CSS thing. I’m going to experiment with taking it out on my course wiki (safer than on the nLab). Since it’s in the main instiki file I guess I have to take it out system-wide (though I could put it back on a per-web basis, I guess). What’s the safest way to do that given that this is a file in the VCS? Should I comment out the line, or delete it?

(I want to avoid - as much as possible - breaking things when I do a bzr pull)

 
posted almost 3 years ago
distler 81 posts

Forum: Instiki – Topic: Bugs

Ah. I see.

Thanks.

 
posted almost 3 years ago
Andrew Stacey 118 posts

Forum: Instiki – Topic: Bugs

What are you using to show the source? My default is Firebug, though I also use the “View Source Chart” addon. Here’s what Firebug says it sees:

<div id="thmA" class="num_theorem">
<p>
<span class="theorem_label">Theorem</span>
<span>. </span>
Correct behaviour
</p>
</div>
<div id="thmB" class="num_theorem">
<ol>
<span class="theorem_label">Theorem</span>
<span>. </span>
<li>A list, with</li>
<li>Incorrect behaviour</li>
</ol>
</div>
<div id="thmC" class="num_theorem">
<div style="float: right;">
<span class="theorem_label">Theorem</span>
<span>. </span>
<p>A comment to one side</p>
</div>
<p>The theorem</p>
</div>

In particular, note that the second theorem label is a child of the <ol> element.

If I just do the naive “View Source” then this is what I see:

<div class='num_theorem' id='thmA'>
<h6 id='theorem_1'>Theorem</h6>

<p>Correct behaviour</p>
</div>

<div class='num_theorem' id='thmB'>
<h6 id='theorem_2'>Theorem</h6>

<ol>
<li>A list, with</li>

<li>Incorrect behaviour</li>
</ol>
</div>

<div class='num_theorem' id='thmC'>
<h6 id='theorem_3'>Theorem</h6>

<div style='float: right;'>
<p>A comment to one side</p>

</div>

<p>The theorem</p>
</div>

So you’re right and wrong. What I’m seeing on the page is not an artefact of Maruku. Since the source sent by Instiki is correct, my guess is that it is Javascript that is converting the <h6> to a <span> and is inserting it as a child of the first element. (In my opinion, it should do so only if that first element is a <p>, otherwise it should be in a block element all of its own.)

 
posted almost 3 years ago
distler 81 posts

Forum: Instiki – Topic: Bugs

Sorry.

Maruku’s HTML output looks perfectly OK (ie, as expected) in your example(s). (View the XHTML source, and tell me what you think is wrong with it.)

What you are complaining about is that the CSS doesn’t produce the desired appearance of the output.

Since you’ve been mucking about with the CSS of the Theorem Environment, why don’t you muck about some more and get it to format your example correctly.

 
posted almost 3 years ago
Andrew Stacey 118 posts

edited almost 3 years ago

Forum: Instiki – Topic: Bugs

Here’s a maruku bug; I guess I’m noting it as much for when (if!) you change engines as for hoping that it’ll get fixed now.

In a theorem or proof environment, the conversion of the h6 element to a label doesn’t always work correctly if the following element is a block-level one (list or a div, for example).

I’ve been trying to post an example here, but failing miserably. Even the correct syntax doesn’t seem to be working. So I’ve stuck an example at the top of the Sandbox in the nLab:

http://ncatlab.org/nlab/show/Sandbox

(I originally noticed this on my course wiki.)

 
posted almost 3 years ago
Andrew Stacey 118 posts

Forum: Instiki – Topic: Bugs

I was on 759. I’ll upgrade today.

I was also probably doing something more complicated than I described, only I can’t remember all the steps, since I was moving content from one page to another and renaming them. I thought I’d described the important ones, but there may have been something that I’d missed.

I’ll try to be more observant of my own behaviour in case it occurs again!

 
posted almost 3 years ago
distler 81 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 81 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 81 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 81 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 81 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.