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).
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.
···
In message "Re: ruby wish-list" on Mon, 15 Oct 2007 23:23:06 +0900, Roger Pack <rogerpack2005@gmail.com> writes:
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
···
On Mon, Oct 15, 2007 at 7:23 AM, Roger Pack <rogerpack2005@gmail.com> wrote:
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 )
# 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
>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
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).
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
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:
class Number
def Number.matches? param
return true if param.class == Fixnum or param.class == Float or
param.class == BigDecimal
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!
>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.
>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
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
···
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.
)