Not signed in (Sign In)

Not signed in

Want to take part in these discussions? Sign in if you have an account, or apply for one below

  • Sign in using OpenID

Site Tag Cloud

2-category 2-category-theory abelian-categories adjoint algebra algebraic algebraic-geometry algebraic-topology analysis analytic-geometry arithmetic arithmetic-geometry book bundles calculus categorical categories category category-theory chern-weil-theory cohesion cohesive-homotopy-type-theory cohomology colimits combinatorics complex complex-geometry computable-mathematics computer-science constructive cosmology deformation-theory descent diagrams differential differential-cohomology differential-equations differential-geometry digraphs duality elliptic-cohomology enriched fibration foundation foundations functional-analysis functor gauge-theory gebra geometric-quantization geometry graph graphs gravity grothendieck group group-theory harmonic-analysis higher higher-algebra higher-category-theory higher-differential-geometry higher-geometry higher-lie-theory higher-topos-theory homological homological-algebra homotopy homotopy-theory homotopy-type-theory index-theory integration integration-theory k-theory lie-theory limit limits linear linear-algebra locale localization logic mathematics measure-theory modal modal-logic model model-category-theory monad monads monoidal monoidal-category-theory morphism motives motivic-cohomology nlab noncommutative noncommutative-geometry number-theory of operads operator operator-algebra order-theory pages pasting philosophy physics pro-object probability probability-theory quantization quantum quantum-field quantum-field-theory quantum-mechanics quantum-physics quantum-theory question representation representation-theory riemannian-geometry scheme schemes set set-theory sheaf simplicial space spin-geometry stable-homotopy-theory stack string string-theory subobject superalgebra supergeometry svg symplectic-geometry synthetic-differential-geometry terminology theory topology topos topos-theory tqft type type-theory universal variational-calculus

Vanilla 1.1.10 is a product of Lussumo. More Information: Documentation, Community Support.

