[#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: Austin Ziegler <austin@...>
Date: 2003-11-28 15:56:05 UTC
List: ruby-core #1801
On Thu, 27 Nov 2003 08:34:14 +0900, Chad Fowler wrote:
> On Thu, 27 Nov 2003, Mathieu Bouchard wrote:
>> A classic of evaluating strings is evaluating SQL code, [...]
>> the "?" placeholder has been introduced specially for that
>> purpose. In this case, it's almost the same situation, but about
>> embedding Ruby code into Ruby code.
> There's a big conceptual difference between what is happening with
> SQL and what is happening when you eval something. I view the SQL
> scenario as being not much different than any other interpreter.
> Part of the difference is host/eval language differences (do you
> ever eval SQL inside an engine which is written in SQL?) but more
> importantly, eval'ing is generally (including the case of Ruby,
> something that is delegated from one piece of code back up to the
> engine which parsed itself. I don't see this as being related, but
> it's possible that I'm missing something.

I've been thinking about this, and I *would* like to see a way to do
"parameterized" eval.

Basically, when I did some work on RSS handling, I took some meta
code and parameterized it. It looks something like:

  ACCESSOR_METHODS = %Q{self.rss_<type>_list << "<symbol>"}

  def make_method(symbol, type) #:nodoc:
    module_eval ACCESSOR_METHODS.gsub(/<symbol>/, 
symbol.id2name).gsub(/<type>/, type)
  end

  def rss_element(*symbols) #:nodoc:
    symbols.each { |symbol| make_method(symbol, "element") }
  end

The children of this class would do something like:

  attr_accessor :foo
  rss_element   :foo

Now, this case is relatively simple, as I can simply do string
substitutions, but if I wanted anything more than a string
substitution, I'd have to do something more complex (perhaps
marshaling).

I'm not sure that I'd want to see:

  ACCESSOR_METHODS = %Q{self.rss_?_list << "?"}

  def rss_element(*symbols)
    symbols.each { |symbol|
      module_eval(ACCESSOR_METHODS, "element", symbol.id2name)
    end
  end

It wouldn't work, anyway, since ? is a valid character in Ruby for
three different contexts. But could there not be a way of doing
parameterized evals?

-austin
--
austin ziegler    * austin@halostatue.ca * Toronto, ON, Canada
software designer * pragmatic programmer * 2003.11.28
                                         * 08.29.55



In This Thread