[#25272] [Feature #2032] Change the license to "GPLv2+ or Ruby's original". — Yui NARUSE <redmine@...>

Feature #2032: Change the license to "GPLv2+ or Ruby's original".

51 messages 2009/09/02
[#25368] [Feature #2032] Change the license to "GPLv2+ or Ruby's original". — Kazuhiko Shiozaki <redmine@...> 2009/09/04

Issue #2032 has been updated by Kazuhiko Shiozaki.

[#25461] Re: [Feature #2032] Change the license to "GPLv2+ or Ruby's original". — Gregory Brown <gregory.t.brown@...> 2009/09/07

On Fri, Sep 4, 2009 at 1:10 PM, Kazuhiko Shiozaki<redmine@ruby-lang.org> wrote:

[#25463] Re: [Feature #2032] Change the license to "GPLv2+ or Ruby's original". — Yukihiro Matsumoto <matz@...> 2009/09/08

Hi,

[#30610] [Feature #2032] Change the license to "GPLv2+ or Ruby's original". — Shyouhei Urabe <redmine@...> 2010/06/06

Issue #2032 has been updated by Shyouhei Urabe.

[#30611] Re: [Feature #2032] Change the license to "GPLv2+ or Ruby's original". — Yusuke ENDOH <mame@...> 2010/06/06

Hi,

[#30614] Re: [Feature #2032] Change the license to "GPLv2+ or Ruby's original". — Urabe Shyouhei <shyouhei@...> 2010/06/06

> To avoid enbugging a new bug, we must choose the another solutions.

[#30616] Re: [Feature #2032] Change the license to "GPLv2+ or Ruby's original". — Yusuke ENDOH <mame@...> 2010/06/06

2010/6/6 Urabe Shyouhei <shyouhei@ruby-lang.org>:

[#30652] Re: [Feature #2032] Change the license to "GPLv2+ or Ruby's original". — Urabe Shyouhei <shyouhei@...> 2010/06/08

(2010/06/06 20:27), Yusuke ENDOH wrote:

[#25285] [Feature #2033] Move Core Development to Git — Run Paint Run Run <redmine@...>

Feature #2033: Move Core Development to Git

75 messages 2009/09/02
[#25290] [Feature #2033] Move Core Development to Git — Yui NARUSE <redmine@...> 2009/09/02

Issue #2033 has been updated by Yui NARUSE.

[#25297] Re: [Feature #2033] Move Core Development to Git — Jon <jon.forums@...> 2009/09/02

> Some commiter of Ruby live on Windows.

[#25342] Re: [Feature #2033] Move Core Development to Git — Urabe Shyouhei <shyouhei@...> 2009/09/03

Jon wrote:

[#25343] Re: [Feature #2033] Move Core Development to Git — Michal Suchanek <hramrach@...> 2009/09/03

2009/9/4 Urabe Shyouhei <shyouhei@ruby-lang.org>:

[#25345] Re: [Feature #2033] Move Core Development to Git — Urabe Shyouhei <shyouhei@...> 2009/09/03

Michal Suchanek wrote:

[#25299] Re: [Feature #2033] Move Core Development to Git — Eric Hodel <drbrain@...7.net> 2009/09/02

On Sep 2, 2009, at 11:19, Run Paint Run Run wrote:

[#25306] [Feature #2034] Consider the ICU Library for Improving and Expanding Unicode Support — Run Paint Run Run <redmine@...>

Feature #2034: Consider the ICU Library for Improving and Expanding Unicode Support

16 messages 2009/09/03

[#25394] Unmaintained code (Was: Move Core Development to Git) — Eric Hodel <drbrain@...7.net>

On Sep 4, 2009, at 02:16, Urabe Shyouhei wrote:

10 messages 2009/09/05

[#25420] [Bug #2054] Onigurma Isn't Documented — Run Paint Run Run <redmine@...>

Bug #2054: Onigurma Isn't Documented

17 messages 2009/09/05

[#25442] turning off indentation warnings — Aaron Patterson <aaron@...>

Is there a way in 1.9 to turn off only indentation warnings? I like

19 messages 2009/09/06
[#25510] Re: turning off indentation warnings — Nobuyoshi Nakada <nobu@...> 2009/09/10

Hi,

[#25511] [Bug #2079] win32ole's OLEGEN does not create all classes needed when a TLB has more than one class defined — Bruno Antunes <redmine@...>

Bug #2079: win32ole's OLEGEN does not create all classes needed when a TLB has more than one class defined

18 messages 2009/09/10

[#25644] [Bug #2121] mathn/rational destroys Fixnum#/, Fixnum#quo and Bignum#/, Bignum#quo — Charles Nutter <redmine@...>

Bug #2121: mathn/rational destroys Fixnum#/, Fixnum#quo and Bignum#/, Bignum#quo

12 messages 2009/09/19

[#25709] [Bug #2131] f(not x) => syntax error — "James M. Lawrence" <redmine@...>

Bug #2131: f(not x) => syntax error

16 messages 2009/09/22

[#25769] A challenge: Enumerator#next in JRuby — Charles Oliver Nutter <headius@...>

I have a challenge for anyone who wants to discuss, propose

25 messages 2009/09/25
[#25782] Re: A challenge: Enumerator#next in JRuby — Tanaka Akira <akr@...> 2009/09/26

In article <f04d2210909251312q46bd51c0teacc4b0a8c417f0c@mail.gmail.com>,

[#25820] [Feature #2152] Split functionality of Float#inspect and Float#to_s — Roger Pack <redmine@...>

Feature #2152: Split functionality of Float#inspect and Float#to_s

32 messages 2009/09/28

[#25853] [Bug #2160] JSON can't parse input where top-level object is a string — caleb clausen <redmine@...>

Bug #2160: JSON can't parse input where top-level object is a string

11 messages 2009/09/29

[ruby-core:25836] Re: event hook in 1.9?

From: Rocky Bernstein <rocky.bernstein@...>
Date: 2009-09-29 08:43:46 UTC
List: ruby-core #25836
The event hook definitely works.

The TODO relates I think to setting *id* and *klass* which I what 1.8 does.

*begin long discussion which most may want to ignore:**
*
That said, in my view I don't believe it necessary to ever fill this out.
Instead what I'd rather see is the event hook call interface *simplified*.

Right now it is a trace function call looks like:
  *trace_function(event, file, line, id, bind, klass)
*
What I've been using in an experimental debugger is:
   *trace_function(event, frame, arg=nil)
*
From *frame* you can figure out *file*, *line*, *id*, *bind* and so on. I
was thinking that in the replacement call *arg* would be a placeholder for
any event where it may be desirable to pass more information. For example
the return value in a function or perhaps exception information in a raise.
I think this is how Python does it in their trace hook.

(Right now the way I up a value about to be returned is by just retrieving
the value from the VM stack which is very YARV specific).

As for *file* and *line*, I find this a little weird. The intent clearly is
to indicate a source position of where you are at when the event triggers.
But even though there are two (unnecessary in my opinion) parameters, it
still falls short of being specific and general.

"file" sometimes might not be a file if say you are running the
internal_prelude in a require ;-)
So I use a notion of a  "container" which is a two part thing: one part is
something like a locator ("file") and the other the object in which that
locator lives. Many times the locator is a "file" inside say a filesystem,
but it could be a string variable passed to *eval* or
*RubyVM::InstructionSequenceCompile.
*

So here it may be helpful say in a debugger or trace hook routine to know
not only the position of the text inside that variable but perhaps the
location of the eval. That way you could set the frame to be the context of
the eval on the call stack and pick up the full source text of the eval
which by the way doesn't appear in SCRIPT_LINES__.

In Python where packages can be bundled inside "egg" files and sometimes
compressed,  you might want to indicate that "file" is not in a filesystem
but inside this bundled file.

And as for "line", well, in the general case I think one wants again a
two-part thing: both a start position and and end position which would be a
starting "line" offset and a character offset within that and then an ending
line and an ending-line character offset. Right now I don't believe Ruby
will ever allow a compilation to start in one container (or "file") and end
in another, so repeating the "file" part on the end is not needed.

However in the presence of optimization, it is conceivable that instructions
or source code fragments from different "lines" get combined. So in fact
there may be *several* sets of positions for say a given VM instruction or
stopping place.  So what I have here is an unstructured array of
"positions", each position being in general a two part thingy, but for now I
just have a single Fixnum "line".

Some of these thoughts I have documented in
http://github.com/rocky/rb-threadframe/blob/master/threadframe.rd which is
in need of update.

On Tue, Sep 29, 2009 at 3:21 AM, Ryan Davis <ryand-ruby@zenspider.com>wrote:

> /**
>>  @c setting
>>  @e trace
>>  @j trace 用の命令。
>>  */
>> DEFINE_INSN
>> trace
>> (rb_num_t nf)
>> ()
>> ()
>> {
>>    rb_event_flag_t flag = (rb_event_flag_t)nf;
>>
>>    EXEC_EVENT_HOOK(th, flag, GET_SELF(), 0, 0 /* TODO: id, klass */);
>> }
>>
>
> Am I missing something? Does this TODO imply that the event hook mechanism
> isn't supposed to work yet?
>
>
>

In This Thread