[#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: open-uri patch, added progress_proc hook

From: Mathieu Bouchard <matju@...>
Date: 2003-11-27 23:04:29 UTC
List: ruby-core #1798
On Mon, 24 Nov 2003, T. Onoma wrote:

> On Sunday 23 November 2003 10:51 pm, Mathieu Bouchard wrote:
> > That's what LISP already had before most languages went into existence,
> > and that I've been dreaming about for Ruby, and that I've been begging
> > Matz to add to Ruby, since back when Ruby 1.6 was also a dream. Then I've
> > wrote several letters in favour of the inclusion of that feature, and
> > after receiving not enough approval, I abandoned those ideas, about two
> > years ago. At that moment I had a spec and half of an implementation.
> 
> Exactly! I actually worked up an interesting notion about it myself,
> where the whole of Ruby's syntax could be viewed as nested collections
> of duplicate-key ordered maps --this superset collection would then
> allow for subset views like array. So an assignment, i = true, for
> instance, is equavalent to :i => true. A statement without "assignemt"
> is annonymous, nack => print "A".

I don't have an assignment-centric view of that. I tend to organize all my
stuff into structs. I made my own metadata system to describe types in a
more detailed way than just using class names. The "schema" is a
specification for data exchange between "compiler components", that is,
any component that accepts or produces ruby code but not as a big string.

It is similar to Ruby's internal AST storage, except it's designed to be
convenient from the perspective of program that process code, whereas
Ruby's system is designed to be processed by Ruby's internals and nothing
else. (It uses pseudoobjects that aren't normally accessible from programs
written in Ruby)

> How did you approach it?

RubySchema.rb was the specification for ruby code structures:

http://www.ruby-lang.org/cgi-bin/cvsweb.cgi/~checkout~/lib/metaruby/RubySchema.rb?rev=1.14&content-type=text/plain

Type.rb was the specification for specifications in general:

http://www.ruby-lang.org/cgi-bin/cvsweb.cgi/lib/metaruby/Type.rb

and I was supposed to split RubySchema in two so that a subset of Ruby
could be factored out; that modularization of schemas would have helped
making more modular "compilers" and eliminate some forms of redundancy, as
several "compiler components" would instead process the "microruby
language" and there would be a ruby-to-microruby translator.

I stopped when I was rather close to having a conforming parser for Ruby
1.6 (I didn't write it, but I was modifying someone else's parser code).
[As we know, Ruby 1.8 is already slightly different.]

________________________________________________________________
Mathieu Bouchard                       http://artengine.ca/matju


In This Thread

Prev Next