Recent Posts

Subscribe to Recent Posts 383 posts found

posted 11 months ago
tanzer 36 posts

edited 11 months ago

Forum: Instiki – Topic: Requirements for a server-side Instiki scripting package

Functions to support Use-Case 2.

a) Export. Given an Instiki instance I, define a page set by PageSet(W,C), where W is a list of web identifiers and C is a set of categories. This consists of all pages in webs W that fall under one of the categories in C.

The export function can be given a list of page-set-specifiers (W1,C1), …, (WN,CN). Allow the wildcard specification * for any of the arguments Wi or Ci.

Allow the export to also specify whether the full history should be exported, or just the most recent versions of the pages.

Output of the export statement may be based arounda collection of SQL insert statements, which can be applied to the database for another Instiki installation I’. (To keep the levels clear, let’s defer talk about the SQL specifics to a followup thread.) But as the following functions suggest, some more meta-data may be needed.

 
posted 11 months ago
tanzer 36 posts

Forum: Instiki – Topic: Requirements for a server-side Instiki scripting package

Functions to support Use-Case 1.

TODO: just read off the functions from the Edit Webs page, and specify them as abstract commands here.

 
posted 11 months ago
tanzer 36 posts

Forum: Instiki – Topic: Requirements for a server-side Instiki scripting package

Use Case 3: Develop new and more powerful methods for manipulating the data that constitutes Instiki webs.

This is open-ended, and ideas can grow here as we go along.

 
posted 11 months ago
tanzer 36 posts

Forum: Instiki – Topic: Requirements for a server-side Instiki scripting package

The story behind use-case 2.

I maintain one Instiki installation that is competely private, password protected, and not referenced from anywhere on the internet. This is the staging area for Instiki webs that am planning to publish. For some things, I’d rather not think aloud in the open, and would prefer to release when I deem them completed.

I will maintain another Instiki installation for the published webs. It’s also a security precaution, to make sure that my staging webs won’t get compromised if the public installation gets hacked, attacked or spammed.

Now in the staging webs, I will build a full image of what the published webs will contain. To accomplish this, I will just add the line “category:publish:” to any page in a staging web that I want to get published.

So: I’ll want a scripting function that exports all of the data from one installation that is tagged with “publish”, and another one that imports the data into an existing Instiki installation.

 
posted 11 months ago
tanzer 36 posts

edited 11 months ago

Forum: Instiki – Topic: Requirements for a server-side Instiki scripting package

Use Case 2: I want to be able to write scripts to export subsets of the data on one Instiki installation, and import them into other Instiki installations.

 
posted 11 months ago
tanzer 36 posts

edited 11 months ago

Forum: Instiki – Topic: Requirements for a server-side Instiki scripting package

Sidenote: The saga behind use case 1.

The concrete thing which is motivating me here is that I am running Instiki on hosted server account, and want to manage it securely using https, but my host – RailsPlayground – which has been fantastic in every regard except for this one is having a bunch of technical problems getting https to work well. First, they don’t yet support SNI (server name identification) in Apache, so a dedicated IP, for 2 bucks per month, is required in order to get SSL to work. But worse than that is that they are claiming that the dedicated IP, along with a wildcard SSL certificate for the whole domain, will not work for the whole domain – that actually I’ll need a 2 dollar per month dedicated IP for each application running on each subdomain. On top of this, they say that for each login, they can only provide one dedicated IP!

I was also willing to use lynx and regular http to localhost, but lynx isn’t supported on this shared host. It’s rather confused and annoying. I’ve pleaded my case with them, and the admins are sympathetic, so they are going to escalate the issue internally.

In all fairness, I should say that overall I’m really happy with their service, which provides 5 shell/cPanel accounts, lots of bandwidth and ok storage. Each account gets 200G per month of bandwidth, and 6G of storage. Stuff is backed up (so they say), and custom php.ini is supported. Leaving https aside, these guys are real experts on managing Rails applications, and general system administration, and their level of responsiveness is impressive. The Azimuth wiki has been running without incident (well, just one brief incident, where the web server had to be restarted because Passenger stopped spawning processes), appears more responsive than it was on the previous VPS (at RailsPlaygrond also) that was running the Azimuth wiki, and does not manifest the “Smoke” error to do with growing cookies.

