[30588] in Perl-Users-Digest
Perl-Users Digest, Issue: 1831 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Sep 1 18:09:44 2008
Date: Mon, 1 Sep 2008 15:09:05 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Mon, 1 Sep 2008 Volume: 11 Number: 1831
Today's topics:
ANNOUNCE: Text-CSV_XS 0.53 <h.merijn@xs4all.nl>
Integrating Inline-C-based module into a Perl distribut <th@example.invalid>
Re: is there a GUI for Perl to display large tree struc <zentara@highstream.net>
Re: is there a GUI for Perl to display large tree struc <smallpond@juno.com>
Re: List Context in a Boolean Expression <benkasminbullock@gmail.com>
Re: perl multithreading performance dniq00@gmail.com
Re: Proper way to install module that uses shared libs <benkasminbullock@gmail.com>
Re: The Importance of Terminology's Quality (Rob Warnock)
Re: The Importance of Terminology's Quality (Robert Maas, http://tinyurl.com/uh3t)
Re: The Importance of Terminology's Quality <martin@see.sig.for.address.invalid>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 1 Sep 2008 07:19:16 GMT
From: "H.Merijn" <h.merijn@xs4all.nl>
Subject: ANNOUNCE: Text-CSV_XS 0.53
Message-Id: <K6ILvC.Aw1@zorch.sf-bay.org>
file: $CPAN/authors/id/H/HM/HMBRAND/Text-CSV_XS-0.53.tgz
size: 90623 bytes
md5: 29e421cbcccf8daf1bb560e5db07fc7c
I had to raise the minimal perl version from 5.005 to 5.005_03
2008-09-01 0.53 - H.Merijn Brand <h.m.brand@xs4all.nl>
* SvUPGRADE is a safer choice than sv_upgrade (Lubomir Rintel,
RT#38890)
* bring docs in sync with reality for msg 2023
* Default eol for print is $\
* examples/csv-check should default to CSV , not to ;
* Tests for SetDiag (0)
* Tests for error 2030
* Code cleanup (Devel::Cover++)
2008-06-28 0.52 - H.Merijn Brand <h.m.brand@xs4all.nl>
* Using undef for hash keys is a bad plan
* Fix, tests, and documentation for column_names ()
2008-06-17 0.51 - H.Merijn Brand <h.m.brand@xs4all.nl>
* Allow UTF8 even without binary => 1
* Fixed a few pod typo's
* Lifted the max of 255 for bind_columns
------------------------------
Date: Mon, 01 Sep 2008 17:49:41 +0200
From: Thomas <th@example.invalid>
Subject: Integrating Inline-C-based module into a Perl distribution
Message-Id: <g9h2ul$ka6$1@aioe.org>
I want to integrate my module Foo.pm which relies on Inline::C into an
existing Perl distribution. Luckily, I can add directories and files to
perl/site/lib and perl/site/lib/auto as I please and give the complete
Perl directory tree to the user to run it. (I *don't* want my module to
become a part of any official distribution or CPAN, that's not what this
is about.)
However, I still set libraries I depend on as absolute paths in the LIBS
setting of my use Inline statement (..., 'LIBS => c:/foo/bar.lib', ...).
Unfortunately, I can't keep doing that. I can't influence where the perl
directory tree will be installed (could be c:\perl, d:\perl). What am I
supposed to use as LIBS value? Where should the .lib files (or .so under
Unix) go?
What's the standard way of distributing a module like mine? I have seen
the Math::Simple example in
http://search.cpan.org/~ingy/Inline-0.44/Inline.pod#Writing_Modules_with_Inline
However, I haven't followed that way (calling h2xs -PAXn Math::Simple
and extending that). I have two Windows .lib files I depend on and the
DLL and other files Inline created in
/build/Foo_a3d7/blib/arch/auto/Foo_a3d7 Everything works fine with
absolute paths, but the exact configuration is my (last) obstacle. BTW,
I also depend on the files Inline built to remain unchanged -- the
user's system does not have a compiler or make to do the compilation.
Thanks in advance!
------------------------------
Date: Mon, 01 Sep 2008 08:22:53 -0400
From: zentara <zentara@highstream.net>
Subject: Re: is there a GUI for Perl to display large tree structures ?
Message-Id: <58nnb41q8l2krme381tktlmbd2glcrmu94@4ax.com>
On Sun, 31 Aug 2008 16:41:34 -0700 (PDT), Woland99 <woland99@gmail.com>
wrote:
>I am looking for a way to display large tree structure - 60-70,000
>nodes
>resulting from parsing source code for an OO language. I tried Tk
>widget
>in the best but it would choke. I know it can be done in VB but I was
>curious
>if there are any GUI toolkits in Perl capable of doing it.
>At the beginning I would like the tree nodes to be all collapsed and I
>would
>like to be able to do regexp searh for a node that would result in
>expansion
>of intermediate nodes. Essentially I need a source code browser for
>a proprietary (Java like) language.
>
>TIA for any pointers/info/references,
>
>JT
Gtk2 will probably handle it better than Tk. Try this, pulled from some
maillist. The Perl code can be converted to c for more speed.
Or google for "Gtk2 xmlviewer" for other Perl viewers.
#!/usr/bin/perl
use strict;
use warnings;
use constant TRUE => 1;
use constant FALSE => !TRUE;
use Gtk2 -init;
use XML::Simple;
# Read the xml file into a hash using the XML::Simplemodule
my $tree_xml_file = 'tree-from-xml-data.xml'; # or use shift
my $data_tree = XMLin( $tree_xml_file, forcearray => 1 );
# Define the columns in the order to be seen
my $all_columns = [
{ ColumnName => 'Name' },
{ ColumnName => 'Color' },
{ ColumnName => 'Price' },
{ ColumnName => 'Taste' },
{ ColumnName => 'Source' }
];
# Let us choose to freeze the first column
my $frozen_columns = [ $all_columns->[ 0 ] ];
# Create two arrays for sending into the Gtk2::TreeStore->new method
my @tree_store_full_types =
map { 'Glib::String' } @$all_columns;
my @tree_store_frozen_types = map { 'Glib::String' } @$frozen_columns;
# Create the 'full' tree on the right side pane
my $tree_store_full = Gtk2::TreeStore->new( @tree_store_full_types );
my $tree_view_full = Gtk2::TreeView->new( $tree_store_full );
my $column_count = 0;
for my $column ( @$all_columns ) {
my $column_name = $column->{ ColumnName };
my $column = Gtk2::TreeViewColumn->new_with_attributes(
$column_name,
Gtk2::CellRendererText->new(),
text => $column_count
);
$column->set_resizable( TRUE );
$tree_view_full->append_column( $column );
# Hide the first column
# Ensure that the expander is fixed to the first
# column( and hence is hidden too )
if ( $column_count == 0 )
{
$column->set_visible( FALSE );
$tree_view_full->set_expander_column( $column );
}
$column_count++;
}
# Create the single column tree for the left side pane
my $tree_store_frozen = Gtk2::TreeStore->new( @tree_store_frozen_types
);
my $tree_view_frozen = Gtk2::TreeView->new( $tree_store_frozen );
# There is only one column (the first column) in this case
my $column_name = $frozen_columns->[ 0 ]->{ ColumnName };
my $column =
Gtk2::TreeViewColumn->new_with_attributes( $column_name,
Gtk2::CellRendererText->new(),
text => 0 );
$column->set_resizable( TRUE );
$tree_view_frozen->append_column( $column );
# Synchronize the frozen-tree with the full-tree
$tree_view_frozen->signal_connect(
'row-expanded' => sub {
my ( $view, $iter, $path ) = @_;
$tree_view_full->expand_row( $path, 0 );
}
);
$tree_view_frozen->signal_connect(
'row-collapsed' => sub {
my ( $view, $iter, $path ) = @_;
$tree_view_full->collapse_row( $path );
}
);
# Recursive function to actually create the tree
append_children( $tree_view_full->get_model(), undef, $data_tree,
$all_columns );
append_children( $tree_view_frozen->get_model(),
undef, $data_tree, $frozen_columns );
# Add the frozen-tree to the left side of the pane
my $paned = Gtk2::HPaned->new;
$paned->add1( $tree_view_frozen );
# we set the vertical size request very small, and it ill fill up the
# available space when we set the default size of the window .
$tree_view_frozen->set_size_request( -1, 10 );
# Add the full-tree to a scrolled window in the right pane
my $scroll = Gtk2::ScrolledWindow->new;
$scroll->add( $tree_view_full );
$paned->add2( $scroll );
# Synchronize the scrolling
$tree_view_frozen->set( vadjustment => $tree_view_full->get_vadjustment
);
# Create a new window and add the pane into it
my $window = Gtk2::Window->new;
$window->signal_connect(
destroy => sub {
Gtk2->main_quit;
}
);
$window->add( $paned );
$window->set_default_size( 300, 100 );
$window->show_all;
Gtk2->main;
# The obligatory recursive function to display the tree
# I don't know the performance implications of using recursion,
# but it seems easy to write and understand
sub append_children {
my ( $tree_store, $iter, $data_tree, $columns ) = @_;
if ( $data_tree ) {
my $count = 0;
my $child_iter = $tree_store->append( $iter );
for my $column ( @$columns ) {
my $column_name = $column->{ ColumnName };
if ( $data_tree->{ $column_name } ) {
$tree_store->set( $child_iter, $count,
$data_tree->{ $column_name } );
}
$count++;
}
foreach my $child ( @{ $data_tree->{ 'Node' } } ) {
append_children( $tree_store, $child_iter, $child, $columns );
}
}
}
__END__
zentara
--
I'm not really a human, but I play one on earth.
http://zentara.net/Remember_How_Lucky_You_Are.html
------------------------------
Date: Mon, 1 Sep 2008 07:42:53 -0700 (PDT)
From: smallpond <smallpond@juno.com>
Subject: Re: is there a GUI for Perl to display large tree structures ?
Message-Id: <047beb81-d72f-4986-bc6a-09f2c06fd4ee@k30g2000hse.googlegroups.com>
On Aug 31, 7:41 pm, Woland99 <wolan...@gmail.com> wrote:
> I am looking for a way to display large tree structure - 60-70,000
> nodes
> resulting from parsing source code for an OO language. I tried Tk
> widget
> in the best but it would choke. I know it can be done in VB but I was
> curious
> if there are any GUI toolkits in Perl capable of doing it.
> At the beginning I would like the tree nodes to be all collapsed and I
> would
> like to be able to do regexp searh for a node that would result in
> expansion
> of intermediate nodes. Essentially I need a source code browser for
> a proprietary (Java like) language.
>
> TIA for any pointers/info/references,
>
> JT
On a 1GHz Athlon, 100,000 calls to Tk::HList::addchild took
12 seconds. That's too slow?
--S
------------------------------
Date: 01 Sep 2008 12:52:19 GMT
From: Ben Bullock <benkasminbullock@gmail.com>
Subject: Re: List Context in a Boolean Expression
Message-Id: <48bbe582$0$522$c5fe31e7@reader.usenet4all.se>
On Sat, 16 Aug 2008 02:05:47 -0700, h3xx wrote:
> I have a question about when things are and aren't taken to be a list
> when doing boolean comparisons. I tested the following code:
>
> my @foo = qw/ one two three /;
> my @bar = ();
>
> my @baz = @bar || @foo;
> print "@baz\n";
The || forces @bar into scalar context. scalar(@bar) = 0, so the left
hand side is false, so Perl evaluates the right hand side.
> This produces "one two three." Hence, we know that a list CAN be
> returned from a boolean expression. I tried it the other way:
>
> my @baz = @foo || @bar;
> print "@baz\n";
The || forces @foo into scalar context. scalar (@foo) = 3, so Perl never
evaluates the right hand side.
> This produced "3," the scalar evaluation of @foo. This is the same for
> any amount of parentheses and using the "or" operand instead of "||."
> Now, what happened?
You've really answered your own question. This is the behaviour of ||,
forces what's on the left of it into scalar context.
------------------------------
Date: Mon, 1 Sep 2008 09:17:37 -0700 (PDT)
From: dniq00@gmail.com
Subject: Re: perl multithreading performance
Message-Id: <50e81aea-2995-47a2-958b-d5bd1b2cea75@e39g2000hsf.googlegroups.com>
On Aug 27, 3:59=A0pm, dni...@gmail.com wrote:
> Hope anybody can enlighten me...
>
> THANKS!
Hello again, oh almighty All! :)
The amount of useful information to my post has been great, and I
REALLY appreciate all the input so far! I've gotten some ideas from
your responses on what I can do, and will try a few things once the
holiday is over. I guess I will have to abandon the <> approach and
parse files instead. I kinda love, though, the advantage that the <>
gives me: my script doesn't need to know what and how much it is being
given. Be it a list of files (many small ones, or fewer large ones), a
pipe or whatever - it doesn't care.
Initially, the first multithreaded version I've made, processed the
data line-by-line, with reader thread pushing each line to the queue,
and parser threads yanking a line out of it. The performance was
absolutely horrible - it consumed 3 times more CPU, and worked 3 times
slower than a single-threaded process (about 10-11 thousand lines per
second). That's why I started splitting the data into chunks and
pushing references to the chunks into the queue, which helped a bit,
but not by much.
Tomorrow I'm going to try to take a list of files and split it across
the worker threads, to see if it gives me an improvement. Not sure yet
if I want to go the mmap way, though, but probably I will give it a
try as well. I'm trying to make my script as independent of the way
it's being fed the data as possible, so I will have to find the best
way to handle as many situations as I can.
To answer a few questions asked in the thread: the $counters, produced
by each worker thread, are then being aggregated, serialized and
written to a file (this doesn't take much time and resources), which
is then processed by another script, which stores all the data into an
Oracle database. I've done that so that there can be multiple servers,
processing data, without adding more load on the database, which is,
as you might imagine, already very busy as it is :)
Again, thanks a million for all the great ideas! I will report back
with my results, if anyone cares ;)
With best regards - Dmitry.
^D
------------------------------
Date: 01 Sep 2008 12:55:42 GMT
From: Ben Bullock <benkasminbullock@gmail.com>
Subject: Re: Proper way to install module that uses shared libs
Message-Id: <48bbe64e$0$522$c5fe31e7@reader.usenet4all.se>
On Wed, 13 Aug 2008 11:53:30 -0700, B wrote:
> Does anyone know the proper way to install a Perl module on Linux that
> loads several shared libraries? For standard libs that comes with
> Perl, the .so files are in the ${PERL_HOME}/i386-linux-thread-multi/
> auto directory. Is this where my libs should go also? I do not want to
> depend on LD_LIBRARY_PATH if at all possible. Also, what about
> managing versions? Is there a document that describes best practices
> for handling this scenario?
There are a lot of documents describing best practices in Perl, and
usually they disagree with each other. I'm not clear if you're a module
author or someone trying to install modules. If you're a module author,
then I recommend trying "Module::Starter" and "Module::Install" and
rooting around CPAN's documentation. If you're someone trying to install
modules, the best advice is to use cpan (a command line program which
comes with Perl) or ppm (comes with ActiveState Perl) if you are on
Windows.
------------------------------
Date: Mon, 01 Sep 2008 05:55:26 -0500
From: rpw3@rpw3.org (Rob Warnock)
Subject: Re: The Importance of Terminology's Quality
Message-Id: <VeOdnUJG6cODVybVnZ2dnUVZ_qjinZ2d@speakeasy.net>
Robert Maas, <jaycx2.3.calrobert@spamgourmet.com.remove> wrote:
+---------------
| > From: rpw3@rpw3.org (Rob Warnock)
| > In the LGP-30, they used hex addresses, sort of[1], but the
| > opcodes (all 16 of them) had single-letter mnemonics chosen so that
| > the low 4 bits of the character codes *were* the correct nibble for
| > the opcode! ;-}
...
| By the way, do you remember exactly all the 16 opcodes, or have a
| Web reference available?
+---------------
There are quite a few out there; here's one:
http://www.users.nwark.com/~rcmahq/jclark/lgp30.htm
Some notes on the opcodes:
- "Bring" (B) would be called "Load" in current parlance.
- "Extract" (E) would be called "And" in current parlance.
- "Unconditional Transfer" (U) would be called "Jump" or "Branch".
- "Hold" (H) would be called "Store"; "Clear" (C) would be called
"Store-and-Clear" (the "DCA" instruction of the DEC PDP-8).
- There are two "Multiply" ops, "M" & "N", depending on whether the
upper or lower bits (respectively) of the product are returned.
- "Store Address" (Y) stores an address in the AC into the address
field of the destination [yes, modifying the code in-place!! --
it was mostly used for indexing through arrays], whereas the
"Return Address" (R) stores the current instruction address + 2
into the address field of the destination. The subroutine calling
sequence is thus an "R/U" pair:
R foo_last
U foo
where the FOO subroutine might be written as:
foo: ...
...
foo_last: U foo_last ; overwritten
+---------------
| > The LGP-30 character code was defined before the industry had
| > yet standardized on a common "hex" [sic, "hexadecimal", base 16
| > not base 6!!!] character set,
...
| > they used "0123456789fgjkqw".
|
| That doesn't make sense. The low-order four bits of those letters
| aren't consecutive ascending values from 9+1 to 9+6. Did you make a
| typo, or did you explain something wrong?
+---------------
No, what I wrote is correct. The low 4 bits of "0123456789fgjkqw"
*are* 0 through 16 (or "0123456789abcdef" in current "hex")... IN
THE *LGP-30 FLEXOWRITER* CHARACTER CODE, *not* in ASCII or EBCDIC
or Baudot or any other standard code.
Well, actually, it's a little more complex than that. The LGP-30
used a 6-bit "keyboard" code on the Flexowriter (and the paper tape
reader & punch), but the machine could be put into either 6-bit or
4-bit input mode. In the latter, only the first four bits of each code
got shifted into the accumulator. So I suppose you could say those
were the *upper* 4 bits of each character, though when read into
the accumulator in "4-bit input mode" they truly *were* the lower
4 bits. (Sorry for the confusion. It was an "interesting" machine.)
+---------------
| (map 'list #'char-code "0123456789fgjkqw")
| => (48 49 50 51 52 53 54 55 56 57 102 103 106 107 113 119)
+---------------
That's ASCII. The LGP-30 did not use ASCII. The LGP-30 used
Flexowriter keyboard code, see:
http://ed-thelen.org/comp-hist/lgp-30-man-f002.gif
-Rob
p.s. The full programming manual for the LGP-30 can be found here:
http://ed-thelen.org/comp-hist/lgp-30-man.html
but good luck reading its archaic style. ;-}
-----
Rob Warnock <rpw3@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
------------------------------
Date: Mon, 01 Sep 2008 12:04:05 -0700
From: jaycx2.3.calrobert@spamgourmet.com.remove (Robert Maas, http://tinyurl.com/uh3t)
Subject: Re: The Importance of Terminology's Quality
Message-Id: <rem-2008sep01-004@yahoo.com>
> From: George Neuner <gneun...@comcast.net>
> A friend of mine had an early 8080 micros that was programmed
> through the front panel using knife switches
When you say "knife switches", do you mean the kind that are shaped
like flat paddles? I think that would be the IMSAI, which came
after the ALTAIR. Those flat paddle-shaped switched would
presumably be much more comfortable on the fingers than the
standard metal toggle switches on the ALTAIR. I had an ALTAIR,
which made front-panel programming rather painful on the fingers.
> ... toggle in the binary address, latch it, toggle in the binary
> data, latch it, repeat ad nauseam.
For manually loading software in sequential locations, you have to
enter the binary address only once. After that, you press the
EXAMINE-NEXT toggle to increment the address by one. That reduced
the effort by nearly a factor of 3. Instead of toggling a 16-bit
address and EXAMINE and 8-bit datum and STORE each time, you toggle
just EXAMINE-NEXT and 8-bit datum and STORE for each consecutive
memory location after the first. Note the address and data toggles
are bistable, stay in whatever position you left them in, whereas
the three control toggles (EXAMIME EXAMINE-NEXT STORE) are spring
loaded, making momentary contact when you force them then spring
back to inactive when you release them.
> It had no storage device initially ... to use it you had to input
> your program by hand every time you turned it on.
Almost but not quite true. With static RAM, most of the data can
survive power-downs of hours or even days. I had 28k bytes of
static RAM on my ALTAIR, so if I needed to start it up after it had
been shut down I'd toggle in the starting address by hand, EXAMINE
that, compare what shows with what's on my printed listing, and if
it matches just EXAMINE-NEXT to compare the next. In the few cases
I saw a bit or two flipped, I'd re-enter that one byte of data.
I had to do that only for my BOOT1 loader, which was hand-loaded
from front panel and took text input in 3n+1 form from Beehive 3A
terminal connected to serial port, maybe also for BOOT2 loader
which had been loaded in 3n+1 form and took input in hexadecimal
form, and maybe also for BOOT3 loader which had been loaded in
hexadecimail form from Beehive and automatically downloaded the
next bootstrap loader from modem. If only a few bytes (of BOOT2 or
BOOT3) had been damaged by days of power down, comparing binary
against listing to verify it's 99% correct, and then manually
patching just one or two bytes, would be faster and safer than
manually entering 3n+1 or hexadecimal from keyboard. But once BOOT3
was loaded, I always downloaded all the rest of the software from
the PDP-10 over the modem.
> I did a little bit of programming on it, but I tired of it quickly.
Did your friend's machine have two serial ports, one for local
terminal and one for modem, and did you have access to a remote
PDP-10 or other mainframe for running a cross-assembler? Or did you
have some other computer locally available, where you could use
that other computer both to store your library of code and to
perform automated file transfer from archive on other computer to
where it's needed on IMSAI?
> As did my friend - once he got the tape storage working (a new
> prom)
Yeah, I never had the money to buy that, and with the PDP-10
available for both cross-assembling and archiving/downloading, I
didn't need it.
> Machine coding is not relevant anymore - it's completely
> infeasible to input all but the smallest program.
That's not totally true. For some educational purposes, like
*really* understanding pointers (not the kind in C so much as the
kind that are inherent in all pointer-linked data structures such
as linked lists and binary search trees etc.), it helps to have
some "hands-on" experience writing and executing machine-language
code, in a sense actually "seeing" a register first point to the
first byte of a CONS cell then by indexing with offset pointing
*through* the *second* pointer of that CONS cell to whatever the
CDR points to. Then "mission impossible" when your instructor tells
you to see if there's a way to reverse that process, whereby you
are given the register pointing to whatever the CDR points to, and
you are supposed to find the address of the original CONS cell.
Instant enlightenment, no lecture/sermon needed!
------------------------------
Date: Mon, 1 Sep 2008 21:03:44 +0000 (UTC)
From: Martin Gregorie <martin@see.sig.for.address.invalid>
Subject: Re: The Importance of Terminology's Quality
Message-Id: <g9hlbf$liu$1@localhost.localdomain>
On Mon, 01 Sep 2008 12:04:05 -0700, Robert Maas, http://tinyurl.com/uh3t
wrote:
>> From: George Neuner <gneun...@comcast.net> A friend of mine had an
>> early 8080 micros that was programmed through the front panel using
>> knife switches
>
> When you say "knife switches", do you mean the kind that are shaped like
> flat paddles?
>
Pedantic correction:
"Knife switch" is the wrong term. These are high current switches,
typically used in the sort of heavy duty circuit where the wiring hums
when power is on or in school electrical circuits so even the back of the
class can see whether the switch is open or closed. In these a copper
'blade' closes the contact by being pushed down into a
narrow, sprung U terminal that makes a close contact with both sides of
the blade. Like this: http://www.science-city.com/knifeswitch.html
What you're talking is a flat handle on a SPST or DPST toggle switch. It
is often called a paddle switch and mounted with the flats on the handle
horizontal. Like this, but often with a longer handle:
http://www.pixmania.co.uk/uk/uk/1382717/art/radioshack/spdt-panel-mount-
paddle-s.html
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 1831
***************************************
