ruby wish-list

A thought on current_block_yield and then the GC:

> It's not exactly the same, but couldn't you just define a
> recursive map function?
>
> class Array
> def map_r &block
> map{|e|Array===e ? e.map_r(&block) : block[e]}
> end
> end
> p [[1,2,[3]],[[[5],6],7],8].map_r{|e|e.to_s}
>
> => [["1", "2", ["3"]], [[["5"], "6"], "7"], "8"]

Though a little hackish, I wonder if you can receive a named block then
pass that block to itself, a la
def map_r &block
map{|e| block(e, &block) }
end
so that the block could itself call yield. But this would still be a
little harder than being able to say current_block, should it be doable.
Just thinking out loud.

A question on the GC.
So if you try and build a multi-threaded GC [one thread picks up on free
objects, hands them back to the parent thread for use], it turns out
that if you don't free memory, then my current GC does this:

1) you run out of freelist, so you call garbage_collect which spawns a
child thread, and adds to the heap so the parent can continue.
2) when the child thread terminates the heap is now in a larger state
than it was.
3) when it runs out of freelist again, it adds to the heap and spawns
the child thread. The child thread now takes longer to finish than it
did before. Meaning the parent will be adding more to heap while
waiting for it to finish.
4) repeat 3 over and over until you run out of memory.

So currently it doesn't free any memory ever [commented it out]. I'm
hoping that adding that capability will do the trick. If that doesn't
work, though, it seems possible for these two threads to become engaged
in a cycle, if you ever get above a certain threshold then basically it
will just eat up all the memory in the system as it takes longer and
longer to collect. So it exacerbates the problem.

Potential ways to beat this: never add to the heap during a garbage
collect?

Thoughts?
Thanks!
-R
--
Posted via http://www.ruby-forum.com/.

Rubbing the lamp....
I wish...

a = [1,2,3,4]

a[0..1, 4]

or

a[1,2,3]

worked.


-=R
--
Posted via http://www.ruby-forum.com/.

On Aug 14, 2:35=A0pm, Roger Pack <rogerpack2...@gmail.com> wrote:
> Rubbing the lamp....
> I wish...
>
> a =3D [1,2,3,4]
>
> a[0..1, 4]
>
> or
>
> a[1,2,3]
>
> worked.

Two things:

1) In my mind, this general thread is somewhat ridiculous. It's been
going on for -- what is it? -- ten months now? It seems to be just a
laundry list for things you want Ruby to do, whether they're sensible
or not, without a lot of thought into them, and at least sometimes
with reasoning like "I'm lazy and don't want to type some brackets".

2) "I wish X worked" is not a very useful way to describe what should
happen. I'm not saying you have to write tests or specs, but do
describe the behavior you expect. Maybe looking at the RubySpec
project will give you an idea of everything Ruby presently "should do"
and what the other implementations are working towards. If that
doesn't get you going, think about it as contributing to Rubinius in
some way, and the sooner that comes out the sooner you can easily
twist even more of Ruby to your desires.

When you're working on describing the behavior, consider this (from an
irb session in Ruby 1.8.6):

>> arr =3D (1..10).to_a
=3D> [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
>> arr[3,4]
=3D> [4, 5, 6, 7]

You seem to want arr[3,4] to return [4,5], and guess what? There's a
way to do that now:

>> arr.values_at(3,4)
=3D> [4, 5]

Let's say you don't care for Array#values_at and Array#[] is changed
to work as you expect. What will happen when someone who expects the
old behavior tries to use it?

--
-yossef

>> Oh, I wasn't understanding your idea, which does seem to make sense now.
>> There's the overhead of essentially duplicating the object space of the
>> original process in the fork (since mark will write to memory pages).
>> Maybe it would be worth this cost (esp. on a second processor) for the
>> benefit of not having to stop the main process?
...
> I'll probably hack it up sometime, first version as a straight patch to
> 1.8.6

Turns out that just increasing the malloc limit to 80MB or so gives a
nice decrease in GC time[1]--about 80% for me. So that's an easy stop
gap till I get this going. It does tend to use a lot more RAM, though,
unfortunately.

Question about typical VPN's: I assume that typically the bottleneck is
typically RAM and not CPU [ex: on 256MB slice], and they have access to
multiple cores where available, is that right?
Thanks!
-=R
[1] http://github.com/skaes/railsbench/tree/v0.8.3/GCPATCH
--
Posted via http://www.ruby-forum.com/.

>> > Assuming you mean Range#to_a (i.e. an instance rather that class
>> > method) I don't think it's becoming obsolete.
>>
>> It throws warnings as deprecated, for some reason.
>
> I don't think so:
>
> shadowfax:~/Documents/terralien/dltsolutions/enrollnow rick$ ruby1.9 -v
> ruby 1.9.0 (2007-10-25 patchlevel 0) [i686-darwin8.10.2]
> shadowfax:~/Documents/terralien/dltsolutions/enrollnow rick$ ruby1.9
> -we '(1..3).to_a'

Ahh I get it. Odd
>> S.find 1..6.to_a
(irb):19: warning: default `to_a' will be obsolete

I was confusing that for
>> S.find (1..6).to_a

which works as expected. Thanks for helping me figure that out. I have
no idea why 1..6.to_a doesn't raise an exception. Oh well.
Thanks.
-=R
--
Posted via http://www.ruby-forum.com/.

Mikael Høilund wrote:
> Perhaps a bit controversial, but I'd like to see a keyword for the
> �current block� as a way to refer to the Proc instance created inside
> that block. That would allow for recursive anonymous blocks like:
>
> [[1,2,[3]],[[[5],6],7],8].map { |e|
> Array === e ? e.map(&current_block) : e.to_s
> }

Appears maybe possible [Y combinator in Ruby]:
http://53cr.com/blog/2008/10/recursive-lambdas-in-ruby/
Cheers.
-=R
--
Posted via http://www.ruby-forum.com/.