[#23457] [Bug #1471] "Mutual join" deadlock detection faulty in 1.8.6 and 1.8.7 — John Carter <redmine@...>

Bug #1471: "Mutual join" deadlock detection faulty in 1.8.6 and 1.8.7

17 messages 2009/05/15

[#23483] [Bug #1478] Ruby archive — Oleg Puchinin <redmine@...>

Bug #1478: Ruby archive

29 messages 2009/05/16
[#29225] [Feature #1478] Ruby archive — Luis Lavena <redmine@...> 2010/04/02

Issue #1478 has been updated by Luis Lavena.

[#30345] Re: [Feature #1478] Ruby archive — "NAKAMURA, Hiroshi" <nakahiro@...> 2010/05/21

On Fri, Apr 2, 2010 at 17:13, Luis Lavena <redmine@ruby-lang.org> wrote:

[#30346] Re: [Feature #1478] Ruby archive — Jonathan Nielsen <jonathan@...> 2010/05/21

> Thanks for your comment.

[#30347] Re: [Feature #1478] Ruby archive — Jonathan Nielsen <jonathan@...> 2010/05/21

OK Hiroshi, I read some of the comments earlier in the thread that I

[#30355] Re: [Feature #1478] Ruby archive — Caleb Clausen <vikkous@...> 2010/05/21

On 5/20/10, Jonathan Nielsen <jonathan@jmnet.us> wrote:

[#30364] Re: [Feature #1478] Ruby archive — Benoit Daloze <eregontp@...> 2010/05/22

Hi,

[#23505] [Bug #1494] tempfile#unlink may silently fail on windows — Nicholas Manning <redmine@...>

Bug #1494: tempfile#unlink may silently fail on windows

19 messages 2009/05/19

[#23572] [Bug #1525] Deadlock in Ruby 1.9's VM caused by ConditionVariable.wait and fork? — Hongli Lai <redmine@...>

Bug #1525: Deadlock in Ruby 1.9's VM caused by ConditionVariable.wait and fork?

27 messages 2009/05/27

[#23595] Meaning of RUBY_PLATFORM — Rick DeNatale <rick.denatale@...>

The RUBY_PLATFORM constant is documented in the latest Pickaxe as "The

17 messages 2009/05/28
[#23596] Re: Meaning of RUBY_PLATFORM — Luis Lavena <luislavena@...> 2009/05/28

On Thu, May 28, 2009 at 3:41 PM, Rick DeNatale <rick.denatale@gmail.com> wrote:

[#23602] Re: Meaning of RUBY_PLATFORM — Rick DeNatale <rick.denatale@...> 2009/05/28

On Thu, May 28, 2009 at 2:52 PM, Luis Lavena <luislavena@gmail.com> wrote:

[#23608] Re: Meaning of RUBY_PLATFORM — Luis Lavena <luislavena@...> 2009/05/28

On Thu, May 28, 2009 at 7:08 PM, Rick DeNatale <rick.denatale@gmail.com> wrote:

[#23609] Re: Meaning of RUBY_PLATFORM — Rick DeNatale <rick.denatale@...> 2009/05/29

On Thu, May 28, 2009 at 7:22 PM, Luis Lavena <luislavena@gmail.com> wrote:

[ruby-core:23503] [Feature #1493] [patch] lex_state as bit field / IS_lex_state() macro

From: Dave B <redmine@...>
Date: 2009-05-19 17:18:07 UTC
List: ruby-core #23503
Feature #1493: [patch] lex_state as bit field / IS_lex_state() macro
http://redmine.ruby-lang.org/issues/show/1493

Author: Dave B
Status: Open, Priority: Normal

#  ? Changelog:
#  Represent lex_state by bit field instead of serial integer enum
#   so that single or multiple values can be checked together using
#   unifying macro IS_lex_state().  States remain mutually exclusive.

Example:

Each use of current macro IS_BEG() ..
#define IS_BEG() (lex_state == EXPR_BEG   || lex_state == EXPR_MID || \
                  lex_state == EXPR_VALUE || lex_state == EXPR_CLASS)

.. results in up to 4 tests which can be reduced to 1.

An extreme use case ..

        if (IS_BEG() ||
            lex_state == EXPR_DOT ||
            IS_ARG()) {

.. requires up to 7 tests on lex_state.

To my knowledge, compilers can't optimize this.
As a bit field, there's no need to:

        if (IS_lex_state( EXPR_BEG_ANY | EXPR_ARG_ANY | EXPR_DOT ))

.. reduces to:    if (lex_state & (test_bits))  // TRUE/FALSE

All changes in this patch were scripted to eliminate the possibility
of typos.  Where some replaced sections looked similar or the same,
they were verified with MD5sum before applying!
Multiple state tests were merged using simple, strict logic and any
"surprise" code would have been left unchanged.

Therefore, it should not be necessary to check every line of the patch;
I hope that a check of a random sample will give confidence in the rest.

There were several repeated switches which could have been replaced with:

  lex_state = (IS_lex_state( EXPR_FNAME | EXPR_DOT )) ? EXPR_ARG : EXPR_BEG

 but I assumed you would prefer if-else for flexibility and legibility:

 	if (IS_lex_state( EXPR_FNAME | EXPR_DOT )) {
	    lex_state = EXPR_ARG;
	}
	else {
	    lex_state = EXPR_BEG;
	}

Say what you don't like about anything - it might be easy to change. :)

Wouldn't it be nice to use some spare bits to combine other state?

        if ((lex_state == EXPR_BEG && !cmd_state) || ...
        if (IS_ARG() && space_seen && ...

 - I haven't explored those, yet.


My motivation was not to reduce processor heat. ;)
In the future, if we need to break the dependence on Yacc/Bison, these
state transitions might need to become token information and the change
makes them far easier to store.
( e.g. Any of 'THESE states' => 'THIS state' )


daz


----------------------------------------
http://redmine.ruby-lang.org

In This Thread

Prev Next