Posted
27 days
ago
You can grab the 0.7.5 release from the download page.
Fix some reader inconsistencies with reader keys moving selections
Wrap some harmless, rare curses exceptions
Workaround messed up SIGCHLD handling in multiprocessing
Doc
... [More]
updates
This fixes the problems arising with the move to Karmic Koala for Ubuntu. I'm
not sure what in particular caused it to break between Jaunty and now, whether
it was the addition of 2.6.4 or just some obscure timing thing that happens to
be prevalent or not.
There were a number of features queued up in the git tree, but I wasn't really
planning on releasing this quick until the Karmic bugs started to crop up
yesterday, so I tucked them into a branch and will re-merge them later.
As a side note, I'm not a fan of Ubuntu for this very reason. This bug isn't
their fault (or mine, AFAICT thanks to the multiprocessing module - a module
built around spawning new processes - being intolerant of custom SIGCHLD
handlers), but because Ubuntu is now frozen for karmic, I won't be able to get
0.7.5 into the main repo until the next release... despite the fact that I only
start to get bugs after the release is actually made. It would make more
sense, to me at least, if they froze stuff that was part of their core
distribution (GNOME, firefox, kernel etc.) but continued to track Debian testing
for their unsupported 'universe' packages (which is where canto falls).
Anyway, have fun! Submit bugs! [Less]
Posted
3 months
ago
In the tradition of the last few weeks of avoiding source commits that actually
mean anything =P, I've started to mirror the canto source at
GitHub. This is mainly because I attempted
to do the same thing with Google Code, but git->svn
... [More]
is a pain in the ass and the
only reason I chose GC in the first place (well, aside from the fact that NRSS
was Google Code and GitHub didn't even exist at the time) was that it had an
issue tracker. Now that GitHub has that as well, I've been looking for the time
to move it in there.
Obviously, I will continue to host my own git / site / etc. so nothing on the
user end should change unless you're looking to fork the project or a submit a
bug directly into the tracker.
The handful of open bugs in the Google Code tracker have been moved over by
hand. All but one of them are merely wishlist.
As time permits, I might try to convert the site markdown to display correctly
on GitHub as you browse, but since this site uses some extra extensions to
python-markdown 2.0, I doubt it will work with a single source.
Have fun! Submit bugs (to the new tracker)! [Less]
Posted
3 months
ago
Wow, so three weeks since I've touched git and the world of Canto hasn't
imploded. Hooray. Last month shattered some records with respect to site traffic
/ downloads / bandwidth / popcon installs and votes / AUR votes (basically
across
... [More]
the board), but bug reports are still sparing. In fact yesterday was the
first actual bug that required a commit to fix.
You can see a write up w/ workaround (for those that use the n/p keybinds in the
reader and don't want to wait for release)
here.
Bug in long-running instances
One report notes
that for Canto instances that have been running for a long while (a couple of
days, in a screen session), the client stops updated and starts dominating the
CPU.
I've managed to track this down to a call to the multiprocessing module that
decides to choke to death deep in the C code because the length of something
it's attempting to write is > INT_MAX which seems... highly unlikely... I
don't think the cPickle output of a feed is going to reach into the gigabytes of
size....
Regardless, I'm still attempting to fix it, even if it turns out that I have to
submit patches to Python itself.
Debian Maintainership
Some bad news. The long-time Canto maintainer, Daniel
Baumann had to drop the package as one of his
main packages, along with a number of others (like ncurses itself). Currently,
Canto's maintainer is listed as Debian Q-A. If anyone would like to take over,
the position is open =).
Thanks to Daniel for being such a great maintainer.
Have fun! Submit bugs! [Less]
Posted
3 months
ago
Just some quick notes. First of all, thanks to mruwek for getting a new 0.7.4
ebuild into the Gentoo sunrise overlay. I don't know if he's going to follow it,
but he put in the initial effort and has the ability to. Regardless, thanks
... [More]
for
being so prompt and helping me out (it's been awaiting moderation for a couple
of days, but it's now in the overlay proper).
Also good news is that 0.7.2 was synced into Ubuntu Karmic and while I would've
been happier with 0.7.4 (the Debian package hasn't even updated though, so I
understand), the important point is that 0.7.2 is 100% compatible with 0.7.4 so
that after Karmic becomes the default install, Ubuntu users won't have to be
constantly shepherded through an upgrade process. The reason I bring it up is
that Jaunty is still running 0.5.7 which is not only configuration incompatible,
but also disk incompatible with >0.6.x and it sucks, but at the same time I
won't continue to support legacy changes (yes, my friends, there is a reason
that the first number in the version is a zero) because one distro is frozen a
year in the past.
Lastly, I'd like to encourage anybody with suggestions for future ideas to
submit a bug (or use any other form of contact) to go ahead and
suggest it. I consider Canto to be fairly featureful, but ideas for improvements
are always welcome.
Have fun! Submit bugs! [Less]
Posted
3 months
ago
You can grab the 0.7.3 release from the download page.
Fix various update issues on long-running clients
Fix sluggish reader link toggling
Fix worker signals (and ^C as a side-effect)
Fix reader n/p keys not setting items
... [More]
read
Fix double quotes in programmatically added main tags
Fix shadows on horrendously broken feeds
Fix all-filtered stub
Refix hard-filters (??)
Minor cleanups
Documentation clarifications
This release kills a number of bugs. The major bug killed is the failure to
continue to update after running for quite awhile (usually only noticeable when
running in screen for hours on end, although it could've cropped up earlier
than that). Hard filters had to be tweaked again, I'm not sure why but the
conditional wrapped in a lambda ceased to work so it was eliminated... I'm
disappointed that I didn't catch this before, but it could be a 2.6 quirk (or I
just didn't test hard enough).
The rest are pretty minor. Clearing up some poor behavior, usually only
triggered on a few feeds (particularly the shadows).
A note to Gentoo users
The ebuild in the sunrise overlay
is old (0.6.7), but should still be valid with a rename (and -9999 works), although it requires
Python 2.6 or a slot dependency on 2.5 w/dev-python/processing (not an issue since most of you should have 2.6). Anyone willing to
step up and maintain the overlay ebuild, feel free. The bug for inclusion is
here if you want to chime in,
or if you're a maintainer looking for an easy package to put into Portage.
As it is, I'm trying to avoid packaging stuff myself, I haven't done that since
Debian picked up the package and I stopped building .debs.
Anyway, have fun! Submit bugs! [Less]
Posted
3 months
ago
You can grab the 0.7.4 release from the download page.
Correct some overlooked 0.7.3 stuff =P
And that about sums it up.
Posted
4 months
ago
You can grab the 0.7.2 release from the download page.
Fix some precache troubles with aggregate filters / reverse
Restore feed-order without sort
Startup cleanups
More tweaks to the 0.7.x code. The big thing is fixing the
... [More]
crashes with
precache on reverse_sort and the aggregating filters (any_of, all_of).
Other minor improvements include the maintaining of feed order when no sort is
defined (which was the promised behavior in 0.6.x), and a minor startup cleanup
that should mean that Canto reaches its idle state faster on startup.
Have fun, submit more bugs! [Less]
Posted
4 months
ago
You can grab the 0.7.1 release from the download page.
Fix hard (feed) filters
Fix keyword escaping for non-regex searches
Fix items with totally undefined titles
Fix fetchlog header from arg refactor
Ignore some exceptions
... [More]
cause by multiprocessing
Minor doc tweaks
Just some little fixes.
Processing Exceptions
Some folks have been getting strange errors in the multiprocessing module trying
to use Canto. For example:
OSError: [Errno 13] Permission denied
or
OSError: [Errno 38] Function not implemented
I have diagnosed this as failure to have /dev/shm mounted or writable. I've
added more information to the
section on upgrading. [Less]
Posted
4 months
ago
You can grab the 0.7.0 release from the download page.
Convert to multiprocessing worker slave (huge performance)
Vast memory improvement (esp. for large lists)
Large scale refactor of lots of code
Better code
... [More]
documentation
Better site documentation
Partially validating configuration code
Partial test framework (to be added to as bugs arise)
Added configurable update triggers
Added never_discard() to keep certain items indefinitely.
Added SIGUSR2 signal to output debug backtrace.
Added state_change_hook
Added canto-inspect, a simple wrapper for examining feed internals
Added no-content stub for unfetchable feeds to avoid trying to update broken
URLS repeatedly.
Added add_info extra function for adding content to the reader
new_hook now enforced by canto-fetch
Ignore keep settings lower than the number of items in a feed
tags variably now implicitly set to sane default
"reader" keybind now doesn't set item read (coupled with "just_read" for
default)
Filters and Sorts now all subclass Filter and Sort class
Accept conf.py as well as conf for config name.
Fix double enforcement of rates (client more responsive to fetch updates)
Fix blank titles
Fix runhere.sh killing c-f
Performance
Whew. 5 months of work secreted away in the experimental branch has finally
come to fruition. The upside of the new code is that performance has been
increased significantly. Not only is it employing a brand-spanking-new process
based multi-threading model (sounds pretty impressive, eh?), it's also been
changed to partially update the display where 0.6.x did all of the processing
before display so it feels a lot quicker even on slow machines. These
changes are particularly effective in making the interface more responsive when
filtering and updating large lists.
Memory
The individual memory usage of Canto has been lowered significantly.
Unfortunately, because the performance gains were achieved through black mag-...
multi-processing, the overhead of running two full blown Python interpreters
chokes out any improvement. The end baseline is a little higher, but it should
scale much better for large lists.
Documentation
The old documentation has been stripped to the core and rewritten to be much
more comprehensive. I feel like one of the primary problems with Canto 0.6.x was
that a lot of great functionality was too hidden. This has hopefully been
rectified.
Compatibility
There may be compatibility issues if your current (0.6.x) config uses advanced
features. This is why the first number in Canto's version is zero =). I've
written a short section on
upgrading from 0.6.x. It may be incomplete, but
will be expanded as issues arise. The fortunate part is that the disk format
hasn't changed from 0.6.x so your current feed information shouldn't be lost
even if you have trouble with the new configuration.
As I mention in that section, if you have trouble feel free to
contact me or any of the kind volunteers in the IRC channel or the
mailing list. I would be glad to help you port your config.
Downsides
The only downside with upgrading to the new Canto is that, as of today, I only
know three people that are currently running it (including myself). I've fixed
all of the bugs that we have detected and I am satisfied enough to put it out.
However, there are going to be bugs and there are going to be quirks that
need improvement. There are dark corners that three people aren't going to
stumble upon in daily usage.
So. IF YOU FIND A BUG. REPORT IT. If something behaves
unexpectedly, let me know. I anticipate putting out a bugfix release that can
correct these quickly, but I can't fix what I don't know about.
A Final Word
I'd like to thank everyone in the #canto IRC channel for hanging out. In
particular, matiasag and evaryont for being my guinea pigs and helping me
iron out a bunch of bugs.
Have fun! [Less]
Posted
6 months
ago
First, the bad news. I didn't make as much progress over the weekend as I'd
hoped. In fact, I really achieved only one thing from that whole post and it was
a side-effect of some other developments.
I threaded the Canto interface
... [More]
not because I really wanted to take advantage of
multiple cores or get a speedup in the actually task of filtering and sorting
item. I threaded it to get the interface to be more responsive. To an extent, it
worked. The interface became more responsive, but only because in implementing
the thread model, I had to implement partial updates. It effectively removed the
problem with long lists by allowing you to use the interface when only part of
the total work was done.
I never really cared to ponder why, as a whole, performance didn't really work
out until I read David Beazley's slides on the
GIL (PDF). It really clicked with me why
I was still running into trouble, even with the threads.
Now, the good news. I converted the entirety of the threading model to use
processes, which avoids the GIL all together by communicating through
traditional pipes. No GIL locking required. Worst case scenario is a moderate
speed up (because the locking overhead is completely gone). Best case scenario
is a hefty speed up brought on by today's multi-core processors. I've noticed a
big difference on my Core2 even when one core is being dominated by another
process.
There are still some issues in the implementation (interested parties can glance
at the git log.
But as a whole, the process based code is not that much different than the
thread based code was. Everything is still protocolized but the protocol has to
be entirely comprised of pickle-able objects.
I don't anticipate too many problems directly related to the new process based
code, but it's possible. Also, you're going to take a hit in memory usage
because the same set of objects has to be synced between the two processes, but
the dumb process doesn't keep too much state by default so it's been minimized.
I also don't think it's enough to outweigh the memory gains made by keeping more
content on disk so overally the memory performance is worse than when threading,
but should still be better than 0.6.x.
New dependency for 2.5
To ease the use of processes, Python 2.5 users will have to install
python-processing. Fortunately, this module has been integrated into the Python
standard library in 2.6+ as the "multiprocessing" module.
Testing
As always, the code is in the experimental branch. If you 'git' it, feel free to
report on the mailing lists or #canto on irc.freenode.net.
Have fun, submit bugs! [Less]
