My personal ruby wish-list (for any feedback):


1) the ability to rescue arrays (or some way to rescue multiple classes
without pain), like this:

all_socket_interrupts_array = [SocketError, Errno::EHOSTUNREACH,
Errno::ENETUNREACH]

begin
  # stuff
rescue all_socket_interrupts # non ugly, yet precise!

end

2) a GC that is 'user-definable' (run after this definable threshold,
this often), and (asidedbly), a GC that can run in its own (native)
thread so it doesn't pause execution of normal threads.

3) an ensure block that's uninterruptible, a la:

begin
 # do stuff
rescue
 # rescue stuff
ensure_uninterruptible # (or call it ensure_critical)
 # do stuff which is guaranteed to get run, and not interrupted.
end

4) the optional ability to have it display the whole backtrace on
uncaught exceptions (and also for all existing threads).

Guess that's it :)

Any thoughts?
Thanks.
-Roger
-- 
Posted via http://www.ruby-forum.com/.

Roger Pack wrote:
> My personal ruby wish-list (for any feedback):
> 
> 
> 1) the ability to rescue arrays (or some way to rescue multiple classes
> without pain), like this:
> 
> all_socket_interrupts_array = [SocketError, Errno::EHOSTUNREACH,
> Errno::ENETUNREACH]
> 
> begin
>   # stuff
> rescue all_socket_interrupts # non ugly, yet precise!
rescue *all_socket_interrupts_array => e

Should work, I think.  At least, it appears to under my brief tests...

-- 
Alex

Works great thanks Alex!

> > begin
> >   # stuff
> > rescue all_socket_interrupts # non ugly, yet precise!
>
> rescue *all_socket_interrupts_array => e
>
> Should work, I think.  At least, it appears to under my brief tests...
>
> --
> Alex

Hi,

In message "Re: ruby wish-list"
    on Mon, 15 Oct 2007 23:23:06 +0900, Roger Pack <rogerpack2005@gmail.com> writes:

|1) the ability to rescue arrays (or some way to rescue multiple classes
|without pain), like this:
|
|all_socket_interrupts_array = [SocketError, Errno::EHOSTUNREACH,
|Errno::ENETUNREACH]
|
|begin
|  # stuff
|rescue all_socket_interrupts # non ugly, yet precise!
|
|end

Now you know you can.

|2) a GC that is 'user-definable' (run after this definable threshold,
|this often), and (asidedbly), a GC that can run in its own (native)
|thread so it doesn't pause execution of normal threads.

I'd rather prefer smarter collector, but it's possible.

GC on its own thread is a different story.  Interaction between
collector and mutator may hinder the performance.

|3) an ensure block that's uninterruptible, a la:
|
|begin
| # do stuff
|rescue
| # rescue stuff
|ensure_uninterruptible # (or call it ensure_critical)
| # do stuff which is guaranteed to get run, and not interrupted.
|end

It's not as simple as you've expected.  First we need to define how
"uninterruptible" section work.

|4) the optional ability to have it display the whole backtrace on
|uncaught exceptions (and also for all existing threads).

Simple code like:

  begin
    ...
  rescue => e
    puts e.backtrace
  end

would do.

							matz.

Thanks Matz.
Comments on comments:

> |2) a GC that is 'user-definable' (run after this definable threshold,
> |this often), and (asidedbly), a GC that can run in its own (native)
> |thread so it doesn't pause execution of normal threads.
> 
> I'd rather prefer smarter collector, but it's possible.

Yeah a smarter collector would be even nicer.

> |ensure_uninterruptible # (or call it ensure_critical)
> 
> It's not as simple as you've expected.  First we need to define how
> "uninterruptible" section work.

I agree.  One definition would be to mark Thread.critical, then runs the 
block, then unmark.  I would use it :)

> |4) the optional ability to have it display the whole backtrace on
> |uncaught exceptions (and also for all existing threads).
> 
> Simple code like:
> 
>   begin
>     ...
>   rescue => e
>     puts e.backtrace
>   end
> 
> would do.
> 
>               matz.

Good point :) My suggestions are thinning down quickly :)
Thanks.
-Roger
-- 
Posted via http://www.ruby-forum.com/.

On 15.10.2007 17:24, Roger Pack wrote:
>> |ensure_uninterruptible # (or call it ensure_critical)
>>
>> It's not as simple as you've expected.  First we need to define how
>> "uninterruptible" section work.
> 
> I agree.  One definition would be to mark Thread.critical, then runs the 
> block, then unmark.  I would use it :)

Bad idea in light of native threads IMHO.  Every construct that halts 
all threads should be avoided.  If you need exclusive access to 
resources you need to proper synchronize on them.

> Good point :) My suggestions are thinning down quickly :)

:-)

Cheers

	robert

On 15.10.2007 18:45, Robert Klemme wrote:
> On 15.10.2007 17:24, Roger Pack wrote:
>>> |ensure_uninterruptible # (or call it ensure_critical)
>>>
>>> It's not as simple as you've expected.  First we need to define how
>>> "uninterruptible" section work.
>>
>> I agree.  One definition would be to mark Thread.critical, then runs 
>> the block, then unmark.  I would use it :)
> 
> Bad idea in light of native threads IMHO.  Every construct that halts 
> all threads should be avoided.  If you need exclusive access to 
> resources you need to proper synchronize on them.

I meant: in the light of the fact that native threads will come at a 
certain point in time.  Your suggested feature would make it 
unnecessarily complex and slow to use native threads (there would have 
to be regular synchronization on some hidden global lock, which defies 
the whole purpose of using (native) threads).

	robert

I don't really see the reason why the GC would need or want a specific thread to itself - for a start, such a design makes the system slower on low end systems. There may also be cases where it is possible to choose 'optimal' times to run the GC within a single thread context.

One thing regarding the GC I am unsure about are the conditions under which the GC is actually run. One not uncommon problem with external libraries (classic and common example is RMagick) do not malloc using the correct api, Ruby often fails to call the GC, at all.

A call to GC.start under these conditions can prevent an OOME, as calling GC.start does in fact cause RMagick to free memory - but ruby doesn't know about this.

The simplest solution to this issue I can see is to ensure that the GC is run when an OOME occurs, or more particularly, all loaded extensions are told to free when an OOME occurs (this does not seem to happen under these conditions). Whilst I know this is not really the responsibility of Ruby, this simple addition could solve problems for quite a number of scripts, thus removing a FAQ.

More regular GC runs may actually be sensible, depending on the real performance issues that might arise with longer running applications and fragmentation. A documented example of such a problem, and a solution is here: http://zdavatz.wordpress.com/2007/07/18/heap-fragmentation-in-a-long-running-ruby-process/

Robert Klemme wrote:
> On 15.10.2007 18:45, Robert Klemme wrote:
>> On 15.10.2007 17:24, Roger Pack wrote:
>>>> |ensure_uninterruptible # (or call it ensure_critical)
>>>>
>>>> It's not as simple as you've expected.  First we need to define how
>>>> "uninterruptible" section work.
>>>
>>> I agree.  One definition would be to mark Thread.critical, then runs 
>>> the block, then unmark.  I would use it :)
>>
>> Bad idea in light of native threads IMHO.  Every construct that halts 
>> all threads should be avoided.  If you need exclusive access to 
>> resources you need to proper synchronize on them.
> 
> I meant: in the light of the fact that native threads will come at a 
> certain point in time.  Your suggested feature would make it 
> unnecessarily complex and slow to use native threads (there would have 
> to be regular synchronization on some hidden global lock, which defies 
> the whole purpose of using (native) threads).
> 
>     robert
> 
> 

I agree.  Thinking out loud...with a true 'native' threaded model I 
don't know if it would be a spectacular idea to be able to block all 
threads.  I've often wondered how Ruby 1.9 will implement 
Thread.critical, at all.  If it does attempt to, then maybe this 
suggestion (though aimed mostly at 1.8.6) might still be useful (if you 
don't mind the possible slowdown).  If not then yeah--probably not worth 
the hassle :)

Other suggestions of how ensure_uninterruptable might work (like 'this 
thread doesn't accept interruptions [thread_name.raise's] for awhile') 
seem like even worse ideas.

The benefit of having such a feature in the first place would be that 
you can 'nest' timeouts and other code that executes 
other_thread_name.raise, without some dangerous issues cropping up when 
two raises occur very close to the same time.  Or basically that you can 
execute other_thread_name.raise on more complex code without the 
drawbacks that might occur.

An example of this is if you nest two timeouts one within another, and 
one happens to expire when the other is not finished processing its 
ensure block.  This will possibly cause a 'random' exception to be 
raised on the origin thread later.  I guess basically currently the use 
of other_thread_name.raise is dangerous, this would help that.

Just my $.02
Thought welcome.
-Roger


Robert Klemme wrote:
> On 15.10.2007 18:45, Robert Klemme wrote:
>> all threads should be avoided.  If you need exclusive access to 
>> resources you need to proper synchronize on them.
> 
> I meant: in the light of the fact that native threads will come at a
> certain point in time.  Your suggested feature would make it
> unnecessarily complex and slow to use native threads (there would have
> to be regular synchronization on some hidden global lock, which defies
> the whole purpose of using (native) threads).
> 
>   robert
-- 
Posted via http://www.ruby-forum.com/.

So you'd prefer a few tweaks:

> I don't really see the reason why the GC would need or want a specific 
> thread to itself - for a start, such a design makes the system slower on 
> low end systems. There may also be cases where it is possible to choose 
> 'optimal' times to run the GC within a single thread context.

So if it were someday created to run as a separate thread, you'd like to 
still be able to have a call 'GC.start.join' or what not, to let it 
finish during an 'optimal' time?



>...A call to GC.start under these conditions can prevent an OOME, or more 
> particularly, that all loaded extensions 
> are told to free when an OOME occurs

And you'd prefer a small change to the GC such that it also starts on 
OOME's, correct?


http://zdavatz.wordpress.com/2007/07/18/heap-fragmentation-in-a-long-running-ruby-process/
Wow I hope I never run into any memory issues like that!

Yeah those also sound reasonable :)
Wish lists have no bias :)
Take care.
-Roger
-- 
Posted via http://www.ruby-forum.com/.

Hey!

Not **quite** on topic of garbage collection.... But how hard would  
it be to create maybe a style of method creation that doesn't use  
the  . to represent Object.behavior ?

In retrospect, it seems like definitely a core language feature that  
may or may not be impossible to get at... But I figured I'd ask :-)


Also, Is there an easy/hard way to define new %{} style methods? Like  
for a Rope object, maybe %m{} or something.

Just a newbie's musings.

Thanks,
Ari
--------------------------------------------|
If you're not living on the edge,
then you're just wasting space.

Ari Brown wrote:
> Hey!
> 
> Not **quite** on topic of garbage collection.... But how hard would
> it be to create maybe a style of method creation that doesn't use
> the  . to represent Object.behavior ?
Define your code in the global namespace, like
def a
end
is a function a 'in the global namespace' -- no dots.
Maybe hard code in the parent class?
The way Rails does it is by say you do the command
my_special_class_function_one
if it doesn't exist it catches the error thrown for non-existence, looks 
up how and then defines the method and returns it (redefines things 
in-line).

> 
> In retrospect, it seems like definitely a core language feature that
> may or may not be impossible to get at... But I figured I'd ask :-)
> 
> 
> Also, Is there an easy/hard way to define new %{} style methods? Like
> for a Rope object, maybe %m{} or something.

Not sure.
GL!

> 
> Just a newbie's musings.
> 
> Thanks,
> Ari
> --------------------------------------------|
> If you're not living on the edge,
> then you're just wasting space.

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

On 10/15/07, Ari Brown <ari@aribrown.com> wrote:
>
> Also, Is there an easy/hard way to define new %{} style methods? Like
> for a Rope object, maybe %m{} or something.

This has come up before - I can't find the thread, but I believe the
answer was that it would hinder the ability to add new ones to the
core (since that could potentially break code that had already defined
it).

martin

GC wish list:
Isn't it possible to create your own reference checking style object? 
Would this be possible, for example.


Class Object

 attr_reader :internal_object # only used if you call 
new_with_timely_death_wrapper for your new call--see below
 def new_with_timely_death_wrapper class_to_use, *args
   @internal_object = class_to_use.new *args # since this object is 
'only internal' deleting it later will be OK
 end

 def assign_to_me this_wrapped_object
  dec
  @internal_object = this_wrapped_object.internal_object
  inc
 end

 def do_method name, *args
   eval("@internal_object.#{name} *args") # ok there's probably a better 
way :) maybe object.internal_object.do_whatever args
 end

def dec
  @internal_object.count -= 1
  recycle_current_object if count == 0
end

def inc
  @internal_object.count += 1
end

def recycle_current_object
   # traverse internal members of @internal_object--force_recycle them, 
unless they're wrappers, then just dec them.
   @internal_object.recycle
end

def inc
  @internal_object.count += 1
end

def go_out_of_scope
  dec
  self.force_recycle # we are toast :) -- this is scary and might not be 
right
end

end

Then the example:

a = Array.new_with_timely_death_wrapper(0,0)
b = Array.new_with_timely_death_wrapper(0,0)  # only time you should use 
assign is on start
b.assign_to_me a #recycle's b's object, assigns internal_object to a's 
internal_object.a, sets count to 2
a.go_out_of_scope # a set to 1
b.go_out_of_scope # a set to 0 -- recycled.

?
-- 
Posted via http://www.ruby-forum.com/.

Roger Pack wrote:
> GC wish list:

Another wish for Ruby would be the power to define ones own unary or 
binary operators.

Like I wish I could define "is_within?' for arrays, like
if element_x is_within? array_y
# do stuff
end

