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 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 nforum 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 sheaves simplicial space spin-geometry stable-homotopy-theory stack string string-theory 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).

Topics

Results 31 to 60 for nothing

Previous Next

    • I've just (or am just about to) put a load of arrowheads in the SVG Sandbox.

      How do these look? Are they okay? Should there be more (if so, which?)? Are some of these too strange to be in the "official" list?

      The list is based on what the xy package offers as "standard" arrowheads.

    • There's lots more tweaking and stuff that I could do, but there comes a point where it's useful to have other points of view ...

      I've been working on a program with the original intention of converting xymatrix diagrams into SVG. It got a bit bigger and is on the way to being a LaTeX to XHTML+MathML+SVG converter. If you want to try it out, you can play with it here:

      http://www.math.ntnu.no/~stacey/PHPLaTeX

      The two main selling points are:

      1. It's written entirely in PHP, so it's quite portable.
      2. It tries to emulate TeX's method of parsing a document by reading and expanding tokens. This means that it can process macros.

      So if you write \newcommand{\R}{\mathbb{R}} then you'll be able to use \R for \mathbb{R} for the rest of your document.

      It's an alpha release, if even that, so don't expect it to do anything right. Also, you can't cut-and-paste the diagrams into the n-lab because it uses something that Jacques doesn't allow. However, if my method of getting MathML embedded into SVG produces reasonable results, then I don't think it would be hard to add support for the extra bits. (Instiki sanitises incoming SVGs and so has to be told to let through stuff.)

      Anyway, have fun playing with it if you feel so inclined. Let me know what's missing (I know that there's lots missing, but if you tell me then that tells me what to prioritise), and what it does wrong. You can download the source if you feel so inclined using bzr (just point it to the same place).

      Oh, and it currently only supports LaTeX maths environments. I'll put in support for dollars later since so many people use them (though they really ought to know better).

    • The purpose of this discussion is to talk about how we might like to make easier the following situation:

      You see a page with a link foo, and you know that foo really should redirect to bar, but it doesn't yet. Or maybe you even put the link foo in the page because you'd like it to appear that way, and you want to create a redirect rather than write ‘foo’.

      Now, if you click on foo, you'll be asked to create a new page, which is exactly what you don't want to have happen! What you really want to do is to add ‘!redirects foo’ to bar, but you don't have a link to get to bar.

      The best thing to do now is to hack the URI to read http://ncatlab.org/nlab/edit/bar. Even that is frought with peril, because if you remember this only after you click the link to start foo, then you might accidentally end up at http://ncatlab.org/nlab/new/bar, and that would be wrong! (But saving this is not as wrong as creating an unnecessary foo would be, since you can rollback bar afterwards.)

      I had one suggestion, at another discussion, but I'm opening this one up because it's not perfect and I would like to see more suggestions that don't get buried at the bottom of a two-page discussion.

    • OK, I've found a missing feature that I think really amounts to a bug in the redirection system: we can't redirect pages whose titles begin with spaces.

      For example, Tim Porter just made a contribution signed as ‘  Tim Porter’. This isn't the first time that Tim's misspelt his own name; in the past, I created redirect pages to point to Tim Porter. But now I decided that I should add ‘!redirects   Tim Porter’ instead. But I was rather suspicious that this might not work … and it didn't!

      Note that no amount of fixing links and deleting bad pages will get rid of this. The contribution is signed ‘  Tim Porter’, and going to the contribution listing or archive page will always link to   Tim Porter as the contributor.

      (Note that it is no longer possible to create wikilinks to pages with trailing or double spaces. But you can still sign your name like that or create such pages by following such a signature or by hacking the URI.)

    • The ‘Change page name.’ feature doesn't work on some pages with odd names, such as Connes' cyclic category. (Be sure to cancel your edit after checking this for yourself.)

    • [The following is a text that arose out of private discussion Andrew Stacey and myself had. Discussion of this text should take place here, whereas any stable effects this discussion hopefully bears should be implemented at the nLab entry <a href="http://ncatlab.org/nlab/show/organization+of+the+nLab">organization of the nLab</a>]


      The n-Lab has been up and running for a few months now and seems to be doing fairly well. We think it's now time to put in place a more formal organisational structure.

      Whilst the n-Lab was small, and while the group involved is small, then many
      issues can be sorted out on a case-by-case basis and by whoever happens to be
      involved. As the size of the Lab increases, both in amount of material and
      number of participants, the number of issues increases as does the potential
      for misunderstandings and conflicts. It would be best to have a formal system
      in place at the start which everyone recognises before they get involved.

      Also there are matters that need to be sorted out that affect the whole
      set-up: things like licences and copyrights, and how to handle original
      research. Other matters will no doubt arise later. Again, having a formal
      structure in place makes it obvious how these should be handled.

      We would like the n-Lab to be open and welcoming to new contributors. An
      informal system, such as we have now, can be a considerable barrier to new
      people joining as it is hard to find out how things work. We think that having
      a formal system will make it easier for people to join in as it is clearer how
      things work and where are good places to start getting involved.

      Without a formal structure there is the danger that some things which are
      "anyone's responsibility" will become in practice "no-one's responsibility".
      For example, the n-Lab has several goals, one of which is to encourage active
      research. Initially, and understandably, the focus has been more on
      exposition. We should be looking for ways to encourage more research but this
      could so easily get forgotten.

      So we would like to set up some sort of group with responsibility for making
      decisions. We are not sure exactly how that would work, nor who would be on it,
      so we are looking for suggestions.

      Let us make two things clear to finish with. We are not trying to create more
      administration. The things that we have in mind happen anyway, or need to
      happen anyway, but should be more co-ordinated. Secondly, this is primarily
      about organisation not about editorial control (though whether or not there
      should be an editorial board may be one thing that this body should decide
      upon).

      So, thoughts? Suggestions? Volunteers? Nominations?
    • Hi people, I would like to know if there is any package that I might be missing because whenever this function is called, it is rendered as a crazy square. What should I do?

    • This is pretty trivial; I just wanted to record it somewhere.

      There is an example at discrete fibration (between edits 2 and 3) of two edits that are exactly 30 minutes apart, down to the second, with the same editor.

    • I've moved all of the redirect pages to pages of the form foo -- history and changed the redirect targets to the proper places as well. (I know that not everybody was entirely happy with that format, but they can be moved again, and more easily this time too.) Now what shall we do with these pages?

      Note that these will, from time to time, be created again. Just today, John created |cocomplete category, not only not noticing the spurious character but also forgetting that he had just created cocomplete category barely one week ago. So I moved it to |cocomplete category -- history, added the one item that John wrote now that he hadn't written before to cocomplete category, and made that the redirect target for |cocomplete category. Very well … but the point is that this sort of thing will probably happen again.

      I have carefully put all of these history pages in category: redirect if they have content somewhere in their history and in category: delete if they do not. But personally, I would not delete any of them; they are a very small proportion of all pages (less than 15% altogether when I checked last month), and the proportion will keep getting smaller. In fact, now that they're all identifiable by their names, I would simply get rid of those categories. Just leave each of these pages with a link to its target and nothing more; nobody now will come across them who isn't looking for them.

      By the way, there are a few pages with improper names (of the form foo/history) due to a bug, but Jacques fixed the last one, so I'm sure that he'll fix this one too. Then I'll fix those pages.

    • I see that Eric has started a putative bibliography on the n-lab.

      Much as I like Instiki, and the n-lab in particular, I think that references might be best served by a system specifically designed for references. I realise that I am proposing yet another extension to the n-group, which some people may not relish, but I think that such a system has major advantages. For example, the following are generally available on these systems:

      1. Easy import of references from arXiv or MathSciNet
      2. Much more flexible linking (essentially, anything that uniquely specifies a record could be used)
      3. Tagging, grouping, keywords,
      4. Importing and exporting of BibTeX files
      5. Powerful searching

      The single advantage of an internal page that I can think of is that one can use Wiki-links to link to a reference. I suspect that the Wiki-link mechanism could easily be subverted to allow Wiki-links to a certain number of external sites (so that, for example, vector space (wikipedia) redirected to the wikipedia page on vector spaces rather than the local one) so I don't see this as a major reason for sticking with an internal system.

      I've been adapting RefBase to make it mathematically-friendly so it would be easy to set this up for the n-lab. You can see my version of it here though certain features, such as the arXiv and MathSciNet features won't be visible as they are only available to account-holders (currently only me).

    • Hey! I think we have our first decision making test!

      It relates to matters of style.

      I contribute technical content to the nLab whenever I can, but most of what I can offer comes in the form of "beautification". This is helpful to me because I learn as I edit pages.

      I've been attempting to replace ascii links with symbolic links and place redirects to the ascii pages. For example \infty-categories gets redirected to infinity-category, etc.

      I've also been adding redirects for plural links. For example, categories is now redirected to category.

      Zoran recently modified Drinfel'd twist where I noticed two links that had the undesirable (to me anyway) plural links bialgebra cocycles and Hopf algebras.

      I changed these to bialgebra cocycles and Hopf algebras and added the appropriate redirects.

      Zoran was not happy with this and changed the links BACK to bialgebra cocycles and Hopf algebras.

      Should we let this slide? Should we decide on matters of style like this and enforce them?

      Based on Toby's comment on the Latest Changes page, it seems like he will continue to change "]]s" to "s]]" when he comes across them EXCEPT for modifications made by Zoran. Personally, I am not interested in checking to see who made the change and am inclined to go ahead and change "]]s" to "s]]" while adding the necessary redirects. I don't want to do this if Zoran is going to go back and change things back to "]]s".

      In the grand scheme of things, this is not very important, but I'd like to have an n-community decision made as to what to do about it since there does seem to be a conflict.

      How do we resolve this?

      My vote is that we develop a "Matters of Style" page that has some guidelines regarding issues like this.

      On it, I would probably add something stating that we should not change "s]]" to "]]s" and that "s]]" is the preferred form for plural links.

    • There's a discussion on latest changes about making an html copy of the n-lab downloadable every now and then. Jacques has disabled the official export html facility for reasons of severe server overload.

      I'll need to experiment, but I think that what Zoran wants could be achieved with a simple wget command which would also have the advantage of making sure that all the links are correct (and wouldn't require any changes to Instiki). I presume that, as Zoran wants to be able to do stuff offline, this would be desirable. What else would be useful for this?

    • This comment is invalid XHTML+MathML+SVG; displaying source. <div> <p>I didn't realize that pages containing redirected links show up on "Wanted Pages" as a wanted page. So all the redirected links I've added are showing up as "Wanted Pages".</p> <p>Is this desirable? This pretty much makes the Wanted Pages meaningless because it is impossible to sift through which pages are truly wanted and which are redirects.</p> <p>I was going to bring this up with Jacques as a "bug", but wanted to run it by you guys first.</p> <p>I think the "Wanted Pages" should reflect truly pages that do not exist and are "Wanted" as opposed to merely pages with links that are redirected to other pages. For example, <a href="http://ncatlab.org/nlab/list">All Pages</a> currently says</p> <blockquote> (infinity,1)-categories wanted by simplicial localization </blockquote> <p>But <a href="https://ncatlab.org/nlab/show/simplicial+localization">simplicial localization</a> does not "want" <a href="https://ncatlab.org/nlab/show/%28infinity%2C1%29-categories">(infinity,1)-categories</a>. Rather, the link to <a href="https://ncatlab.org/nlab/show/%28infinity%2C1%29-categories">(infinity,1)-categories</a> on <a href="https://ncatlab.org/nlab/show/simplicial+localization">simplicial localization</a> is redirected to <a href="https://ncatlab.org/nlab/show/%28infinity%2C1%29-category">(infinity,1)-category</a>.</p> <p>In other words, <a href="https://ncatlab.org/nlab/show/simplicial+localization">simplicial localization</a> is complete and does not "want" anything.</p> <p>In my opinion, "Wanted Pages" should be a reference to pages that need attention in some form or other. Pages with redirected links do not need attention.</p> </div>

    • Jacques is great, but he has to program Instiki for everybody, not just for us. Ultimately, the decisions on how it works are taken by him, not by us[*], on the basis of general needs, not our needs. Should we learn how to hack Instiki for ourselves?

      [*] Of course, he is one of us, but he comprises a very small portion of us.

      Certainly it is possible to run a branch of Instiki for one's own work and keep it updated with bug fixes from the main branch. As I understand it, Jacques himself did just this to add iTeX, before this was incorporated into the main branch and Jacques became the main person working on the main branch. (See the introductory comments here.)

      Who is interested in and capable of doing this? I think that I am, but only if I make a large commitment of time, and I'd rather do math ….

    • I guess that things that require Instiki to go through every page are expensive in terms of server load. I have a suspicion that these will go away (or at least, become a little less apparent) when we move to a new server since then we can migrate to MySQL as well which will optimise a few things.

      In the mean time, it's worth doing a little experimenting to see if there are ways around this problem without losing too much functionality. Using 'latest changes' instead of 'recently revised' is an important one, but obviously not one that the lab elves can use.

      I wonder if using the RSS is cheaper than the recently revised page? It might be worth running a test or two to find out.

      Also, rather than basing this on "how long I think it took the page to load" we should take a look at the production log where it actually logs how long Instiki took to generate the page.

    • David raises an interesting point over on the cafe.

      I’m not completely convinced of nLab acting as both reference wiki and as a place to work out ideas.

      As I commented there, his main comment is related to our discussion on "original research". Maybe it's time to actually design a few icons for that (and other things).

      However, it is an interesting point. According to its home page, the n-lab is for both exposition and doing research. Indeed, I doubt that the two can be properly separated. However, it is possible for one to get swamped by the other - and if that happens it is most likely to be exposition swamping new research. That is, the desire to have "safe exposition" becomes such that new research is almost impossible to put up, or has to be put up in such obscure ways that no-one sees it (who does go round the private labs, by the way?). You never know, we may end up with a section of the n-lab with a "No Original Research" slogan over the door. To indicate it's pedestrian feel, we might call it, err, n-labipedia.

      I'm not raising this because I think that we need to actually do anything yet, beyond designing a few markers, but just out of curiosity as to how others see and use the n-lab. So here's a mini-questionnaire. I'll try to think of some virtual prizes for the first ten respondents. I've put some "possible answers" to start you thinking, but this isn't intended as multiple choice.

      1. What is your main reason for going to an n-lab page? Some possible answers:

        • to add substantial content
        • to clean it up
        • as a reference

      2. If looking up something categorical, what's your list of "places to look", and where is the n-lab on your priority list? Some possible answers:

        • Mac Lane (or other text)
        • Wikipedia
        • n-lab
        • dunno, guv, just hit 'search' in that box up there

      3. When adding something to the n-lab, how careful are you?

        • If I'm not sure, I put it in a query box
        • If I'm not sure, I don't write it
        • If I'm not sure, who cares? Toby will come along later and fill in the details.

      4. When reading something on the n-lab, how careful are you?

        • Don't believe anything unless I've checked it with Wikipedia
        • Urs has an honest face, I believe everything
        • Who cares? It's not as if the referee is actually going to read the article I write, is it?

    • Has anybody else had this problem?

      I started editing a large page (say latest changes) and make my edits at the top. Even though I'm not rushing or anything, by the time I go to hit Submit, the page hasn't finished loading into my edit box. Note noticing this, I save anyway. Result: a bunch of stuff gets cut off.

      Mostly I want to gripe, but also potentially to warn people to watch out for this.

    • I want to make sure that people know that there is now a shortcut to restart Instiki, particularly convenient when (as right now) it's difficult to type more than 2 or 3 characters into the server at once.

      Log in, and then type the command

      ~/x

      That's it!

      (Earlier I told some people to type ./x, but that only works if you're in the home directory when you log in, which is not necessarily the case!)

      Twice now, I've done this where I was only able to get the ~ in and the terminal froze. So I killed that terminal, logged in again, and continued with /x. It worked! Before I created the script, it could take forever (sometimes effectively literally) to type /etc/init.d/lighttpd restart and /etc/init.d/instiki restart.

      (Note that if the terminal freezes as you're entering a command, the first character after the last echoed character, that is the first character that did not get echoed back to you, did go in, so you should not type it again when you log in a second time.)

    • Leading on a bit from Eric's discussion on matters of style, here's a style question. Should we have a lab convention on fonts for categories, functors, and the like? I realise that it may not be possible to always adhere to such a convention, so more of a guideline than a strict rule.

      My point is that good notation should aid the reader. Having preferred fonts for categories, functors, and so forth can make the relationships between different pages a little easier.

      In one recent paper, I (and my coauthor) used a for elements and morphisms, A for objects, \mathcal{A} for categories, and \mathfrak{A} for functors. Of course I'm not suggesting that this be the convention, just raising the question as to whether or not there should be one, then if that is agreed upon here's my initial suggestion.

      (By the way, maths on this forum is contained in double dollars, even inline maths)

    • I may be hallucinating, but i am wondering if the formatting by which theorem-, proof- remark-environments are being displayed has changed.

      In fact, currently it seems that none of these environments is having any visible effect whatsoever.

      I may be mixed up. Also, I keep working on the nLab with somewhat outdated software equipment, so there may be effects there in general but not on my side.

      But generally: I would like that all these environments are being displayed in a clearly visible and distinguishable format. Preferably with a little bit of indenting. For theorems and props and lemmas in some italicized font. It would be good if the end of a remark environment were clearly visible. Otherwise there is little purpose in using that environment.

      And notably: it would be great if proofs were ended by some common endofproof sign. I prefer a box.

      Does anyone know how to implement these wishes? Probably using the css functionality?

    • I just wrote an addition to regular space, and I can't even tell if it got saved properly. There's no response from the Lab (just a long wait, no error message, until it times out), even though I've restarted it twice.

      Incidentally, it's been at least a week since I've been able to get more than two characters into the terminal at a time. Even to restart it with ~/x, I have to log in twice!

    • Following on from Urs' announcement, here's where to record anything regarding the migrated nlab.

    • Copied over from 'latest changes':

      I'm hesitant to weigh in on this as I'm as guilty as everyone else, but merely flagging something here is not really enough. We should all think about how to organise the material here to make it easily findable. Of course, linking from related page to related page is good, but there should also be some hierarchical organisation. For example, there should be a philosophy index page and foundations and philosophy should be on it. Perhaps, appropriately enough, we should make more use of the category features in Instiki. At the moment, we have the following categories: biography, category, delete, drafts, foundational axiom, lexicon, meta, people, place, redirect, reference, spam.

      Here's a proposal. We should use categories as a way of doing automatic indexing. When you create a page, think where in the index it should appear (which may be in more than one place). Then assign the page the parental categor(y|ies).

      As an example, Frolicher spaces are a form of generalised smooth space. So in Frolicher spaces I assign the category 'generalised smooth space'. I do this in the 'hidden' way:

      :category generalised smooth space

      It's also relevant to differential topology, but I don't assign it that category because the 'generalised smooth space' page is already assigned the category 'differential topology'.

      Then at the bottom of 'generalised smooth space' we assign it to its own category in the 'unhidden' way, thus generating a list of all things in that category (it may be that this list is not formatted in a pretty way, but we can modify that). This list is automatic so we don't have to keep going up the tree to add new stuff.

      It's important to only assign the lowermost categories, so that the pages appear in their correct places and not at every stage up the tree.

      How does this sound?

    • Before we do the full migration, I want some sort of terms/warranty/get-out-of-jail-free card. Since I'm now the person whose name is on the server, I want some sort of "It wasn't me, guv" notice. Something along the lines of:

      By posting material to this site, you agree that: 1) you own the copyright to the material that you post, 2) you absolve us [me, nlab, railsplayground] of all responsibility for the material that you post, 3) you grant us an unrevocable license to use, distribute, and modify what you post, 4) you will not post offensive or illegal material, nor the means to obtain offensive or illegal material.

      The nLab is provided as a service to the community. It is provided AS IS with no warranty, implicit or otherwise.

      I guess that Toby's at the extreme opposite position to me so I figure if we can come to some sort of agreement then we're probably going to be okay with most everyone else.

    • The nLab clearly has something in robots.txt that prevents Google from indexing past versions and past diffs, but Google still indexes the latest diff. I would find it more convenient to search the Lab if Google didn't index this either, so I propose copying the line in robots.txt that covers past versions and diffs to cover the latest diff as well.

    • It strikes me that the "database of categories" really would be better as a database. I'm minded to try implementing it as such. It would have to be technically outside the nLab, though not far outside. As a learning experience, I thought of doing it in ruby. So my questions are:

      1. Is this a good idea?
      2. If so, what features would it be useful to have? Obviously, linked to entries on the nLab, and also filters to, say, display only complete categories, and to sort by columns, and the like. Anything else?

    • Is there a way, in instiki-wiki-syntax, to link from one web to the published version of another one (so that if editing the second web is password-protected, people without the password can still make and follow links to it)?

    • This continues where I left off on the Café here.

      One possibility is to allow everything, as long as it doesn't interfere with the good parts of the Lab. If the cranks write articles only on their own topics, don't take up good article names, and don't paste inappropriate links all over the regular articles, then they're mostly harmless. In the short run, I think that this is feasible (I may be alone in that), but in the long run, it means that we're free hosting for alternative theories, which is probably not tenable.

      At the opposite end, we could require that everything (not the words, but the ideas) be published first in a peer-reviewed journal. This is essentially Wikipedia's solution. But of course it rules out many of the contributions that we have so far, particularly many of those by Urs (who has written more than anybody else, of course), but also those by others (including me). Surely we don't want this!

      So we need something in between. For example, we could allow articles on established topics by anybody, thereby encouraging other academics to write about what they know, but allow original research only by a group of official ‘lab technicians’ approved by … some process. Or we could preapprove anybody with a PhD in one of the three relevant fields, although this still includes plenty of cranks, or anybody with tenure at an accredited university (probably still a few cranks), with others required to apply for invitation (or possibly approved by their advisors if graduate students). Keep in mind that the latter would mean that Eric Forgy and I (and perhaps some other original regulars) would have had to apply for invitation! We could also use a sponsorship system like the arXiv, although then we'd still have to decide on guidelines for sponsors to use.

      Keep in mind that much of what we write on the Lab would be considered at least mildly crankish by many others. On the categories mailing list, there are those who find higher category theory a bit silly. On the fom (foundations of mathematics) list, where some of the top researchers in that field hang out, categorial foundations are regarded as silly or worse. I think that there are even a few regular contributors to the Lab that disagree with the emphasis on weak n-categoires or don't like to see discussion of what happens if you don't use the axiom of choice (or worse, excluded middle). It's easy to distinguish ourselves from AP, harder to distinguish ourselves from FS, and perhaps impossible to distinguish ourselves from JA.

      Since comparison with Wikipedia is inevitable, I also want to stress this: Much of what is on the Lab, even in articles on established topics, would be unacceptable at Wikipedia because it would violate the neutrality rule; we give undue emphasis to minority viewpoints. This shows up particularly with foundational questions, with our preference for structuralism and tolerance for constructivism, but it even shows up in core articles on n-categories, with our preference for weak structures and for (\infty,\infty) rather than (\infty,1). (There are also articles where we express outright opinions, although in principle these could be made NPOV.) Some day we may also have to decide what our opinions are, although so far it's really only a matter of deciding on conventions.

    • This is the current migration TODO list:

      1. Set the timezone correctly to UTC
      2. Adjust the following column definitions:
        • page name => varchar(100) (up from 60)
        • redirect name => varchar(100) (up from 60)
        • page data => longtext (up from text)
      3. Make string comparisons case sensitive

      There are, of course, other things to do but these are the ones that have a visible impact. If there's anything I've missed, please add a comment below.

Results 31 to 60 for nothing

Previous Next
Top of Page