alive results from the CPAN

App-Chart

                                (chartprog-process-filter chartprog-process "")))
                 (setq form nil))

               ;; process another form, perhaps
               form)))))

(defun chartprog-process-sentinel (proc event)
  "An internal part of chartprog.el.
The sentinel for the chart subprocess per `set-process-sentinel'.

The subprocess should stay alive forever, until we ask it to stop
by the `chartprog-process-timer, so any termination is
unexpected."
  (when (get-buffer "*chartprog-watchlist*")
    (with-current-buffer "*chartprog-watchlist*"
      (let ((inhibit-read-only t))
        (save-excursion
          (goto-char (point-min))
          (when (looking-at "\\s-*Starting")
            (erase-buffer))
          (insert (format "\nSubprocess died: %s\n\n" event))))))

lib/App/Chart/Download.pm view on Meta::CPAN

      $etag    = App::Chart::Database->read_extra($symbol,"$key-ETag");
      $lastmod = App::Chart::Database->read_extra($symbol,"$key-Last-Modified");
    }
  }

  if ($etag)    { $req->header ('If-None-Match' => $etag); }
  if ($lastmod) { $req->header ('If-Modified-Since' => $lastmod); }

  my $resp = $ua->request ($req);

  # internal message from LWP when a keep-alive has missed the boat
  if ($resp->status_line =~ /500 Server closed connection/i) {
    substatus (__('retry'));
    $resp = $ua->request ($req);
  }

  my $code = $resp->code;
  if ($resp->is_success
      || ($options{'allow_401'} && $code == 401)
      || ($options{'allow_404'} && $code == 404)
      || (($etag || $lastmod) && $code == 304)

lib/App/Chart/Glib/Ex/DirBroadcast.pm view on Meta::CPAN

Connect coderef C<$osubr> to be called for notifications of C<$key>, for as
long as Perl object C<$obj> exists.  C<$obj> is the first argument in each
call, followed by the notify data,

    sub my_func {
      my ($obj, $data...) = @_;
    }

If C<$obj> is destroyed then C<$osubr> is no longer called.  Only a weak
reference to C<$obj> is kept, so just because it wants to hear about some
notifications it won't keep it alive forever.

=back

=head1 SEE ALSO

L<Glib>, L<Glib::MainLoop>

=cut

lib/App/Chart/Glib/Ex/MoreUtils.pm view on Meta::CPAN

 use App::Chart::Glib::Ex::MoreUtils;

=head1 FUNCTIONS

=over 4

=item C<< App::Chart::Glib::Ex::MoreUtils::ref_weak ($obj) >>

Return a reference to a weak reference to C<$obj>.  This is good for the
"userdata" in signal connections etc when you want some weakening so you
don't keep C<$obj> alive forever due to the connection.  For example,

    $model->signal_connect (row_deleted, \&deleted_handler,
                            App::Chart::Glib::Ex::MoreUtils::ref_weak($self));

    sub deleted_handler {
      my ($model, $path, $ref_weak_self) = @_;
      my $self = $$ref_weak_self || return;
      ...
    }

lib/App/Chart/Glib/Ex/SignalBlock.pm view on Meta::CPAN


instead use

    {
      my $blocker = App::Chart::Glib::Ex::SignalBlock->new ($obj,$id);
      ...
      # automatic signal_handler_unblock when $blocker out of scope
    }

SignalBlock holds weak references to the target objects, so the mere fact a
signal is blocked won't an object alive once nothing else cares if it lives
or dies.

=back

=head1 OTHER NOTES

When there's multiple signals in a SignalBlock it's currently unspecified
what order the unblock calls are made.  (What would be good?  First-in
first-out, or a stack?)  You can create multiple SignalBlock objects and
arrange your blocks to destroyed them in a particular order if it matters.

lib/App/Chart/Gtk2/Ex/GdkColorAlloc.pm view on Meta::CPAN

                                              raise_error => 0);
    if (! $color) {
      print "cannot allocate writable colour\n";
    }

=item C<< $color->colormap >>

Return the C<Gtk2::Gdk::Colormap> in which C<$color> is allocated.

A GdkColorAlloc object keeps a reference to its colormap, so the colormap
will remain alive for as long as there's a GdkColorAlloc object using it.

=back

=head1 OTHER NOTES

Each C<< $colormap->alloc_color >> does a round-trip to the X server, which
may be slow if you've got thousands of colours to allocate.  An equivalent
to the mass-allocation of C<alloc_colors> or the plane-oriented
C<gdk_colors_alloc> would be wanted for big colour sets, but chances are if
you're working with thousands of colours you'll want a pattern in the pixel

lib/App/Chart/Gtk2/JobQueue.pm view on Meta::CPAN

use Glib::Object::Subclass
  'Gtk2::ListStore';

use Class::Singleton 1.03; # 1.03 for _new_instance()
use base 'Class::Singleton';
*_new_instance = \&Glib::Object::new;


