[#1651] A min/max bug? — "Christoph" <chr_news@...>
Hi,
[#1690] Re: open-uri patch, added progress_proc hook — Elliott Hughes <ehughes@...>
In effect. I mean that if a method's interface is getting too complicated,
In article <AD4480A509455343AEFACCC231BA850F17C358@ukexchange>,
On Sun, Nov 16, 2003 at 07:51:42PM +0900, Tanaka Akira wrote:
[#1699] FileUtils bug and fix — Chad Fowler <chad@...>
As posted in ruby-talk:85349, I believe there is a bug in FileUtils.cp's
[#1706] gc_sweep in Ruby 1.8 — Richard Kilmer <rich@...>
I posted about this before but Matz wanted me to post more detail.
>>>>> "R" == Richard Kilmer <rich@infoether.com> writes:
[#1711] Re: open-uri patch, added progress_proc hook — "T. Onoma" <transami@...>
Tanaka Akira:
On Sunday 23 November 2003 07:12 pm, Mathieu Bouchard wrote:
On Sunday 23 November 2003 08:26 pm, Mathieu Bouchard wrote:
On Sunday 23 November 2003 09:32 pm, Mathieu Bouchard wrote:
On Sunday 23 November 2003 11:13 pm, Mathieu Bouchard wrote:
On Mon, Nov 24, 2003 at 05:32:09AM +0900, Mathieu Bouchard wrote:
[#1716] Re: open-uri patch, added progress_proc hook — "T. Onoma" <transami@...>
Tanaka Akira:
[#1718] Re: open-uri patch, added progress_proc hook — Elliott Hughes <ehughes@...>
In article <AD4480A509455343AEFACCC231BA850F17C434@ukexchange>,
On Saturday 22 November 2003 04:34 pm, Tanaka Akira wrote:
In article <200311221024.05642.transami@runbox.com>,
On Sunday 23 November 2003 02:24 am, Tanaka Akira wrote:
In article <200311230325.21687.transami@runbox.com>,
On Sunday 23 November 2003 03:10 pm, Tanaka Akira wrote:
In article <200311230648.41003.transami@runbox.com>,
On Monday 24 November 2003 03:19, Tanaka Akira wrote:
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).
>>>>> "R" == Richard Kilmer <rich@infoether.com> writes:
Yes, there are several (Ruby) threads working during this gc_sweep.
>>>>> "R" == Richard Kilmer <rich@infoether.com> writes:
of course this effects 300 machines ;-)
>>>>> "R" == Richard Kilmer <rich@infoether.com> writes:
The saga continues:
>>>>> "R" == Richard Kilmer <rich@infoether.com> writes:
There is a discussion (found by chad fowler) on ruby-dev (22000)
[#1755] Re: Controlled block variables — Jamis Buck <jgb3@...>
On Mon, 2003-11-24 at 02:04, T. Onoma wrote:
On Monday 24 November 2003 05:22 pm, Jamis Buck wrote:
On Monday 24 November 2003 11:51, T. Onoma wrote:
On Monday 24 November 2003 06:40 pm, Sean E Russell wrote:
On Tue, 25 Nov 2003, T. Onoma wrote:
On Monday 24 November 2003 14:02, T. Onoma wrote:
On Monday 24 November 2003 09:15 pm, Sean E Russell wrote:
[#1799] Syck install on Debian Standard (Ruby 1.6.7) — "T. Onoma" <transami@...>
Hi, I'm having some trouble installing Syck on Debain (woody). I'm not
On Friday 28 November 2003 09:17 am, T. Onoma wrote:
On Fri, Nov 28, 2003 at 05:22:48PM +0900, T. Onoma wrote:
[#1819] Re: configure.in: do not override CCDLDFLAGS, LDFLAGS, XLDFLAGS — Eric Sunshine <sunshine@...>
Hello,
Re: Controlled block variables
On Monday 24 November 2003 09:15 pm, Sean E Russell wrote:
"You take the blue pill, the story ends...you wake up in
your bed and believe whatever you want to believe. You take the
red pill, you stay in wonderland and I'll show you how deep the
rabbit hole goes." -- Morpheus
What are you saying Sean? That eval dosen't do what I'm asking it to do? Of
course not! If it did, I wouldn't here asking that it be made better by doing
so.
I think you are the One confused, for not seeing what could be, for what is.
It does not follow the current norms of evals scope, but as I have described
it: cutting holes though to the higher scope.
Would you like to see how far this rabbit hole goes? Or will you remain with
your limited "expectations"?
-t0
> I wouldn't expect this to work; it wouldn't even work if you rewrote it:
>
> eval "a = [1,2,3] ; def z ; p a ; end ; z"
>
> > argument there's no point in eval at all. Would you say the same thing
> > about:
> >
> > a = [1,2,3]
> > eval %Q{
> > def z
> > p "#{a}"
> > end
> > z
> > }
> >
> > Should that be 'wrong' b/c "this doesn't work in Ruby anyway. 'a' isn't
> > in scope inside the method."
>
> No. It isn't wrong at all. Scope doesn't enter into it.
>
> I think you're confusing string expansion, scoping, and late binding. #{a}
> isn't an eval() thing; it isn't a scoping thing. #{} doesn't have any
> special meaning to eval(). The string expansion is handled by the string
> class (or whatever), before the string ever gets to eval.
>
> That code works like I expect it to do: turn "a" into a string using to_s()
> and replace #{a} with the value -- THEN pass the result to eval().
>
> eval 'p a'
>
> and
>
> eval 'p #{a}'
>
> are two different things. In the first, 'a' is bound to the array in the
> eval environment. In the second, there is no 'a'.
>
> The Tick: "Spoon!"
> Neo: "There is no spoon."
>
> --- SER