Not signed in

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

• Username
• Password
• Remember me

• Sign in using OpenID
• Remember me

• Forgot your password?
• Apply for membership

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

1. • CommentRowNumber1.
   • CommentAuthorRichard Williamson
   • CommentTimeAug 22nd 2018
   • (edited Aug 22nd 2018)
   • PermaLink
   Author: Richard Williamson
   Format: MarkdownItexJust a quick message to say that I have made a fairly significant, though rather technical, change to the way that the asynchronous processing of pages which need to be re-rendered following a page edit (say because a missing link has now been filled, or because the edited page is included in it) is handled. Somewhat remarkably, I could not find an existing simple tool which does what I needed, which is to process jobs one at time in the order they arrive, in a thread-safe way, ideally persisting over deployments, and which is not a long-living process like a server or a socket or a queue in the usual sense, but is controlled by very short lived command line processes/involves only very short-lived threads on the server. I tried for some time to try to persuade Ruby to achieve this within the main nLab code, but found it impossible to do so properly, even if I sacrificed several of the requirements; I have noted in some earlier comments that there was some instability in what I did come up with. Thus I have written my own little command line API for it, which is file-based (some care is needed to avoid race conditions in such an approach, but I believe I have something which does so), and I have now changed the renderer to call it. Initial testing seems to suggest that it is working, but just let me know if you encounter any strange behaviour. When I get the chance, I will change the rendering of the actual page edited to be asynchronous as well, which will make timeout issues go away. This, however, necessitates a change in the user interface and some non-trivial work to connect things together, so it may take a little time.

   Just a quick message to say that I have made a fairly significant, though rather technical, change to the way that the asynchronous processing of pages which need to be re-rendered following a page edit (say because a missing link has now been filled, or because the edited page is included in it) is handled. Somewhat remarkably, I could not find an existing simple tool which does what I needed, which is to process jobs one at time in the order they arrive, in a thread-safe way, ideally persisting over deployments, and which is not a long-living process like a server or a socket or a queue in the usual sense, but is controlled by very short lived command line processes/involves only very short-lived threads on the server. I tried for some time to try to persuade Ruby to achieve this within the main nLab code, but found it impossible to do so properly, even if I sacrificed several of the requirements; I have noted in some earlier comments that there was some instability in what I did come up with.

   Thus I have written my own little command line API for it, which is file-based (some care is needed to avoid race conditions in such an approach, but I believe I have something which does so), and I have now changed the renderer to call it. Initial testing seems to suggest that it is working, but just let me know if you encounter any strange behaviour.

   When I get the chance, I will change the rendering of the actual page edited to be asynchronous as well, which will make timeout issues go away. This, however, necessitates a change in the user interface and some non-trivial work to connect things together, so it may take a little time.