Want to take part in these discussions? Sign in if you have an account, or apply for one below
Vanilla 1.1.10 is a product of Lussumo. More Information: Documentation, Community Support.
I was just alerted (here) that things didn’t render properly at Science of Logic: most hyperlinked words didn’t show up at all (not even the link text). I made a trivial edit and resubmitted, now things seem to be back to normal (also in the history, rev 261 it is back to normal, so I cannot point to a page that still has the problem).
But then I noticed that the link to ∞-representation remains gray, while the entry infinity-representation does exist, and should be redirecting.
Looking at that entry, it, too had the problem that hyperlinked words didn’t display! I resaved, and it works now. But maybe this means that some/all entries need another re-rendering?
And the following issue remains: ∞-representation still does not redirect. I copy-and-pasted it into the redirect, to be sure that there is no funny unicode ambiguity in the background, but that didn’t help here.
One or two entries may unfortunately still need re-rendering, yes. Should only be a very small number, though. There have been issues with getting all pages to render in a sequence. I think I may have tracked down the reason (some unexpected, for me at least, way some command in Rails behaves), and we have the new queue now which seems to be working well, so I can give it another go once I have added a ’low priority’ option to the queue.
Not sure what the issue with ∞-representation is, I’ll look into it. Thanks for raising it!
All right, thanks a million!
In fact none of the redirects at infinity-representation were working. This was due to a syntax error higher up the page (a tex block had not been correctly closed), which I have now fixed. I need to add something to try to detect these kind of syntax errors, but it is not completely trivial, as we have discussed before.
Oh, I see. Thanks for informing us. I’ll try to keep an eye out for syntax errors next time that something seems not to quite work.
Just trying to make an edit to: causal locality. But upon hitting submit I keep getting the error message “Couldn’t find Web without an ID” above an edit pane that has forgotten my edits. (?)
But upon hitting submit I keep getting the error message “Couldn’t find Web without an ID” above an edit pane that has forgotten my edits. (?)
My apologies. I was in the process of activating the new renderer for all webs (before it was only the main nLab). Now completed, but there was some disruption for a while (it was not simply a trivial case of ’switching it on’, I had to make some changes here and there). I should have made an announcement; I am very sorry if you lost a significant amount of work.
I think that things are working fine, both on the main nLab and on personal webs, now. But there may be a few gremlins; just let me know if so.
The edit pane seems unpredictable with regard to whether it retains or loses edits when there is an error. Something to look into when I get the chance.
I’ll try to keep an eye out for syntax errors next time that something seems not to quite work.
Great! They can be hard to spot, though, so don’t worry. It is my responsibility to find a better way of detecting the errors, so I do not mind having the burden of fishing out the errors in the meantime.
Whilst I have now switched on the new renderer for all webs, I have not, by the way, re-rendered any content for the moment. So it will only take effect after an edit is made. But Towards a diagrammatic proof of the Poincaré conjecture for knots (richardwilliamson), whose source is entirely with the new ’LaTeX syntax’, has been rendered with the new renderer.
Hi RIchard,
just to let you know: This morning also Albert algebra had the problem with hyperlinked words not showing up, even though the entry worked and was edited just yersterday.
It seemed to me that the top of the page was okay, and the proble started right where you had added the new proposition syntax, but I didn’t check carefully before re-saving the entry. Should have done that. Just saying in case you recognize some potential causation.
Hi Urs, thanks for letting me know. That is very strange. Please let me know next time you see an occurrence of this, I cannot think of any explanation of it at the moment. I have not observed this myself! If re-saving fixed it, it would not be likely to be caused by the new syntax.
Hi Richard,
sorry, one more:
The links to complex K-theory do not work, even though this is a redirect to topological K-theory.
I suppose this means that the latter page has a hidden syntax error somewhere. But I don’t see it…
Thanks Urs! No need to apologise, it is I who should be doing so. I have been wrapped up with other things and had no time to look into anything this evening, but will take a look as soon as I get the chance. I did however make some progress earlier on the long-running asynchronous problems, I think I may be able to solve them. Again, need a little more time, but will keep people updated.
By the way, I have switched off all re-rendering for now except on the immediately edited page. This means that any changes in redirects or included pages will not be reflected in pages which depend upon them, unless one manually re-renders them. Apologies for the inconvenience; as in the previous paragraph, I’ll fix as soon as possible. Better this I think than running the risk of the nLab being down, which is what happens when the re-rendering spirals out of control.
I am about to switch re-rendering back on. I have made some significant changes to how it is done, and am hopeful that it may work better this time. Some disruption may be seen when editing for a short period; I suggest to save all edits before submitting until I make another message here.
Yes, there are some issues. I am going to try to fix them rather than revert. You should not lose any work if you submit, but the page will not render properly for the moment.
Actually, I would ask people for the moment not to submit any edits, please. Apologies for inconvenience, I will update soon.
I am still fine-tuning some things, but things should be stable now. I will update when I completely done.
Am done for today. I have tested now on a page which triggers very heavy re-rendering, and it seems to be handled fine.
There is only one issue that I know of remaining: one may on a rare occasion get a timeout when saving an edit. I am not quite sure why (the code is supposed to be non-blocking), and will look into it. However, the timeout is harmless; the edit will be saved, and the content will be rendered.
For those interested, recall that because the nLab pages are now more or less static content, if one makes an edit on a page that affects a link on another page, or is included in another page, all those pages which depend on it must be re-rendered. We cannot on a web server wait until all that is completed, a web server should respond to requests quickly. Thus we have to do the re-rendering asynchronously, i.e. the web server just says ’I’ll handle it’ and returns, and the re-rendering is carried out later, in a different thread/process.
What I have done in the latest update is that I realised that Maruku (the thing which produces HTML from the Markdown/Tex that we write) can be run from the command line. Previously I have had to use it within Rails, i.e. within the web server on which Instiki is running. This increased the complexity of the logic, and created enormous problems with threading: a web server is made for threads to be handled quickly, and it is not good to have to introduce further threading which is not part of the dealing with the web requests, which is what is needed to have asynchronicity. So now I was able to rework the rendering logic a bit so that Rails is not involved: it just calls the renderer API as before, but now this renderer API does not have to go back into Rails to render the markdown, it is all handled by command line APIs outside of the web server. The threading is now handled by the operating system on the server (together with the queue API I wrote), which is very robust. In particular, I have been able to increase the throughput massively in the queue API (and we could go much higher I believe, I am being a bit careful).
In summary, I am cautiously optimistic that things might be working well now on this front, which will leave me free to work on the other things which have been piling up. As I have mentioned before, the page one immediately edits should also be rendered asynchronously; I have been waiting until we had stability with the asynchronous rendering before proceeding to this, but if we now have that, I can tweak the user interface to allow for this.
The links to complex K-theory do not work, even though this is a redirect to topological K-theory.
I suppose this means that the latter page has a hidden syntax error somewhere. But I don’t see it…
Yes, there was a tex block which was not closed/opened properly. Not easy to find, I have fixed it now.
I have also begun the process of trying to make it easier to detect syntax errors. In particular, tex strings are now validated (by running itex2MML on them outside of Maruku) in the course of rendering. This was not actually very helpful in this particular case, because the invalid tex string ended up being empty (!), but at least it would have been flagged as an issue with opening/closing of LaTeX blocks.
Re #18: Just to confirm that things do seem to be working very well now. The timeout issue is still there, but not very serious, as I mentioned. Will fix when I see where the blocking is coming from!
Just saw the following:
The entry Deligne’s theorem on tensor categories currently does not render properly (to see this quickly, scroll down to the very bottom: all double square bracket hyperlinks appear non-rendered).
This must be due to LaTeX syntax errors in the code. Luckily, there is now the functionality that upon saving the syntax error is displayed in an error message, very helpfully.
However, there seem to be several syntax errors in this entry, and the following problem occurs: After fixing the first, one does get the error message for where the second is, but thereby, in the edit pane the first error is being reinstantiated. I suppose the second error message prevents the first fix from being saved?
Luckily, there is now the functionality that upon saving the syntax error is displayed in an error message, very helpfully.
Yes, I added this yesterday :-).
However, there seem to be several syntax errors in this entry, and the following problem occurs: After fixing the first, one does get the error message for where the second is, but thereby, in the edit pane the first error is being reinstantiated. I suppose the second error message prevents the first fix from being saved?
Ah, thanks for pointing this out. Your diagnosis sounds correct. Do not have the opportunity to fix it now, but will do so later if I get the chance.
Thanks, Richard!
I have fixed it now by some copy-and-paste yoga, saving the article paragraph-wise and checking for errors.
Now it all works again.
Besides a doubled closing curly bracket, which was announced in the error message and easily fixed, it seems that what confused the system was a missing opening dollar sign. It seems that this is what got reported as an erroneous but allegedly empty LaTeX block.
Great, thanks for taking the time to fix this!
The bug mentioned in #21 when there are several syntax errors should now be fixed. See here.
When I get the chance, I will see if I can find a way to improve the error message in the ’allegedly empty’ case. It is not completely obvious to me how to do it just now.
Thanks!
I can see that making the system spot missing opening dollar signs must be pretty hard. But it shouldn’t be too important in usual practice.
Thanks, Richard!
Hope you don’t mind me mentioning one more bug. This has been around since the beginning of the nLab, but maybe now is the time that for you it’ll be immediate to fix:
After one comes back from the dialogue of instiki’s file upload process, the link to the file (now existing) remains gray. Usually it’s secretly active, but displays as if it were not. One has to re-save the entry to trigger the link being shown properly. (recorded also here).
I say “usually”, because sometimes it isn’t, and one has to repeat the upload dialogue (and repeat the re-save.) But I don’t know if this is two separate bugs or two incarnations of the same one.
And one more, if I may, just for the record:
I keep coming across entries that have included tables via [[!include entry name]] that don’t display properly: One sees the table outline and some symbols do appear, but mostly the table entry are shown empty.
In each case resaving the entry (the including entry!) solves the problem.
I gather you keep saying that you trigger re-rendering of all pages? Just out of interest, how long does it take for all entries to get touched this way? Seems to be days and weeks, is that possible?
Thanks for reporting, I’ll look into these when I get the chance.
I gather you keep saying that you trigger re-rendering of all pages?
I had tried on many occasions, but things were never stable enough to have a complete run. I usually trigger re-rendering of just a subset. Things should be stable now, though, because the asynchronous stuff seems to be robust and working well now, so I can give it another go sometime.
Just out of interest, how long does it take for all entries to get touched this way? Seems to be days and weeks, is that possible?
No, indeed, the reason not all entries have been touched is, as above, that there has not been a complete run. Also, because we are in a period of quite major improvements (or what are hopefully improvements, at least!) and fixes, I try not to re-render everything on each occasion. But we should definitely do a completely run through again soon.
The throughput on the asynchronous re-rendering is quite high now. I can try to see, next time, how long it takes; I would guess an hour or so now, but it might be less (or more!). The thing is that it does not just re-render all 18000 pages, it has to follow the tree of redirects and includes, so the number of re-renderings is quite a bit higher.
The issue with table rendering might be a relatively new one, by the way; it was maybe not announced very prominently, but I made a major change last week so that Maruku (the Markdown renderer, including the itex2MML renderer) is now run outside of Rails. This seems to have gone fine on the whole, but there may be an issue or two with includes that need solving.
I see, thanks.
Please allow me to mention yet one more:
at our old friend, the entry geometry of physics – perturbative quantum field theory, the table of contents has disappeared again (The word “Contents” appears, but then the list of sections is missing)
The same problem as in #31 occurs also at geometry of physics – categories and toposes. The table of contents does not appear any more, except for the line “Contents”.
Re-saving does not help. Maybe it has to do with the chpaters being in !include-files?
Yes, I believe it is a problem with includes. Thanks for raising, I will try to fix as soon as possible (but cannot do so just now unfortunately).
No rush. Thanks for looking into it!
Hi Richard,
hm, now I see that also the equation numbering broke again. To see this at geometry of physics – perturbative quantum field theory search the document for the string (eq:.
Thanks for mentioning. All the same issue I think, not had a chance to look into it unfortunately. Apologies!
All the same issue I think
Oh, okay. Sounds good.
I see that the list of categories on the bottom of the page lost the comma and the spacing between the items. For example in my personal web https://ncatlab.org/zoranskoda/show/analiti%C4%8Dka+geometrija instead of
category: zadarmat2, zadarmat4
now it is displayed something like
category: zadarmat2zadarmat4
Thanks for raising this, Zoran. Ali has raised a similar issue. I will fix as soon as I get the chance (not had time for a week or so to do much maintenance).
Just for the record, for later use:
I could maybe narrow down the rendering problem with geometry of physics – categories and toposes:
I tried to re-save all the separate !included entries.
One of them didn’t save now, due to a LaTeX syntax error. I fixed that.
But this problem here remains, and might cause the toc not rendering in the full entry:
Trying to re-save geometry of physics – homotopy types consistently fails with a “524 timeout error” (?)
Thanks! I will try to find time to take a look later.
Very strange! I deleted the link modal logic and retyped it to see if it made any difference. It did not!
Re #42 and #43: this was due to a syntax error. Someone had used a backtick, like one would in LaTeX, instead of ’ for the left hand quotation mark around ’knowledge’. This caused everything afterwards to be rendered verbatim, because it is interpreted as a code block. We have seen this one before; I should try to add a check for it at some point. Fixed now.
Thanks. The back ’tick’ is a very annoying feature of these systems.
Re #38: Fixed now. I re-rendered the page that you linked to, but otherwise have not re-rendered anything; thus the fix will take affect only after an edit is made (of course one can make a trivial one).
Re #31 and #32: I believe that I have now fixed the table of contents issue. Was a tiny difference in the output of Maruku when called directly as opposed to from within Rails before, which caused the table of contents renderer not to find the relevant place to insert it. Fixed this bug now.
I have re-rendered all pages whose title begins ’geometry of physics’. Several of the pages had LaTeX syntax errors, but I have fixed all of these now. The page Super topological T-Duality (schreiber) on your personal web, Urs, also has a LaTeX syntax error, but it is in the enormous block including \text{given by}, and I do not have the time just now to go through that block to find out exactly where the error is!
Re #35: Equation numbering still does not work. This is not an aspect that I had previously looked into in the new renderer, it is only Maruku that had been handling this. It breaks on pages with includes. I will add something to the new renderer to handle these kind of references to equations, but it is too late for me to do so today, unfortunately.
Re #40: The timeout can happen; the immediate page that is edited is rendered synchronously, and the rendering has to be completed within 3 minutes, or else CloudFlare, which has a hard-coded limit of 3 minutes, complains. For now, I would suggest to get around this simply by dividing the page up into sections and including them in, like you have done elsewhere. The rendering does not actually stop when the timeout occurs, it will go through as normal, it is just a poor user experience. I have mentioned before that we could make the rendering asynchronous for the immediately edited page as well, which would mean no more timeouts, but we would have to change the user interface and the design would be more complex, so I have changed my mind a bit, and am now thinking of focusing on speeding up the rendering (e.g. by getting rid of/replacing Maruku) instead, because this has become much more feasible now that I have extracted the Maruku/Itex2MML rendering from Rails.
Re #35 and #47: I have now added something to the new renderer to handle equation referencing. In particular, the equation references at geometry of physics – perturbative quantum field theory seem to work fine now.
It does add a little more time to the rendering, and I think one will get a timeout if one tries to save this page directly now. But the timeout should I think be harmless, the edit should still go through. It remains a high priority to either make the rendering faster or else make it asynchronous (or both).
The way I have implemented the equation numbering/referencing is server side. I plan to change the theorem environment numbering/referencing to be server-side as well, in the same way (currently it is client side).
A consequence of the way I have implemented it is that each page now has the equation references within it stored in a JSON file. I will do the same for theorem environment/referencing when I get around to that. This means amongst other things that it will be fairly straightforward to implement referencing of theorems/equations across pages, and that it will be easy to give an error message if a reference does not exist, which is on the Technical TODO list (nlabmeta).
Thanks a million for this, Richard!!
Thanks for raising this, Urs, I will fix it as soon as possible!
when you follow this second link it works fine.
This is because revisions are still using the old renderer; the problem comes from the interaction between the new renderer and Maruku.
ah, right, you had told me this before, should have remembered. No rush, but would be nice if this could be fixed. Thanks!
on various entries the following bug appears:
Clicking on “Related entries” in the table of contents has no effect (while for all other sections it works!)
Example entries include:
but also many more. (Not sure if it affects every entry, need to check).
Thanks very much for reporting this! I believe it is essentially the same issue. I am tempted to make this the point at which I scrap Maruku and put the markdown parsing into the new renderer. But we’ll see how much time I get. If not, I can put in a workaround.
Just to bump this up:
This morning I saw two pages that didn’t render anymore, but showed xml parsing errors.
One was thesis Wellen (schreiber). I made a trivial edit and re-saved, now it’s fine.
The other is geometric quantization, as kindly pointed out by John Baez here. Here re-saving didn’t help.
Will try to take a look this evening. Very little time at the moment. If someone has time, one could just go through it bit by bit in the Sandbox until the error is located. But it could also be a bug in the table of contents, although there has not been one of those for a while. Leave it until this evening, just in case it’s a table of contents bug.
OK, fixed geometric quantization after all. There was some strange, inconsistent choice of heading depth at one place (probably a typo) that broke the table of contents renderer. The renderer should be able to detect that as a problem, though, I will try to fix that detection issue when I get the chance.
Thanks!! And thanks again.
This will be a pain, but allow me to say it nevertheless, just for the record:
Two subsections of geometry of physics – categories and toposes do not show up in the table of contents.
The issue is with the last of the !included chapters: geometry of physics – basic notions of higher topos theory. For debugging purposes, I have given that last chapter its own table of contents for the moment. As you see there, it has two sections, each with three subsections.
But the table of contents of the global entry geometry of physics – categories and toposes only shows the last two of these three subsections, in both cases. The subsections titled “Locally presentable -Categories” and “Cohesive -toposes” do not show up in the global toc (though they do show up in the local toc that I added just for debugging purposes).
(?)
Hopefully #59 is fixed now. The problem here was that Maruku (which is still used for part of the rendering, after the home-grown renderer has done its part of the job) was for some bizarre reason squashing together the HTML of the included page into one long line, without line breaks (the table of contents renderer expects at most one header in a line). It seems that it does not so if one surrounds it with a <div> block, so as a workaround I have now added such a block around all included pages. I hope that this does not have any side effects; please let me know if so.
The proper fix will be, as ever, to remove Maruku completely. Not that difficult, just no time at the moment.
Thanks!!
I fully understand that you have no time for such nuisances at the moment. All the more Thanks! for the quick fix!
Now that you say this, I realize that in the main file I had indeed separated all the !include lines by the Schreiberian whitespace.
$\,$
Or rather: all except the last one! (Which I have added now, just because it won’t hurt.)
So that “explains” why the problem occurred only with the last !include file.
You’re welcome!
Actually, this whitespace was there before, I removed it while debugging :-). Probably we just got lucky with the other includes (any kind of mathematical environment will introduce a line break, for instance).
I wished to raise this actually, maybe in a different thread. I would like to suggest that we do not use this whitespace hack. In another thread (#22 here), it seemed to cause a problem with includes. But in any case, it adds load to MathJax on a non-Firefox browser, and is not good semantically :-). Let’s introduce something better which you can use instead and which does what you need.
I guess that you need more vertical space. How about we introduce a little piece of syntax like
<add vertical space>
or something?
Thanks. Sure, I have no particular attachment to this hack. Now I forget why I didn’t use
<br>
Maybe there was a reason. If not, or if not anymore, I could just adopt using that.
Richard,
introducing those “div”-s seems to be causing problems elsewhere:
Presently the entry string theory is badly broken right after the table of branes. The first thing one sees where the rendering breaks is
\div>
Maybe now that I know to separate !includes by some line breaks, we could remove those div-s for the time being?
Thanks for reporting this Urs. There was a typo in my code from yesterday evening which affected inclusion of certain kinds of things, including tables. Fixed now, hopefully. Hopefully not too many pages were affected; just re-render if you see any.
The line breaks are not the issue here, the divs are necessary (until I remove Maruku, but even then they are not the worst idea).
Okay. Thanks!
1 to 67 of 67