That would be sweet.  If such a thing were possible, then one could 
really create code that looks like complete sentences :)
My $.02 for the day.

-Roger
-- 
Posted via http://www.ruby-forum.com/.

Oh, wishing star! Here are my wishes:

1. Use "new" as the name of the constructor instead of "initialize". 
You can keep "initialize" around for legacy support; just "alias 
initialize new" for the future.

This makes it easy to connect the dots:  "SomeClass.new" actually calls 
the "new" instance method of a newly instantiated object of class 
SomeClass.


2. Fix the Ruby parser to treat // (literal regexp) just like the 
%r{...} (also literal regexp) construct so that you aren't forced to use 
parentheses in method calls:

  $ ruby -v
  ruby 1.8.6 (2007-03-13 patchlevel 0) [i686-linux]

  $ ruby -w -e '"foo".sub /o$/, "x"'
  -e:1: warning: ambiguous first argument; put parentheses or even 
spaces

  $ ruby -w -e '"foo".sub %r/o$/, "x"'
  [observe lack of warning]

This problem becomes especially apparent when you use gsub! or sub!:

  "foo".gsub! /o$/, "x"   # IMHO, sweet!

  "foo".gsub! %r/o$/, "x" # IMHO, so-so!

  "foo".gsub!(/o$/, "x")  # IMHO, ugly!

Thanks for your consideration.
-- 
Posted via http://www.ruby-forum.com/.

On Oct 19, 2007, at 5:09 PM, Roger Pack wrote:

> Roger Pack wrote:
>>
> Like I wish I could define "is_within?' for arrays, like
> if element_x is_within? array_y
> # do stuff
> end
>

That can't be done now?!?

arr = ['a', 'b']

if arr.include? 'a'
puts "array arr includes the letter 'a'"
end

should be easy to do it the other way as well.

cross-post from core:
After examining how the 1.8.6 gc works, I had a few thoughts:

Background:

It seems that on a 'cpu intensive' program (one that generates a lot of
discardable objects--quite common), there is a competition between two
aspects of the gc to call garbage_collect first.  They are:

1) If you run out of available heap slots ruby calls garbage_collect, 
and
if
"FREE_MIN" slots now exist (by default 4096) then it returns and leaves 
the heap the same size.  It also resets the current 'malloc'ed bytes' 
counter to 0, since it called garbage_collect.

2) If you reach GC_MALLOC_LIMIT of malloc'ed bytes, then it calls
garbage_collect, resets it to 0.

Anyway so what happens in today's implementations is that number 1 is
called often (I believe) preventing number 2 from ever even springing, 
as it
resets the current count of malloc'ed bytes.  It's like garbage_collect 
is
trying to serve 2 masters, and ends up serving just the one.  I see this 
as curious as it basically disallows GC_MALLOC_LIMIT from being reached, 
which is not what you would expect.


Thoughts?

On another point, I have a question on this line of code, run at the end
of garbage collection:
if (malloc_increase > malloc_limit) {
    malloc_limit += (malloc_increase - malloc_limit) * (double)live /
(live + freed); // this line
    if (malloc_limit < GC_MALLOC_LIMIT) malloc_limit = GC_MALLOC_LIMIT;
 }

I haven't checked this, but it seems to me that It seems to me that
(malloc_increase - malloc_limit) will always be a very small number (?)
which may not be what was expected.  I could be wrong.



So my question is "what should the GC do, and when?
Any thoughts?
In my opinion, if it runs out of heap slots available, it should call 
garbage_collect AND increase the heap size (so that next time it won't 
run out, and will have enough to hopefully reach GC_MALLOC_LIMIT).

I think when it does reach GC_MALLOC_LIMIT malloc'ed bytes, it should 
set it

new_malloc_limit = GC_MALLOC_LIMIT *
(1 - percent_of_recent_allocated_memory_that_was_freed)

to allow the malloc_limit to change dynamically, maybe with a fixed max 
size.

So my question is what should best happen?
Ruby rox.
-- 
Posted via http://www.ruby-forum.com/.

> Another wish for Ruby would be the power to define ones own unary or 
> binary operators.
> 
> Like I wish I could define "is_within?' for arrays, like
> if element_x is_within? array_y
> # do stuff
> end

I guess it is possible:

if element_x.is_within? array_y
# do stuff
end


Ruby is flexible enough again!

Another wish list item would be being able to use "a {var_name}" instead 
of "a #{var_name}" I hate that extra pound, as it reminds me of perl :)

Take care.
-Roger
-- 
Posted via http://www.ruby-forum.com/.

Suraj Kurapati wrote:

>   "foo".gsub! /o$/, "x"   # IMHO, sweet!
> 
>   "foo".gsub! %r/o$/, "x" # IMHO, so-so!
> 
>   "foo".gsub!(/o$/, "x")  # IMHO, ugly!
> 
> Thanks for your consideration.

I wonder if that fact that regex's always with have two /'s might 
help...


Now my own wish.  I wish ruby didn't need ,'s for method parameters. 
Why are they always necessary?
foo a b c # as long as a, b, and c aren't functions, and aren't 
operators, this could parse!
Take care.
-Roger
-- 
Posted via http://www.ruby-forum.com/.

> Take care.
> -Roger

I wish that ranges could be descending, like
(2000..1950)
and that Range.to_a wouldn't become obselete, as it seems quite useful 
in rails!
-- 
Posted via http://www.ruby-forum.com/.

On Nov 5, 2007, at 3:27 AM, Roger Pack wrote:

> Another wish list item would be being able to use "a {var_name}"  
> instead
> of "a #{var_name}" I hate that extra pound, as it reminds me of  
> perl :)

"a %s" % var_name

a @ http://codeforpeople.com/
--
it is not enough to be compassionate.  you must act.
h.h. the 14th dalai lama

On Nov 5, 2007, at 1:28 PM, Roger Pack wrote:

>
> I wonder if that fact that regex's always with have two /'s might
> help...
>

probably not - unless you wanted to introduce ';'s to ruby too:


cfp:~ > cat a.rb
x = 1

result =
x / 4 * 2 /
   42
p result

def x(*re) 'forty-two' end

result =
x / 4 * 2 /
   42
p result

result =
x(/ 4 * 2 /)
   42
p result


cfp:~ > ruby a.rb
0
0
"forty-two"



a @ http://codeforpeople.com/
--
share your knowledge.  it's a way to achieve immortality.
h.h. the 14th dalai lama

> 
> probably not - unless you wanted to introduce ';'s to ruby too:
> 
> 
> cfp:~ > cat a.rb
> x = 1
> 
> result =
> x / 4 * 2 /
>    42
> p result
> 

Dang that does seem ambiguous then.  Ahh well.

My latest wish is that
 unexpected $end, expecting kEND

would say something less cryptic--like "unexpected $end (end of file) 
expected word "end" "
-- 
Posted via http://www.ruby-forum.com/.

On 11/6/07, Roger Pack <rogerpack2005@gmail.com> wrote:
> > Take care.
> > -Roger
>
> I wish... that Range.to_a wouldn't become obselete, as it seems quite useful
> in rails!

Assuming you mean Range#to_a (i.e. an instance rather that class
method)  I don't think it's becoming obsolete.

There was talk some time ago when Matz changed 1.9 to use to_splat
instead of to_a that ranges wouldn't be splatted, e.g.

a = *(1..3)

In 1.8 this sets a to [1,2,3] whereas at one time in 1.9 it was to
have set it to [(1..3)].

But testing with a fairly recent irb1.9 this seems to be one of the
changes which has been backed out of 1.9.


-- 
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

>> I wish... that Range.to_a wouldn't become obselete, as it seems quite useful
>> in rails!
> 
> 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 like it!

And my latest wish
variables that can end in ?
Oh wishing star...
Take care all!
-Roger
-- 
Posted via http://www.ruby-forum.com/.

On Nov 11, 2007 1:13 AM, Roger Pack <rogerpack2005@gmail.com> wrote:
> >> I wish... that Range.to_a wouldn't become obselete, as it seems quite useful
> >> in rails!
> >
> > 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'
shadowfax:~/Documents/terralien/dltsolutions/enrollnow rick$ ruby1.9
-we 'p (1..3).to_a'
-e:1: warning: (...) interpreted as grouped expression
[1, 2, 3]
shadowfax:~/Documents/terralien/dltsolutions/enrollnow rick$ ruby1.9
-we 'p((1..3).to_a)'
[1, 2, 3]



-- 
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

"unless you wanted to introduce ';'s to ruby too:"

Hopefully a mandatory ; on the end of each line, as is the case with 
perl,
will NEVER appear in Ruby ... but then again who would wish for bad 
stuff ;-)


"variables that can end in ?"

I dont like this, mostly because we can use method calls such as
  dragon.hungry?

And I would not want to have a variable inside the dragon that
has something like ... i dont know

   hungry? = true

I'd rather have a variable that would state
  is_hungry = true

instead and then query if the dragon is hungry by using either
  is_hungry? or hungry?

(By the way, an accessor_read that can query variables with ? on the end 
would
be nice in std ruby too... I am not complaining at all, ruby is so 
flexible,
I already use this for my code and i love it, like @file.readable? that 
queries a "special" reader accessor... i think it reads nicer than 
@file.readable but this is just my opinion)


But I know what i would like to REALLY have:

  * real keyword arguments in 2.0

:-)
-- 
Posted via http://www.ruby-forum.com/.

> 
>   * real keyword arguments in 2.0
> 
> :-)

Not sure what those are.

My latest wish, oh wishing star...

(I think something in osx does this)

begin_funcion_name param1 keep_going_function_name param2 end

# so you can have your function calls read really like English

run_if_queue_below 24 every 24 seconds

yeah :)
Stay well.
-Roger
-- 
Posted via http://www.ruby-forum.com/.

Roger Pack wrote:
>> 
>>   * real keyword arguments in 2.0
>> 
>> :-)
> 
and the ability to parse .25 as a float, instead of 0.25 :)
-- 
Posted via http://www.ruby-forum.com/.

Marc Heiler wrote:
> (By the way, an accessor_read that can query variables with ? on the end 
> would be nice in std ruby too... I am not complaining at all, ruby is so 
> flexible, I already use this for my code and i love it, like @file.readable? 
> that queries a "special" reader accessor... i think it reads nicer than 
> @file.readable but this is just my opinion)

Do you mean that attr_accessor treats symbols with a question mark 
differently by creating a "symbol_without_question=" writer method and a 
"symbol_with_question" reader method?  For example:

  class Foo
    attr_acessor :readable?  # defines Foo#readable= and Foo#readable?
  end

  f = Foo.new
  f.readable? #=> nil
  f.readable = 99
  f.readable? #=> 99

This would be very useful, because it would make the following 
workaround obsolete:

  class Foo
    attr_writer :readable  # only defines Foo#readable=

    def readable?
      @readable
    end
  end

Oh wishing star, here is another wish for you! :-)
Thanks for your consideration.
-- 
Posted via http://www.ruby-forum.com/.

On Nov 15, 2007 11:48 AM, Suraj Kurapati <snk@gna.org> wrote:
> Marc Heiler wrote:
> > (By the way, an accessor_read that can query variables with ? on the end
> > would be nice in std ruby too... I am not complaining at all, ruby is so
> > flexible, I already use this for my code and i love it, like @file.readable?
> > that queries a "special" reader accessor... i think it reads nicer than
> > @file.readable but this is just my opinion)
>
> Do you mean that attr_accessor treats symbols with a question mark
> differently by creating a "symbol_without_question=" writer method and a
> "symbol_with_question" reader method?  For example:
>
>   class Foo
>     attr_acessor :readable?  # defines Foo#readable= and Foo#readable?
>   end
>
>   f = Foo.new
>   f.readable? #=> nil
>   f.readable = 99
>   f.readable? #=> 99
>
> This would be very useful, because it would make the following
> workaround obsolete:
>
>   class Foo
>     attr_writer :readable  # only defines Foo#readable=
>
>     def readable?
>       @readable
>     end
>   end
>
> Oh wishing star, here is another wish for you! :-)
> Thanks for your consideration.

I would think that you would want to maintain the ? behavior across
the board.  In other words, it should return TrueClass or FalseClass
objects.

Todd

Todd Benson wrote:
> I would think that you would want to maintain the ? behavior across
> the board.  In other words, it should return TrueClass or FalseClass
> objects.

Why?  In Ruby, anything that is neither nil nor false is the same as 
true...  I cannot express how many thousands of times this convention 
has simplified my code and eased my life!  Furthermore, like method 
aliases, this convention falls in line with Ruby's TIMTOWDI philosophy.

So, forcing question-mark methods to return only 'true' and 'false' 
feels far too restrictive and seems to follow a 
there's-only-one-way-to-do-it philosophy IMHO.
-- 
Posted via http://www.ruby-forum.com/.

Suraj Kurapati wrote:
> Todd Benson wrote:
>> I would think that you would want to maintain the ? behavior across
>> the board.  In other words, it should return TrueClass or FalseClass
>> objects.
> 
> Why?  In Ruby, anything that is neither nil nor false is the same as 
> true...  I cannot express how many thousands of times this convention 
> has simplified my code and eased my life!  Furthermore, like method 
> aliases, this convention falls in line with Ruby's TIMTOWDI philosophy.
> 
> So, forcing question-mark methods to return only 'true' and 'false' 
> feels far too restrictive and seems to follow a 
> there's-only-one-way-to-do-it philosophy IMHO.

Forcing would be bad, but there is the convention that foo? returns true 
vs. false, not something vs. nil.

If a foo? method happens to be returning something other than TrueClass, 
and you start depending on that quirk, you run the risk that a later 
version of that method returns some other non-nil/non-false  object.

