There ain't no commenting thing. Mail me at kake@earth.li. I like
getting mail.
There ain't no commenting thing. Mail me at kake@earth.li. I like
getting mail.
View current version link broken on http://openguides.org/london/index.cgi?id=Gaucho_Grill&version=1
Look at Pod::Simple::Wiki
CGI::Wiki::Plugin::Locator::UK - make sure it doesn't die if there are non-numeric co-ords in the database, if I can - or don't let non-numeric co-ords be stored, or something.
OpenGuides - preview doesn't work when you only have metadata and no content?
Check out why CGI::Wiki::Formatter::UseMod can do second-level nested lists but not third-level.
Look at Richard's makereadme thing (parsing yaml file to auto-generate list of prereqs).
Get the OpenGuides running under -T - suspect I'll need to patch Search::InvertedIndex.
Page renaming for CGI::Wiki. Also document somewhere why I gave up on changing it to use private page IDs.
I stopped updating this, bad me. I'm no good at timesheets either.
Mostly been working on stuff for the London.crafts wiki - a few enhancements to CGI::Wiki::Kwiki (which really needs a more appropriate name), but mostly planning out what I want to do with the yarn/pattern database. I want people to be able to use it to catalogue their stashes, to find suitable substitutions for patterns that use yarns they can't get hold of, to find suitable patterns for yarns that they have and want to use. The classes are mostly written, thanks to Class::DBI, but I'm putting off writing the glue.
I'm finding this pretty satisfying to work on, since it's something I have a real need for, its components are useful already even though the big picture is nowhere near completion, and I don't think anyone's likely to pop up and reinvent it.
Cut the OpenGuides stuff short because I'd promised crazyinsomniac
that I'd get back to them about the weird CGI::Wiki test failures
they've been getting. The problem seems to be that ->retrieve_node
sometimes works and sometimes doesn't. I've not seen these failures
from anyone else, and the complication is that crazyinsomniac is
running Windows - a platform I don't have available to me.
Still working on this. Very little progress. Bah.
Released CGI::Wiki::Kwiki 0.41 - just a few tweaks to the tests to avoid test failures on systems without CGI::Wiki::Formatter::Multiple installed.
Started making notes for perl.com article on OpenGuides. While I was writing the section on authentication I realised that we really should be storing IP addresses like all other wikis in the whole world ever. So made a start on that.
Day off to visit friends.
Released CGI::Wiki::Kwiki 0.4 - now with multiple formatter support.
Released CGI::Wiki 0.49 - now you can make your metadata search be case-insensitive. It really does make much more sense like this.
Released OpenGuides 0.25 - the simple search box will now look for your terms in the categories and locales of the nodes as well as in the titles and bodies - so for example a search on "holborn & pubs" will Do The Right Thing. Finally this search box is mostly working as I expect it to - Principle of Least Surprise.
I need a beer now.
Multiple formatter support for CGI::Wiki::Kwiki is mostly done now. This afternoon I need to:
* Check that my tests properly cover the case where only one formatter is specified
* Test that case in real life - ie get the London.crafts wiki running on this version
* Add facility to decide which formatter will be the default in the edit dropdown
* Make it clear in the docs that the method of specifying a formatter has changed
* Commit it and release it
That should be done by mid-afternoon with any luck, and then I'll do some work on OpenGuides.
Released CGI::Wiki::Formatter::UseMod 0.09 - a fix for its habit of sprinkling <br /> all over the place and thus surrounding tables with huge amounts of whitespace.
Got CGI::Wiki::Kwiki into a new CVS repository set up by Tom on his new box.
Released a minor fix to CGI::Wiki::Kwiki - the removal of a bogus
use CGI qw( :standard ); from CGI::Wiki 0.48 had revealed a
small bug.
Released CGI::Wiki::Formatter::Multiple 0.01 - it only supports ->format so far but it's a nice start.
Hacked about on CGI::Wiki::Kwiki for a couple of hours - nothing committed or released yet, but I'm well on the way to having easy-to-use multiple formatter support. This has been the end goal of most of today's programming, since I want to set up a wiki for the CGI::Wiki rewrite, and I'd like to be able to treat documentation, test, code and discussion nodes differently.
Warning: this blog may be tedious for the next few weeks. I want to document all the programming tasks that I've been doing, so I can prove to myself that I'm not just being an unemployed slacker, but am working just as hard as when I was being paid, except on my own stuff.
I'm not going to work every day though, since that would involve staying in the house far too much for sanity.
(Yes I have finally given up and admitted that people other than me read this, hence the warning.)
Released CGI::Wiki::Kwiki 0.31 - tidied up the tests as per previous blog entry because the difficulty of testing the previous version was holding me back on further development.
Released CGI::Wiki 0.48, just a few small changes to allow the formatters access to the node metadata - I need this to allow multiple formatters per wiki.
Cast on for CGI::Wiki::Formatter::Multiple - ie, wrote the
documentation, Build.PL and a simple use_ok test. I could write
a big screed here about similarities I've noticed between knitting and
programming, but I won't.
I left my job yesterday, before the end of the trial period but it was already clear that it wasn't working out.
In roughly the 24 hours since then, I've designed and implemented an alpha release of an application that lets the members of my craft group add details of yarns they've used and what gauge they got with them, and search for appropriate yarns for a given gauge (many patterns will specify not only the brand of yarn they recommend, which often we can't get locally or in the right colour, but also a gauge measurement to let you find a suitable yarn to substitute). It has a nice big test suite that I wrote as I went along. Oh, and I really enjoyed writing it, too.
Spent a few hours over the weekend playing about with Games::Set in an attempt to make it generate puzzles like the Set Daily Puzzle. I wrote some extra methods but haven't sent Richard patches since I've failed to make practical use of them yet due to having forgotten far too much maths. I did think at one point that I could attack it with group theory, but eventually realised that a group is not a group without an identity. Duh.
Now I know that Set's been around for long enough that other people are already going to have thrown maths at it, but I want to have a play on my own and see how far I can get.
Let the number of:
characteristics per card be c cards per set be n different values each characteristic can take be v
So for a standard Set deck we have c = 4, n = 3, v = 3
The size of the deck will then be v**c (v to the power of c), since
the value of each characteristic is independent of the values of the others
- we have v choices for the first characteristic, v choices for
the second characteristic, etc, all the way to v choices for the
cth characteristic.
Here are some definitions I felt the need to invent and/or formalise. The terminology is complicated by the fact that the word "set" has been taken to describe something specific. So I'm going to use "collection" instead. A collection has no internal structure; the structured entities are going to be called decks and subdecks.
A card is a set of c characteristics, each of which can take one
of v values.
A collection of cards is one or more cards.
A subcollection F of a collection E is a collection of cards such
that every member of F is also a member of E.
The deck D is a collection of cards such that every possible value
of every possible characteristic is held by at least one card in D.
A Set is a collection of cards such that for each characteristic, either each card has the same value, or each card has a different value.
A completion of a collection E of size c - 1 is any card
which when added to E forms a Set.
A collection E is complete if for each subcollection F of
E of size c - 1, every completion of F is also a member of
E.
A subdeck is a complete subset of a deck.
A subdeck is proper if its size is smaller than the size of the deck.
So far I've just been playing with definitions and proving simple propositions, for example:
Sets cannot exist unless v >= n.
For the case n = 2, every collection of size n is a Set, so
completions are not unique, and there are no proper subdecks.
This is fun.
I made a CGI::Wiki dev list.
I'd like to be able to make wikis where the author of a node can choose what wiki (or other) syntax to write in - using, for example, a drop-down box on the edit screen.
This will allow you to do things like have documentation pages written in POD, test suite pages written in plain text and rendered using a simple formatter class that just puts <pre> around everything, and discussion pages written in your favourite Wiki syntax.
Now this could be done in the calling code - just call $relevant_formatter->format( ... ) rather than $wiki->format(
... ). But I'm wondering whether it should be explicitly supported
by CGI::Wiki, and if so, should this be done by changing the CGI::Wiki
API or by creating CGI::Wiki::Formatter::Multiple to handle it all.
The main tasks that a solution needs to accomplish are:
- when saving a node, store some metadata to indicate the required formatter
- when displaying a node, retrieve that metadata and use it to choose the appropriate formatter
Changing the CGI::Wiki API would mean that CGI::Wiki was mandating the behaviour of a particular metadata field, something it hasn't done up to now and I'm not sure it should do.
Handling it via CGI::Wiki::Formatter::Multiple would mean that the application code would be responsible for storing and retrieving the formatter-type metadata. The wins in this case over just handling all the multipleness in code would be:
- can just call $wiki->format instead of selecting the right
formatter class, instantiating and calling that
- things like allowed_tags only need to be supplied once, to CGI::Wiki::Formatter::Multiple->new, rather than to each individual
formatter. (On the other hand, you might want to allow different
tags for the different types of pages.)
I'm also considering a grand renaming of CGI::Wiki, maybe to Wiki::Toolkit. We're discussing a major API change and a name change would help avoid the backwards compatibility demon.
foo
HTML generated from pod with podblog