[#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 Tue, 25 Nov 2003, T. Onoma wrote:
> On Monday 24 November 2003 06:40 pm, Sean E Russell wrote:
> > On Monday 24 November 2003 11:51, T. Onoma wrote:
> > > In such a simple case, of course. But consider:
> > >
> > > a=[1,2,3]
> > > eval "def z; p a; end; z"
> >
> > But... this doesn't work in Ruby anyway. 'a' isn't in scope inside the
> > method. Cut, paste, and run:
> >
> > a = [1,2,3]
> > def z
> > p a
> > end
> > z
> >
> > Why should method definitions in evals behave any differently?
>
> What's the point of having eval, then? Look at your example. By your argument
> there's no point in eval at all. Would you say the same thing about:
No, by Sean's argument there is no point having eval do some kind of
bizarre magical treatment, before it's even executed, of local
variables inside a scope that doesn't exist yet.
> 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. 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.
eval is not for constructing code piecemeal with various variables.
eval is for evaluating strings as code at runtime. If you wish to use
that facility for the purpose of constructing code piecemeal with
various variables, you may do so. But if a facility that evaluates
strings as code at runtime does not help you construct code piecemeal
with various variables, then you need to find another way to do it or
reconsider what you're doing.
eval is rather simple, and provides a functionality that exists in
many languages. The first thing that happens is that a string gets
created. Then it gets evaluated as code.
In your example, the string that gets created is:
def z
p [1,2,3]
end
z
Then it gets evaluated as code. The string does not, cannot, and must
not communicate some non-existent knowledge of the future scope of
what will be created once it's eval'd to eval.
You can't solve every programming issue by introducing a new feature
to the language, coming up with new (but usually already in-use)
syntax, or redefining concepts like runtime string evaluation to fit
one or two particular cases for which it isn't the right answer in the
first place.
> Of course, the above example dosen't really do what I want it to. For that, I
> have to get fancy:
>
> p "#{a.join(',')}"
>
> I don't like getting fancy.
I don't either, which is why I don't think it's good to resort right
out of the starting gate to syntax and core language changes. New
syntax and rules is not always the answer.
Speaking of "core language", I'm not sure what this is doing on this
list. It belongs on ruby-talk, or perhaps on a wiki somewhere.
So.... <http://www.rubygarden.org/ruby?EvalAndScope>. I honestly
think that's a better place for wide-ranging, open-ended, speculative
discussions of the nature of string evaluation and so on.
David
--
David A. Black
dblack@wobblini.net