But even apart from this Saga, I rather like writing scripts to do things, so I’d be pretty happy administering Instiki this way.

 
posted 11 months ago
tanzer 36 posts

edited 11 months ago

Forum: Instiki – Topic: Requirements for a server-side Instiki scripting package

Use Case 1. I want to write scripts to perform the standard administrative operations that are made available from the Edit Web page of Instiki.

 
posted 11 months ago
tanzer 36 posts

Forum: Instiki – Topic: Requirements for a server-side Instiki scripting package

There are three general use cases that motivate this feature for me.

 
posted 11 months ago
tanzer 36 posts

edited 11 months ago

Forum: Instiki – Topic: Requirements for a server-side Instiki scripting package

I would like to develop a server-side scripting packaging for managing Instiki webs, which will be based on direct calls to the database.

If anyone knows of such a thing already, or even the rudiments of it, do tell – because I’d be glad to use something already existing that meets the bill.

In this thread, I will spell out the requirements that I have in mind. I welcome any comments or suggested modifications to these requirements. Then, in a followup thread, we can talk about how these requirements (for commands) will get translated to SQL update and query statements. Then, in another thread, we can talk about implementation approaches (at the moment I’m leaning towards using Python along with its interface to Mysql).

In any case, on with the requirements…

 
posted 11 months ago
tanzer 36 posts

Forum: Instiki – Topic: How to develop an ABC music plugin for Instiki?

Thanks for the good information.

All I’ve worked with is the script abc2ly.py, which comes with Liliypond. It parses ABC pretty well – though not perfectly. It’s fairly simple, in that it generates a Lilypond script. Then the “fat” app Lilypond does the heavy lifting, when given this script as input, it produces a PDF with beautifully typeset music notation.

So a klunky solution would be to have a Maruku ABC extension that just calls this script, then fires off a Lilypond process, and stores the pdf somewhere in the file area. It would be good to employ some sort of caching scheme for the rendered files, so that this bloated process would only be run once for each exact instance of an ABC source file on a given page. To spell out the idea here more specifically, a crude implementation could be achieved by having a directory for each instiki page, which would contain the source text for all ABC snippets on that page, along with their associated rendered PDF files. When a page is reprocessed, it would match the new ABC snippets against the stored ones, and use the rendered PDF files if there was an exact match. Of course there are nicer ways to do this, but what I just said does define the idea.

If the Maruku filter generates PDF, can that be embedded in the Instiki output in a nice way?

This solution is klunky in the sense that it shells out to some heavy processes, and requires them to be installed on the server. On the other hand, there is a coding minimalism to it – music typesetting is a huge challenge, especially to do well – in that the whole buck gets passed to Lilypond.

This could be a default approach in the absence of something nice that would be more integrated with the Wiki.

 
posted 12 months ago
distler 92 posts

Forum: Instiki – Topic: How to develop an ABC music plugin for Instiki?

There is a hierarchy of processing of inputs in Instiki

  • The chunk handler processes various bits of “Wiki Syntax.” It is extensible, by writing new handlers and including them, by name, in lib/wiki_content.rb.
  • A content engine (Markdown, by default, but Textile and RDoc are also available). New content engines can be added in lib/chunks/engines.rb.
  • Within one of the Markdown content engines, itextomml handles equations.

Maruku (our Markdown processor) has an extension mechanism. Math support is implemented as an extension. But so is the div syntax, as are fenced codeblocks and citations.

Presumably, what you want is an ABC extension for Maruku. That would be much easier to create, if there were a Rubygem implementation of ABC notation. But there doesn’t seem to be one.

Is there a good library in Python/Perl/… that might be worth porting to Ruby?

 
posted 12 months ago
tanzer 36 posts

Forum: Instiki – Topic: How to develop an ABC music plugin for Instiki?

Does Instiki have a general interface / API designed for writing plugins?

 
posted 12 months ago
tanzer 36 posts

edited 12 months ago

Forum: Instiki – Topic: How to develop an ABC music plugin for Instiki?