# Had some trouble during program exit with Job 'status-changed' emissions
# reaching our _do_job_status_changed() after we have been DESTROY'ed.  This
# must be late in exit since the singleton keeps us alive globally.  But
# it's not at global destruction, according to Devel::GlobalDestruction.
#
# In any case an explicit disconnect of $self->{'hook'} stops the emission.
#
# Normally DESTROY is wrong for Glib::Object subclasses since it's called
# variously when the object loses its last Perl reference but not last C
# reference, or something like that.  But here as a global the last Perl
# reference means program exit.
#
sub DESTROY {

lib/App/Chart/Suffix/LME.pm view on Meta::CPAN

use constant DEBUG => 0;


# As of July 2007, in https requests to secure.lme.com for the daily metals
# prices it seems essential to use http/1.1 persistent connections.  If
# "Connection: close" is requested by the client something fishy happens and
# the connection hangs at about byte 48887 out of about 62110 (waiting for
# the last 16kbyte tls packet).  This is with either gnutls or openssl and a
# trace with gnutls shows it just stops sending, though the TCP connection
# remains up.  Either the default http/1.1 persistence (no Connection header
# at all) or the compatibility "Connection: keep-alive" style seems to make
# it better.  Presumably it's something buggy in the server (Microsoft-IIS
# 6.0).

my $pred = App::Chart::Sympred::Suffix->new ('.LME');
App::Chart::TZ->london->setup_for_symbol ($pred);

# App::Chart::setup_source_help
#   ($pred, __p('manual-node','London Metal Exchange'));

lib/App/Chart/UserAgent.pm view on Meta::CPAN

# Would have preferred to get this in via the UserAgent instance
# or class here, but looks like no way to get through to that
# protocol bits.
#
use LWP::Protocol::http;
push @LWP::Protocol::http::EXTRA_SOCK_OPTS, MaxLineLength => 0;


sub new {
  my ($class, %options) = @_;
  if (! exists $options{'keep_alive'}
      && ! exists $options{'conn_cache'}) {
    $options{'keep_alive'} = 1;  # connection cache 1 sock
  }
  if (! exists $options{'agent'}) {
    # not given, use our default
    $options{'agent'} = $class->_agent;
  } elsif (defined $options{'agent'} && $options{'agent'} =~ / $/) {
    # ends in space, append our default
    $options{'agent'} .= $class->_agent;
  }
  my $self = $class->SUPER::new (timeout => 60,  # seconds, default
                                 %options);

maybe/IdleObject.pm view on Meta::CPAN


=head1 DESCRIPTION

C<Gtk2::Ex::IdleObject> is an object-oriented wrapper around the
C<< Glib::Idle->add >> mechanism.  It automatically removes the idle from
the main loop just by forgetting the object, and an idle object can be
associated with a widget to have it stop if/when that widget is destroyed.

Automatic removal saves you fiddling about with C<< Glib::Source->remove >>
in a cleanup, and the widget version uses weak references so the widget
doesn't stay alive forever just because it's in an idle handler.

=head1 FUNCTIONS

=over 4

=item C<< Gtk2::Ex::IdleObject->new ($callback, [$userdata, [$priority]]) >>

Create and return a new idle object.  The parameters are the same as for
C<< Glib::Idle->add >>, but the return is an object instead of an ID number.

=item C<< Gtk2::Ex::IdleObject->new_weak ($callback, [$userdata, [$priority]]) >>

Create and return a new idle object which keeps only a weak reference to
its C<$userdata>, if C<$userdata> is a reference.

If the C<$userdata> object is being used nowhere other than the idle then
it's garbage collected and the idle makes no further C<$callback> calls.
This is an easy way to ensure the mere fact an idle is operating on a Perl
object won't keep it alive when nothing else is interested in it.

If C<$userdata> is not a reference then C<new_weak> is the same as plain
C<new> above.

=item C<< Gtk2::Ex::IdleObject->new_for_widget ($callback, $widget, [$priority]) >>

Create and return a new idle object with a C<Gtk2::Widget> as the
C<$userdata>.  The idle keeps only a weak reference to the widget, so that
if/when it's no longer used anywhere else then the widget is destroyed and
the idle stops.

t/ListStoreDBISeq.t view on Meta::CPAN

use lib 't';
use MyTestHelpers;
BEGIN { MyTestHelpers::nowarnings() }

use Test::More 0.82 tests => 1;

require App::Chart::Gtk2::Ex::ListStoreDBISeq;


# DBI::_new_dbh() and DBI::_new_sth() use substr() lvalue assignments which
# seems to keep the lexical target $imp_class alive, until the next call to
# each function, and that looks like a leak of the $imp_class values stored
# into $dbh->{'ImplementorClass'} and $sth->{'ImplementorClass'}, or rather
# in the underlying tied hash object.  Dunno if this is some perl 5.10.0
# thing, but as a hack make a new run of _new_dbh() and _new_sth() here to
# clear out the scratchpad.
#
sub hack_clear_new_handle_scratchpad {
  my $fh = File::Temp->new (TEMPLATE => 'dbh-scratchpad-XXXXXX',
                            SUFFIX => '.sqdb',
                            TMPDIR => 1);

( run in 0.964 second using v1.01-cache-2.11-cpan-df04353d9ac )