Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Commits on Jul 5, 2012
  1. @nurse

    r36301 changes __callee__'s behavior when the method is aliased.

    nurse authored
    See also r36312 and r36313.
  2. @nurse
Commits on Jun 28, 2012
  1. @nurse

    Follow MRI r34582 as commit 51a1c39

    nurse authored
    * vm_method.c (rb_method_boundp):
      obj.respond_to?(:a_protected_method) should return false because
      calling a protected method may cause NoMethodError if called
      from outside the class inheritance tree.  Kernel#respond_to? is
      mostly used to test if it is safe to call a method, so the false
      positive should be avoided. [ruby-dev:40461] [ruby-dev:41739]
      [ruby-dev:41837]
  2. @nurse
  3. @nurse
  4. @brixen

    Merge pull request #140 from no6v/fix-slice_before_spec

    brixen authored
    make sure the block to be called
Commits on Jun 27, 2012
  1. @brixen

    Another race in Process.kill specs.

    brixen authored
    It appears that the Processs.exit! was being handled before the write
    to STDOUT had finished so the specs were failing on 1.9.3 with an empty
    string instead of 'signaled'. This change allows the signal handling
    code to finish and the process will naturally exit the busy loop once
    it has been signaled.
  2. @brixen
  3. @brixen

    Avoid handling signal twice in Process.kill specs.

    brixen authored
    The Mutex added in 57187385 fixes the race condition but loses the ability to
    ensure that the signal handler only runs once. Once the mutex unlocks, the
    handler code can interrupt the code implementing Process.exit! and print
    'signaled' again.  We first lock the mutex, then check the flag. This ensures
    there is no race and the correct value of the flag is always seen. The flag
    itself ensures the handler only runs once.
  4. @dbussink @brixen

    Setup locking around Process.kill process

    dbussink authored brixen committed
    This fixes a potential race that could occur in this subprocess. The
    problem is that when two signals were received at the same time, there
    was a race condition.
    
    What could happen is that when two signals were received, it would run
    the signal handler twice. One handler could set signaled to true, the
    other one would see signaled as false and exit before the other handler
    would print the "signaled" string.
    
    With a Mutex we can use try_lock to attempt to lock once and then exit.
    This makes sure we only print "signaled" once and immediately exit.
    
    Why not use Mutex.synchronize {} one might ask here. Well, that doesn't
    work since signals are handled in the same thread, so what happens then
    is that you can recursive locking errors since the Mutex is locked twice
    in the same thread so the deadlock detection kicks in and causes an
    exception.
  5. @jfredett @brixen

    add specs for Time#round

    jfredett authored brixen committed
  6. @jfredett @brixen

    add specs for Rational#round

    jfredett authored brixen committed
  7. @dbussink @brixen

    Make sure we join the returned thread before continuing

    dbussink authored brixen committed
  8. @kubo @brixen

    Add spec of CAPI rb_usascii_str_new.

    kubo authored brixen committed
    Signed-off-by: Dirkjan Bussink <d.bussink@gmail.com>
  9. @dbussink @brixen

    Fix yet another race condition in Process.kill specs

    dbussink authored brixen committed
    This time it gets even trickier. The problem is that writing the pid
    file consists of two steps, first creating the file and then writing the
    pid into it. POSIX file system semantics guarantee that each of those
    separate operations is atomic, but that still allows for the case where
    the file is created, but the content isn't written to it yet and
    therefore another thread sees an empty file.
    
    This means that when it seems an empty file, it reads the empty string,
    runs .to_i on it and sets the pid to 0. This means it will kill the
    process itself, causing the SIGTERM issues.
    
    The reason that this is happening more on Travis is probably because on
    Travis build machines they still use good old spinning magnetic disks.
    These are much slower, greatly increasing the changes of having this
    race occur. I actually managed to trigger it much more often on an old
    iMac which still has a spinning disk too.
    
    So the change for now is that we keep trying to read the file until we
    actually get contents back instead of continuing on an empty file read.
  10. @dbussink @brixen

    Fix more race issues in Process#kill specs

    dbussink authored brixen committed
    Make sure we only write the pid file after we've setup the signal
    handler. This makes sure we're not sending a signal before the handler
    is actually setup.
    
    The other issue is that we won't return from the constructor for
    Signalizer before the thread we start has properly started the
    executable. Otherwise we might be trying to kill something before we're
    done.
  11. @dbussink @brixen

    Make sure we cleanup pid files from a previous run that can cause a hang

    dbussink authored brixen committed
    With this change I'm not seeing any hangs anymore, but only the SIGTERM
    issue that it isn't handled properly.
  12. @brixen

    Rewrote Process.kill specs.

    brixen authored
  13. @dbussink @brixen

    Add spec for defining a method within the TOPLEVEL_BINDING

    dbussink authored brixen committed
  14. @txus @brixen

    Rename StaticScope to ConstantScope... EVERYWHERE

    txus authored brixen committed
    StaticScope is (ehem, was) where constants were scoped to, so IMHO
    ConstantScope makes for a much better name :)
  15. @eregon @brixen
  16. @ileitch @brixen

    Add specs to show assignment of a MatchData instance to $~ also chang…

    ileitch authored brixen committed
    …es derived globals.
  17. @jfirebaugh @brixen

    Add Regexp encoding-related specs

    jfirebaugh authored brixen committed
    * Regexp#{==,eql?,hash} with /n option
    * Regexp::FIXEDENCODING constant
    * Regexp::NOENCODING constant
    * Regexp#options on 1.9
    * Regexp#inspect with legacy kcode options
    * Regexp#union with mixed encodings
  18. @jfirebaugh @brixen

    Fix style and description errors in specs

    jfirebaugh authored brixen committed
  19. @ileitch @brixen

    capi/globals_spec.rb uses StringIO, require it.

    ileitch authored brixen committed
  20. @ileitch @brixen

    Specs for rb_lastline_get

    ileitch authored brixen committed
  21. @ileitch @brixen

    The default internal encoding cannot be set multiple times using -U a…

    ileitch authored brixen committed
    …nd -E.
  22. @ileitch @brixen

    Implement CAPI function rb_enumeratorize.

    ileitch authored brixen committed
  23. @ryoqun @brixen

    Add a spec for Thread.list with thread groups

    ryoqun authored brixen committed
  24. @antekpiechnik @brixen

    Fixed invalid spec descriptions for Float#to_s

    antekpiechnik authored brixen committed
    Instead of *decimal places* we should use *significant figures* to describe
    the number of digits that carry meaning contributing to precision of those numbers.
    
    http://en.wikipedia.org/wiki/Significant_figures
    
    I think :)
  25. @antekpiechnik @brixen

    Corrected a typo in Float#to_s spec description

    antekpiechnik authored brixen committed
  26. @ileitch @brixen

    Improve spec coverage of IO#advise.

    ileitch authored brixen committed
  27. @carlosgaldino @brixen

    Add spec for various Struct methods that should not override the attr…

    carlosgaldino authored brixen committed
    …ibutes accessor.
    
    The methods that should not override the accessor are:
    Struct#each
    Struct#each_pair
    Struct#hash
    Struct#length
    Struct#members
    Struct#select
    Struct#size
    Struct#to_a
  28. @carlosgaldino @brixen
  29. @carlosgaldino @brixen

    Add spec for Struct#length when accessor method is defined

    carlosgaldino authored brixen committed
    See #1724
Something went wrong with that request. Please try again.