[#1711] Re: open-uri patch, added progress_proc hook — "T. Onoma" <transami@...>

Tanaka Akira:

22 messages 2003/11/19
[#1737] Re: open-uri patch, added progress_proc hook — Mathieu Bouchard <matju@...> 2003/11/23

[#1739] Re: open-uri patch, added progress_proc hook — Mathieu Bouchard <matju@...> 2003/11/23

[#1740] Re: open-uri patch, added progress_proc hook — "T. Onoma" <transami@...> 2003/11/23

On Sunday 23 November 2003 08:26 pm, Mathieu Bouchard wrote:

[#1741] Re: open-uri patch, added progress_proc hook — Mathieu Bouchard <matju@...> 2003/11/23

[#1718] Re: open-uri patch, added progress_proc hook — Elliott Hughes <ehughes@...>

22 messages 2003/11/21
[#1722] Re: open-uri patch, added progress_proc hook — Tanaka Akira <akr@...17n.org> 2003/11/22

In article <AD4480A509455343AEFACCC231BA850F17C434@ukexchange>,

[#1724] Re: open-uri patch, added progress_proc hook — "T. Onoma" <transami@...> 2003/11/22

On Saturday 22 November 2003 04:34 pm, Tanaka Akira wrote:

[#1726] Re: open-uri patch, added progress_proc hook — Tanaka Akira <akr@...17n.org> 2003/11/23

In article <200311221024.05642.transami@runbox.com>,

[#1731] Re: open-uri patch, added progress_proc hook — "T. Onoma" <transami@...> 2003/11/23

On Sunday 23 November 2003 02:24 am, Tanaka Akira wrote:

[#1732] Re: open-uri patch, added progress_proc hook — Tanaka Akira <akr@...17n.org> 2003/11/23

In article <200311230325.21687.transami@runbox.com>,

[#1733] Re: open-uri patch, added progress_proc hook — "T. Onoma" <transami@...> 2003/11/23

On Sunday 23 November 2003 03:10 pm, Tanaka Akira wrote:

[#1750] Re: open-uri patch, added progress_proc hook — Tanaka Akira <akr@...17n.org> 2003/11/24

In article <200311230648.41003.transami@runbox.com>,

[#1759] Re: open-uri patch, added progress_proc hook — Sean E Russell <ser@...> 2003/11/24

On Monday 24 November 2003 03:19, Tanaka Akira wrote:

[#1762] Re: open-uri patch, added progress_proc hook — "Nathaniel Talbott" <nathaniel@...> 2003/11/24

Sean E Russell [mailto:ser@germane-software.com] wrote:

[#1753] gc_sweep under 1.8 ... not syck.so — Richard Kilmer <rich@...>

We still encountered a gc_sweep in our use of Ruby 1.8 on Linux (v8).

16 messages 2003/11/24
[#1754] Re: gc_sweep under 1.8 ... not syck.so — ts <decoux@...> 2003/11/24

>>>>> "R" == Richard Kilmer <rich@infoether.com> writes:

[#1757] Re: gc_sweep under 1.8 ... not syck.so — Richard Kilmer <rich@...> 2003/11/24

Yes, there are several (Ruby) threads working during this gc_sweep.

[#1758] Re: gc_sweep under 1.8 ... not syck.so — ts <decoux@...> 2003/11/24

>>>>> "R" == Richard Kilmer <rich@infoether.com> writes:

[#1763] Re: gc_sweep under 1.8 ... not syck.so — Richard Kilmer <rich@...> 2003/11/24

of course this effects 300 machines ;-)

[#1755] Re: Controlled block variables — Jamis Buck <jgb3@...>

On Mon, 2003-11-24 at 02:04, T. Onoma wrote:

26 messages 2003/11/24
[#1756] Re: Controlled block variables — "T. Onoma" <transami@...> 2003/11/24

On Monday 24 November 2003 05:22 pm, Jamis Buck wrote:

[#1760] Re: Controlled block variables — Sean E Russell <ser@...> 2003/11/24

On Monday 24 November 2003 11:51, T. Onoma wrote:

[#1761] Re: Controlled block variables — "T. Onoma" <transami@...> 2003/11/24

On Monday 24 November 2003 06:40 pm, Sean E Russell wrote:

Re: Controlled block variables

From: Ryan Pavlik <rpav@...>
Date: 2003-11-26 01:53:19 UTC
List: ruby-core #1786
On Tue, 25 Nov 2003 01:51:36 +0900
"T. Onoma" <transami@runbox.com> wrote:

> On Monday 24 November 2003 05:22 pm, Jamis Buck wrote:
> > Hmm.  Couldn't you just do:
> >
> >   a = [ 1, 2, 3 ]
> >   eval "a"
> 
> In such a simple case, of course. But consider:
> 
>   a=[1,2,3]
>   eval "def z; p a; end;  z"
> 

I had a sudden inspiration with respect to this problem.  As others
have said, you wouldn't expect this to work in any case.  However, I
believe your ultimate goal is to put together code, so you can do
something like:

   a = [1, 2, 3]
   eval <<-END

     def foo(...)
        :
        munge(#{a})
        :
     end

   END

It's not really a matter of scope or not being able to put other
literals into code---these are just behaviors that prevent you from
doing this the way you're currently suggesting.  The real question is,
what do you _want_?  You want to take a predetermined value, and be
able to create a function or piece of code that uses this value at
some later date.

So, the trick is to just do what you want: store it.  Here's a quick
hack:

   class Ref
     @@id = Hash.new
   
     def initialize(ob)
       @@id[ob.__id__] = ob
       @ob             = ob
     end
   
     def to_s
       return "Ref[#{@ob.__id__}]"
     end

     def deref
       return @ob
     end
   
     def Ref::[](id)
       return @@id[id]
     end
   end

   # You could even do this:
   class Object
     def to_ref
       return Ref.new(self)
     end
   end

   a = [1, 2, 3].to_ref
   eval "def foo; p #{a}; end"

To say this is a bit of a hack is putting it gently, but it gets the
job done, it doesn't rely on redefining the core language, and it only
takes a few lines of code.

-- 
Ryan Pavlik <rpav@mephle.com>

"I'm pretty sure that 'Mr Pibb' and 'Dr Pepper' figure
 rather prominently in this scheme." - 8BT

In This Thread