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.
Jacques and I have been having a few conversations recently to try to figure out what causes the nLab to crash or go slow. Upgrading everything, and reverting a few of the changes that I put in (which were intended to help!) seems to have fixed the crashing problem for the moment (*crosses fingers*) but still some pages are slow to generated. Whilst this is okay once pages are cached, it’s a bit annoying in the edit-view cycle. I sent Jacques a page that was taking a considerable length of time (over a minute) to render and he worked out that it is actually maruku that is the biggest slow step in the process.
Now Jacques isn’t too happy with maruku for licensing reasons, so this is just another nail in its coffin. He’s already looked around for replacements, but the problem is that maruku is a pretty advanced (as in, lots of extra stuff) Markdown renderer. So any replacement would need modifying so that it could handle maruku’s syntax (which we do use, to good effect).
The one he’d like to use is called rpeg-markdown which uses something called a peg grammar to figure out its rules. So we’d need to write the routines for all the extra stuff.
If anyone is willing to help with this, the conversations that I’ve been having with Jacques about this can be found at his forum in the Instiki section.
(Note that that forum is a new project by Jacques and is as much to test the code as to have an actual forum for discussing instiki. Please think carefully before posting other stuff there.)
I am writing from (soon ending) vacation so can not download and look into large files these days, so I am just asking for future references. First of all, for every inclusion of new people in any Lab-related software project it would be nice to have at one place the effective picture of the whole system we use, that is which programs, databases etc. are used, size of each program source code, which program calls which, where are the main references on each part of the system, what system each runs on, which parts of the system can work and be tested standalone and so on.
Second, I am asking again why “Recently revised” is generated by testing each page in the database and not by incremental change of Recently revised list (actually its abstract form in a form of list ordered by better accessible key than the output key of time ordering) at each change of some page.
Regarding your first point: I would say that it sounded like a good idea, except that I’m probably the only person with sufficient overview to write it! I’ll sketch out a skeleton on nlabmeta and then people can ask for more details of those bits that are unclear.
Regarding your second point: Jacques would be better placed to answer this, but I can guess two reasons: Firstly, if you look at recently revised then you will see that it is not actually a sequential list of recently edits. Each page is listed at most once and by the most recent edit. So each edit’s incremental change would have to remove the previous one of that page. Secondly, Instiki saves this sort of information in the database. So the only real effect of your suggestion would be to have a new database table that just contained the last edit date of each page.
So each edit’s incremental change would have to remove the previous one of that page.
Surely, I think I commented on that before. This is not much time consuming process.
Surely also that it kind of assumes new database or list to be kept, but that new database can be very simple (and short if we limit to say last 50, 200 or 500 entries). I would even not say a database. It is enough to have a list of entries involved in say alphabetical order (so that it is easy to find) such that each listed entry has a link to the previous entry in time order. So that the output of the list is obtained by simply going down the list in this linked order (not the original order, which is useful for search). This way this list has two different axis.
Alternatively, one could go and look into the main database just for the time of the last edit of the new entry and change just the output list (or its internal format, which could be simplified) incrementaly: once one knows the timing one searches through output which is listed in time order to find the line where this entry is mentioned – this is logarithmic with the size of the list, as the list is time ordered. Then one erases that line and adds a line on the top. Nothing can be quicker than that and this would not require additional database. Just with each change of an entry, one looks for that single entry into database and if the entry is new (or the last edit of that entry before is older than the default time span of the Revised Entries). Then
I’ll sketch out a skeleton on nlabmeta and then people can ask for more details of those bits that are unclear.
It is also good to have parts of the code schematically separated into main function pieces. So that if someone gets looking into instiki or database part for example that one does not spend time going into irrelavant code, say the code which deals with html presentation. This is specially relevant if one hires somebody to help at critical point.
Some people in Croatia, belonging to 2 different project would like to establish a wiki for their own purpose with LaTeX capability and they are considering instiki as one of the options. If we had some clean info on our experience (not only instikiu istelf but supporting things like database used etc.) maybe we will get somebody paralelly working with ,ktesting and improve more or less the same system (it is in our interest that they setup as similar system as possible to share the experience in solving problems). One of the projects is in fact international and it is about the study of complex systems.
1 to 6 of 6