[#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:20155] Re: [Bug #797] bug or feature: local method ?

From: Francoys <francois.pr@...>
Date: 2008-11-28 19:22:15 UTC
List: ruby-core #20155
Brian Candler wrote:
> If you really want to organise your code like this, you can using lambdas:
>   def foo
>     a_list = ...
>     b_list = ...
>     c_list = ...
>
>     foo1 = lambda {
>       op1(a_list, b_list, c_list)
>     }
>
>     ...
>     foo1[]
>   end
>
> This just avoids having to pass a_list, b_list, c_list to foo, because they
> are visible in the enclosing scope.
>
> But in many cases a more Rubyesque way would be to create a container class
> to hold those three lists and to group together the operations on them.
>
> class A
>   class B
>     attr_accessor :a, :b, :c
>     def initialize(a,b,c)
>       @a, @b, @c = a,b,c
>     end
>     def foo1
>       op1(@a, @b, @c)
>       # or perhaps: @a, @b, @c = op1(@a, @b, @c)
>     end
>     ...
>   end
>
>   def foo
>     a_list = ...
>     b_list = ...
>     c_list = ...
>
>     b = B.new(a_list, b_list, c_list)
>
>     b = b.foo1
>     ...
>     return b.a, b.b, b.c
>   end
> end
>
> Notice that a 'throwaway' instance of class B is created inside method
> A#foo, and is garbage-collected after it returns. That doesn't matter -
> objects are cheap to create in Ruby, and it's a small object as it just has
> three instance variables (which only hold a reference to the list objects,
> which already exist).
>
> With this approach you need to decide where it makes most sense for op1 to
> live. If it makes sense to live in class B then it gets even simpler, as it
> can access the instance variables @a, @b, @c directly without having to have
> them passed as arguments.
>
> I reiterate - objects are created and destroyed often in Ruby. You may not
> realise it, but even
>
>    10.times { puts "hello" }
>
> creates 10 distinct String objects, and garbage collects them.
>
> Regards,
>
> Brian.
>
>
>   
I was aware that could used a class to do the trick, but a like to stay
away of programming practice who generate
code.that.look.like.java.expression  ...    :-)

You must admit this type of code( foo4) is more clean, and provide a
simpler form of encapsulation of the code.

But your Lambda's version is very tempting, but my experience with the
use of Proc come at the price of performance penalty. But inside a
method, thing might be a bit different. I most admit that i like a lot
the elegance of the lambda's version.

------------------------------------------------------------------------------------------------------------------------

def foo4

  @bar = 10

  def gazonk
    print @bar
  end

  gazonk
end

foo4
--------------------------------------------------------------------------------------------------------------------------

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


foo()
   @a_list = # a big link list
   @b_list = # another big link list
   @c_list = # result of operation on a_list and b_link

   def foo1()
     op1(@a_list,@b_list,@c_list)
    end

    def foo2()
       op2(@a_list,@b_list,@c_list)
    end

    def foo3()
      op2(@a_list,@b_list,@c_list)
    end

foo1()
foo2()
return foo3()
end

p foo()

--------------------------------------------------------------------------------------------------------------------------

Yes, the penalty do not seem very high in Ruby, but when you are writing
a Prolog interpreter/compiler, reducing the amount of garbages is your
main concern. In some case, half of the time is spend in the garbage
collection.
   
To illustrated the importance of the garbage collection on Prolog. The
prolog's version of SWI Prolog with a very smart garbage collector is
faster the original version in C.


/Perhaps you've misunderstood how assignments work in Ruby. If you do

  a = [:an, :array, :of, :stuff]
  b = a

then the second line does *not* create any new object. So what you say is
true only if function foo1 creates and returns three new lists./



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 *. (That why technic 2 have 6 lists and technic 3 only 3 ,
technic 1 generate a least 12 **) That the difference between call by
value and call by reference .  You can fool the interpreter by putting
values inside an array, so it gone modify the value of variable outside
the scope of the function. ( because the interpreter copy a pointer,
exactly like an assignments)

test this:

 
  a=1
  b=1
  c=[a,b]
 
def foo1(x,y)
    x +=1
    y +=1
end

foo1(a,b)

p a,b # no modification of the content of a or b

def foo2(x)
    x[0] +=1
    x[1] +=1
end

foo2(c)

p c[0],c[1]  #Surprise. The content of c have change !


By using variable outside the function, you are bypassing the cloning
process and the old value is crushed every times that you are using that
variable. And so far, it's seem to work with every programming language.
And because it's a common practice to reclaimed the space of the inner
variable after the uses of a function in many garbage collector, i feel
technic 3 is a bit better. But in term of speed there is no big
difference between 2 and 3)

This code :

i=0
for i in 0..100000
    p i
end

is faster than this one:

for i in 0..100000
    p i
end


* That the reason why many programming language do not allowed Array as
parameter, but only pointer on an array.

** i have the bad feeling that only the first node is a copy ....  :(





  Regards
 
  Fran輟ys



In This Thread