Shlomi Fish | 31 Jul 2010 10:14
Picon
Gravatar

Fwd: Rakudo Star - a useful, usable, "early adopter" distribution of Perl 6


----------  Forwarded Message  ----------

Subject: Rakudo Star - a useful, usable, "early adopter" distribution of Perl 
6
Date: Thursday 29 July 2010, 15:23:35
From: "Patrick R. Michaud" <pmichaud <at> pobox.com>
To: perl6-language <at> perl.org, perl6-compiler <at> perl.org, perl6-users <at> perl.org, 
parrot-dev <at> lists.parrot.org

On behalf of the Rakudo and Perl 6 development teams, I'm happy to
announce the July 2010 release of "Rakudo Star", a useful and usable
distribution of Perl 6.  The tarball for the July 2010 release is
available from <http://github.com/rakudo/star/downloads>.

Rakudo Star is aimed at "early adopters" of Perl 6.  We know that
it still has some bugs, it is far slower than it ought to be, and
there are some advanced pieces of the Perl 6 language specification
that aren't implemented yet.  But Rakudo Perl 6 in its current form
is also proving to be viable (and fun) for developing applications
and exploring a great new language.  These "Star" releases are
intended to make Perl 6 more widely available to programmers, grow
the Perl 6 codebase, and gain additional end-user feedback about the
Perl 6 language and Rakudo's implementation of it.

In the Perl 6 world, we make a distinction between the language 
("Perl 6") and specific implementations of the language such as
"Rakudo Perl".  "Rakudo Star" is a distribution that includes
release #31 of the Rakudo Perl 6 compiler [1], version 2.6.0 of
the Parrot Virtual Machine [2], and various modules, documentation,
(Continue reading)

Don Marti | 31 Jul 2010 17:42

Fun* with ssh tunnels

For some reason I often end up thinking about the
problem of doing this in a script: bring up an ssh
tunnel, do something over the tunnel, drop the tunnel.
For example, I send outgoing queued mail from my
laptop over a tunnel to my mail server.

I used to do this something like...

  ssh -L 10025:localhost:25 $MAILHOST sleep 5 &

...then sleep on the client to allow for the tunnel to
come up, then do the thing that has to connect over
the tunnel (in this case connect to the configured
"smarthost" which is localhost, port 25.

But this is kind of inelegant and requires tweaking
sleep times.   And you get the unavoidable problem
of having to sleep long enough to allow for the
slowest possible time to bring up the tunnel.
So here's what I came up with a little while ago,
and if you're reading this it actually works.

Start an ssh connection to the server with two tunnels
on it.  One forwards local port 10025 to the server's
SMTP port, and the other forwards port 10022 on the
server back to the client's ssh port.  And instead of
running "sleep" or something on the server to hold the
tunnel open until the flow of data starts, run ssh on
the server, using one tunnel to ssh back to the client
to run the command that has to use the other tunnel.
(Continue reading)


Gmane