Forum: Instiki – Topic: nlab

Okay, so after a day’s trading at the nLab, here are the closing prices. This is with nothing disabled.

atom_with_content: 192 requests, 176 taking less than 10s to process, 16 taking 50s to process.

list: 6 requests, 2 taking less than 10s to process, 4 taking 5 minutes to process.

Total number of requests: 4223, breakdown of time taken to process (rounded down to nearest 10s):

  0: 4142
  1: 47
  2: 8
  3: 3
  4: 1
  5: 17
  6: 1
  7: 1
  30: 1
  31: 2
  32: 1

So those atom_with_content and list are a major part of the requests that take longer than 30s to deliver.

Forum: Instiki – Topic: Feature Requests

As far as I can tell, updating the application files on a running Rails application (in production mode) has no effect, until the application is restarted. I, honestly, haven’t thought about the bundled Gems, but I expect the answer is the same.

In any case, ruby bundle is pretty fast (of course, that’s because it’s actually superfluous) if the Gemfile hasn’t changed. I suppose you can stat the Gemfile to see whether you actually need to run ruby bundle at all.

But I don’t think that’s your issue…

Forum: Instiki – Topic: Feature Requests

Okay. So simpler just to have separate copies of the code.

I guess what I’m stumbling around with this is some way to make the update cycle a little simpler. At the moment, I update a live instiki installation from golem, and with the ruby bundle step as well, then the update can take a noticeable length of time. What would be better would be to pull the changes to an offline copy on that machine, then update the live versions from the offline copy.

I can easily do that with the bzr stuff, but how would it work with the gems? Perhaps if the live versions weren’t bzr repositories but were more simply synced with the offline version in some fashion (thinking a bit like how rsync works). Hmm, so the workflow would be:

1. Pull the latest instiki revisions to the “dead” code
2. Run ruby bundle on that
3. Copy any updated files from the “dead” version to the live versions, being sure not to clobber anything special
4. Restart instiki on the live versions

would that work, do you think?

Or is this another case of me thinking something is important which really isn’t.

Forum: Instiki – Topic: nlab

I have a script that exports the day’s revisions to a set of bzr repositories (this is to make it easier for people to keep incremental backups of their webs). I haven’t reinstalled it as a cron job yet, and again I can run it manually.

Root has its usual cron jobs (at least, it does now: in the installed image then it doesn’t run them but lets anacron do it, which is fine except that on a server, anacron isn’t running; however, cron just checks for the existence of anacron, not whether or not it is running). But that’s all.

Forum: Instiki – Topic: Feature Requests

Given that instiki can be installed as a gem …

Instiki cannot be installed as a Gem.

There’s an old (~0.10.x) version, which worked as a Gem, and which is probably still floating around (on the internets, nothing ever really disappears). But that was long before my time, and I have not even thought about packaging the current version as a Gem.

Of course, under Passenger, you can run multiple instances of a Rails application (including Instiki), under different subdirectories (or subdomains, if you have virtual hosts enabled).

(At least with Instiki, that would require separate copies of the code, as each instance would have to point to its own database (in config/database.yml). I suppose one could use soft-links astutely, so that there was really only one copy of the source code, shared by these different instances.)

Forum: Instiki – Topic: nlab

Let’s keep it “off” for the time-being; I don’t have any plans to change anything for the next week, at least.

Do you have any other scripts/cron-jobs running?

Forum: Instiki – Topic: Feature Requests

Is the following possible? I tried a couple of things, but don’t know enough to know if what I tried was all that there was. Given that instiki can be installed as a gem, can I install a system-wide version of the code and then run it as a user, with each user having their own separate instiki process, but sharing the code?

Forum: Instiki – Topic: nlab

I’ve now upgraded the nLab server and reinstalled everything. In particular, I pulled a fresh copy of instiki from the repository and made only two changes:

1. Using mysql as the database
2. Disabled the DNSBL spam check

In particular, I’m not mucking about with the logs just yet. We’ll see how this goes for now.

Now, should I enable the daily check on the instiki source code, or shall I keep that off for the time being and update manually?

Forum: Instiki – Topic: Feature Requests

Something that is a “dummy” is not necessarily “dumb”. A “dummy” simply means a fake …

I am familiar with the usage (there’s not a UK/US distinction).

I was making a lame attempt at humour, whilst making the serious point that these CSS classes are used for styling (generated content), and as structural hooks (for converting the \ref{}s into hyperlinks), hence are not “dummy” in either sense.

Forum: Heterotic Beast – Topic: Bugs

This place doesn’t seem to remember me at the moment. *sigh*

Forum: Instiki – Topic: Feature Requests

Ah, another UK/US distinction. Something that is a “dummy” is not necessarily “dumb”. A “dummy” simply means a fake (although it’s not as pejorative), a “stand in”. Had I meant to be rude, I would have said “dumb CSS classes”.

Forum: Heterotic Beast – Topic: Bugs

Hmmm. /users/nnn/posts?monitored=true doesn’t seem to return anything, here on Golem. But it works fine on my test installation.

