[#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: "T. Onoma" <transami@...>
Date: 2003-11-25 05:10:54 UTC
List: ruby-core #1772
On Tuesday 25 November 2003 05:46 am, Dmitry V. Sabanin wrote:
> On Tuesday 25 November 2003 02:02, T. Onoma wrote:
> > No. Eval is for constructing code piecemeal with various variables, not
> > just to do what can already be done without it. But as it stands, one
> > must build literals within strings to accomplish such things. That's a
> > lot of extra work and makes for choppy ugly code.
>
> I think that eval just gives access to ruby interpreter itself in run-time.
> How could it behave differently from ruby then, if it _is_ ruby? That's
> just a needless ambiguity.
>
> > Of course, the above example dosen't really do what I want it to. For
> > that, I have to get fancy:
> >
> >   p "#{a.join(',')}"
>
> You can just do p "#{a.inspect}", as it works great with strings, arrays
> and hashish..oops..hashes :). Or you always can define a method, i.e.
> to_evil in String, Array, Hash, or in any other class you use in eval, and
> use it like #{a.to_evil}.
> As I see it, it's just ten lines or so.

Hey! That's a workable solution. Not quite as clean, but it works for me. 
Hmm...think i'll alias #i, or something small, for inspect. Nice.

> You can't change ruby behavior for things just to make it more comfortable
> for you, sometimes you have to change the way _you_ do it.

I wouldn't hold on to that argument too tightly, otherwise you might find 
yourself programming in Assemby ;)

But if you mean JUST ME, then I wouldn't. I suggested it b/c I thought it 
would be useful in general, and others might like to have it to. But your 
solution in concise enough. So it's all good.

BTW: This idea first came out of my considering, "what-if" all blocks were 
locally scoped-off, how would you get to variables outside? I thought of 
"holes". With a notation like:

  a = "hole"
  { "This is a block with a" + |a| + " in it." }

So when I was working with complex evals I kept thinking, "Ugh, I wish I had 
that."

Thanks!
-t0


In This Thread