It's similar to the use of foo!.   You don't *have* to use the bang only 
when your method is doing something destructive, but you'd be foolish 
not to follow the  conventions.



-- 
James Britt

"Programs must be written for people to read, and only incidentally
  for machines to execute."
   - H. Abelson and G. Sussman
   (in "The Structure and Interpretation of Computer Programs)

On Fri, 16 Nov 2007, Roger Pack wrote:

> My latest wish, oh wishing star...
>
> (I think something in osx does this)
>
> begin_funcion_name param1 keep_going_function_name param2 end
>
> # so you can have your function calls read really like English
>
> run_if_queue_below 24 every 24 seconds


def begin_funcion_name( param1, qualifier1, param2, qualifier1) {
}

run_if_queue_below 24, :every, 24, :seconds


--
-----------------------------------------------------------
   Tomas Pospisek
   http://sourcepole.com -  Linux & Open Source Solutions
-----------------------------------------------------------

On Nov 15, 2007 5:30 PM, James Britt <james.britt@gmail.com> wrote:
>
> Suraj Kurapati wrote:

> > So, forcing question-mark methods to return only 'true' and 'false'
> > feels far too restrictive and seems to follow a
> > there's-only-one-way-to-do-it philosophy IMHO.
>
> Forcing would be bad, but there is the convention that foo? returns true
> vs. false, not something vs. nil.

There is no such convention in Ruby.

> If a foo? method happens to be returning something other than TrueClass,
> and you start depending on that quirk, you run the risk that a later
> version of that method returns some other non-nil/non-false  object.

There ARE cases in the ruby language where a x? returns something
other than true or false

defined?(a) # => nil
a = 1
defined?(a) # => "local-variable"

By the way, you really meant true instead of TrueClass right?

The real danger is that you start testing 'truth' with expressions
like x == true or x == false.  As long as you don't do that and simply
use the value in conditional expressions like
  if x ...
  x ? ... : ...
and the like you'll be fine.

You rarely need an actual true/false value in Ruby.

For more on this see
http://www.therailsway.com/2007/8/1/dangers-of-cargo-culting


-- 
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

On Nov 15, 2007 5:48 PM, Suraj Kurapati <snk@gna.org> wrote:
> Marc Heiler wrote:
> > (By the way, an accessor_read that can query variables with ? on the end
> > would be nice in std ruby too... I am not complaining at all, ruby is so
> > flexible, I already use this for my code and i love it, like @file.readable?
> > that queries a "special" reader accessor... i think it reads nicer than
> > @file.readable but this is just my opinion)
>
> Do you mean that attr_accessor treats symbols with a question mark
> differently by creating a "symbol_without_question=" writer method and a
> "symbol_with_question" reader method?  For example:
>
>   class Foo
>     attr_acessor :readable?  # defines Foo#readable= and Foo#readable?
>   end
>
>   f = Foo.new
>   f.readable? #=> nil
>   f.readable = 99
>   f.readable? #=> 99
>
> This would be very useful, because it would make the following
> workaround obsolete:
>
>   class Foo
>     attr_writer :readable  # only defines Foo#readable=
>
>     def readable?
>       @readable
>     end
>   end
>
> Oh wishing star, here is another wish for you! :-)
> Thanks for your consideration.

Here you go (wouldn't use it myself though):

class Module
  # get a unique alias
  method_name = '__attr_accessor__#{rand(123456789)}__#{Time.now.to_i}'
  alias_method method_name, :attr_accessor

  define_method :attr_accessor do |name|
    name = name.to_s
    if name[-1] == ??
      sname = name[0..-2]
      attr_writer sname
      define_method "#{name}" do
        instance_variable_get "@#{sname}"
      end
    else
      send(method_name, name)
    end
  end
end


class Foo
  attr_accessor :readable?
  attr_accessor :bar
end

f = Foo.new
f.readable?                     # => nil
f.readable = 99                 # => 99
f.readable?                     # => 99

f.bar = 42                      # => 42

Regards,
Sean

On Nov 15, 2007 5:28 PM, Rick DeNatale <rick.denatale@gmail.com> wrote:
> On Nov 15, 2007 5:30 PM, James Britt <james.britt@gmail.com> wrote:
> >
> > Suraj Kurapati wrote:
>
> > > So, forcing question-mark methods to return only 'true' and 'false'
> > > feels far too restrictive and seems to follow a
> > > there's-only-one-way-to-do-it philosophy IMHO.
> >
> > Forcing would be bad, but there is the convention that foo? returns true
> > vs. false, not something vs. nil.
>
> There is no such convention in Ruby.

No convention in Ruby, but in Ruby programmers.

> > If a foo? method happens to be returning something other than TrueClass,
> > and you start depending on that quirk, you run the risk that a later
> > version of that method returns some other non-nil/non-false  object.
>
> There ARE cases in the ruby language where a x? returns something
> other than true or false

Yes, that's great!  No forcing, but just realizing that for your code
to work with others' requires some establishment of convention.  Ruby
is a weird and happy monster that way.  You can do almost anything
with it, but then when you want to do something with it, you start
setting down ground rules in order to play well with others.

> defined?(a) # => nil
> a = 1
> defined?(a) # => "local-variable"
>
> By the way, you really meant true instead of TrueClass right?

Well, that's kind of just semantics.  James may have meant an instance
of TrueClass, but didn't word it that way.

a=nil
(a==a).class
#=> TrueClass

>
> The real danger is that you start testing 'truth' with expressions
> like x == true or x == false.  As long as you don't do that and simply
> use the value in conditional expressions like
>   if x ...
>   x ? ... : ...
> and the like you'll be fine.
>
> You rarely need an actual true/false value in Ruby.

To newbies, this statement doesn't make much sense, but I do
understand where you're coming from.  Newbies should definitely learn
that in a conditional, thinks are not always what they seem (and I
love it!).

a = 1
b = 2
a if b

> For more on this see
> http://www.therailsway.com/2007/8/1/dangers-of-cargo-culting

I didn't know this acquired the euphemism "cargo-culting".  I still
thought it was called "script kiddies".  I must be getting old :-)

> --
> Rick DeNatale
>
> My blog on Ruby
> http://talklikeaduck.denhaven2.com/
>
>

Todd

>> run_if_queue_below 24 every 24 seconds
> 
> 
> def begin_funcion_name( param1, qualifier1, param2, qualifier1) {
> }
> 
> run_if_queue_below 24, :every, 24, :seconds
> 
> 
> --
Clever.  I like it.
-Roger
-- 
Posted via http://www.ruby-forum.com/.

Todd Benson wrote:
> On Nov 15, 2007 5:28 PM, Rick DeNatale <rick.denatale@gmail.com> wrote:
>> On Nov 15, 2007 5:30 PM, James Britt <james.britt@gmail.com> wrote:
>>> Suraj Kurapati wrote:
>>>> So, forcing question-mark methods to return only 'true' and 'false'
>>>> feels far too restrictive and seems to follow a
>>>> there's-only-one-way-to-do-it philosophy IMHO.
>>> Forcing would be bad, but there is the convention that foo? returns true
>>> vs. false, not something vs. nil.
>> There is no such convention in Ruby.
> 
> No convention in Ruby, but in Ruby programmers.

Right.  And in a TIMTOWTDI language is can amount to the same thing.

> 
>>> If a foo? method happens to be returning something other than TrueClass,
>>> and you start depending on that quirk, you run the risk that a later
>>> version of that method returns some other non-nil/non-false  object.
>> There ARE cases in the ruby language where a x? returns something
>> other than true or false
> 
> Yes, that's great!  No forcing, but just realizing that for your code
> to work with others' requires some establishment of convention.  Ruby
> is a weird and happy monster that way.  You can do almost anything
> with it, but then when you want to do something with it, you start
> setting down ground rules in order to play well with others.

Exactly.    Yes, there are exceptions, and yes that can be handy, but 
(culturally speaking) treating foo? as an attribute accessor is probably 
a mistake because you may be relying on a quirk of implementation.

Since *every* method could be used as a boolean value, the use of  '?' 
should be reserved to expressed a particular meaning, i.e., all this 
method assures you is that you'll get a return value than can be 
interpreted as true or false, and is not meant to be an object accessors.


> 
>> defined?(a) # => nil
>> a = 1
>> defined?(a) # => "local-variable"
>>
>> By the way, you really meant true instead of TrueClass right?
> 
> Well, that's kind of just semantics.  James may have meant an instance
> of TrueClass, but didn't word it that way.


Yes, thank you. I meant not simply true (i.e., something that is not 
nil), but "only" true (and not some particular object you are relying on 
to have a secondary value).



-- 
James Britt

"Programs must be written for people to read, and only incidentally
  for machines to execute."
   - H. Abelson and G. Sussman
   (in "The Structure and Interpretation of Computer Programs)

James Britt wrote:
> you'll get a return value than can be interpreted as true or false
                                        ^^^^^^^^^^^

Bingo!  I don't want to restrict the return values of question-mark 
methods to only true and false because I see nothing special about 
'true' and 'false'.  In my mind, they are just objects that just happen 
to have some useful equivalents when evaluated in a boolean context. 
And that's the key point here: context.

Who cares what the type/class of an object really is, so long as the 
object can be *interpreted* in a meaningful way in the particular usage 
context?  Sounds like the fundamental concept of duck typing to me. :-)
-- 
Posted via http://www.ruby-forum.com/.

Suraj Kurapati wrote:
> James Britt wrote:
>> you'll get a return value than can be interpreted as true or false
>                                         ^^^^^^^^^^^
> 
> Bingo!  I don't want to restrict the return values of question-mark 
> methods to only true and false because I see nothing special about 
> 'true' and 'false'.  In my mind, they are just objects that just happen 
> to have some useful equivalents when evaluated in a boolean context. 
> And that's the key point here: context.
> 
> Who cares what the type/class of an object really is, so long as the 
> object can be *interpreted* in a meaningful way in the particular usage 
> context?  Sounds like the fundamental concept of duck typing to me. :-)

This is what I'm warning against:

# First release of some library API
def account?
   @account
end

# In some naive end-user's code:
@a.cancel if @a = foo.account?

# Later release of library API, after some internal changes
def account?
   parent_has_account_and_is_active?
end


Now, what happens to the end user's code?

'account?' is still meaningful as a true/false indicator method; code 
(mistakenly) relying on a more meaningful return object may get a 
surprise one day.

I'm arguing that methods that end in "?" should be designed and used as 
answers to true/false  or yes/no questions.  That they can return an 
arbitrary non-nil object to indicate 'true' is convenient, but I'm 
skeptical of the value of "?" methods being used as both boolean 
indicators *and* object accessors.

Its a matter of hiding implementation details, and self-documenting code.

Now, should one do this?

def account?
   @account ? true : false
end


Well, maybe; it might keep end-users from trying to be too clever.

But I don't think it should be baked into the language.


-- 
James Britt

"Programs must be written for people to read, and only incidentally
  for machines to execute."
   - H. Abelson and G. Sussman
   (in "The Structure and Interpretation of Computer Programs)

On Nov 15, 2007 10:29 PM, Suraj Kurapati <snk@gna.org> wrote:
> James Britt wrote:
> > you'll get a return value than can be interpreted as true or false
>                                         ^^^^^^^^^^^
>
> Bingo!  I don't want to restrict the return values of question-mark
> methods to only true and false because I see nothing special about
> 'true' and 'false'.  In my mind, they are just objects that just happen
> to have some useful equivalents when evaluated in a boolean context.
> And that's the key point here: context.
>
> Who cares what the type/class of an object really is, so long as the
> object can be *interpreted* in a meaningful way in the particular usage
> context?  Sounds like the fundamental concept of duck typing to me. :-)

I'm out of my league here (again), but I should mention that even
though we enjoy/love the flexibility of the Ruby language, that
freeness comes with a modicum of responsibility.

If you start turning ? into a Fixnum (i.e. that's what the #whatever?
method returns), you've started to turn a duck in to a goose (or cat,
dog, whatever).  Hey, whatever floats your boat...

I can't think of one single reason for a variable/accessor to have a ?
on the end of it.

Todd

On Nov 16, 2007 3:04 AM, Todd Benson <caduceass@gmail.com> wrote:
>
> On Nov 15, 2007 10:29 PM, Suraj Kurapati <snk@gna.org> wrote:
> > James Britt wrote:
> > > you'll get a return value than can be interpreted as true or false
> >                                         ^^^^^^^^^^^
> >
> > Bingo!  I don't want to restrict the return values of question-mark
> > methods to only true and false because I see nothing special about
> > 'true' and 'false'.  In my mind, they are just objects that just happen
> > to have some useful equivalents when evaluated in a boolean context.
> > And that's the key point here: context.
> >
> > Who cares what the type/class of an object really is, so long as the
> > object can be *interpreted* in a meaningful way in the particular usage
> > context?  Sounds like the fundamental concept of duck typing to me. :-)
>
> I'm out of my league here (again), but I should mention that even
> though we enjoy/love the flexibility of the Ruby language, that
> freeness comes with a modicum of responsibility.
>
> If you start turning ? into a Fixnum (i.e. that's what the #whatever?
> method returns), you've started to turn a duck in to a goose (or cat,
> dog, whatever).  Hey, whatever floats your boat...
>
> I can't think of one single reason for a variable/accessor to have a ?
> on the end of it.

I'll add more noise and clarify a little.  I think James made a very
succinct point.  Useful at times, yes; should be baked into the
language, umm, probably not.  The ? trailing symbol can be seen
several different ways.  I tend to agree with others that it should
give me something I can count on (TrueClass or FalseClass).  If people
want to mess with that ... I can adapt; no big deal.

