[#19731] use of require thread safety — "Roger Pack" <rogerpack2005@...>

I'm sure this has been discussed before, but...should there be

56 messages 2008/11/08
[#19796] Re: use of require thread safety — Nobuyoshi Nakada <nobu@...> 2008/11/11

Hi,

[#21651] Re: use of require thread safety — Charles Oliver Nutter <charles.nutter@...> 2009/01/29

Nobuyoshi Nakada wrote:

[#19798] Re: use of require thread safety — "Roger Pack" <rogerpack2005@...> 2008/11/11

> While a thread is requiring a given file, another thread which

[#20732] Re: use of require thread safety — "Roger Pack" <rogerpack2005@...> 2008/12/20

> Currently with 1.8.7 (for me) the secondmost thread continues

[#20737] Re: use of require thread safety — Charles Oliver Nutter <charles.nutter@...> 2008/12/20

Roger Pack wrote:

[#20769] Re: use of require thread safety — Charles Oliver Nutter <charles.nutter@...> 2008/12/21

Charles Oliver Nutter wrote:

[#20795] Re: use of require thread safety — Paul Brannan <pbrannan@...> 2008/12/22

On Mon, Dec 22, 2008 at 03:05:07AM +0900, Charles Oliver Nutter wrote:

[#19821] Re: use of require thread safety — Paul Brannan <pbrannan@...> 2008/11/11

On Tue, Nov 11, 2008 at 10:51:45AM +0900, Nobuyoshi Nakada wrote:

[#19829] Re: use of require thread safety — Charles Oliver Nutter <charles.nutter@...> 2008/11/11

Paul Brannan wrote:

[#19759] Proposal: Method#get_args — "Yehuda Katz" <wycats@...>

I'd like to propose a way to introspect into the arguments of a method

97 messages 2008/11/09
[#19787] Re: Proposal: Method#get_args — "Roger Pack" <rogerpack2005@...> 2008/11/11

The only question I have is why would one want to know the names of

[#19789] Re: Proposal: Method#get_args — Trans <transfire@...> 2008/11/11

On Nov 10, 7:18=A0pm, "Roger Pack" <rogerpack2...@gmail.com> wrote:

[#19818] Re: Proposal: Method#get_args — Mikael Hlund <mikael@...> 2008/11/11

Allow me to throw in my ~.116892074 DKK;

[#19837] Re: Proposal: Method#get_args — Charles Oliver Nutter <charles.nutter@...> 2008/11/11

Mikael H淡ilund wrote:

[#19838] Re: Proposal: Method#get_args — Dave Thomas <dave@...> 2008/11/11

[#19870] Re: Proposal: Method#get_args — Brian Candler <B.Candler@...> 2008/11/12

On Wed, Nov 12, 2008 at 04:48:03AM +0900, Dave Thomas wrote:

[#19874] Re: Proposal: Method#get_args — Paul Brannan <pbrannan@...> 2008/11/12

On Wed, Nov 12, 2008 at 06:01:40PM +0900, Brian Candler wrote:

[#19881] Re: Proposal: Method#get_args — Charles Oliver Nutter <charles.nutter@...> 2008/11/12

Paul Brannan wrote:

[#19887] Re: Proposal: Method#get_args — Paul Brannan <pbrannan@...> 2008/11/12

On Thu, Nov 13, 2008 at 02:06:15AM +0900, Charles Oliver Nutter wrote:

[#19889] Re: Proposal: Method#get_args — Charles Oliver Nutter <charles.nutter@...> 2008/11/12

Paul Brannan wrote:

[#19892] Re: Proposal: Method#get_args — Jim Weirich <jim.weirich@...> 2008/11/12

[#19893] Re: Proposal: Method#get_args — Jim Deville <jdeville@...> 2008/11/12

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

[#19894] Re: Proposal: Method#get_args — Brian Candler <B.Candler@...> 2008/11/12

On Thu, Nov 13, 2008 at 04:33:07AM +0900, Jim Deville wrote:

[#19895] Re: Proposal: Method#get_args — Jim Weirich <jim.weirich@...> 2008/11/12

[#19896] Re: Proposal: Method#get_args — Charles Oliver Nutter <charles.nutter@...> 2008/11/12

Jim Weirich wrote:

[#19899] Re: Proposal: Method#get_args — Jim Weirich <jim.weirich@...> 2008/11/12

On Nov 12, 2008, at 4:12 PM, Charles Oliver Nutter wrote:

[#19915] Re: Proposal: Method#get_args — Brian Candler <B.Candler@...> 2008/11/13

On Thu, Nov 13, 2008 at 07:02:25AM +0900, Jim Weirich wrote:

[#19927] Re: {Proc,Method}#parameters (Re: Proposal: Method#get_args) — Nobuyoshi Nakada <nobu@...> 2008/11/14

Hi,

[#19784] Status of copy-on-write friendly garbage collector — Hongli Lai <hongli@...99.net>

Hi.

22 messages 2008/11/10
[#19799] Re: Status of copy-on-write friendly garbage collector — "Narihiro Nakamura" <authornari@...> 2008/11/11

Hi.

[#19812] Re: Status of copy-on-write friendly garbage collector — "Yehuda Katz" <wycats@...> 2008/11/11

Narihiro,

[#19823] Re: Status of copy-on-write friendly garbage collector — Yukihiro Matsumoto <matz@...> 2008/11/11

Hi,

[#19845] [Bug #743] Socket.gethostbyname returns odd values — Roger Pack <redmine@...>

Bug #743: Socket.gethostbyname returns odd values

11 messages 2008/11/11

[#19846] [Bug #744] memory leak in callcc? — Roger Pack <redmine@...>

Bug #744: memory leak in callcc?

142 messages 2008/11/11
[#21394] [Bug #744] memory leak in callcc? — Roger Pack <redmine@...> 2009/01/17

Issue #744 has been updated by Roger Pack.

[#21429] Re: [Bug #744] memory leak in callcc? — Brent Roman <brent@...> 2009/01/19

[#21441] Re: [Bug #744] memory leak in callcc? — Nobuyoshi Nakada <nobu@...> 2009/01/19

Hi,

[#21483] Re: [Bug #744] memory leak in callcc? — Brent Roman <brent@...> 2009/01/21

[#21487] Re: [Bug #744] memory leak in callcc? — Michal Babej <calcifer@...> 2009/01/21

On Wednesday 21 of January 2009 10:21:19 Brent Roman wrote:

[#21711] Re: [Bug #744] memory leak in callcc? — Brent Roman <brent@...> 2009/02/01

[#22062] Re: [Bug #744] memory leak in callcc? — Roger Pack <rogerdpack@...> 2009/02/14

>> I've tried that myself but it didn't work very well

[#22265] Re: [Bug #744] memory leak in callcc? — Michal Babej <calcifer@...> 2009/02/19

On Saturday 14 of February 2009 08:17:22 Roger Pack wrote:

[#21514] Re: [Bug #744] memory leak in callcc? — Brent Roman <brent@...> 2009/01/22

[#19945] [Bug #744] memory leak in callcc? — Roger Pack <redmine@...> 2008/11/15

Issue #744 has been updated by Roger Pack.

[#19968] Re: [Bug #744] memory leak in callcc? — Brent Roman <brent@...> 2008/11/17

[#19969] Re: [Bug #744] memory leak in callcc? — Martin Duerst <duerst@...> 2008/11/17

At 12:54 08/11/17, Brent Roman wrote:

[#19970] Re: [Bug #744] memory leak in callcc? — Brent Roman <brent@...> 2008/11/17

[#19972] Re: [Bug #744] memory leak in callcc? — Kurt Stephens <kurt@...> 2008/11/17

A common technique is to allocate a reasonably sized array (256-bytes)

[#20149] Promising C coding techniques to reduce MRI's memory use — Brent Roman <brent@...> 2008/11/28

[#20517] Re: Promising C coding techniques to reduce MRI's memory use — "Roger Pack" <rogerpack2005@...> 2008/12/13

> I implemented a scheme for recording the maximum depth of the C stack in

[#20534] Re: Promising C coding techniques to reduce MRI's memory use — Brent Roman <brent@...> 2008/12/13

[#20750] [PATCH] Promising C coding techniques to reduce MRI's memory use — Brent Roman <brent@...> 2008/12/21

[#20751] Re: [PATCH] Promising C coding techniques to reduce MRI's memory use — Ezra Zygmuntowicz <ezmobius@...> 2008/12/21

[#20752] Re: [PATCH] Promising C coding techniques to reduce MRI's memory use — Brent Roman <brent@...> 2008/12/21

[#20781] Re: [PATCH] Promising C coding techniques to reduce MRI's memory use — "Roger Pack" <rogerpack2005@...> 2008/12/22

First thanks for doing all that hard work. I'm sure it's not pleasant

[#20783] Re: [PATCH] Promising C coding techniques to reduce MRI's memory use — Brent Roman <brent@...> 2008/12/22

[#20903] Re: [PATCH] Promising C coding techniques to reduce MRI's memory use — "Roger Pack" <rogerpack2005@...> 2008/12/26

Seems to overall be a tidge slower for "micro" stuff--5 or 10%.

[#20914] Re: [PATCH] Promising C coding techniques to reduce MRI's memory use — Brent Roman <brent@...> 2008/12/27

[#20922] Re: [PATCH] Promising C coding techniques to reduce MRI's memory use — "Roger Pack" <rogerpack2005@...> 2008/12/27

> You ran this benchmark suite, correct?

[#20931] Re: [PATCH] Promising C coding techniques to reduce MRI's memory use — Brent Roman <brent@...> 2008/12/28

[#20995] Re: [PATCH] Promising C coding techniques to reduce MRI's memory use — "Roger Pack" <rogerpack2005@...> 2008/12/30

Hmm interesting.

[#21261] Re: [PATCH] Promising C coding techniques to reduce MRI's memory use — "Stephen Sykes" <sdsykes@...> 2009/01/11

Brent,

[#20168] Re: Promising C coding techniques to reduce MRI's memory use — Nobuyoshi Nakada <nobu@...> 2008/11/30

Hi,

[#20175] Re: Promising C coding techniques to reduce MRI's memory use — Brian Candler <B.Candler@...> 2008/11/30

The problem can be demonstrated with a very simple program (attached), and

[#20178] Re: Promising C coding techniques to reduce MRI's memory use — Brent Roman <brent@...> 2008/11/30

[#20185] Re: Promising C coding techniques to reduce MRI's memory use — Brian Candler <B.Candler@...> 2008/12/01

> What I did come up with was not ugly at all. Factor the unwieldy switch

[#19938] Fibers in 1.8 — "Aman Gupta" <rubytalk@...1.net>

Are there any plans to backport Fiber to ruby 1.8?

13 messages 2008/11/15

[#20008] [Bug #766] 'Not enough space' error on windows — Ittay Dror <redmine@...>

Bug #766: 'Not enough space' error on windows

17 messages 2008/11/20

[#20092] [Bug #797] bug or feature: local method ? — Francois Proulx <redmine@...>

Bug #797: bug or feature: local method ?

23 messages 2008/11/25
[#20097] Re: [Bug #797] bug or feature: local method ? — Yukihiro Matsumoto <matz@...> 2008/11/25

Hi,

[#20098] Re: [Bug #797] bug or feature: local method ? — Dave Thomas <dave@...> 2008/11/25

[#20100] Re: [Bug #797] bug or feature: local method ? — Yukihiro Matsumoto <matz@...> 2008/11/25

Hi,

[#20127] Re: [Bug #797] bug or feature: local method ? — Francoys <francois.pr@...> 2008/11/26

Yukihiro Matsumoto wrote:

[ruby-core:20157] Re: [Bug #797] bug or feature: local method ?

From: Brian Candler <B.Candler@...>
Date: 2008-11-28 19:59:08 UTC
List: ruby-core #20157
On Sat, Nov 29, 2008 at 04:22:15AM +0900, Francoys wrote:
> But your Lambda's version is very tempting, but my experience with the
> use of Proc come at the price of performance penalty.

Beware (a) premature optimisation, and (b) using your intuition to decide
where hotspots are. Even the most experienced programmers usually get it
wrong if they try to guess where to optimise. Profile first, optimise later.

In any case, Ruby is about writing programs which are elegant and easy to
maintain; performance is secondary. Don't fight the language. If you are
trying to write spaghetti Ruby just to gain a 5% performance benefit, then
you would be better off writing in a completely different language.

> ------------------------------------------------------------------------------------------------------------------------
> 
> def foo4
> 
>   @bar = 10
> 
>   def gazonk
>     print @bar
>   end
> 
>   gazonk
> end
> 
> foo4
> --------------------------------------------------------------------------------------------------------------------------

This doesn't work the way you expect.

What happens here is that every time you call foo4, you are actually
*redefining* the method 'gazonk' in the top level object. So now you have
the worst of all possible worlds; unnecessarily bad performance, and still
no sharing of local variables.

That is: in Ruby, "def xxx ... end" defines a method when the def statement
is actually *executed*. Normally you write these statements inside a class
statement, so they are only executed once (when the file is run). But if you
stick a def statement inside a loop, or inside a method body, then it *will*
redefine the method repeatedly.

However you can avoid the performance penalty by rewriting your code above
simply as:

  def gazonk
    print @bar
  end

  def foo4
    @bar = 10
    gazonk
  end

This is perfectly fine and reasonable Ruby.

> By the way, i didn't test the third model and this is the correct
> version, the @ are making a big difference:

This will work fine *without* using instance variables. But since you're not
posting real code here, only dummy stuff, I can't be sure where you're going
wrong.

Perhaps in op1() you are reassigning @a_list to point to a different object.
(But in that case, there is no point passing in @a_list and friends as
arguments).

> Unless Ruby have a radical new approach, every time that you are using a
> function, the interpreter must clone the values that are passed in
> parameter *.

Wrong.

Ruby's approach *is* different to other languages - perhaps you can call it
radical if you've not seen it before.

In Ruby, every value is an object reference. Absolutely *every* value. So:

  def foo
    puts foo.object_id
  end

  a = 1
  foo(a)       # pass a single object reference

  a = [1,2,3]
  foo(a)       # pass a single object reference

In both calls to foo, a single object reference is passed. There is no
'cloning' of anything. The references are passed by value (copied, if you
like), but the objects themselves are not cloned.

I'm afraid I was as guilty as anyone when I first came to Ruby: jumping in
with "why doesn't Ruby do this" or "I expected it to do that" or "wouldn't
it be better if it did the other". My advice is: go with the flow. Relax,
expand your mind, open yourself to new concepts which may not be the same as
what you're familiar with. Learn how these may enhance your programming; by
all means compare and contrast with what you know, but don't reject what's
new out of hand. Sure, other languages may have advantages over Ruby, but
you may also find that you can do things in Ruby much more easily than you
could do before.

I'd also suggest this discussion would be better suited to ruby-talk rather
than ruby-core.

Regards,

Brian.

In This Thread