Both are running in production mode. The test installation uses sqlite3; this one uses mysql. The (admittedly complicated) SQL join seems not to work on the latter.

Hah! Fixed, now. Boolean comparisons are not the same in SQLite3 and MySQL. Finding a syntax that works in both was … umh … fun.

Forum: Heterotic Beast – Topic: Feature Requests

Hmm. I think tagging a post as having been edited, after the grace period, should suffice.

See what you think.

Forum: Instiki – Topic: Feature Requests

…dummy CSS classes.

I bridle, only at referring to these as “dummy.” I thought that the whole mechanism I invented with those classes was very clever. And even more versatile than I had originally envisioned.

Not “dummy” at all….

Forum: Heterotic Beast – Topic: Feature Requests

I was just thinking that if only the post itself was tagged with the edit then it wouldn’t be clear to someone reading the end of the thread that something earlier had been changed. Having it sorted by “updated_at” would fix this, but at too great a cost, I think. The extra line was meant to mitigate this without resorting the posts.

You’re right that the guest user doesn’t have an empty password. The script has to know guest’s password.

Forum: Instiki – Topic: Feature Requests

Yes, it worked!

And to finish the thought, since I’m generating this from a LaTeX source, it can automatically handle adding the dummy CSS classes.

Forum: Instiki – Topic: Feature Requests

Actually, I’m going the other way. I’m going from LaTeX to Instiki. So the source file has \label{foo} and \ref{foo} in it already and in the LaTeX output then it gets converted to “In (2) we saw that …”. So there’s nothing in the source to put as the text in the anchor and something has to be put in its place. Thus my thinking was to subvert the maruku counter-counting to figure out what text should go there. Putting a class .num_enuma on each element of the list makes maruku think that there is a list to be counted there and so it converts the \ref{foo} to the correct hyperlinked text. If you’re using maruku here, this should work:

1. The first item.

2. The second item.

Now we should be able to refer to 1 and 2. I won’t know if that worked until I save the reply, though!

Anyway, it certainly does work on Instiki. I don’t need another list in the CSS because the counters are already produced by the browser working on the list. All I need is for maruku to count the entries in the list, and for that I just need the dummy num_X classes. You’re right that I need one per list, but that shouldn’t be that many on any given page.

(Okay, time to see if that list worked.)

Forum: Instiki – Topic: Feature Requests