But, if you do, you kind of open pandora's box, because then we might
have to start questioning every object before we can ask it to do
something (be it true, false, nil, fixnum, string, etc).  I'm willing
to do that, but I don't think that is a healthy way to program.

Todd

James Britt wrote:
> Suraj Kurapati wrote:
>> Who cares what the type/class of an object really is, so long as the 
>> object can be *interpreted* in a meaningful way in the particular usage 
>> context?  Sounds like the fundamental concept of duck typing to me. :-)
> 
> This is what I'm warning against:
> 
> # First release of some library API
> def account?
>    @account
> end
> 
> # In some naive end-user's code:
> @a.cancel if @a = foo.account?

Naive indeed.  Why would anybody use a question mark method in that way? 
They are only meant to be used in boolean contexts.

I think the convention lies not in what the return value of a 
question-mark method is, but in what way the return value is used:

if foo.account?
  foo.account.cancel
end

> # Later release of library API, after some internal changes
> def account?
>    parent_has_account_and_is_active?
> end
> 
> 
> Now, what happens to the end user's code?
> 
> 'account?' is still meaningful as a true/false indicator method; code
> (mistakenly) relying on a more meaningful return object may get a
> surprise one day.

Exactly.  That was foolishness on the user's part.

> I'm arguing that methods that end in "?" should be designed and used as
> answers to true/false  or yes/no questions.  That they can return an
> arbitrary non-nil object to indicate 'true' is convenient, but I'm
> skeptical of the value of "?" methods being used as both boolean
> indicators *and* object accessors.

Ah, now I understand your point.  I never considered them being used as 
object accessors because you would never know it was an object accessor 
just by looking at the method name.

foo.account? does not appear like an attr_reader because of the 
question-mark.

> Its a matter of hiding implementation details, and self-documenting 
> code.
> 
> Now, should one do this?
> 
> def account?
>    @account ? true : false
> end

Yuck!  No way.  This is what I was arguing against.  No forcing of 
return value to be true/false only.

> Well, maybe; it might keep end-users from trying to be too clever.

I don't see how they can be clever *unless* they look at the underlying 
implementation of your classes.  When I see the name of a question-mark 
method, I think "this method answers a yes/no question".  There is no 
way I would think otherwise unless I was given insider information about 
the method's implementation.

> But I don't think it should be baked into the language.

I think the "accessor" in attr_accessor might have mislead you guys 
about this whole question-mark argument.
-- 
Posted via http://www.ruby-forum.com/.

Suraj Kurapati wrote:
> I think the convention lies not in what the return value of a 
> question-mark method is, but in what way the return value is used:
> 
> if foo.account?
>   foo.account.cancel
> end

Whoops, that is a bad example.  Try this one instead:

if foo.account?
  # do something...
end
-- 
Posted via http://www.ruby-forum.com/.

> I'm arguing that methods that end in "?" should be designed and used as
> answers to true/false  or yes/no questions.  That they can return an
> arbitrary non-nil object to indicate 'true' is convenient, but I'm
> skeptical of the value of "?" methods being used as both boolean
> indicators *and* object accessors.
> 
> Its a matter of hiding implementation details, and self-documenting 
> code.

Yeah--I'd be in favor that anything that ends in ? be something that can 
be evaluated as nil/non-nil (and hence having a 'boolean-only' variable 
that ends with ? would be the same effect, hence my wishing that 
variables could end in ?.  Then you wouldn't have to create wrappers for 
them.  My $0.02)
-- 
Posted via http://www.ruby-forum.com/.

On Nov 16, 2007 9:26 AM, Roger Pack <rogerpack2005@gmail.com> wrote:
> > I'm arguing that methods that end in "?" should be designed and used as
> > answers to true/false  or yes/no questions.  That they can return an
> > arbitrary non-nil object to indicate 'true' is convenient, but I'm
> > skeptical of the value of "?" methods being used as both boolean
> > indicators *and* object accessors.
> >
> > Its a matter of hiding implementation details, and self-documenting
> > code.
>
> Yeah--I'd be in favor that anything that ends in ? be something that can
> be evaluated as nil/non-nil (and hence having a 'boolean-only' variable
> that ends with ? would be the same effect, hence my wishing that
> variables could end in ?.  Then you wouldn't have to create wrappers for
> them.  My $0.02)
>

Like I said before, I can see the utility of such a thing, but the ?
symbol is sort of special.  In other words, I don't see it useful to
add functionality to Ruby that makes the ? symbol equal to whether a
variable/accessor exists or not.  It doesn't fit for me.  Maybe
another symbol/word?

Todd

My latest wish for the wishing tree...
that if you used a variable
@not_yet_defined
that it would throw an error.  I think it would help avoid a few bugs.
My daily $.02 for free :)
-Roger
-- 
Posted via http://www.ruby-forum.com/.

On Nov 29, 9:28 pm, Roger Pack <rogerpack2...@gmail.com> wrote:
> My latest wish for the wishing tree...
> that if you used a variable
> @not_yet_defined
> that it would throw an error.  I think it would help avoid a few bugs.
> My daily $.02 for free :)
> -Roger

mmm... probably too few to be too worried about it though ?

i have one for you, since were throw'n them out. i wish "@" was a
hash.

  x = "a"
  @[x] = 1

  @a  #=> 1

  @.each do |k,v|
    "just another instance var #{k} = #{v}"
  end

  #=> just another instance var a = 1

T.

On Fri, 30 Nov 2007 12:06:18 +0900, Trans <transfire@gmail.com> wrote:

> i have one for you, since were throw'n them out. i wish "@" was a
> hash.
>
>   x =3D "a"
>   @[x] =3D 1
>
>   @a  #=3D> 1
>
>   @.each do |k,v|
>     "just another instance var #{k} =3D #{v}"
>   end
>
>   #=3D> just another instance var a =3D 1
>
> T.
>
>

You can already do that
irb(main):001:0>  @a =3D 1
=3D> 1
irb(main):002:0> instance_variables.each do |k|
irb(main):003:1*  v =3D instance_variable_get(k)
irb(main):004:1>  puts "just another instance var #{k} =3D #{v}"
irb(main):005:1> end
just another instance var @a =3D 1
=3D> ["@a"]

On Nov 29, 10:16 pm, "Paul McMahon" <p...@ubit.com> wrote:
> On Fri, 30 Nov 2007 12:06:18 +0900, Trans <transf...@gmail.com> wrote:
> > i have one for you, since were throw'n them out. i wish "@" was a
> > hash.
>
> >   x = "a"
> >   @[x] = 1
>
> >   @a  #=> 1
>
> >   @.each do |k,v|
> >     "just another instance var #{k} = #{v}"
> >   end
>
> >   #=> just another instance var a = 1
>
> > T.
>
> You can already do that
> irb(main):001:0>  @a = 1
> => 1
> irb(main):002:0> instance_variables.each do |k|
> irb(main):003:1*  v = instance_variable_get(k)
> irb(main):004:1>  puts "just another instance var #{k} = #{v}"
> irb(main):005:1> end
> just another instance var @a = 1
> => ["@a"]

Really? That's amazing! ;)

T.

My biggest wish list currently is...I wish I didn't have to use # within 
strings--just braces.  That would ruby-like in elegance, in my opinion, 
and (I think) parsable.
Thoughts?
-Roger

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

On Jan 9, 2008 2:37 PM, Roger Pack <rogerpack2005@gmail.com> wrote:
> My biggest wish list currently is...I wish I didn't have to use # within
> strings--just braces.  That would ruby-like in elegance, in my opinion,
> and (I think) parsable.
> Thoughts?
> -Roger
>
>

I think bare braces are too common in strings to force backslashing
them all over the place, whereas the character sequence #{ almost
never shows up. Plus, it would be a mess every time you wanted to,
say, eval() a string that includes a block.

-A

> I think bare braces are too common in strings to force backslashing
> them all over the place, whereas the character sequence #{ almost
> never shows up. Plus, it would be a mess every time you wanted to,
> say, eval() a string that includes a block.
I'd use them (well, I never use eval maybe that's why)

Next wish for the magic lamp:
a command that does something like
module X
 CONSTANT = '3'
 def class_function
 end
end

class Y
 extend_and_include_constants X # this one
end
 :)
-- 
Posted via http://www.ruby-forum.com/.

2008/1/21, Roger Pack <rogerpack2005@gmail.com>:
> Next wish for the magic lamp:
> a command that does something like
> module X
>  CONSTANT = '3'
>  def class_function
>  end
> end
>
> class Y
>  extend_and_include_constants X # this one
> end

That's not too hard.  All the ingredients are there already:

irb(main):001:0> class Module
irb(main):002:1>   def your_extend(mod)
irb(main):003:2>     extend mod
irb(main):004:2>     mod.constants.each do |co|
irb(main):005:3*       const_set(co, mod.const_get(co))
irb(main):006:3>     end
irb(main):007:2>   end
irb(main):008:1> end
=> nil
irb(main):009:0> module X
irb(main):010:1>   Foo = 2
irb(main):011:1>   def mm; 1; end
irb(main):012:1> end
=> nil
irb(main):013:0> class Y
irb(main):014:1>   your_extend X
irb(main):015:1> end
=> ["Foo"]
irb(main):016:0> Y.mm
=> 1
irb(main):017:0> Y::Foo
=> 2

Cheers

robert

-- 
use.inject do |as, often| as.you_can - without end

Robert Klemme wrote:
> irb(main):001:0> class Module
> irb(main):002:1>   def your_extend(mod)
> irb(main):003:2>     extend mod
> irb(main):004:2>     mod.constants.each do |co|
> irb(main):005:3*       const_set(co, mod.const_get(co))
> irb(main):006:3>     end
> irb(main):007:2>   end
> irb(main):008:1> end
> => nil
wow
Thanks!
-- 
Posted via http://www.ruby-forum.com/.

I know this is controversial, but I wish that if you did
string_1 + object_2 (or any object) that it would just call .to_s on 
object_2 (instead of having to write it explicitly).  I hate having to 
write extra .to_s's (even if it avoids ambiguity).  That's just me, but 
hey :)
Take care.
-Roger
-- 
Posted via http://www.ruby-forum.com/.

Chad Perrin wrote:
> On Thu, Jan 31, 2008 at 04:34:49AM +0900, Roger Pack wrote:
>> I know this is controversial, but I wish that if you did
>> string_1 + object_2 (or any object) that it would just call .to_s on 
referent to
'a' + 3
which, if I had my wish, would automatically be 'a' + 3.to_s

> Seems like it already does what you want.  What am I missing?

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

On Jan 30, 12:34=A0pm, Roger Pack <rogerpack2...@gmail.com> wrote:
> I know this is controversial, but I wish that if you did
> string_1 + object_2 (or any object) that it would just call .to_s on
> object_2 (instead of having to write it explicitly). =A0I hate having to
> write extra .to_s's (even if it avoids ambiguity). =A0That's just me, but
> hey :)

Having provided support on a #javascript IRC channel for years, I can
say that one of the most common errors and questions among users
(particularly when they were working with input from forms) was: "Why
is 1 + 1 =3D=3D 11???"

JavaScript and Ruby are both dynamically typed. JavaScript, however,
is somewhat loosely typed; it performs some automatic 'helpful'
conversion from one data type to another. Ruby is more strongly typed,
requiring you to be explicit about type conversion, most of the time.

I like Ruby's balance. It's not so strong that you have to do things
like "Hello #{person.to_str}", but not so loose that you see many
1+"1" =3D=3D "11" types of errors.

> On Thu, Jan 31, 2008 at 09:06:05AM +0900, Roger Pack wrote:

Another wish--I wish that the block style stuff was invertable.
programs.each_with_index {|program, index|...}

would work with

for program, index in programs.each_with_index {}

Then you wouldn't have to remember syntax again, ever :)
Take care.
-Roger
-- 
Posted via http://www.ruby-forum.com/.

On 04.02.2008 20:52, Roger Pack wrote:
>> On Thu, Jan 31, 2008 at 09:06:05AM +0900, Roger Pack wrote:
> 
> Another wish--I wish that the block style stuff was invertable.
> programs.each_with_index {|program, index|...}
> 
> would work with
> 
> for program, index in programs.each_with_index {}

Like

$ irb -r enumerator
irb(main):001:0> programs = %w{foo bar}
=> ["foo", "bar"]
irb(main):002:0> for p,i in programs.to_enum(:each_with_index)
irb(main):003:1> puts p, i
irb(main):004:1> end
foo
0
bar
1
=> ["foo", "bar"]

?

> Then you wouldn't have to remember syntax again, ever :)

I don't see the difference - I mean, you have to remember both ways, 
don't you?

Cheers

	robert

> irb(main):002:0> for p,i in programs.to_enum(:each_with_index)
> irb(main):003:1> puts p, i
> irb(main):004:1> end

nice

>> Then you wouldn't have to remember syntax again, ever :)
> 
> I don't see the difference - I mean, you have to remember both ways,
> don't you?

perhaps with this way you can 'always' use one way, if you have any 
question of which would work.
Just thinking out loud.
Thanks for your timely reply.
-Roger
-- 
Posted via http://www.ruby-forum.com/.

Hi,

At Tue, 5 Feb 2008 05:44:58 +0900,
Robert Klemme wrote in [ruby-talk:289837]:
> $ irb -r enumerator
> irb(main):001:0> programs = %w{foo bar}
> => ["foo", "bar"]
> irb(main):002:0> for p,i in programs.to_enum(:each_with_index)
> irb(main):003:1> puts p, i
> irb(main):004:1> end

