I don’t really want to give up PDF::Writer or its ancillary libraries, but I owe it to the community to find a maintainer who will be more responsive and put more effort into it than I have. There are some issues to sort out regarding the pieces of the projects, and some changes that I would like to see someone implement. There are basically three projects:

1. Transaction::Simple. This has improved significantly since the last release, but I have not yet implemented the Ruby 1.9 Marshal.load block trick that Matz implemented for me after a minimal case for a #become-like behaviour was shown.
2. color-tools: This involves someone else, because after some preliminary discussion last year, I moved the color-tools codebase to the Color project on RubyForge and restructured things to be a bit smarter. There’s also some work that should happen hear regarding colour profiles, but that’s manageable. I basically want to work with the current owner of the Color project to hand this entire project off to someone who is interested in the math behind colours, and has the expertise to do something with it.
3. PDF::Writer. The big one. I need someone to take care of this. No, the community needs someone to take care of this. I’m more than willing to share some thoughts about the code, but it’s a bit of a mess, and there are better ways to do what I did. The code can’t support the ultimate goal of reading.

None of this means that I’m giving up on Ruby, or on PDF generation; if I find time, you may yet find a different set of PDF tools from me in the future. But PDF::Writer is here and it needs someone to help maintain it.

Could that be you? Comments open on this post for interested parties to let me know. Be warned: I’m not just handing off PDF::Writer. I’m going to be looking at code samples; wanting patches. I need to know that you’re going to give the care the PDF::Writer needs and deserves before I hand off the virtual keys to the project.

The matz Roundtable was pretty short; not too many questions were asked this year, and the discussion didn’t continue for an hour as it did the year before. I was shot down when asking for “become” behaviour (related to the Transaction::Simple bug). After the Roundtable, I managed to snag matz to talk about the problem which led me to request this. I showed him the test case:

#!/usr/local/bin/ruby
require 'rubygems'
require 'transaction/simple'

class Child
  attr_accessor :parent
end

class Parent
  include Transaction::Simple

  attr_reader :children
  def initialize
    @children = []
  end

  def < <(child)
    child.parent = self
    @children << child
  end
end

parent = Parent.new
puts "parent.object_id: #{parent.object_id}"
parent << Child.new
puts "parent.children[0].parent.object_id: #{parent.children[0].parent.object_id}"
puts "starting transaction"
parent.start_transaction
parent << Child.new
puts "parent.children[1].parent.object_id: #{parent.children[1].parent.object_id}"
puts "aborting transaction"
parent.abort_transaction
puts "aborted transaction"
puts "parent.object_id: #{parent.object_id}"
puts "parent.children[0].parent.object_id: #{parent.children[0].parent.object_id}"
parent << Child.new
puts "parent.children[1].parent.object_id: #{parent.children[1].parent.object_id}"

producing the output:

parent.object_id: 3265800
parent.children[0].parent.object_id: 3265800
starting transaction
parent.children[1].parent.object_id: 3265800
aborting transaction
aborted transaction
parent.object_id: 3265800
parent.children[0].parent.object_id: 3265500
parent.children[1].parent.object_id: 3265800

This bug affects PDF::Writer’s table generation and contributes significantly to the high memory usage. What’s happening is that when you call Parent#start_transaction, Transaction::Simple creates a transaction checkpoint with Marshal::dump. When you call Parent#rewind_transaction or or Parent#abort_transaction, the transaction checkpoint is reverted. This reversion is extremely robust except for this one item. What we really need is something like:

self = Marshal::restore(checkpoint)

Obviously, that won’t work and this leads to the problem that is illustrated above. After long discussion with Tim Pease, Patrick Hurley, and Matz, we came up with a workaround that can work for the example bug and for PDF::Writer. It’s not super-efficient, though. Essentially, I will modify Transaction::Simple to have callback methods for post-processing after a transactional operation. Something like this:

class Parent
  def post_restore_hook
    @children.map! { |child|
      child.parent = self unless self.object_id == child.parent.object_id
      child
    }
  end
end

parent = Parent.new
puts "parent.object_id: #{parent.object_id}"
parent < < Child.new
puts "parent.children[0].parent.object_id: #{parent.children[0].parent.object_id}"
puts "starting transaction"
parent.start_transaction
parent << Child.new
puts "parent.children[1].parent.object_id: #{parent.children[1].parent.object_id}"
puts "aborting transaction"
parent.abort_transaction
parent.post_restore_hook # would be called automatically in the real case
puts "aborted transaction"
puts "parent.object_id: #{parent.object_id}"
puts "parent.children[0].parent.object_id: #{parent.children[0].parent.object_id}"
parent << Child.new
puts "parent.children[1].parent.object_id: #{parent.children[1].parent.object_id}"

Which produces the output:

parent = Parent.new
puts "parent.object_id: #{parent.object_id}"
parent < < Child.new
puts "parent.children[0].parent.object_id: #{parent.children[0].parent.object_id}"
puts "starting transaction"
parent.start_transaction
parent << Child.new
puts "parent.children[1].parent.object_id: #{parent.children[1].parent.object_id}"
puts "aborting transaction"
parent.abort_transaction
parent.post_restore_hook
puts "aborted transaction"
puts "parent.object_id: #{parent.object_id}"
puts "parent.children[0].parent.object_id: #{parent.children[0].parent.object_id}"
parent << Child.new
puts "parent.children[1].parent.object_id: #{parent.children[1].parent.object_id}"

This isn't great: it doesn't feel very Ruby to me, but it does get the job done. It's also not very efficient. After thinking about this for the better part of an hour, matz has suggested that there might be a very ugly hack that’s possible that he’ll look at for me, which may be able to implement everything in Transaction::Simple. ]]> http://www.halostatue.ca/2006/10/22/ruby-conference-2006-day-1-evening-friday-20-october-2006/feed/ 7