I’m interested in using Instiki for a wiki that includes sheet music. I like the ABC notation, which is a pure ASCII format, with a defined standard, that’s widely used.

For example, see this link for a sample of the format, the output it renders. (It’s also a really nice Balkan song, Jovano Jovanke.) The ABC converters also generally produce MIDI also, but this is of secondary interest to me.

I realize that this request is out of the context of a math-focused wiki, so potentially the only developer for this would be me. Not sure if I’m up for making the leap to Ruby / rails development, but possibly…

As a starting point, I’m interested in discussing here how one might go about implementing this as an extension / plugin to Instiki.

For reference, PmWIki implements an ABC plugin, here.

But I want to stick with – Instiki.

Still it would be interesting to see how they accomplish it.

A long time ago I wrote an ABC plugin for MediaWiki. I piggybacked on a script abc2ly which is distributed with LilyPond (GPL music typesetting program). This script takes an ABC file as input, and generates a PDF file. My extension was simple but heavy-handed – it called the script, cached up the generated PDF file, and then included it on the page. (Many years later they archived this extension, for being unsupported and a security risk.

Another source of ideas could be from the Traditional Tune Archive, which uses Semantic MediaWiki, and has an ABC plugin. That page has a link to an open source javascript component for rendering ABC notation. However, when I clicked on the link for the actual wiki, it took me to a page with some music and text on it, and then…froze completely. Which led me to wonder whether that whole rig is half-baked.

 
posted about 1 year ago
tanzer 36 posts

Forum: Instiki – Topic: Is there a server-side file-cache for internal files?

Answer to my question: there is an application caching mechanism in place.

Touching tmp/restart.txt forces it to restart.

 
posted about 1 year ago
tanzer 36 posts

Forum: Instiki – Topic: Is there a server-side file-cache for internal files?

Hi I’m using Instiki with Passenger, on a hosted account.

In config/database.yml, I had the incorrect credentials set, let’s say that I had the username coded as abc.

When I go to the Instiki home page, I get the Smoke error. Checking in log/production.log, I see the error message about the wrong credentials abc.

Then I go to fix database.yml, to change the username to xyz.

However, I get the same Smoke error, and the log file still complains about username abc.

Then I go out for a long walk, and when I come back, it fails with a message about xyz.

Do you know of any components (Passenger?) that would be caching up the contents of the database.yml file, and then expiring the cache after some time?

 
posted about 1 year ago
distler 92 posts

Forum: Instiki – Topic: Question marks in Instiki page titles?

I can’t think of a reason why question marks in the page name would be a problem. The name is CGI-escaped when forming the URI.

 
posted about 1 year ago
tanzer 36 posts

Forum: Instiki – Topic: Question marks in Instiki page titles?

I recall hearing some advice about avoiding question marks in page titles. Is this well-founded? What are the issues, and what are the workarounds.

One possibility that I could imagine are problems with the question mark in the URL string, leading to invalid http requests. Another is that certain parts of the code, e.g. search, interpret the question mark as part of a regular expression.

 
posted about 1 year ago
distler 92 posts

Forum: Heterotic Beast – Topic: Evaluating HB for Azimuth Forum

Heterotic Beast supports the following hierarchy

Sites ⊃ Forums ⊃ Topics ⊃ Posts

Different Sites have different URLs (virtual hosts, in Apache parlance), and different user-lists. For instance, the LHC Forum is another Site, running under the same Heterotic Beast instance as this one.

The thing closest to Vanilla’s “categories” is Heterotic Beast’s “Forums”. I’m not sure we need both. But we can discuss it.

 
posted about 1 year ago
tanzer 36 posts

edited about 1 year ago

Forum: Heterotic Beast – Topic: Evaluating HB for Azimuth Forum

Also, I’m not evaluating now how important these features are. Once I have a clear picture of what HB can do now, and what it potentially could do without a lot of extra effort, then I’m hoping to adjust our Vanilla-based expectations to the HB.

Regarding categories, for example, we’re very used to it, and take it for granted, but I’m not convinced that it’s a really important feature. For example, although it’s nice to think that I can filter the posts by category, I have never actually done this in practice.

The other uses of categories I mentioned are still valid, though I could probably make a case for workarounds (a separate forum called Technical) or doing without them.

Previewing is just a nice-to-have.

Moreover, we can assess later, now I’m just trying to learn how it works and throw out ideas as they come up.

Thanks

By the way, I meant to change the title of this thread from “Evaluating HB for Azimuth Forum” to “Discussion of HB for Azimuth Forum,” but when I clicked on the Edit link, it takes me right to the Login screen. However, this bug is not present in the instance of HB that we now have running.

 
posted about 1 year ago
tanzer 36 posts

Forum: Heterotic Beast – Topic: Evaluating HB for Azimuth Forum

Our current software supports a categorization scheme for posts. When you submit a post, you choose a category for it. The category shows in the summary line for the post. The categories can be used to filter the list of posts. I believe that Andrew uses this, for example, to view just the posts in the category Technical. Also, the visibility of posts can be controlled at the category level. For instance, the category Strategy can be made readable only to members.

To what extent are such mechanisms supported in HB? We could have separate forums, e.g., one for Technical, but is there a more fine-grained way to classify the posts?

 
posted about 1 year ago
tanzer 36 posts

Forum: Heterotic Beast – Topic: Evaluating HB for Azimuth Forum

Feature Request: ability to preview a post before submitting it.

 
posted about 1 year ago
tanzer 36 posts

Forum: Heterotic Beast – Topic: Evaluating HB for Azimuth Forum

Hi we are currently experimenting with HB, and considering switching over to it. I’m going to use this thread for any feedback, questions or feature requests from the group.

HB provides the essential functionality that we need, which includes Itex and Markdown. So does our current forum software, which is an installation of Vanilla that has been customized by Andrew Stacey to generate MathML and do other good things. We’re happy with the current software, but Andrew is moving on, and we are setting up a new server independently of the nLab. I won’t be able to support this modification of an old version of Vanilla. So we’re motivated to change to a supported package, and Andrew pointed us to the Heterotic Beast.

So the challenge will be to see if I can get the Azimuth group to accept the new package, which is fundamentally similar to what they have now, yet will inevitably differ in form from what they are quite comfortable with now.

I will be posting “feature requests” here that come from that perspective. Please take them with a grain of salt, and don’t do any work on our behalf that you wouldn’t want for yourself – especially because the group might not reach the consensus to make the change. In any case, these feature requests might give you something useful to think about.

 
posted about 1 year ago
tanzer 36 posts

Forum: Heterotic Beast – Topic: Bugs

That a good resolution. Thanks.

 
posted about 1 year ago
distler 92 posts

edited about 1 year ago

Forum: Heterotic Beast – Topic: Bugs

The culprit is

  before_validation :normalize_login_and_email

in app/models/user/validation.rb.

The point is that we don’t want a “David Tanzer”, a “david tanzer” and a “dAvid tanzEr”. The normalize_login_and_email downcases both the login name and email address, associated to an account, to put them in canonical form (before checking the database to see if there is already an account with that name/email).

While downcasing the email address is clearly the right thing to do, it’s not so clear that’s the “right” thing to do for the login name. I’ve fixed it so that we just make a case-insensitive check on uniqueness.

 
posted about 1 year ago
tanzer 36 posts

Forum: Heterotic Beast – Topic: Bugs

Minor: Account names get lowercased. I created an account “David Tanzer” from the signup page, but it gets recorded as “david tanzer.” I find it somewhat unsettling to see proper names in lower case. But its easy enough to workaround by updating the database.

 
posted about 1 year ago
distler 92 posts

Forum: Heterotic Beast – Topic: Can I view the source text for other people's posts?

That might be a worthwhile feature to add.

But, as an Instiki user, you are probably well-familiar with the syntax. Heterotic Beast uses Maruku as its Markdown processor and itex2MML to process equations. It even has the same WYSIWYG SVG editor that Instiki uses. So, except for a few bits of Wiki syntax ([[...]] for wikilinks, [!include ...] to include other wiki pages, etc), it should work exactly the same as what you’re used to.

 
posted about 1 year ago
tanzer 36 posts

Forum: Heterotic Beast – Topic: Can I view the source text for other people's posts?

Hi, is there a way to see a read-only view of source text of other people’s posts, just as it appears when one edits one’s own post? It’s useful for getting ideas from other people, with respect to formulas and formatting.

Thanks,

David Tanzer

Azimuth Project

 
posted over 1 year ago
raptastics 1 post

Forum: Instiki – Topic: Debian Init.d Script

Thanks for the awesome wiki!

I couldn’t get the init.d script from the site working on my Debian server. I wrote one form scratch to manage starting and killing the process. It should be fully LSB-compliant and working with update-rc.d.

https://github.com/raptastics/Instiki-Init-Script

Let me know if it does or doesn’t work for you.

 
posted over 1 year ago
distler 92 posts

Forum: Instiki – Topic: Debian installation

I love this software so much I’m starting to worry, when are you going to grow tired of maintaining it? Thank you!

My problem is lack of time, not lack of enthusiasm.

 
posted over 1 year ago
xabier 8 posts

Forum: Instiki – Topic: Debian installation

Worked as a charm for the development version.

For the current release version (0.19.6) the bundling is successful but when I tried to run instiki this is what I got:

/home/xabier/instiki-0.19.6/vendor/rails/activesupport/lib/active_support/dependencies.rb:184:in 'require': cannot load such file -- zip/zip (MissingSourceFile) from /home/xabier/instiki-0.19.6/vendor/rails/activesupport/lib/active_support/dependencies.rb:184:in 'require' from /home/xabier/instiki-0.19.6/app/controllers/file_controller.rb:3:in '<top (required)>' from /home/xabier/instiki-0.19.6/vendor/rails/activesupport/lib/active_support/dependencies.rb:184:in 'require' from /home/xabier/instiki-0.19.6/vendor/rails/activesupport/lib/active_support/dependencies.rb:184:in 'require' from /home/xabier/instiki-0.19.6/vendor/rails/activesupport/lib/active_support/dependencies.rb:291:in 'require_or_load' from /home/xabier/instiki-0.19.6/vendor/rails/activesupport/lib/active_support/dependencies.rb:250:in 'depend_on' from /home/xabier/instiki-0.19.6/vendor/rails/activesupport/lib/active_support/dependencies.rb:162:in 'require_dependency' from /home/xabier/instiki-0.19.6/vendor/rails/railties/lib/initializer.rb:414:in 'block (2 levels) in load_application_classes' from /home/xabier/instiki-0.19.6/vendor/rails/railties/lib/initializer.rb:413:in 'each' from /home/xabier/instiki-0.19.6/vendor/rails/railties/lib/initializer.rb:413:in 'block in load_application_classes' from /home/xabier/instiki-0.19.6/vendor/rails/railties/lib/initializer.rb:411:in 'each' from /home/xabier/instiki-0.19.6/vendor/rails/railties/lib/initializer.rb:411:in 'load_application_classes' from /home/xabier/instiki-0.19.6/vendor/rails/railties/lib/initializer.rb:197:in 'process' from /home/xabier/instiki-0.19.6/vendor/rails/railties/lib/initializer.rb:113:in 'run' from /home/xabier/instiki-0.19.6/config/environment.rb:14:in '<top (required)>' from /home/xabier/instiki-0.19.6/vendor/rails/activesupport/lib/active_support/dependencies.rb:182:in 'require' from /home/xabier/instiki-0.19.6/vendor/rails/activesupport/lib/active_support/dependencies.rb:182:in 'block in require' from /home/xabier/instiki-0.19.6/vendor/rails/activesupport/lib/active_support/dependencies.rb:547:in 'new_constants_in' from /home/xabier/instiki-0.19.6/vendor/rails/activesupport/lib/active_support/dependencies.rb:182:in 'require' from /home/xabier/instiki-0.19.6/script/server:92:in '<top (required)>' from ./instiki:6:in 'load' from ./instiki:6:in '<main>'

Of course I’m more than happy to run the development version. I’ve copied this chunk of code just in case you wanted to know the outcome.

I love this software so much I’m starting to worry, when are you going to grow tired of maintaining it? Thank you!