FYI, in 1.9 each_with_index returns an Enumerator (which is
built-in now) if no block is given, so you don't need to_enum
here.

  for p, i in programs.each_with_index
    puts p, i
  end

-- 
Nobu Nakada

Nobuyoshi Nakada wrote:

> FYI, in 1.9 each_with_index returns an Enumerator (which is
> built-in now) if no block is given, so you don't need to_enum
> here.
> 
>   for p, i in programs.each_with_index
>     puts p, i
>   end

Wow my wish come true :) Now I've had two come true.  Thank you.
-Roger
-- 
Posted via http://www.ruby-forum.com/.

Is it possible to easily strip arbitrary characters off a string?
a la "abc:".strip ':'
?
it looks like it's possible with gsub
abc:'.gsub(/:$/, '')
however the wish is a simpler function for it.

If not then it goes on the wish list.

Thanks.  Sorry to ramble on.
-Roger
-- 
Posted via http://www.ruby-forum.com/.

Roger Pack wrote:
> Is it possible to easily strip arbitrary characters off a string?
> a la "abc:".strip ':'
> ?
> it looks like it's possible with gsub
> abc:'.gsub(/:$/, '')
> however the wish is a simpler function for it.
> 
> If not then it goes on the wish list.
> 
> Thanks.  Sorry to ramble on.
> -Roger

"abc:".chomp(":")
or
"abc:".chomp!(":")

Regards,

Siep
-- 
Posted via http://www.ruby-forum.com/.

Chad Perrin wrote:
> On Wed, Feb 06, 2008 at 05:30:06AM +0900, Siep Korteling wrote:
>> > Thanks.  Sorry to ramble on.
>> > -Roger
>> 
>> "abc:".chomp(":")
>> or
>> "abc:".chomp!(":")
> 
> Note: That only works if the character you want to strip away is the 
> last
> character in the string.  When you don't supply an argument, it removes
> only any newline character at the end of the string, e.g.:
(...)
Yes. Well you can chop off any substring with chomp("any string").
If "strip" means delete all occurances of a substring, there is uhm, 
delete.
"a:bc:".delete(":")
=> "abc"


Regards,

Siep
-- 
Posted via http://www.ruby-forum.com/.

> Now my own wish.  I wish ruby didn't need ,'s for method parameters. 
> Why are they always necessary?
> foo a b c # as long as a, b, and c aren't functions, and aren't 
> operators, this could parse!
Or could it?  Still wishing for this one sigh :)
-Roger

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

All right magic genie--my next request! (from Aladdin movie)
Better syntax and expanded coolness for hashes.
Like multi-map hashes, ordered hashes (in 1.9?),
better normal hash syntax for
hash['a'] = true
hash -= 'a' # instead of delete
or maybe not even use brackets at all--they confuse with their 
similarity to arrays.
Thoughts?
-Roger
-- 
Posted via http://www.ruby-forum.com/.

On Feb 13, 2008, at 2:56 PM, Roger Pack wrote:
> or maybe not even use brackets at all--they confuse with their
> similarity to arrays.
> Thoughts?

I tend to define [] and []= whenever possible if the object behaves  
like an indexed collection of objects.  I think this helps with duck- 
typing.  If every collection had a different manner of indexing items  
it would defeat any duck-typing.

Less common, but also useful is to provide fetch/store in addition to  
[] and []=.  The fetch API is nice when you want to substitute a  
different default value:

  fetch(index)        # get item or raise exception
  fetch(index, miss)  # get item or return miss
  fetch(index) { }    # get item or compute miss

Gary Wright

> I tend to define [] and []= whenever possible if the object behaves
> like an indexed collection of objects.  I think this helps with duck-
> typing.  If every collection had a different manner of indexing items
> it would defeat any duck-typing.

Interesting.  Is there a common delete api?
Cheers.
=roger
-- 
Posted via http://www.ruby-forum.com/.

Roger Pack wrote:
> hash -= 'a' # instead of delete

That would be the same as

  hash = hash - 'a'

so (whatever Hash#- does) it involves making a copy of the hash and 
changing that instead, whereas #delete is destructive.

-- 
        vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

On Feb 13, 2008 2:32 PM, Joel VanderWerf <vjoel@path.berkeley.edu> wrote:
> so (whatever Hash#- does) it involves making a copy of the hash and
> changing that instead, whereas #delete is destructive.

Which means if you use #- you're creating a new object and #delete
does not, right? It may not be much of a drain, but you want to cut
back on object creation when it's obviously superfluous, right?


Ben

Yeah my wish would be for a syntax that "makes sense" for deleting 
objects (seeing that [] adds them) which wouldn't create new objects but 
would act like delete.
:)
Just wishing.

> Which means if you use #- you're creating a new object and #delete
> does not, right? It may not be much of a drain, but you want to cut
> back on object creation when it's obviously superfluous, right?
-- 
Posted via http://www.ruby-forum.com/.

I personally hate elsif [as opposed to elseif or else if]. I imagine it 
comes from some lesser language. Come on, is 'e' so damn hard to type?
-- 
Posted via http://www.ruby-forum.com/.

My latest wish--a GC that actually worked, instead of mongrel processes 
that take 600MB and growing :)
lol
-- 
Posted via http://www.ruby-forum.com/.

On Feb 13, 2008, at 11:36 PM, Roger Pack wrote:

> My latest wish--a GC that actually worked, instead of mongrel  
> processes
> that take 600MB and growing :)

You can't determine from the size of a process whether the GC is  
working or not since memory (even when freed by the GC) is never  
returned to the OS.  So with a magic 100% perfect GC, the memory  
footprint of your process will always reflect its peak memory usage.

You also have to determine if the GC is failing to collect dead  
objects or if you simply have some obscure references that are  
keeping large groups of objects on life support.

Gary Wright

> You can't determine from the size of a process whether the GC is
> working or not since memory (even when freed by the GC) is never
> returned to the OS.  So with a magic 100% perfect GC, the memory
> footprint of your process will always reflect its peak memory usage.

that being the case then my wish would be clarified as a GC that was 
fast and freed memory when no longer needed (appropriately and 
bug-free).
Cheers!
-Roger
-- 
Posted via http://www.ruby-forum.com/.

On Mon, Oct 15, 2007 at 7:23 AM, Roger Pack <rogerpack2005@gmail.com> wrote:
>  2) a GC that is 'user-definable' (run after this definable threshold,
>  this often), and (asidedbly), a GC that can run in its own (native)
>  thread so it doesn't pause execution of normal threads.

Is available in JRuby :)

>  4) the optional ability to have it display the whole backtrace on
>  uncaught exceptions (and also for all existing threads).

Not sure if anyone has mentioned that already, but this is simply a
matter of either changing TRACE_HEAD and TRACE_TAIL #defines, and
recompiling Ruby, or wrapping your "main" in something like

begin
  ...
rescue Object => e
  puts e.message
  print '  '
  puts e.backtrace.join("\n  ")
  exit -1
end

-- 
Alexey Verkhovsky
CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com]
RubyWorks [http://rubyworks.thoughtworks.com]

Alexey Verkhovsky wrote:
>   puts e.backtrace.join("\n  ")

puts e.backtrace

puts will automatically insert the platform-dependent line-break for 
you.  (Note that join("\n") is not sufficient to produce proper 
line-breaks on Windows).
-- 
Posted via http://www.ruby-forum.com/.

Hi,

At Fri, 15 Feb 2008 06:50:23 +0900,
Suraj Kurapati wrote in [ruby-talk:291073]:
> Alexey Verkhovsky wrote:
> >   puts e.backtrace.join("\n  ")
> 
> puts e.backtrace
> 
> puts will automatically insert the platform-dependent line-break for 
> you.

Alexey uses indentation.

> (Note that join("\n") is not sufficient to produce proper 
> line-breaks on Windows).

Not true always.  It depends on whether the output is opened in
text mode or in binary mode.

-- 
Nobu Nakada

> Not sure if anyone has mentioned that already, but this is simply a
> matter of either changing TRACE_HEAD and TRACE_TAIL #defines, and
> recompiling Ruby, or wrapping your "main" in something like

Yeah I've done that before and it's like a breath of fresh air when the 
output includes the entire trace. Ahh.

My next wish, ruby-genie!
Some type of variable that holds the 'last return value'
so, for example, in irb
>> 35+89
=> 124
>> b = _____ # meaning it should be set equal to 124

:)
-- 
Posted via http://www.ruby-forum.com/.

Roger Pack wrote:
> My next wish, ruby-genie!
> Some type of variable that holds the 'last return value'
> so, for example, in irb
>>> 35+89
> => 124
>>> b = _____ # meaning it should be set equal to 124

irb(main):001:0> 35+89
=> 124
irb(main):002:0> _
=> 124

-- 
       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

Joel VanderWerf wrote:
> irb(main):001:0> 35+89
> => 124
> irb(main):002:0> _
> => 124

awesome. Thanks.
-- 
Posted via http://www.ruby-forum.com/.

Alexey Verkhovsky wrote:
>>  4) the optional ability to have it display the whole backtrace on
>>  uncaught exceptions (and also for all existing threads).
> Not sure if anyone has mentioned that already, but this is simply a
> matter of either changing TRACE_HEAD and TRACE_TAIL #defines, and
> recompiling Ruby, or wrapping your "main" in something like
> 
> begin
>   ...
> rescue Object => e
>   puts e.message
>   print '  '
>   puts e.backtrace.join("\n  ")
>   exit -1
> end

Note that $! (which contains the current exception) is still defined
when Ruby is about to exit on an exception, while it's processing the
END blocks. You can get the same effect without wrapping main by adding
your exception printing code in an END block, which can be anywhere:

END { puts $!.backtrace*"\n\t" }

Clifford Heath.

Roger Pack wrote:
> My personal ruby wish-list (for any feedback):

I guess it's been suggested here before, but I have often wished for a 
way to have 'tighter' control over the variables passed to a parameter. 
Sometimes duck typing doesn't immediately catch errors, until you run 
through certain (possibly rare sequences).  So anyway my wish is for 
checking of parameters.  Fortunately it seems already possible (as about 
30% of rush wishes seem :P )



# a class to match

class Number
 def Number.matches? param
   return true if param.class == Fixnum or param.class == Float or 
param.class == BigDecimal
 end
end


def verify_params params_to_verify
  for param, should_match_this_class in params_to_verify do
    if should_match_this_class.respond_to? :matches?
      raise 'poor parameter' unless should_match_this_class.matches? 
param
    else
      raise 'poor parameter' unless param.class == 
should_match_this_class
    end
  end

end

def method_1 a, b, c
 verify_params a => Number, b => String

end

Ahh. Type checking at last.
Ok you may begin to throw the stones :)
I actually like this setup since it helps describe the parameters.
Thanks :)

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

Hi --

On Sat, 22 Mar 2008, Roger Pack wrote:

> Roger Pack wrote:
>
> # a class to match
>
> class Number
> def Number.matches? param
>   return true if param.class == Fixnum or param.class == Float or
> param.class == BigDecimal
> end
> end
>
>
> def verify_params params_to_verify
>  for param, should_match_this_class in params_to_verify do
>    if should_match_this_class.respond_to? :matches?
>      raise 'poor parameter' unless should_match_this_class.matches?
> param
>    else
>      raise 'poor parameter' unless param.class ==
> should_match_this_class
>    end
>  end
>
> end
>
> def method_1 a, b, c
> verify_params a => Number, b => String
>
> end
>
> Ahh. Type checking at last.

It's class checking actually, not type checking. Type is different
from class in Ruby.


David

-- 
Upcoming Rails training from David A. Black and Ruby Power and Light:
   ADVANCING WITH RAILS, April 14-17 2008, New York City
   CORE RAILS, June 24-27 2008, London (Skills Matter)
See http://www.rubypal.com for details. Berlin dates coming soon!

> It's class checking actually, not type checking. Type is different
> from class in Ruby.
> 
> 
> David

In that case I shall refer to it as "parameter verification" nobody 
would disagree with that :)
-- 
Posted via http://www.ruby-forum.com/.

Hi,

At Sat, 22 Mar 2008 07:33:56 +0900,
Roger Pack wrote in [ruby-talk:295325]:
> # a class to match
> 
> class Number
>  def Number.matches? param
>    return true if param.class == Fixnum or param.class == Float or 
> param.class == BigDecimal
>  end
> end

Numeric === obj

-- 
Nobu Nakada

Next wish :)
I wish that you could make arrays more easily.  As in

a = [1,2,3]
a.map{|n| n,n }

and it would work :)
-R
-- 
Posted via http://www.ruby-forum.com/.

On Fri, Mar 28, 2008 at 12:21 AM, Roger Pack <rogerpack2005@gmail.com> wrote:
> Next wish :)
>  I wish that you could make arrays more easily.  As in
>
>  a = [1,2,3]
>  a.map{|n| n,n }
>
>  and it would work :)
>

You want to create a two-dimensional array, right?
It works when you add square braces:

a = [1,2,3]
a.map{|n| [n,n] }

> You want to create a two-dimensional array, right?
> It works when you add square braces:
> 
> a = [1,2,3]
> a.map{|n| [n,n] }
Yeah I'm just a little lazy and dislike all the brackets :)
-- 
Posted via http://www.ruby-forum.com/.

On Thu, Mar 27, 2008 at 6:34 PM, Roger Pack <rogerpack2005@gmail.com> wrote:
> > You want to create a two-dimensional array, right?
>  > It works when you add square braces:
>  >
>  > a = [1,2,3]
>  > a.map{|n| [n,n] }
>  Yeah I'm just a little lazy and dislike all the brackets :)
>
>
> --
>  Posted via http://www.ruby-forum.com/.
>
>

