Forum: Ruby - posixtimer 0.1

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Caleb T. (Guest)
on 2005-12-12 15:05
(Received via mailing list)
http://rubyforge.org/projects/posixtimer/

Here's my first RubyForge release, a small utility that wraps around the
POSIX
timer API.  This is only available for systems which implement
timer_create()
calls - Linux being where I've tested it on.

It's very simple: create a new timer, arm it, and after a certain number
of
seconds it will trigger a signal to your application:

timer = Posix::Timer.new
timer.arm(10.0)

# do some stuff for 10 seconds

10 seconds later => SignalException

You can specify a different signal than the default SIGALRM:

Posix::Timer.new("USR1")

or you can pass a block to the initializer and have it executed upon
timeout:

a = Posix::Timer.new do
  puts "hi"
  raise MyCustomException
end

a.arm(10.0)

# 10 seconds later => MyCustomException


Other features:

a.disarm   # disarm the timer
a.armed? # true or false
a.timeout # return number of seconds until timer expires



#
# Caveats
#
#
# The Posix::Timer instance uses POSIX signals to trigger
# the timeouts.  This may conflict with other signals you wish to
# use in your application.
#
# Passing a block to the constructor will perform a Signal.trap on
# the signal.  This may override an existing Signal.trap.  In a future
# version I intend to rollback the previous trap context.
#
# Multiple timers using the same signal may conflict.
Joel VanderWerf (Guest)
on 2005-12-12 20:01
(Received via mailing list)
Caleb T. wrote:
> http://rubyforge.org/projects/posixtimer/

I'd be really interested in knowing how this performs compared to simply
using using ruby threads and #sleep (e.g. timeout.rb or similar
mechanisms). In a lightly/moderately/heavily loaded environment, are the
timing errors worse or better? How about reliability? If there are
several posix timers armed, do signals get lost if one handler is
running while another expires?
Caleb T. (Guest)
on 2005-12-12 21:58
(Received via mailing list)
> I'd be really interested in knowing how this performs compared to simply
> using using ruby threads and #sleep (e.g. timeout.rb or similar
> mechanisms). In a lightly/moderately/heavily loaded environment, are the
> timing errors worse or better? How about reliability? If there are
> several posix timers armed, do signals get lost if one handler is
> running while another expires?

I have a feeling it's implementation dependent.  I'll plan to run a few
tests
on it to see what kind of performance I get, though.

Caleb
Sylvain J. (Guest)
on 2005-12-12 23:22
(Received via mailing list)
> > How about reliability? If there are
> > several posix timers armed, do signals get lost if one handler is
> > running while another expires?
It depends on the kind of signal used. For posix timers, it is
recommended
to use real-time signals, because they are queued.
Caleb T. (Guest)
on 2005-12-12 23:34
(Received via mailing list)
> It depends on the kind of signal used. For posix timers, it is recommended
> to use real-time signals, because they are queued.

Yep - I'm working on that for the next release.

Caleb
speechexpert (Guest)
on 2005-12-12 23:43
(Received via mailing list)
OK - Here's my issue
My Outlook Expres is getting bogged down by the 50,000 or so emails I
have
on Ruby and Rails ml's.
I find searching these lists a valuable source of information.
I tried to search the archives directly, and my impression is the search
engine was slow and unreliable.

How do you all solve this problem, since it must be a common issue.
??

Thanks in advance,

John B
Eero S. (Guest)
on 2005-12-12 23:54
speechexpert wrote:
> OK - Here's my issue
> My Outlook Expres is getting bogged down by the 50,000 or so emails I
> have
> on Ruby and Rails ml's.
> I find searching these lists a valuable source of information.
> I tried to search the archives directly, and my impression is the search
> engine was slow and unreliable.
>
> How do you all solve this problem, since it must be a common issue.
> ??

Google with the site: parameter.

By the way, it looks like may have committed the dreaded
'thread hijack attack' where you reply to an unrelated
message. This may cause a problem with threading mailreaders
(as well as the archives) so try to avoid it :)

> Thanks in advance,
>
> John B


E
Bill G. (Guest)
on 2005-12-13 00:04
(Received via mailing list)
On 12/12/05, speechexpert <removed_email_address@domain.invalid> wrote:
> OK - Here's my issue
> My Outlook Expres is getting bogged down by the 50,000 or so emails I have
> on Ruby and Rails ml's.
> I find searching these lists a valuable source of information.
> I tried to search the archives directly, and my impression is the search
> engine was slow and unreliable.
>
> How do you all solve this problem, since it must be a common issue.
> ??

Some of us use gmail.  It's an excellent way to read lists.  Can send
you an invite if you like.
Gregory B. (Guest)
on 2005-12-13 04:44
(Received via mailing list)
On 12/12/05, Bill G. <removed_email_address@domain.invalid> wrote:
>
> Some of us use gmail.  It's an excellent way to read lists.  Can send
> you an invite if you like.

I use Gmail and generally love it, but two annoying things for anyone
considering using it to view lists:

1) It doesn't thread

2) It sends you a copy of your own messages you've sent, giving the
appearance of double posts.
(unless you set up a filter, then you dont see your posts at ALL

On the good side of things, the search is wonderful and it's very easy
to set up filters for various things.   Of course, thunderbird has
good things going for it too, but if you're on many computers in the
course of a day.  (I constantly mention that I frequent five different
OSes in the course of a day), having a web based system is great.

You can also search the mailing lists on google groups or ruby-forum.com
Dick D. (Guest)
on 2005-12-13 18:32
(Received via mailing list)
On 13/12/05, Gregory B. <removed_email_address@domain.invalid> wrote:

> I use Gmail and generally love it, but two annoying things for anyone
> considering using it to view lists:
>
> 1) It doesn't thread

Isn't that what a 'conversation' is?

> 2) It sends you a copy of your own messages you've sent, giving the
> appearance of double posts.

only on some lists (this being one of them)
Gregory B. (Guest)
on 2005-12-13 20:36
(Received via mailing list)
On 12/13/05, Dick D. <removed_email_address@domain.invalid> wrote:
> On 13/12/05, Gregory B. <removed_email_address@domain.invalid> wrote:
>
> > I use Gmail and generally love it, but two annoying things for anyone
> > considering using it to view lists:
> >
> > 1) It doesn't thread
>
> Isn't that what a 'conversation' is?

Actually, yes and no.
I should have said it doesn't nest threads.

In Gmail, all your conversations are one big long thread(for each
subject), but it doesn't have a tree view.

OTOH, Google G. does, so I'm surprised it's not in Gmail yet.
Gene T. (Guest)
on 2005-12-13 21:33
(Received via mailing list)
speechexpert wrote:
> OK - Here's my issue
> My Outlook Expres is getting bogged down by the 50,000 or so emails I have
> on Ruby and Rails ml's.
> I find searching these lists a valuable source of information.
> I tried to search the archives directly, and my impression is the search
> engine was slow and unreliable.
>

This is a major win for Redmond: Outlook Express scales!

Searching is art and science.  The basic problems are
polysemy/synonymy, which are loosely related to precision/recall ( i
actually believe reading the lucene book will help you formulate better
searches, you see both sides of the coin)..  Basically you need to
define a subset of c.l.ruby to search, and think of all the synonyms
you can.  A hash is a dict/mapping/associative array.  There are data
structures named lists, arrays, containers, queues, sets, stacks, bags,
enumerations, ring buffers, deques, linked lists, heaps etc. etc.
This topic is locked and can not be replied to.