I’m not sure I understand. If an element has an explicit id, because you gave it a {: #foo} IAL, then you can refer to it a [fubar](#foo). \ref{...} is used for linking to things with generated numbers (like theorems, ‘n such).

I think your motivation is to have something that converts to LaTeX. \ref{foo} converts just fine. There are two issues, if I understand correctly.

1. The IAL on the list-item doesn’t get converted to a \label{foo} on the \item in the LaTeX output.
2. For the XHTML output to behave as you would like, you need to invoke Maruku’s internal counter, so that \ref{foo} is converted to a hyperlink, with anchor-text being the number of the list-item.

The latter is a bit awkward, as there can be several ordered-lists on a page. We’d need a separate counter for each one, no?

Forum: Heterotic Beast – Topic: Feature Requests

With the anonymous posting, then I can specify it on a “per category” basis in Vanilla. The hierarchy in Vanilla is:

Forum: Category: [Subcategory:...] Discussion: Post

I think this maps onto

Site: Forum: Topic: Post

with the proviso that (at least as currently implemented) “Sites” need to live on separate subdomains.

So you’re talking about allowing anonymous postings on a per-forum basis?

To avoid spam, the person has to solve a reCaptcha to post.

There’s some captcha mechanism built-in (but disabled) in Beast. Will have to explore …

Behind the scenes, there is a “guest” user and the software logs in the guest user, posts the post, and then logs out again. All such posts get authored by “Guest” and (this is less than ideal) …

I suppose just creating a “Guest” user, with a blank password, would not suffice, as “Guest” could then post to any forum.

Regarding “editable” posts, I’d go for “created_at”. A discussion is a linear thing, and most of the time edits will be for minor typos which certainly shouldn’t change the order. Deciding on the difference between minor and major is a human thing.

If you wanted the best of both worlds, an edit to a post could insert a line at the relevant time point saying “Post X was edited at …”. That wouldn’t disrupt the flow of the conversation but would signal that someone had potentially thrown a stone in to the water.

Or simply tag the post, itself, as having been “Edited at …”

Maybe best of all would be a 5-minute grace period: if updated_at time - created_at time > 5 minutes, then include such a tag.

… Like on this post.

Forum: Instiki – Topic: Bugs

Ah, that’s unfortunate. What other markdown engines are available for Ruby?

There are several.

1. There’s rdiscount, based on discount.
2. There’s BlueCloth, which was the “original” Markdown interpreter for Ruby, which sucked bigtime. But Bluecloth 2.x has been rewritten to use discount.
3. There’s rpeg-markdown, based on peg-markdown.

The latter is probably the most promising. One “just” needs to write a PEG grammar for Maruku’s extended Markdown syntax, and then drop it in as a replacement.

“Just” …

Forum: Instiki – Topic: Feature Requests

Just tested adding IALs to lists. Definitely useful, but I’d add one minor modification: the ability to use \ref to refer back to list elements (at the very least, to enumerated list elements). So

1. {: #first} The first item

The first item was \ref{first}

would work. At the moment, I have a hack that uses the numbering system for theorems and so forth to get this to work, putting the class .num_enumX (X increments with the enumerate environment so that each is unique) on a +-- ... =-- div at the top of the list element. This seems to be enough to trigger the internal maruku counter and so make \ref{...} work. It’d be great if this were done automatically without that hack.

Forum: Heterotic Beast – Topic: Feature Requests

With the anonymous posting, then I can specify it on a “per category” basis in Vanilla. The hierarchy in Vanilla is:

Forum: Category: [Subcategory:...] Discussion: Post

Subcategories aren’t really hierarchical in the code, just in the layout. So “per category” doesn’t descend to categories (unless I’m misremembering … I did code this part so I ought to know!). On the nForum, then the allowed category is “nLab - Latest Changes”. To avoid spam, the person has to solve a reCaptcha to post. Behind the scenes, there is a “guest” user and the software logs in the guest user, posts the post, and then logs out again. All such posts get authored by “Guest” and (this is less than ideal) there’s no obvious “Put your name here” field (one has to put it in the post itself). Nonetheless, it works reasonably well and means that people can leave short messages about nLab pages without having to sign up.

Regarding the roles, I’d want something in between moderator and user. On the nForum, then some users have slightly more “power” with regard to organising the place. They don’t have full moderator power, so can’t edit others’ posts and so forth, but they can move posts from one category to another, or similar simple things.

Regarding “editable” posts, I’d go for “created_at”. A discussion is a linear thing, and most of the time edits will be for minor typos which certainly shouldn’t change the order. Deciding on the difference between minor and major is a human thing.

If you wanted the best of both worlds, an edit to a post could insert a line at the relevant time point saying “Post X was edited at …”. That wouldn’t disrupt the flow of the conversation but would signal that someone had potentially thrown a stone in to the water.

Forum: Instiki – Topic: Bugs

Incidentally, I got around my immediate indentation problem, so you can consider that one downgraded!

Forum: Instiki – Topic: Bugs

Ah, that’s unfortunate. What other markdown engines are available for Ruby?

If you’re actively looking, I could run some searches on the nLab pages to see what syntax is used and what isn’t.

I do think that the attribute stuff is a brilliant addition; it makes it possible to make the pages a little more easily customised.

Forum: Instiki – Topic: Feature Requests

Ah, number 2 is fantastic. I hadn’t spotted that (I’ve been particularly bad at monitoring the RSS feeds since my feed reader blew up). I’ll try that.

Forum: Heterotic Beast – Topic: Feature Requests

Andrew Stacey wants:

• The ability to selectively allow anonymous posts (ie, posts by unregistered users). It’s not clear whether he wants that on a per-forum basis, or on a per-topic basis. It’s also not clear who gets to decide (moderator or admin).
• Themes. I think themes_for_rails looks promising.
• More fine-grained access-controls. Apparently, admin/moderator/user(/anon) is insufficiently fine-grained.

Other thing that bear looking at:

• The Signup process.
• Since posts are editable, should they be ordered by updated_at instead of by created_at dates?

Forum: Heterotic Beast – Topic: Bugs

Let’s discuss bugs in Heterotic Beast.

Forum: Instiki – Topic: Bugs

Both this request (for “fenced” quotations and lists) and this one, in the other thread, are for extensions to the Markdown syntax in Maruku.

Frankly, I’m very reluctant to spend any time working on Maruku.

The author (who is no longer actively developing the software) insists on a GPL license, which conflicts with the licenses for both Instiki (Ruby) and Heterotic Beast (MIT). Unless he changes his mind (which seems unlikely, as I’ve asked several times), I would prefer to ditch Maruku, in favour of another Markdown engine.

Consequently, I’d rather spend my time extending that engine (whatever it turns out to be). Of course, for the present, I am still going to fix bugs in Maruku.

Update:

Well, OK, I didn’t exactly keep that promise…

Forum: Instiki – Topic: Feature Requests

Hmmm.

1. I agree that *this*{: style="font-style: normal; color: red;"} is a little silly.
2. I thought you could already do that (see here). (It seems that you need a space between the ”2.” and the IAL, despite what I said there. I think this is a result of this commit.)
3. I’m not sure I understand your Javascript suggestion. Could you point to some software that implements something similar?

Forum: Instiki – Topic: Feature Requests

Here’s another random idea: to make it easier for people to contribute to a wiki (thinking particularly of the nLab), howabout a javascript annotation system? Some people might find it a bit daunting to edit a whole page just to correct a minor spelling mistake, but could leave a quick note so that the next person who does edit the page can see what outstanding notes there are.

Just a random idea - I haven’t thought it through very much. (But I did a little search to see that it was, at least, technically possible via javascript.)