No brackets, huh?
>> a = [1,2,3]
=> [1, 2, 3]
>> a.zip(a)
=> [[1, 1], [2, 2], [3, 3]]

Roger Pack wrote:
>> You want to create a two-dimensional array, right?
>> It works when you add square braces:
>>
>> a = [1,2,3]
>> a.map{|n| [n,n] }
> Yeah I'm just a little lazy and dislike all the brackets :)

I read somewhere that the best computer in the world was the one that 
that Scotty uses on Star Trek, because no matter what he wanted to do he 
could program it in two or three button presses.

Until we get one of Scotty's computers, though, programming requires 
typing. Lots and lots of typing. Maybe a little less with Ruby than, 
say, with Java, but still...lots.

-- 
RMagick: http://rmagick.rubyforge.org/
RMagick 2: http://rmagick.rubyforge.org/rmagick2.html

Since this thread is alive again I am throwing in my wish which occured 
to me in last months.

I wish parameters can be omited when calling methods with parameter 
which have default values set and is (are) in the middle ro begining of 
the parameter set.

Example:

def myMethod(a=1, b=2, c=3)
end
myMethod(3,,5)
myMethod(,,5)

This way I don't have to know the value of parameter b (which I am also 
not interested in) and the called method would use default defined value 
of 2.

of course if method is defined as:

def myMethod(a=1, b, c=3)
end
myMethod(3,,5)  => should throw an error.


by
TheR


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

On 28.03.2008 00:21, Roger Pack wrote:
> Next wish :)
> I wish that you could make arrays more easily.  As in
> 
> a = [1,2,3]
> a.map{|n| n,n }
> 
> and it would work :)
> -R

You can do

irb(main):002:0> Array.new(3) {|n| [n,n]}
=> [[0, 0], [1, 1], [2, 2]]
irb(main):003:0> (1..3).map {|n| [n,n]}
=> [[1, 1], [2, 2], [3, 3]]

But you don't get rid of the brackets that way.

	robert

On Fri, Mar 28, 2008 at 8:34 AM, Damjan Rems <d_rems@yahoo.com> wrote:
>
>  I wish parameters can be omited when calling methods with parameter
>  which have default values set and is (are) in the middle ro begining of
>  the parameter set.
>

I have already replied once and I thought and still think that
something like mymethod(2, ,3) looks kind of ugly.
But since then I took a look at Python and I like how it works with
default parameters and default values:


>  Example:
>
>  def myMethod(a=1, b=2, c=3)
>  end

You can call myMethod(b=5) and the other default values aren't
changed. I think this looks more beautyful than leaving empty space
between commas.
Ruby 1.9 supports named parameters, but I don't know anything about
it. Just take a look at it and see if it does what you want.
You can still work with hashes:
def myMethod(opts = {})
  defaults = {:a => 1, :b => 2, :c=> 3}
  opts = defaults.merge(opts)
  #whatever
end

> Ruby 1.9 supports named parameters, but I don't know anything about
> it. Just take a look at it and see if it does what you want.

Appears the new syntax is
def lolmatz(param1, param2 = 'second', param3)
  print param1, param2, param3
end
lolmatz('first', 'third') # prints 'firstsecondthird'

and it works.
Proc's also can have default parameters that way, too.
So I guess my wish would be a more intuitive style still, like
lolmatz('first', param3='third')
which worked out of the box :)

Another would be (of course) easier multi-line comments (more 
intuitive), like
###
comments!
###

That would be nice.

As a final note, in retrospect it would be possible to create a 'custom' 
hash that inherited from the Hash class and had the functionality as if 
it were ordered.  Go Ruby for flexibility.

Thanks all :)
-R
-- 
Posted via http://www.ruby-forum.com/.

On Apr 2, 2008, at 12:10 PM, Roger Pack wrote:
>> Another would be (of course) easier multi-line comments (more
> intuitive), like
> ###
> comments!
> ###

=begin
lots of
comment
lines
=end

Gary Wright

Gary Wright wrote:

yep one just like that that was more intuitive to me, since I always 
forget this one :)

> =begin
> lots of
> comment
> lines
> =end
-- 
Posted via http://www.ruby-forum.com/.

> If I wanted something "intuitive",
> 
>   /*
>   I'd probably prefer something like this,
>   */

Yeah that'd be sweet.

I believe this next wish has been mentioned before, but...
I wish you could call functions with the same name from arbitrary 
ancestor classes.

class A
 def run
 print 'A'
 end
end
class B < A
 def run
 print 'B'
 end
end

test = B.new
test.run # prints B
test.class.run_as(A).run # prints 'A'

:)
Thanks again.
-R
-- 
Posted via http://www.ruby-forum.com/.

On Apr 7, 1:01 pm, Roger Pack <rogerpack2...@gmail.com> wrote:
> > If I wanted something "intuitive",
>
> >   /*
> >   I'd probably prefer something like this,
> >   */
>
> Yeah that'd be sweet.
>
> I believe this next wish has been mentioned before, but...
> I wish you could call functions with the same name from arbitrary
> ancestor classes.
>
> class A
>  def run
>  print 'A'
>  end
> end
> class B < A
>  def run
>  print 'B'
>  end
> end
>
> test = B.new
> test.run # prints B
> test.class.run_as(A).run # prints 'A'

See Facets Kernel#as.

  http://facets.rubyforge.org

T.

> See Facets Kernel#as.
> 
>   http://facets.rubyforge.org
> 
> T.

Wow facets looks really nice!  It even has the multi-hash that was a 
wish a few posts ago, plus some other utilities that I've had to write 
from scratch before [but not anymore].  Rock on.
-R
-- 
Posted via http://www.ruby-forum.com/.

Next wish :)
I wish you could have distinguishable separatable name-spaces, something 
along the lines of

class Abc
end
namespace one
 class Abc
   def func1
   end
 end
end

namespace two
 # class Abc will NOT have func1, right here
end

ok maybe it wouldn't be all that widespread used, but somewhat useful 
for keeping code nice and separate.
Thanks for reading :)
-R
-- 
Posted via http://www.ruby-forum.com/.

On Apr 12, 10:49 am, Roger Pack <rogerpack2...@gmail.com> wrote:
> Next wish :)
> I wish you could have distinguishable separatable name-spaces, something
> along the lines of
>
> class Abc
> end
> namespace one
>  class Abc
>    def func1
>    end
>  end
> end
>
> namespace two
>  # class Abc will NOT have func1, right here
> end
>
> ok maybe it wouldn't be all that widespread used, but somewhat useful
> for keeping code nice and separate.
> Thanks for reading :)
> -R
> --
> Posted viahttp://www.ruby-forum.com/.

Can you show a use case where using modules as namespaces isn't enough?

On 12.04.2008 20:40, Chris Shea wrote:
> On Apr 12, 10:49 am, Roger Pack <rogerpack2...@gmail.com> wrote:
>> I wish you could have distinguishable separatable name-spaces, something
>> along the lines of
>>
>> class Abc
>> end
>> namespace one
>>  class Abc
>>    def func1
>>    end
>>  end
>> end
>>
>> namespace two
>>  # class Abc will NOT have func1, right here
>> end
>>
>> ok maybe it wouldn't be all that widespread used, but somewhat useful
>> for keeping code nice and separate.
>> Thanks for reading :)
>> -R
> 
> Can you show a use case where using modules as namespaces isn't enough?

That was my first reaction as well.  But now I suspect that Roger wanted 
::Abc and ::one::Abc to be the _same class_ but method func1 should only 
be visible in namespace one.  With modules there were two distinct 
classes that would not have anything in common.  In this particular case 
the behavior could be emulated with inheritance:

class Abc
end

module one
   class Abc < ::Abc
     def func1
     end
   end
end

but it would not be the same and not work in all cases where the wished 
for feature would work.  I believe the concept has been discussed under 
the term "selector namespaces" numerous times here.  I cannot remember 
the current status of this feature though. :-)

Personally I am not yet convinced that the feature would be so great. 
My doubts are fed by the increased complexity of the language 
implementation as well as complexity of the code that uses this feature. 
  For example, what happens in this case:

class Foo; end

module Bar
   class Foo
     def bar_meth; end
   end

   class Inherited < Foo
     def test
       bar_meth # ok here because in Bar
     end
   end
end

class WhatNow < ::Bar::Inherited
   def test2
      test # error or not?
      bar_meth # error or not?
   end
end

Kind regards

	robert

Robert Klemme wrote:
> On 12.04.2008 20:40, Chris Shea wrote:
>>>  end
>> 
>> Can you show a use case where using modules as namespaces isn't enough?
Yeah the only thing I can think of it being useful for would be when you 
are 'meta-running' code

I got the idea as python doctests can run each file's doctest in a 
'separate namespace' so that they don't munge each others tests.
I suppose you can accomplish about the same thing by [as rails 
active_support does] keeping track of which new constants are created 
during a test and tearing them down.
Another use would be if you were running multiple rails instances with 
the same ruby--you might want them each to live in distinct lands.

> classes that would not have anything in common.  In this particular case
> the behavior could be emulated with inheritance:
Interesting point.  I agree with you that it would add some serious 
complexity, though, which might be a bad thing.

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

I wish this worked :)

>> def a
>> end
=> nil
>> a {:b => true}
SyntaxError: compile error
(irb):3: syntax error, unexpected tASSOC, expecting '}'
a {:b => true}
        ^
  from (irb):3

I have no idea why it doesn't consider a hash a parameter.
-R
-- 
Posted via http://www.ruby-forum.com/.

2008/4/21, Roger Pack <roger@doachristianturndaily.info>:
> I wish this worked :)
>
>  >> def a
>  >> end
>  => nil
>  >> a {:b => true}
>  SyntaxError: compile error
>  (irb):3: syntax error, unexpected tASSOC, expecting '}'
>  a {:b => true}
>         ^
>   from (irb):3

irb(main):001:0> def a(x)end
=> nil
irb(main):002:0> a(:b=>true)
=> nil
irb(main):003:0>

>  I have no idea why it doesn't consider a hash a parameter.

Precedence.

Cheers

robert


-- 
use.inject do |as, often| as.you_can - without end

>>  I have no idea why it doesn't consider a hash a parameter.
> 
> Precedence.
Yeah for some reason it is considering my function a block a higher 
predencdence than a hash parameter.
So my next wish would be:
That ruby-core would allow us to make suggestions for how to better 
their error messages :)
And also [sigh] that hashes and blocks used a different syntax, or that 
the ambiguity noted could be overcome.
Cheers.
-R
-- 
Posted via http://www.ruby-forum.com/.

On Mon, Apr 21, 2008 at 9:23 AM, Roger Pack
<roger@doachristianturndaily.info> wrote:
> >>  I have no idea why it doesn't consider a hash a parameter.
>  >
>  > Precedence.
>  Yeah for some reason it is considering my function a block a higher
>  predencdence than a hash parameter.
>  So my next wish would be:
>  That ruby-core would allow us to make suggestions for how to better
>  their error messages :)
>  And also [sigh] that hashes and blocks used a different syntax, or that
>  the ambiguity noted could be overcome.
>  Cheers.
>


>> def a(hash)
>>   hash
>> end
=> nil
>> a :a => false, :b =>true
=> {:a=>false, :b=>true}

2008/4/21, Roger Pack <roger@doachristianturndaily.info>:
> >>  I have no idea why it doesn't consider a hash a parameter.
>  >
>  > Precedence.
>
> Yeah for some reason

That "some reason" is probably the language's syntax definition.

> it is considering my function a block a higher
>  predencdence than a hash parameter.
>  So my next wish would be:
>  That ruby-core would allow us to make suggestions for how to better
>  their error messages :)

I have never heard someone was turned down who made a reasonable suggestion.

>  And also [sigh] that hashes and blocks used a different syntax, or that

Not going to happen.  Just think of the mess that would do to existing code.

>  the ambiguity noted could be overcome.

Is it just me or does this issue come up rarely?  My impression is
that people stumble over it at most once and never again.  This does
not feel like a big deal - certainly was never for me.  But of course
YMMV.

Cheers

robert

-- 
use.inject do |as, often| as.you_can - without end

Robert Klemme wrote:
> 2008/4/21, Roger Pack <roger@doachristianturndaily.info>:
>>   from (irb):3
> irb(main):001:0> def a(x)end
> => nil
> irb(main):002:0> a(:b=>true)
Wow. Rock on.  Now that you've pointed out this syntax I find it 
addictive and use it a lot.

My next wish:
that
string =~ 'abc'

would work.  It's not a regex, but I would imagine it makes sense to 
auto-convert it :)
At least I'd use it.
-R
-- 
Posted via http://www.ruby-forum.com/.

All right ruby-genie.  My next wish!
That 1.9 had an option that represents a cross between thread models 2 
and 3[1] [i.e. sometimes threads could run simultaneous,  a la].

guaranteed_thread_safe do
 # thread multi threaded code
end

Though I suppose this is accomplishable using some C code, currently.
Thanks genie!
-R
:)

[1] http://www.atdot.net/yarv/rc2006_sasada_yarv_on_rails.pdf
-- 
Posted via http://www.ruby-forum.com/.

On 12.05.2008 08:58, Roger Pack wrote:
> All right ruby-genie.  My next wish!
> That 1.9 had an option that represents a cross between thread models 2 
> and 3[1] [i.e. sometimes threads could run simultaneous,  a la].
> 
> guaranteed_thread_safe do
>  # thread multi threaded code
> end
> 
> Though I suppose this is accomplishable using some C code, currently.

http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_threads.html

http://www.ruby-doc.org/stdlib/libdoc/monitor/rdoc/index.html
http://www.ruby-doc.org/stdlib/libdoc/thread/rdoc/index.html

