Kurt Stephens

http://devblog.famundo.com/articles/2006/12/07/improving-postgres-listen...

Unfortunately this hack blocks all threads. It should use rb_thread_select(), not select().

I did this little hackage during a boring PGcon 2008 talk…

This patch allows the postgres gem 0.7.9.2008.01.28 to be compiled under Ruby 1.9 against PostgreSQL 8.3.0 client libraries.

It appears to work against a PostgreSQL 8.1 server, but I have not run any detailed testing, yet.

--- ext/extconf.rb.orig	2008-05-22 09:47:06.000000000 -0500
+++ ext/extconf.rb	2008-05-22 09:52:28.000000000 -0500
@@ -1,6 +1,9 @@

+# Ruby 1.9
+PLATFORM = RUBY_PLATFORM unless defined? PLATFORM
+

 # windows compatibility, need different library name
 if(PLATFORM =~ /mingw|mswin/) then
<br class="clear" />

Introduction

TM is a real-time, non-relocating, conservative, allocator using type- and color-segregated lists, based on Henry Baker’s “Treadmill” allocator. The source code for TM is located at http://kurtstephens.com/pub/tredmill.

TM interleaves marking, scanning and sweeping during each mutator’s call to tm_alloc().

TM attempts to limit the amount of work in the collector to avoid stopping the world for long periods of time. It does not require a separate thread for the collector as all collection activities are interleaved with allocation.

Full documentation is located at: http://kurtstephens.com/pub/tredmill/current/doc/html/index.html

http://www.japanesebugfights.com/

Scorpion .vs. Centipede was surprising!

Download: http://github.com/kstephens/ll/tree/master

LL is:

An embeddable pure, class-based, object Lisp system C library with multiple inheritance and mix-in support based on ideas from Scheme, Oaklisp and Dylan. Clean namespace and proper tail calls in C.

Version 0.15:

• Adds a method lookup cache at all call sites, including primitive C code, reduces full method lookups by over 80%.
• Relies on Bohem GC 7.0 (included).
• Passes R4RS tests.
• Improved bytecode compiler and constant folding on non-side-effecting methods.
• Compiles with GCC 4.1.3.

• call/cc is partially supported.

Type tags in MRI Ruby VALUE

Internally, values in MRI Ruby are 32-bit (at least for 32-bit processors). Some of the least-significant bits are used to store type information. See the VALUE definition in include/ruby/ruby.h. Using type tag bits avoids allocating additional memory for commonly-used immutable values, like integers.

Ruby uses a single-bit tag of 0x01 as the Fixnum type tag. The remaining bits, are used to store the Fixnum’s signed value. This is an immediate value; it doesn’t require storage for the Fixnum value to be allocated, unlike the heap space that would be required for a String. Other types will use different tag bits.

Helpful in IRB:

class Regexp
  def to_proc
    @proc ||= lambda { | x | self.match(x) }
  end
end

As in:

irb(main):001:0> pp Object.methods.sort.select(&/meth/)
["instance_method",
 "instance_methods",
 "method",
 "method_defined?",
 "methods",
 "private_class_method",
 "private_instance_methods",
 "private_method_defined?",
 "private_methods",
 "protected_instance_methods",
 "protected_method_defined?",
 "protected_methods",
 "public_class_method",
 "public_instance_methods",
 "public_method_defined?",
 "public_methods",
 "singleton_methods"]
<br class="clear" />

Gem::SourceIndex does not honor GEM_PATH ordering.

See: http://rubyforge.org/tracker/index.php?func=detail&aid=14816&group_id=12...

Gem::SourceIndex#load_gems_in calls #add_spec for all gems found in #spec_dirs, in the order of Gem.path, however #add_spec
overwrites previous gem_specs in the @gems Hash:

So you’re coding some ruby, and you do the obligatory caching of a computation:

def foo(x)
  666
end

$cache = nil
def cryptic_cached_foo
  ($cache ||= [ foo("bar") ]).first
end

def nicey_cached_foo
  unless $cache
    $cache = [ foo("bar") ]
  end
  $cache.first
end

A discussion came up at work: is nicey_cached_foo “better” than cryptic_cached_foo? Obviously, nicey_cached_foo is more readable, but when I find myself doing the same pattern over and over, I prefer the terse cryptic_cached_foo. I expected cryptic_cached_foo to be faster. Oh boy, was I wrong….