Welcome to nForum
If you want to take part in these discussions either sign in now (if you have an account), apply for one now (if you don't).
    • CommentRowNumber1.
    • CommentAuthorUrs
    • CommentTimeJul 15th 2014
    • (edited Jul 15th 2014)

    While the nLab is down (edit: now back up), maybe I should use the time to finally say the following, since it already came up elsewhere.

    As of recently, Andrew Stacey has handed back the tenant-ship of the nnLab server to me and is withdrawing from administering the nnLab software installation. From now on Adeel Khan Yusufzai is kindly offering help with/is taking care of whatever it takes to administer the server. I hope the workload will be light.

    • CommentRowNumber2.
    • CommentAuthorzskoda
    • CommentTimeJul 15th 2014
    • (edited Jul 15th 2014)

    So, there will be no need for a major migration (in terms of software changes) ? Good, if so.

    • CommentRowNumber3.
    • CommentAuthorTodd_Trimble
    • CommentTimeJul 15th 2014

    I hope the workload will be light.

    I do too. Many thanks to Adeel for taking this on!

    • CommentRowNumber4.
    • CommentAuthoradeelkh
    • CommentTimeJul 15th 2014

    Zoran: well, having to restart the server every couple days is not that fun. We are slowly working on setting up a MediaWiki version of the nLab so we can see how that compares.

    • CommentRowNumber5.
    • CommentAuthorTobyBartels
    • CommentTimeJul 16th 2014

    I once had access to restart the server, but it was an unusual log-in system (not password-based) and I lost the codes that gave me access. If I got access again, then I could help with the restarting instead of only posting complaints.

    • CommentRowNumber6.
    • CommentAuthorspitters
    • CommentTimeAug 1st 2014

    Adeel, can you elaborate a bit on the mediawiki plans? There were a number of discussions before. Also, PlanetMath and WorkingWiki were considered.

    • CommentRowNumber7.
    • CommentAuthorMike Shulman
    • CommentTimeAug 1st 2014

    FWIW, I would be very unhappy at having to use Mediawiki markup syntax on the nLab; I find instiki’s syntax infinitely easier to use.

    • CommentRowNumber8.
    • CommentAuthorTobyBartels
    • CommentTimeAug 2nd 2014

    Is that a countable or an uncountable infinity? (^_^)

    I also prefer Markdown to MediaWiki, although it's not a big deal; but I definitely prefer Itex to texvc.

    • CommentRowNumber9.
    • CommentAuthorzskoda
    • CommentTimeAug 2nd 2014
    I second Toby (about iTeX).
    • CommentRowNumber10.
    • CommentAuthoradeelkh
    • CommentTimeAug 2nd 2014
    • (edited Aug 2nd 2014)

    Currently we have a migration script that takes an Instiki installation and sets up a MediaWiki installation with the same pages. We decided to stick with iTeX, so the actual math code is not being converted, but the rest of the Instiki syntax is. This script has been mostly complete for a while, but as you can imagine there are some loose ends that need to be dealt with, which I have been postponing for a while. We are in discussions with Lee Worden, the author of WorkingWiki, and is likely that we may take advantage of his software as well (which is basically an add-on to MediaWiki).

    Mike, I don’t know if you mean just the math syntax or you mean everything else as well. In the latter case, I can’t imagine it would take too long to get used to the MediaWiki syntax, and I hope everyone would agree it would be worth it if it resolves the other issues we are having with Instiki.

    • CommentRowNumber11.
    • CommentAuthorMike Shulman
    • CommentTimeAug 2nd 2014

    Everything else as well. Getting used to it is not the question, I’ve used mediawiki for other projects; I just don’t like it. It’s ugly as heck for one thing.

    • CommentRowNumber12.
    • CommentAuthorzskoda
    • CommentTimeAug 2nd 2014
    • (edited Aug 2nd 2014)
    Could you in the meantime replace the massive "linked from" lists in the nLab with button (link) to a script which generates this just on (rare) request ? I think everybody agreed that this feature is mostly annoying and rarely used.

    As far as "instiki issues", I guess most of those is due heavy updates of databases (like new linked pages get updated with update of every page and when we generate a new version of a page it checks which links to other titles in the nLab are actually to existing pages etc.) and so many extras like massive usage of floating tables of contents and massive aliasing (some pages have tens of aliases). I do not believe other software can avoid this. Only if we decide not to so often update related pages, include so many repeated tables (or even exclude robots at peak hours) etc. we can get radically better results. In other words, I think that most of the problem is in logical requirements the current system satisfies, and it is my impression that the heaviest users like Urs are not going to give up on those.

    As far as your estimate that the learning curve is low, please take in mind how many occasional users hesitate or hesitated to contribute because of learning markup (I myself did not contribute to nLab in first half a year of existence for that reason) and new
    cycle of learning may loose some users. Also what about other users of the system -- I mean personal pages as well as Azimuth Project -- will they be affected if changing the system ?
    • CommentRowNumber13.
    • CommentAuthorTobyBartels
    • CommentTimeAug 2nd 2014

    If we have clear tests showing that MediaWiki will resolve issues that we have, then migration is probably worth it, especially since we can keep Itex. This would mean, at minimum, side-by-side installations of both platforms with the same content, in which the Instiki one shows our problems and the MediaWiki one does not. But if switching to MediaWiki doesn't solve our problems, then I wouldn't want to do it, even keeping Itex.

    • CommentRowNumber14.
    • CommentAuthorzskoda
    • CommentTimeAug 2nd 2014
    How to test ? We need a realistic traffic with robots, multiple users, pages which are in the middle of editing, database keeping the old versions, illegal and invalid edit attempts and possibly doing rolling back as one of the actions. But realistic traffic we get only once the $n$Lab new version is as known and as used as the old one. Probably some things can be simulated but it has to be done very intelligently and having realistic traffic data in various aspects including rare events which might trigger collapsing.
    • CommentRowNumber15.
    • CommentAuthorMike Shulman
    • CommentTimeAug 2nd 2014

    There appear to be some mediawiki extensions that enable Markdown parsing; maybe we could try some of them?

    Is the mediawiki itex going to generate mathml or use mathjax? In addition to the itex input syntax, one of the things I like a lot about instiki is that it generates mathml directly for browsers that understand it, so one doesn’t need to wait forever for mathjax to render a page while it messes up all the scrolling.

    Another problem with mediawiki is that its redirect facility is pretty broken. I didn’t realize this until Jacques implemented a non-broken redirect facility for instiki, but the difference is really huge. AFAIK with mediawiki you have to create a separate page for each redirecting name containing a “redirects to” command, whereas with instiki you simply put commands on the page being redirected to that say all of the different names that should redirect to it. When we have one page that is redirected to by 20-30 different names, obtained by all possible combinations of pluralizations and variations in terminology, I think it’s much easier to manage when we have all the redirects in one place.

    • CommentRowNumber16.
    • CommentAuthoradeelkh
    • CommentTimeAug 3rd 2014
    • (edited Aug 3rd 2014)

    @12: I’ll try to implement your request about the “linked from” section. I don’t completely agree with your diagnosis of the Instiki issues, but I would have to do an audit of the code to say for certain where the performance problems are. I’m willing to do that in case the MediaWiki test doesn’t give positive results.

    @13: I agree completely. I should stress that the MediaWiki experiment is just that, an experiment, unless we see significant improvement in performance.

    @14: There is various software designed specifically for the purpose of running such tests.

    @15: I tried one at some point with not much success, but I’ll look into it again. The iTeX will be converted to MathML, which will be rendered by the browser or otherwise by MathJax. Regarding the redirect function, I would say it’s Instiki’s redirect function which is broken: there are multiple instances of nLab pages which both “want to be redirected” from the same thing. In these cases the software makes an arbitrary decision about which one gets the redirect. Also, the majority of redirects are for plural forms, which in MediaWiki are usually not necessary, due to the possibility of writing e.g.

    [[scheme]]s
    

    Sure, this doesn’t always work, but I wouldn’t say the system is “broken”. Wikipedia hasn’t had any problem with it, for example.

    • CommentRowNumber17.
    • CommentAuthorTobyBartels
    • CommentTimeAug 3rd 2014

    Yes, thanks Mike, MathML is also important to me.

    I think that neither Instiki nor MediaWiki do redirects sensibly, so what do y'all think of that! (^_^)

    • CommentRowNumber18.
    • CommentAuthorzskoda
    • CommentTimeAug 3rd 2014
    • (edited Aug 3rd 2014)

    the majority of redirects are for plural forms

    This is not true; the plural forms are the least important and I personally use them almost never (and list them just because of peer pressure as I was criticised by Urs and others for not creating some plural aliases in old days of nnLab). Majority of redirects is about various spellings of names (including Witten vs. E. Witten vs. Edward Witten), abbreviated vs. very long versions (cf. scheme vs. algebraic scheme, or look at long list of versions for BV formalism/theory, BV-BRST etc. nonabbreviated etc)) and the entries which unify temporarily or permanently close-by entries or topics. For example, Urs was recently suggessting on having absolute value and valuation in the same entry (some, including me were opposing this, but never mind). There are also redirects to some abandoned earlier titles of the page in the history, not to loose the external links. These are all quite essential uses and we have spent huge amount of time (esp. Toby) to properly keep track of all these issues. One should also think of external links which already link to nnLab and crosslinkings with personal labs.

    I do not think it is a good approach to neglect issues as “minority of cases” and alike qualifications. It is better first to analyze the logical and semantical structure of what we have or tended to build in last several years and then to see what can be possibly changed. Thank you for your kind effort, but please be aware of the rich semantic structure beyond the mere existence of links and iTeX.

    • CommentRowNumber19.
    • CommentAuthoradeelkh
    • CommentTimeAug 3rd 2014

    The redirects will continue to work as they are now, if that is your concern.

    • CommentRowNumber20.
    • CommentAuthorzskoda
    • CommentTimeAug 3rd 2014

    will continue to work as they are now

    So, can you include all the redirect commands in the same page or not ? I mean do you mean just from the point of view of viewer or the creator or the page as well ?

    • CommentRowNumber21.
    • CommentAuthorzskoda
    • CommentTimeAug 3rd 2014
    • (edited Aug 3rd 2014)

    Yes, thanks Mike, MathML is also important to me.

    For me that is important only when I am (with my laptop) on an expensive and slow mobile network what is quite often (in fact this is the only choice at least all my weekends).

    • CommentRowNumber22.
    • CommentAuthoradeelkh
    • CommentTimeAug 3rd 2014

    No, I mean that readers of the nLab won’t see any difference. Your post #18 seemed to be worried that only plural redirects would continue to work.

    • CommentRowNumber23.
    • CommentAuthorzskoda
    • CommentTimeAug 3rd 2014
    • (edited Aug 3rd 2014)

    Your post #18 seemed to be worried that only plural redirects would continue to work.

    My concern is that the standard job of creator of nnLab includes quick creation and changes in the structure of various links, not only plurals (what can maybe be automated, hence skipped if well done, in future), and one likes to have control and overview of them from a single page (surely not that important if the same page where the text is, but for all redirects a single place to compare and edit, copy and paste with simple variations etc.).

    • CommentRowNumber24.
    • CommentAuthoradeelkh
    • CommentTimeAug 3rd 2014

    I just found the following MediaWiki extension which seems to replicate the redirect behaviour of Instiki: http://m.mediawiki.org/wiki/Extension:IndexFunction. It also seems not to be “broken” in the sense I mentioned above:

    Multiple pages can share the same indexes, instead of redirecting to the page, the titles will redirect to an automatically generated disambiguation page.

    I would be happy to install this extension.

    • CommentRowNumber25.
    • CommentAuthorMike Shulman
    • CommentTimeAug 3rd 2014

    Excellent! If we can install the IndexFunction extension and also one of the Markdown extensions, then most (maybe all) of my objections to mediawiki would disappear.

    If we do move to mediawiki, we would also have the possibility to experiment with its more powerful templating/inclusion capabilities, and maybe even the semantic mediawiki extensions.

    • CommentRowNumber26.
    • CommentAuthorspitters
    • CommentTimeAug 3rd 2014

    I guess, we could also start using bots, i.e. one for generating and correcting citations. Of course, we have to be careful not to let it be too eager.

    For more semantics approaches planetmath may be better, but I have not looked at the details carefully. Mike did you have specific semantic mediawiki extensions in mind?

    • CommentRowNumber27.
    • CommentAuthoradeelkh
    • CommentTimeAug 3rd 2014

    I should note that Jacques has already (!) addressed the problem with the redirect function I mentioned (#16). Now that I’ve applied the latest update, there is a small disambiguation notice on affected pages: see for example presheaf category, projective spaces, 1-type, univalent foundations.

    • CommentRowNumber28.
    • CommentAuthoradeelkh
    • CommentTimeAug 3rd 2014

    Re #12: I’ve just removed the linked from area for now. If somebody complains I’ll add a link to generate it on request, as Zoran suggested.

    • CommentRowNumber29.
    • CommentAuthorzskoda
    • CommentTimeAug 4th 2014

    Great, thanx!

    • CommentRowNumber30.
    • CommentAuthorTobyBartels
    • CommentTimeAug 4th 2014

    I like having linked-from, but it's not that useful, because what we really need is one that also counts links to redirects (as MediaWiki's does).

    • CommentRowNumber31.
    • CommentAuthorMike Shulman
    • CommentTimeAug 5th 2014

    Re #26, I recall some discussion of a “database of categories” a while ago that I thought could be maintained better using semantic-wiki info on nLab pages.

    Re #27, Jacques’ ability to fix things on request is certainly one advantage of instiki.

    • CommentRowNumber32.
    • CommentAuthorspitters
    • CommentTimeAug 5th 2014

    Mike, it could have been this one. Discussion started with a database for counterexamples in topology combined with ATP.

    • CommentRowNumber33.
    • CommentAuthorzskoda
    • CommentTimeAug 5th 2014

    Re #27, Jacques’ ability to fix things on request is certainly one advantage of instiki.

    Instiki is in version 0.19.7, so with such a programmer behind the scene, much more is expected in future…