My next wish: yeah, you guessed right.

	robert

Back to the wishing well...
I wish there were some elegant way to do .=
a = a.method
as a cleaner syntax.  Only problem being I can't even think of an 
elegant syntax for that.


Oh, and a gripe:

array.map &:id

I think this syntax is good, but slightly confusing.  I know what it 
does, but wish it were deprecated for ugliness, and ruby would 
automatically call .to_proc on parameters, or something better than what 
it does now.  Of course, that's just me, and I can't think of an elegant 
syntax for it ;)
-R
-- 
Posted via http://www.ruby-forum.com/.

I have a big wish :)

Since 1.9 will be/is quite different, I want docu docu docu. And 
examples. And more examples. And more docu. And ... ;)
-- 
Posted via http://www.ruby-forum.com/.

I really wish I was forced to declare all my variables.

This could be an option (like Perl's "use strict") so people wouldn't 
have to declare things if they don't want to.

Dave
-- 
Posted via http://www.ruby-forum.com/.

Marc Heiler wrote:
> I have a big wish :)
> 
> Since 1.9 will be/is quite different, I want docu docu docu. And 
> examples. And more examples. And more docu. And ... ;)

+1 on wishing for tons of documentation and examples.
-- 
Posted via http://www.ruby-forum.com/.

why do you wish for that?
I did have the wish that instance variables couldn't be used before 
being assigned [ugh], but it's less code to write the way it currently 
is, so I'm ok with it.  I guess there's always defined?(var_name), too.

Dave Bass
> I really wish I was forced to declare all my variables.
-- 
Posted via http://www.ruby-forum.com/.

Dave Bass wrote:

> I really wish I was forced to declare all my variables.

Huh? You can't get a variable unless you declare it. Do you mean "wasn't 
forced"?

> This could be an option (like Perl's "use strict") so people wouldn't
> have to declare things if they don't want to.

Correct my Perl, but I think that fixes this:

  $foo = 42;
  if ($fue == 42) ...

Won't non-strict Perl allow the $fue to magically appear, as an "rvalue" 
(mixing a C concept - a readable value), containing undef?

-- 
  Phlip 

Roger Pack wrote:

> I did have the wish that instance variables couldn't be used before
> being assigned [ugh], but it's less code to write the way it currently
> is, so I'm ok with it.  I guess there's always defined?(var_name), too.

There's a use for the @foo == nil trick:

  render :partial => 'html_snip', :locals => { :@foo => 42 }

Now, inside the html_snip, your eRB can safely test @foo for existence...

   @foo ||= 0

....then use it.

(Why not use @foo as an ivar of the calling context, and let the render pass 
it thru by cloning the ivars? Because you might need to test the partial!)

I suspect the alternative, without declaring @foo to be an ivar on the way 
down, is more odious. Maybe I was using it wrong, but I seem to recall I 
could not get defined? to work there.

-- 
  Phlip 

Roger Pack wrote:
> Marc Heiler wrote:
>> I have a big wish :)
>>
>> Since 1.9 will be/is quite different, I want docu docu docu. And 
>> examples. And more examples. And more docu. And ... ;)
> 
> +1 on wishing for tons of documentation and examples.

My mother used to say "Wish in one hand and spit in the other. See which 
one fills up first."

There is a way to ensure that what you wish for happens.

-- 
RMagick: http://rmagick.rubyforge.org/
RMagick 2: http://rmagick.rubyforge.org/rmagick2.html

>> I really wish I was forced to declare all my variables.
Roger Pack wrote:
> why do you wish for that?

declare x1 = 0
declare x, y, z = x1 + 2

xl = z * y + x

=> Error: variable xl undeclared.
(Perhaps you mean x or x1?)

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

>>> I really wish I was forced to declare all my variables.

>> why do you wish for that?
> 
> declare x1 = 0
> declare x, y, z = x1 + 2
> 
> xl = z * y + x
> 
> => Error: variable xl undeclared.
> (Perhaps you mean x or x1?)

Got unit tests?

On May 27, 2008, at 3:08 AM, Dave Bass wrote:

>>> I really wish I was forced to declare all my variables.
> Roger Pack wrote:
>> why do you wish for that?
>
> declare x1 = 0
> declare x, y, z = x1 + 2
>
> xl = z * y + x
>
> => Error: variable xl undeclared.
> (Perhaps you mean x or x1?)

This will be caught the first time you try to read x1.

(To say nothing of your numerous unit tests, right? :)

///ark

latest wish:
gem install package_name --checkout_latest_svn_trunk_and_build_it
or is this possible?
Thanks! :)
-R
-- 
Posted via http://www.ruby-forum.com/.

Roger Pack wrote:
> gem install package_name --checkout_latest_svn_trunk_and_build_it

Not everyone uses Subversion. :)

One way to achieve your request would be for you to manually check out 
the sources of your favorite project from their code repository and run 
the "gem" task in their Rakefile (most projects do).  This will build a 
gem which you can then install.
-- 
Posted via http://www.ruby-forum.com/.

On Wednesday 28 May 2008 20:51:15 Suraj Kurapati wrote:
> Roger Pack wrote:
> > gem install package_name --checkout_latest_svn_trunk_and_build_it
> 
> Not everyone uses Subversion. :)

No reason it has to be SCM-specific.

David Masover wrote:
> On Wednesday 28 May 2008 20:51:15 Suraj Kurapati wrote:
>> Roger Pack wrote:
>> > gem install package_name --checkout_latest_svn_trunk_and_build_it
>> 
>> Not everyone uses Subversion. :)
> 
> No reason it has to be SCM-specific.

From my understanding of the problem, implementing this kind of feature 
would require gem creators to supply some kind of resource identifier in 
the gem's meta-data.

Let us assume that the aforementioned resource identifier is an 
SCM-dependent URL to a project's code repository.  RubyGems would then 
be responsible for (1) checking out the latest copy of the code 
repository, (2) constructing a gem out of it, and (2) installing the 
constructed gem.

In contrast, if we were to make this feature fully SCM-independent, then 
the aforementioned resource identifier would need to be something like a 
URL to a ZIP file that contains the latest code for a particular 
project.  RubyGems would then be responsible for (1) fetching the ZIP 
file, (2) constructing a gem out of it, and (2) installing the 
constructed gem.

All that's needed then is to have some automated process that publishes 
a ZIP file of a project's code repository whenever someone commits new 
changes to the repository.  This would obviously be SCM-specific.
-- 
Posted via http://www.ruby-forum.com/.

On Thursday 29 May 2008 01:26:08 Suraj Kurapati wrote:
> David Masover wrote:
> > On Wednesday 28 May 2008 20:51:15 Suraj Kurapati wrote:
> >> Roger Pack wrote:
> >> > gem install package_name --checkout_latest_svn_trunk_and_build_it
> >> 
> >> Not everyone uses Subversion. :)
> > 
> > No reason it has to be SCM-specific.
> 
> From my understanding of the problem, implementing this kind of feature 
> would require gem creators to supply some kind of resource identifier in 
> the gem's meta-data.
> 
> Let us assume that the aforementioned resource identifier is an 
> SCM-dependent URL to a project's code repository.  RubyGems would then 
> be responsible for (1) checking out the latest copy of the code 
> repository, (2) constructing a gem out of it, and (2) installing the 
> constructed gem.

Make RubyGems pluggable, in some sense, if it isn't already.

Simplest possible implementation that I can think of: Create a mostly static 
gem which depends on (or includes) everything required to interact with the 
SCM, and to run whatever is needed to build the gem file. After which, it 
replaces itself with the built gem (which, in turn, builds native extensions, 
etc etc).

I don't know enough about RubyGems to know if this can be made entirely 
automatic, or if it'd end up being something stupid like:

sudo gem install foo-svn
sudo foo-svn bootstrap
(bootstrap script will automatically run 'gem uninstall foo-svn' on successful 
installation of /var/some/where/foo.gem)

However, every system-level package manager I've worked with (dpkg, etc) has 
support for running arbitrary scripts at various points along the 
installation. For example, I can install Ubuntu's "msttcorefonts" package, 
which, due to licensing strangeness, will actually download and unpack a 
bunch of EXEs as part of the install.

I should probably go read more about RubyGems, though.

> In contrast, if we were to make this feature fully SCM-independent, then 
> the aforementioned resource identifier would need to be something like a 
> URL to a ZIP file that contains the latest code for a particular 
> project.  RubyGems would then be responsible for (1) fetching the ZIP 
> file, (2) constructing a gem out of it, and (2) installing the 
> constructed gem.

I don't like that, because then you're downloading the entire project every 
time, and you're not getting project metadata. It would be nice to be able to 
have, say, /var/lib/gems/checkouts/foo, with which to develop the occasional 
patch against foo.

>> Let us assume that the aforementioned resource identifier is an 
>> SCM-dependent URL to a project's code repository.  RubyGems would then 
>> be responsible for (1) checking out the latest copy of the code 
>> repository, (2) constructing a gem out of it, and (2) installing the 
>> constructed gem.

Seems like minimalistically you'd need
scm_type = :git
scm_url = git://whatever # or something less scm dependent
scm_build_command = 'cd subdir; rake build;'
scm_output_gem = 'subdir/built.gem'

Just my $0.02 :)
-R
-- 
Posted via http://www.ruby-forum.com/.

my latest wish
File.write 'filename', contents
:)
-- 
Posted via http://www.ruby-forum.com/.

Roger Pack wrote:
> my latest wish
> File.write 'filename', contents
> :)

Doh that one's in facets already :)

Question does this exist already?

Some central 'rubydoc' index that has links to the docs for installed 
gems and/or the core docs?  Like an updated index of docs?  If that 
existed I'd be tempted to actually use the rdocs instead of not even 
knowing where they install to, with the current gem stuff [it's painful 
to go after rdocs that are buried X folders deep].
Twould be swell if rubygems automatically updated the doc index.  Or 
does it exist?
-R
-- 
Posted via http://www.ruby-forum.com/.

> If I wanted something "intuitive",
> 
>   /*
>   I'd probably prefer something like this,
>   */
> 
> since that's what I'm used to for multiline comments.  On the other 
> hand,
> 
>   =begin
>   this seems a lot more Ruby-idiomatic to me,
>   =end
> 
> so I like it just fine.

Yeah /* comments */ would be sweet.  Then you could also have 'inline' 
comments, like
a = [8..9 /* bread id's */, 900..990 /* butter id's */]

Which would be awesome in some instances.  Obviously these are poor 
examples, but with some it would be nice.
-R
-- 
Posted via http://www.ruby-forum.com/.

On Wednesday 25 June 2008 18:00:54 Roger Pack wrote:
> > If I wanted something "intuitive",
> >
> >   /*
> >   I'd probably prefer something like this,
> >   */
> >
> > since that's what I'm used to for multiline comments.  On the 
other
> > hand,
> >
> >   =begin
> >   this seems a lot more Ruby-idiomatic to me,
> >   =end
> >
> > so I like it just fine.
>
> Yeah /* comments */ would be sweet.  Then you could also have 
'inline'
> comments, like
> a = [8..9 /* bread id's */, 900..990 /* butter id's */]
>
> Which would be awesome in some instances.  Obviously these 
are poor
> examples, but with some it would be nice.
> -R
a = [ 8..9, #ids pan
900..990 ] #ids mantequilla
-- 
Universidad del Norte

> a = [ 8..9, #ids pan
> 900..990 ] #ids mantequilla

That would work, but forces you to insert line breaks per comment, which 
is livable, but exactly the reason for my wish :)
-R
-- 
Posted via http://www.ruby-forum.com/.

I wish that backtraces had more information, and could also display 
variables and bindings, etc.

ex:
Thread.current.backtrace_bindings or $!.bindings

and outputs like

NameError: undefined local variable or method `abc' for main:Object
  from 
/Users/rogerpack/dev/ruby-roger-useful-functions/irb_lookup.rb:40:in 
`method_missing('abc', 34)'
  from (irb):12


Also displaying the line of code that crashed you would be sweet, a la
NameError: undefined local variable or method `abc' for main:Object
        print abc # the line in question
  from 
/Users/rogerpack/dev/ruby-roger-useful-functions/irb_lookup.rb:40:in 
`method_missing('abc', 34)'
  from (irb):12

Though I suppose this is indeed possible in Ruby as it currently is ex: 
[1]'s source_extract function

Take care.
-R
[1] 
http://github.com/rails/rails/tree/ad772402c46a79c2d38979cef754b26dbd868196/actionpack/lib/action_controller/templates/rescues/template_error.erb
-- 
Posted via http://www.ruby-forum.com/.

Roger Pack wrote:
> I wish that backtraces had more information, and could also display 
> variables and bindings, etc.


another wish:
rescue => e
really should rescue the same as
rescue # nothing

and, IMHO, rescue # blank
should rescue Exception, not just StandardError--a point of confusion to 
almost all newbies :)
Take care!
-R
-- 
Posted via http://www.ruby-forum.com/.

Roger Pack wrote:
> another wish:
My thanks to the 1.9 team, who allowed for "abc\x14" style string 
syntax, so we can actually input any arbitrary strings now within string 
syntax.  That's nicer :)
-R
-- 
Posted via http://www.ruby-forum.com/.

> Roger Pack wrote:
>> another wish:
I wish we had Fiber.root method in 1.9 :)
-R
-- 
Posted via http://www.ruby-forum.com/.

> Of course, it's been possible also in 1.8 or earlier, even in 0.95.
> 
> $ ./ruby -v -e 'print "abc\x14"'| od -tx1z
> ruby - version 0.95 (95/12/21)
> 0000000 61 62 63 14                                      >abc.<
> 0000004

