[#10193] String.ord — David Flanagan <david@...>

Hi,

41 messages 2007/02/05
[#10197] Re: String.ord — Yukihiro Matsumoto <matz@...> 2007/02/06

Hi,

[#10198] Re: String.ord — David Flanagan <david@...> 2007/02/06

Yukihiro Matsumoto wrote:

[#10199] Re: String.ord — Daniel Berger <djberg96@...> 2007/02/06

David Flanagan wrote:

[#10200] Re: String.ord — David Flanagan <david@...> 2007/02/06

Daniel Berger wrote:

[#10208] Re: String.ord — "Nikolai Weibull" <now@...> 2007/02/06

On 2/6/07, David Flanagan <david@davidflanagan.com> wrote:

[#10213] Re: String.ord — David Flanagan <david@...> 2007/02/06

Nikolai Weibull wrote:

[#10215] Re: String.ord — "Nikolai Weibull" <now@...> 2007/02/06

On 2/6/07, David Flanagan <david@davidflanagan.com> wrote:

[#10216] Re: String.ord — David Flanagan <david@...> 2007/02/07

Nikolai Weibull wrote:

[#10288] Socket library should support abstract unix sockets — <noreply@...>

Bugs item #8597, was opened at 2007-02-13 16:10

12 messages 2007/02/13

[#10321] File.basename fails on Windows root paths — <noreply@...>

Bugs item #8676, was opened at 2007-02-15 10:09

11 messages 2007/02/15

[#10323] Trouble with xmlrpc — James Edward Gray II <james@...>

Some of the Ruby code used by TextMate makes use of xmlrpc/

31 messages 2007/02/15
[#10324] Re: Trouble with xmlrpc — "Berger, Daniel" <Daniel.Berger@...> 2007/02/15

> -----Original Message-----

[#10326] Re: Trouble with xmlrpc — James Edward Gray II <james@...> 2007/02/15

On Feb 15, 2007, at 1:29 PM, Berger, Daniel wrote:

[#10342] Re: Trouble with xmlrpc — James Edward Gray II <james@...> 2007/02/16

While I am complaining about xmlrpc, we have another issue. It's

[#10343] Re: Trouble with xmlrpc — Alex Young <alex@...> 2007/02/16

James Edward Gray II wrote:

[#10344] Re: Trouble with xmlrpc — James Edward Gray II <james@...> 2007/02/16

On Feb 16, 2007, at 12:08 PM, Alex Young wrote:

debug.rb does not work in some cases?

From: Martin Krauskopf <Martin.Krauskopf@...>
Date: 2007-02-13 16:35:59 UTC
List: ruby-core #10291
Hi,

in some cases breakpoints are ignored. Namely in the case like this:

   $ cat test.rb
   require 'test2.rb'
   Test2.new.print12
   puts 'three'
   $ cat test2.rb
   class Test2
     def print12
       puts 'one'
       puts 'two'
     end
   end
   $ ruby -rdebug test.rb
   Debug.rb
   Emacs support available.

   test.rb:1:require 'test2.rb'
   (rdb:1) b test2.rb:4
   Set breakpoint 1 at test.rb:4
   (rdb:1) c
   one
   two
   three
   $

Did not stop on test2:4. If I would use "b ./test2.rb:4" it would stop.
But it is not that clear.

I've found similar problem (seems unanswered):

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/69527 
[69528, 69530]

It seems to be due to File.basename()-related changes in:

http://svn.ruby-lang.org/cgi-bin/viewvc.cgi/trunk/lib/debug.rb?r1=3532&r2=3543
http://svn.ruby-lang.org/cgi-bin/viewvc.cgi/trunk/lib/debug.rb?r1=4151&r2=4180

But probably it is intentional? Is there any kind of 'specification' how
exactly it is supposed to set a breakpoint. In help there is just:

   'b[reak] [file:|class:]<line|method>'

by which test2.rb:4 seems ok to me in the above case.

For now I've patched debug.rb to use File.basename similar to as it was
few years ago (those SVN links) and which seems to work for me. Below is
supposed patch. But it might have some drawbacks I do not see?

Thanks for clarification,

   m.

Patch again ruby_1_8 branch (the same for trunk)

Index: lib/debug.rb
===================================================================
--- lib/debug.rb        (revision 11707)
+++ lib/debug.rb        (working copy)
@@ -307,7 +307,7 @@
           pos = $2
            if $1
              klass = debug_silent_eval($1, binding)
-            file = $1
+            file = File.basename($1)
            end
           if pos =~ /^\d+$/
             pname = pos
@@ -665,6 +665,7 @@

    def check_break_points(file, klass, pos, binding, id)
      return false if break_points.empty?
+    file = File.basename(file)
      n = 1
      for b in break_points
        if b[0]          # valid




In This Thread

Prev Next