Nice.
Next wish: IO#read_line [and I know I can make my own--just wishing I 
didn't have to :) ]
-R


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

On Jul 18, 2008, at 2:25 PM, Roger Pack wrote:
>> Of course, it's been possible also in 1.8 or earlier, even in 0.95.
>>
>> $ ./ruby -v -e 'print "abc\x14"'| od -tx1z
>> ruby - version 0.95 (95/12/21)
>> 0000000 61 62 63 14                                      >abc.<
>> 0000004
>
> Nice.
> Next wish: IO#read_line [and I know I can make my own--just wishing I
> didn't have to :) ]
> -R


Granted!

Use IO#gets or IO#readline depending on the behavior that you expect.

-Rob

Rob Biedenharn		http://agileconsultingllc.com
Rob@AgileConsultingLLC.com

Rob Biedenharn wrote:
> On Jul 18, 2008, at 2:25 PM, Roger Pack wrote:
>> -R
> Granted!
> 
> Use IO#gets or IO#readline depending on the behavior that you expect.
Thank you genie!  That's like my 4th wish granted, and one created! You 
rock!

Next wish:
Not mine, but copied from
http://eigenclass.org/hiki/Rename+and+reject+methods+from+included+modules


"Mark Hubbart I particularly like the ':alias => {:orig => :new}' 
syntax. I wish alias_method would take a hash; I think it would be much 
clearer than 'alias_method :new, :old'.
"
I realize it's possible, but hey, here's wishing it were normal :)

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

Next wish [stolen shamelessly from Ryan Davis' blog]:

That 1.9 had a dissassemble command that worked, or some way at the 
abstract syntax tree :)

>> p = proc { |n| n + 2 } 
=> #<Proc:0x3be994@(irb):1>
>> VM::InstructionSequence.disassemble p
>> class Temp1; end
>> Temp1.send :define_method, :m, p
=> #<Proc:0x3be9e4@(irb):1 (lambda)>
>> VM::InstructionSequence.disassemble(Temp1.instance_method :m)
=> nil # this one right here

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

Roger Pack wrote:

Wish I could 'steal' methods from classes.  Without using parse_tree, 
anyway :P

class A
  def b;
    'secret is here!'
  end
end
class C
  alias :stolen_b A:b # copy from a different class.
end

>> C.new.stolen_b
=> "secret is here!"
-- 
Posted via http://www.ruby-forum.com/.

> "Mark Hubbart I particularly like the ':alias => {:orig => :new}' 
> syntax. I wish alias_method would take a hash; I think it would be much 
> clearer than 'alias_method :new, :old'.
> "
> I realize it's possible, but hey, here's wishing it were normal :)
> 
> =R

Or rather wishing that alias weren't a compiler keyword but just a 
function, like include is, or what not, so it could be overridden.
-R
-- 
Posted via http://www.ruby-forum.com/.

On Jul 25, 1:15=A0am, Roger Pack <rogerpack2...@gmail.com> wrote:
> > "Mark Hubbart I particularly like the ':alias =3D> {:orig =3D> :new}'
> > syntax. I wish alias_method would take a hash; I think it would be much
> > clearer than 'alias_method :new, :old'.
> > "
> > I realize it's possible, but hey, here's wishing it were normal :)
>
> > =3DR
>
> Or rather wishing that alias weren't a compiler keyword but just a
> function, like include is, or what not, so it could be overridden.

++1

#alias_method works though.

T.

On Thu, Jun 26, 2008 at 1:00 AM, Roger Pack <rogerpack2005@gmail.com> wrote=
:
> Yeah /* comments */ would be sweet.  Then you could also have 'inline'
> comments, like
> a =3D [8..9 /* bread id's */, 900..990 /* butter id's */]
>
D=E9j=E0 vu?
a =3D [ 8..9 || "bread id's", 900..990 || "butter id's"]
> Which would be awesome in some instances.  Obviously these are poor
> examples, but with some it would be nice.
And my technique just makes it clear how poor they are IMHO.
Robert

--=20
http://ruby-smalltalk.blogspot.com/

There's no one thing that's true. It's all true.
--
Ernest Hemingway

> Now you know you can.
> 
> |2) a GC that is 'user-definable' (run after this definable threshold,
> |this often), and (asidedbly), a GC that can run in its own (native)
> |thread so it doesn't pause execution of normal threads.
> 
> I'd rather prefer smarter collector, but it's possible.
> 
> GC on its own thread is a different story.  Interaction between
> collector and mutator may hinder the performance.

Would the following be a good idea?

When you garbage collect, fork and have the child "check for garbage" 
then report back to the parent on which objects are no longer used.

Children and parents can share memory, it appears [1].
So my thought would be to have the parent and child share a "freeable" 
list.

When the parent runs out of memory it spawns a child to do garbage 
collection, and continues running.  The child would propagate a shared 
[large'ish] "freeable" list with pointers to memory which is no longer 
used.  The parent would later notice GC completion through some message, 
and then reclaim the memory and free any unused blocks, and reap the 
child.

My hypothesis is that this would allow for a single script to execute 
faster, especially on dual core machines when only one script is running 
[the child could run in the other core].  This would theoretically then 
[should it work]: cost more RAM, use about the same total CPU, but allow 
the script to continue running [a la macruby] during GC.  Should you 
have multiple cores available, it should have shorter execution time, 
which is, after all, what we're after.

Thoughts? Cautions?

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

Roger Pack wrote:
> When you garbage collect, fork and have the child "check for garbage" 
> then report back to the parent on which objects are no longer used.

The check for garbage can't be done concurrently with ruby code:

   a = []
   $a = a
   a = nil

depending on how the gc process is scheduled, that empty array may 
falsely appear to be garbage:

   # start scan
   a = []
   # scan globals
   $a = a
   a = nil
   # scan locals

-- 
       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

Joel VanderWerf wrote:
> The check for garbage can't be done concurrently with ruby code:
> 
>    a = []
>    $a = a
>    a = nil
> 
> depending on how the gc process is scheduled, that empty array may
> falsely appear to be garbage:
> 
>    # start scan * SNAPSHOT *
>    a = []
>    # scan globals
>    $a = a
>    a = nil
>    # scan locals

Definitely a consideration.

Do you think this help?  The child process is basically operating off a 
snapshot of memory, since it was a fork.  It will thus only 'mark as 
free' the ruby objects that are inaccessible at the time of the 
snapshot, thus, in this example, not collecting "a" since it...hasn't 
been created yet.

The memory is 'reclaimed' by the parent "all at once" so should avoid 
concurrency weirdness that way, too.  There is always "at most" one fork 
doing a GC.  Come to think of it, I'm not sure how this would work if 
you had a process that actually called fork while running, but for 
single [true] threaded scripts it should work.

Thoughts?

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

Roger Pack wrote:
> Joel VanderWerf wrote:
>> The check for garbage can't be done concurrently with ruby code:
>>
>>    a = []
>>    $a = a
>>    a = nil
>>
>> depending on how the gc process is scheduled, that empty array may
>> falsely appear to be garbage:
>>
>>    # start scan * SNAPSHOT *
>>    a = []
>>    # scan globals
>>    $a = a
>>    a = nil
>>    # scan locals
> 
> Definitely a consideration.
> 
> Do you think this help?  The child process is basically operating off a 
> snapshot of memory, since it was a fork.  It will thus only 'mark as 
> free' the ruby objects that are inaccessible at the time of the 
> snapshot, thus, in this example, not collecting "a" since it...hasn't 
> been created yet.
> 
> The memory is 'reclaimed' by the parent "all at once" so should avoid 
> concurrency weirdness that way, too.  There is always "at most" one fork 
> doing a GC.  Come to think of it, I'm not sure how this would work if 
> you had a process that actually called fork while running, but for 
> single [true] threaded scripts it should work.
> 
> Thoughts?
> 
> -R

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?

Interesting!

-- 
       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

Joel VanderWerf wrote:
>>>    # start scan * SNAPSHOT *
> 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?

Now that you mention it, this might would work even better in 
conjunction with Hongli's Copy on write friendly GC.  Then you wouldn't 
have to copy the entire ruby space per GC :)
> 
> Interesting!

I can't get much credit for the idea since it just came to me while 
reading scriptures yesterday morning :P
Now you know what distracts me a lot.

I'll probably hack it up sometime, first version as a straight patch to 
1.8.6

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

John Joyce wrote:
> On Oct 19, 2007, at 5:09 PM, Roger Pack wrote:
> 
>> Roger Pack wrote:
> if arr.include? 'a'
> puts "array arr includes the letter 'a'"
> end

Another wish [I believe this one is in facets already] is that wherever 
there's a multiples verb like .include? it would also come with 
includes? version so that the grammar isn't as confusing.
Thanks!
-R
-- 
Posted via http://www.ruby-forum.com/.

On Aug 7, 11:17 pm, Roger Pack <rogerpack2...@gmail.com> wrote:
> Another wish [I believe this one is in facets already] is that wherever
> there's a multiples verb like .include? it would also come with
> includes? version so that the grammar isn't as confusing.
> Thanks!
> -R

My interpretation of it is that "include" here is in the infinitive,
as in "Does x include y?", so the API as it is makes sense to me.
YMMV, of course.

AdSR

>> there's a multiples verb like .include? it would also come with
>> includes? version so that the grammar isn't as confusing.
>> Thanks!
>> -R
> 
> My interpretation of it is that "include" here is in the infinitive,
> as in "Does x include y?", so the API as it is makes sense to me.
> YMMV, of course.

Yeah both would be good.

From my side

if a.includes? b ...

works nicely.

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

Perhaps a bit controversial, but I'd like to see a keyword for the =20
=93current block=94 as a way to refer to the Proc instance created =
inside =20
that block. That would allow for recursive anonymous blocks like:

[[1,2,[3]],[[[5],6],7],8].map { |e|
   Array =3D=3D=3D e ? e.map(&current_block) : e.to_s
}

without resorting to ugly syntax like

[[1,2,[3]],[[[5],6],7],8].map &(deep_to_s =3D proc { |e|
   Array =3D=3D=3D e ? e.map(&deep_to_s) : e.to_s
})

--=20
instance_variable_set(%@\@%sample@%%@ew@.succ, Class.new(&proc{def =20
self.net;$;,
$/=3D'','/';%;.fqn-=20
cmtkhng;end}));Kernel.send(:"define_method",:method_missing){|
n,$_|$_<<"?kd!jhl";n=3Dsplit.map{|q|q.succ}*'';puts n.reverse.chomp.tr(*=20=

%w{" a})}
me@example.net

On 8/8/08, Mikael H=F8ilund <mikael@hoilund.org> wrote:
> Perhaps a bit controversial, but I'd like to see a keyword for the "curre=
nt
> 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 =3D=3D=3D e ? e.map(&current_block) : e.to_s
> }
>

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=3D=3D=3De ? e.map_r(&block) : block[e]}
  end
end
p [[1,2,[3]],[[[5],6],7],8].map_r{|e|e.to_s}

=3D> [["1", "2", ["3"]], [[["5"], "6"], "7"], "8"]

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
> }
> 
> without resorting to ugly syntax like
> 
> [[1,2,[3]],[[[5],6],7],8].map &(deep_to_s = proc { |e|
>   Array === e ? e.map(&deep_to_s) : e.to_s
> })
> 

IIUC, this would also let us take this idiom:

pr = proc {|h,k| h[k] = Hash.new(&pr)}
h = Hash.new(&pr)
h[1][2][3] = 6
p h   # ==> {1=>{2=>{3=>6}}}

and simplify to:

h = Hash.new {|h,k| h[k] = Hash.new(&current_block)}

-- 
       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

On Aug 8, 2008, at 20:19, Adam Shelly wrote:

> On 8/8/08, Mikael H=F8ilund <mikael@hoilund.org> wrote:
>> Perhaps a bit controversial, but I'd like to see a keyword for the =20=

>> "current
>> block" as a way to refer to the Proc instance created inside that =20
>> block.
>> That would allow for recursive anonymous blocks like:
>>
>> [[1,2,[3]],[[[5],6],7],8].map { |e|
>> Array =3D=3D=3D e ? e.map(&current_block) : e.to_s
>> }
>>
>
> 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=3D=3D=3De ? e.map_r(&block) : block[e]}
>  end
> end
> p [[1,2,[3]],[[[5],6],7],8].map_r{|e|e.to_s}
>
> =3D> [["1", "2", ["3"]], [[["5"], "6"], "7"], "8"]
>

That's not optimal if it's just for a single usage, especially not if =20=

it requires monkey-patching a built-in class. I could imagine this =20
being used pretty much any time recursive behavior is necessary for an =20=

iterator. And besides, what's more descriptive?

array.map { |e|
   Array =3D=3D=3D e ? e.map(&current_block) : e.to_s
}

or

array.map_r { |e| e.to_s } # Please look somewhere in the source tree =20=

for the definition of Array#map_r

?

On Aug 8, 2008, at 21:30, Joel VanderWerf wrote:
>
> IIUC, this would also let us take this idiom:
>
> pr =3D proc {|h,k| h[k] =3D Hash.new(&pr)}
> h =3D Hash.new(&pr)
> h[1][2][3] =3D 6
> p h   # =3D=3D> {1=3D>{2=3D>{3=3D>6}}}

It's dangerous to go alone. Until we have this sort of divine magic, =20
take this:

 >> h =3D Hash.new { |h, k| h[k] =3D Hash.new(&h.default_proc) }
 >> h[:a][:b][:c] =3D :o
 >> h
=3D> {:b=3D>{:c=3D>:o}}

--=20
Mikael H=F8ilund
http://hoilund.org/

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/.