Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine
 
PerlMonks  

The Monastery Gates

( #131=superdoc: print w/replies, xml ) Need Help??

Donations gladly accepted

If you're new here please read PerlMonks FAQ
and Create a new user.

New Questions
Zip script not running on cron
1 direct reply — Read more / Contribute
by PerlMonger79
on Jul 18, 2019 at 11:24

    Hello. I have a script to find csv files and compress it into a zip file and save to another directory for archive. The script runs when I run it manually from the directory but it does not run when I put it to run as a cron job. What is wrong with my script? Please help.

    #!/usr/bin/perl -w use strict; use warnings; use POSIX qw/strftime/; use IO::Compress::Zip qw(:all); my $now = strftime("%d%b%Y_%H00", localtime(time - 60*60)); my $dir = "/path/to/directory/"; my $arc = "/path/to/archive/"; zip [ glob("*-".$now.".csv") ] => $arc.$now.".zip" or die "Cannot create zip file: $ZipError" ; unlink glob($dir."*-".$now.".csv");
smartmatch with multiple search values
5 direct replies — Read more / Contribute
by toohoo
on Jul 16, 2019 at 09:55

    Hello all,

    is there a way to search other than loop with smartmatch for multiple search values?

    My code below

    best regards

    #!/usr/bin/perl use v5.10; use experimental 'smartmatch'; no warnings 'experimental::smartmatch'; $VAR1 = [ '11', '14' ]; my @owner_grouprights = @$VAR1; if ( '11' ~~ @owner_grouprights ) { print "test3\n"; } # the big deal -- if it only would work if ( {4|5|6|7|8|9|10|11|12} ~~ @owner_grouprights ) { print "test2\n"; } my $owner_grouprights = join( ' ', @owner_grouprights ); # with loop my $testarrorig = '4|5|6|7|8|9|10|11|12'; my @testarr = split( /\|/, $testarrorig ); my $testarr = join( ' ', @testarr ); foreach $tst ( @testarr ) { given( $tst ) { when ( @owner_grouprights ) { print "$_ hit!\n"; } default { #print "$_ miss\n"; } } }
Can split split against more than one character in a string of the same character?
3 direct replies — Read more / Contribute
by Don Coyote
on Jul 15, 2019 at 16:29

    Using Padre's Regex Editor today, very nice tool. I thought I might be able to split a pattern on a string of the same character, but that didn't seem to want to play. I could use something like unpack, but wondered if there were any tricks to doing this using split?

    my @splitted = split /(?:(?=a{2})(?<=a{2}))/, 'aaaaaaaaa'; print join " ", @splitted; output recieved :aa a a a a a aa output desired :aa aa aa aa a

    The main issue is that at each position there is a match, so the string is split at every position. I tried a mix of assertions and literals but the best I got was to match two at the start and end with single entities in between

    I have a solution with s/// that I am happy about. I'm getting a count and any remainders modulo the length of the test string remain in the string. If I need to I can write a while loop rather than a map, though this is probably already better for what I want.

    my $prim_to_test = ${ num_to_nat(2) }[0]; #get_wildmarks(); 'aa' my $split_pattern = qr/(\Q$prim_to_test\E)/; print "split_pat: $split_pattern\n"; my @splitted = map "$_ x $1", ( $wildmarks =~ s/(?=$split_pattern)$split_pattern//g ); print "splitted: ", join " \N{U+68} ", @splitted, "r: $wildmarks"; output:splitted: 4 x aa h r: a

    But can split do it?

    SPoiler ALert: Yes.

    Further, it would appear the ability to use arbitrary characters is also expanded

Can't call method "forprimes"
2 direct replies — Read more / Contribute
by pvfki
on Jul 15, 2019 at 02:13
    Hi, I've been running the following code below and get the following errors:
    #!/usr/bin/env perl use warnings; use strict; use ntheory; use bigint; my $n=12; my $c=1; my $k=10; my $l=10; my $p=100; my @candidates = (0..$l); my $remove; sieve2(); sub sieve2 { forprimes { $p=$_; foreach my $i (0..$l) { if ( ($n*($k+$i)+$c)%$p==0) { $remove=$i; @candidates = grep {!/$remove/} @candidates; } } } print join("\n",@candidates),"\n"; } sieve2();
    Errors:
    C:\Users\Perl Scripts> sieve2.pl Use of uninitialized value in new at C:\Users\Paul\Documents\Perl Scri +pts\question.pl line 20. Use of uninitialized value in new at C:\Users\Paul\Documents\Perl Scri +pts\question.pl line 20. Use of uninitialized value in new at C:\Users\Paul\Documents\Perl Scri +pts\question.pl line 20. Use of uninitialized value in new at C:\Users\Paul\Documents\Perl Scri +pts\question.pl line 20. Use of uninitialized value in new at C:\Users\Paul\Documents\Perl Scri +pts\question.pl line 20. Use of uninitialized value in new at C:\Users\Paul\Documents\Perl Scri +pts\question.pl line 20. Use of uninitialized value in new at C:\Users\Paul\Documents\Perl Scri +pts\question.pl line 20. Use of uninitialized value in new at C:\Users\Paul\Documents\Perl Scri +pts\question.pl line 20. Use of uninitialized value in new at C:\Users\Paul\Documents\Perl Scri +pts\question.pl line 20. Use of uninitialized value in new at C:\Users\Paul\Documents\Perl Scri +pts\question.pl line 20. Use of uninitialized value in new at C:\Users\Paul\Documents\Perl Scri +pts\question.pl line 20. 0 1 2 3 4 5 6 7 8 9 10 Can't call method "forprimes" without a package or object reference at + C:\Users\Paul\Documents\Perl Scripts\question.pl line 18.
    So I know that I've included the right dependencies for forprimes (the exact function is right here: https://metacpan.org/pod/ntheory#forprimes) so I don't see what I'm doing wrong. To be more specific about the code: Given integers n, c, k, l, and p, sieves all numbers of the form n*(k+i)+c where 0 <= i <= l up to all primes less than p. So in my program example where I chose parameters 12, 1, 10, 10, and 100 respectively, the correct output should be:
    3 5 6 9 10
    Any ideas of how to obtain this? Thanks for help in advance!
YAML::Tiny can't serialize an object reference. Can I unbless a Moo object into a hashref and yammily serialize that?
5 direct replies — Read more / Contribute
by Anonymous Monk
on Jul 14, 2019 at 22:39
    I made a class in Moo for some objects. So i wanted to write one as yaml file. Then i could edit the yaml file and easily add more types of objects when i load it in. But YAML::Tiny can't serialize an object reference. Can I unbless a Moo object into a hashref and yammily serialize that? Or is this madness and i should just dump the objects some other way?
Closure confusion in Tkx
3 direct replies — Read more / Contribute
by lbrandewie
on Jul 13, 2019 at 05:56

    Hey Perl Monks,

    I, a poor hacker, am confounded by the following problem. This isn't the problem I'm having (exactly), it's just the simplest case I can reduce it to.

    Let's say you wanted to build a simple text file editor, using the following code:

    use Tkx; use strict; our (@data, @editctls, @buttons); open IN, "test.txt"; flock IN, 1; @data = <IN>; close IN; chomp @data; our $mw = Tkx::widget->new("."); for (my $x = 0; $x < @data; $x++) { push @editctls, $mw->new_ttk__entry(-width => 30, -textvariable => + \$data[$x]); $editctls[$x]->g_grid(-row => $x, -column => 0); push @buttons, $mw->new_ttk__button(-text => "Update", -command => + sub { update($x); } ); $buttons[$x]->g_grid(-row => $x, -column => 1); } Tkx::MainLoop(); sub update { my $which = shift; open DATA, "+<test.txt"; my @stuff = <DATA>; $stuff[$which] = $data[$which] . "\n"; seek DATA, 0, 0; print DATA @stuff; truncate DATA, tell(DATA); close DATA; }

    And I'm using the following text file for testing:

    this is a text file

    The problem is with the update buttons. When clicked, they send the current value of $x to the update subroutine, not the value of $x when the anonymous sub was created. I had thought that when anonymous subs refer to lexical variables, they created a closure, but apparently not so in this case. Am I missing something? Is there a correct way to do this?

    I did try moving the control creation logic to an actual sub but it made no difference.

    Thanks,

    Lars Brandewie

"No child processes" problem with fork() call
3 direct replies — Read more / Contribute
by Anonymous Monk
on Jul 12, 2019 at 14:52

    I've inherited a program that had been running fine for years, but now is throwing errors all the time, and I have no idea why. As far as I can tell, the only change that was made was adding some debugging code in the general vicinity of the problem. I'm not knowledgeable about any IPC-related stuff, and have been reading what I can, but I don't understand what this is doing, which makes it hard to debug :-(

    The program is a web form that shells out to an external (Perl) script to perform a time-consuming task. The structure of the relevant section is more or less this (none of this code is mine):

    $SIG{CHLD} = 'IGNORE'; # ignore dead children, to avoid zombie process +es my $child = fork(); if ($child) { # parent; return data $self->return_data( { data => $data } ); } else { # child; run external process my $child_output; eval { # gather a whole lot of data; assemble $external_command use IPC::System::Simple 'capture'; $child_output = capture($external_command); }; $self->log("Error when running [$external_command]: $child_output") +if $child_output; $self->log("Error when running [$external_command]: $@") if $@; CORE::exit(0); }
    This is now constantly throwing errors having the form:
    Error when running [{external command}]: "{external command}" failed t +o start: "No child processes" at /path/to/web/program.pm line 459.
    If anyone could suggest what's going on and how I can fix it, I would be very grateful indeed.
Seeking a more robust variant of HTML::TreeBuilder::XPath
4 direct replies — Read more / Contribute
by Paradigma
on Jul 12, 2019 at 07:58

    Hello,

    Using this component, sometimes happens I'm limited to fully parse some more complex or broken pages. Though my element is shown in browser's element viewer, I can't reach it in TreeBuilder's tree.

    I would appreciate any other element, even commercial, conceptually similar or same to TreeBuilder, which would parse more aggressively pages with complex structure. Maybe the inability to parse fully could be resolved by tuning up with TreeBuilder initialization parameters?

New Meditations
Off by one key... or yet another example of why strict and warnings are always a good idea (even for "one-liners")
3 direct replies — Read more / Contribute
by atcroft
on Jul 17, 2019 at 20:02
    "Just sit right back and you'll hear a tale
    a tale of a fateful trip,
    that started from this simple term,
    aboard this single slip."

    Please, dear reader, learn from my mistake. (It will likely be less painful than repeating it yourself.)

    Earlier today I did something I have done dozens of times before-created a command-line perl script (a "one-liner", for some very long definition of a "line") to create a file containing a subset of messages from a set of compressed logs, with the intent of pulling them back to my machine for additional processing. I launched it in a screen session, saw it was running and would take some time to begin generating output, and stepped away for lunch. I was rather surprised, however, when I returned to find it throwing "No space left on device" messages-especially when I looked to find that the partition's previous 40GB of free space was now zero. After cleaning up the space, I began trying to find the cause.

    In digging through my code, I almost missed the issue-a line of the form if ( $str -~ m/some pattern/ ) { print $str; }. Notice the issue? An off-by-one-key error from a en.US keyboard, where [-/_] and [=/+] are beside one another. This was compounded by skipping the well-espoused logic of use strict; use warnings; because it was a "one-liner" (where "-Mstrict -Mwarnings" would have added a mere 19 characters in length). Had I have done so, instead of:

    # made-up example with actual issue $ perl -le 'my $str = q{zxcv}; if ( $str -~ m/some pattern/i ) { print + $str; }' zxcv
    I would have seen:
    # made-up example with actual issue, with strict and warnings $ perl -Mstrict -Mwarnings -le 'my $str = q{zxcv}; if ( $str -~ m/some + pattern/i ) { print $str; }' Use of uninitialized value $_ in pattern match (m//) at -e line 1. Argument "zxcv" isn't numeric in subtraction (-) at -e line 1. zxcv
    Seeing unexpected output like that (that early) would likely have resulted in my cancelling the command to investigate, and thus likely not filling up 40GB of storage.

    I know this will probably be like the tone after the television broadcast day ended to a sleeping viewer, but maybe, just maybe, it will help someone. In the end, learning from others' mistakes is often less painful (but not necessarily as memorable).

    (And yes, I do use the the duo on most every script I write-just not always on "one-liners".)

File::Spec->case_tolerant() is broken
No replies — Read more | Post response
by afoken
on Jul 13, 2019 at 20:42

    This is the long version of Re^2: open file error and Re^5: Unify windows filenames (from ten years ago), triggered by Re^2: perl script to compare two directories, plus a little bit of bean counting on the code for non-Unix systems.


    File::Spec has a severe design problem that will cause wrong results on modern Unix systems (*BSD, Linux, MacOS X). It assumes that all filesystems are equal on any Unix operating system. And this assumtion is plain wrong since decades:

    • Any modern Unix can mount FAT and NTFS, two filesystems that are commonly used in a case insensitive way, and so they are generally mounted in a case insensitive way.
    • At the same time, the native filesystems (ext2/3/4, btrfs, ufs, ufs2, zfs) are mounted in a case sensitive way.
    • ISO9660 is case insensive, Rock Ridge extensions make it case sensitive, so a CDROM / DVD-ROM / Blueray mounted on a Unix system may be either case sensitive or case insensitive.
    • Mounting a case insensitive FAT filesystem on Linux is quite common: All Raspberry Pis boot from a FAT partition later mounted as /boot
    • And to drive people mad, Linux 5.2 also can mount its native ext4 filesystem in a case insensitive way.

    To make things worse, the code for at least Windows and cygwin is broken, too.

    And here is how File::Spec handles all of that:

    package File::Spec; use strict; our $VERSION = '3.75'; $VERSION =~ tr/_//d; my %module = ( MSWin32 => 'Win32', os2 => 'OS2', VMS => 'VMS', NetWare => 'Win32', # Yes, File::Spec::Win32 works on Ne +tWare. symbian => 'Win32', # Yes, File::Spec::Win32 works on sy +mbian. dos => 'OS2', # Yes, File::Spec::OS2 works on DJGP +P. cygwin => 'Cygwin', amigaos => 'AmigaOS'); my $module = $module{$^O} || 'Unix'; require "File/Spec/$module.pm"; our @ISA = ("File::Spec::$module"); 1;

    For any modern Unix, the %module hash has no overriding key, and so File::Spec::Unix will implement all methods of File::Spec.

    File::Spec::Unix

    package File::Spec::Unix; use strict; use Cwd (); our $VERSION = '3.75'; $VERSION =~ tr/_//d; # ... sub case_tolerant { 0 } use constant _fn_case_tolerant => 0; # ...

    File::Spec->case_tolerant() constantly returns false, and that is plain wrong, as explained above.

    The constant _fn_case_tolerant, used by File::Spec::Functions, is also wrong. It should not exist at all.

    File::Spec::Win32

    Strangely, the Windows implementation, which optionally allows passing a drive letter to the case_tolerant() method, is better, but still wrong:

    package File::Spec::Win32; use strict; use Cwd (); require File::Spec::Unix; our $VERSION = '3.75'; $VERSION =~ tr/_//d; our @ISA = qw(File::Spec::Unix); # ... sub case_tolerant { eval { local @INC = @INC; pop @INC if $INC[-1] eq '.'; require Win32API::File; } or return 1; my $drive = shift || "C:"; my $osFsType = "\0"x256; my $osVolName = "\0"x256; my $ouFsFlags = 0; Win32API::File::GetVolumeInformation($drive, $osVolName, 256, [], [] +, $ouFsFlags, $osFsType, 256 ); if ($ouFsFlags & Win32API::File::FS_CASE_SENSITIVE()) { return 0; } else { return 1; } } # ...
    • Failing to load Win32API::File silently and magically makes all filesystems case insensitive. Plain wrong. If all filesystems were case insensitive, messing with the Win32 API function GetVolumeInformation() would not be needed and the entire function body could be reduced to { 1 }. Right for the common case, wrong for edge cases.
    • The return value of GetVolumeInformation(), which may fail, is not checked at all. Microsoft does not specify what happens to the variable passed as lpFileSystemFlags, so the contents of $ouFsFlags may be junk in that case. If you are lucky, $ouFsFlags is not touched, stays 0, and the following test for FS_CASE_SENSITIVE ends by returning true, which is right by accident in the common case. If you test an edge case, or if $ouFsFlags has been modified so that its FS_CASE_SENSITIVE bit is set, the returned result is wrong.
    • Omitting the drive letter tests the C: drive, probably to be compatible with the File::Spec::Unix implementation, which has no documented parameters. Again, right for the common case, wrong for edge cases.
    • Undocumented feature: GetVolumeInformation() also accepts UNC paths ('\\server\share'), and case_tolerant() does not prevent you from testing UNC paths.
    • NTFS volume mount points (that allow mounting any filesystem supported by Windows in an empty subdirectory of a NTFS volume) are not documented, neither in File::Spec::Win32, nor in the documentation of GetVolumeInformation(). Probably, some more code is required to handle NTFS volume mount points.

    File::Spec::Cygwin

    package File::Spec::Cygwin; use strict; require File::Spec::Unix; our $VERSION = '3.75'; $VERSION =~ tr/_//d; our @ISA = qw(File::Spec::Unix); # ... sub case_tolerant { return 1 unless $^O eq 'cygwin' and defined &Cygwin::mount_flags; my $drive = shift; if (! $drive) { my @flags = split(/,/, Cygwin::mount_flags('/cygwin')); my $prefix = pop(@flags); if (! $prefix || $prefix eq 'cygdrive') { $drive = '/cygdrive/c'; } elsif ($prefix eq '/') { $drive = '/c'; } else { $drive = "$prefix/c"; } } my $mntopts = Cygwin::mount_flags($drive); if ($mntopts and ($mntopts =~ /,managed/)) { return 0; } eval { local @INC = @INC; pop @INC if $INC[-1] eq '.'; require Win32API::File; } or return 1; my $osFsType = "\0"x256; my $osVolName = "\0"x256; my $ouFsFlags = 0; Win32API::File::GetVolumeInformation($drive, $osVolName, 256, [], [] +, $ouFsFlags, $osFsType, 256 ); if ($ouFsFlags & Win32API::File::FS_CASE_SENSITIVE()) { return 0; } else { return 1; } } # ...
    • This code inherits all problems of File::Spec::Win32 by copying the broken code from File::Spec::Win32::case_tolerant(), and extending it with its own code.
    • Missing Cygwin::mount_flags() silently and magically makes all filesystems case insensitive, even before all problems copied from File::Spec::Win32::case_tolerant() can appear.
    • Any false value (undef, empty string, 0) passed as argumnent, including passing no argument at all, triggers the default logic that creates a Unix-style, cygwin-specific path in $drive. If that path is not detected as "managed" (by cygwin), this Unix-style path will be passed as a drive letter to GetVolumeInformation(). I expect GetVolumeInformation() to fail in that case. As in File::Spec::Win32::case_tolerant(), there is no error check, see there.

    File::Spec::*

    File::Spec::AmigaOS inherits case_tolerant() from File::Spec::Unix, so it returns false. I have no clue how AmigaOS handles file names. AmigaOS states that device names are case insensitive, so case_tolerant() should return true for device names. IIRC, old Amigas could at least read DOS floppies. Again, case_tolerant() should return true for DOS floppies. So, it looks like File::Spec::AmigaOS::case_tolerant() is broken.

    File::Spec::Epoc implements case_tolerant() to constantly return true. Again, I have no clue how EPOC a.k.a. Symbian OS handles file names.

    File::Spec::Mac implements case_tolerant() to constantly return true. This should be ok, the filesystems of classic MacOS (MFS, HFS, HFS+) are case insensitive, as are FAT-formatted floppies from DOS. I don't know if old Macs could access any other filesystems.

    File::Spec::VMS implements case_tolerant() to constantly return true. Again, no clue how VMS handles file names, or if it can mount case-sensitive filesystems. Files-11 suggest case insensitive behaviour. If case-sensitive filesystems can be mounted, this implementation is broken.

    File::Spec::OS2, used also for DOS, implements case_tolerant() to constantly return true. This should be ok for DOS and OS/2 native filesystems (FAT, HPFS). I don't know if later versions of OS/2 support case-sensitive filesystems. If they do, this implementation is broken.

    File::Spec::Functions

    package File::Spec::Functions; # ... our $VERSION = '3.75'; $VERSION =~ tr/_//d; #... my %udeps = ( # ... case_tolerant => [], # ... ); foreach my $meth (@EXPORT, @EXPORT_OK) { my $sub = File::Spec->can($meth); no strict 'refs'; if (exists($udeps{$meth}) && $sub == File::Spec::Unix->can($meth) +&& !(grep { File::Spec->can($_) != File::Spec::Unix->can($_) } @{$udeps{$meth}}) && defined(&{"File::Spec::Unix::_fn_$meth"})) { *{$meth} = \&{"File::Spec::Unix::_fn_$meth"}; } else { *{$meth} = sub {&$sub('File::Spec', @_)}; } } # ...
    • File::Spec::Functions generates function wrappers for the methods of File::Spec.
    • The generic way is a simple function that injects 'File::Spec' as first argument for the method call.
    • For methods that are implemented by File::Spec::Unix, are listed in %udeps, don't have dependencies (from %udeps) implemented in other classes, and have a function named "_fn_$meth" defined in File::Spec::Unix, that function is used instead. The intention is clear: All of those functions in File::Spec::Unix are implemented via constant, and using them saves several CPU cycles compared to wrapping a method. case_tolerant() is one of those methods, and File::Spec::Functions will choose File::Spec::Unix::_fn_case_tolerant() instead of generating a wrapper if the O/S-specific class does not implement its own case_tolerant() method.
    • File::Spec::Functions makes no attempt to speed up constant methods in O/S-specific classes.
    • The return value of File::Spec::Unix::_fn_case_tolerant() is wrong, as explained above.
    • Repairing File::Spec::Unix->case_tolerant() implies that File::Spec::Unix::_fn_case_tolerant() has to be removed, see below.

    Fixing case_tolerant() for Unix

    There seems to be no easy fix for Unix. Returning false is the wrong answer for all of the edge case shown above. Returning true is the wrong answer for all of the common cases (native filesystems).

    At least, case_tolerant() needs a path to work on, as there is no generic answer on Unix. The path should be the equivalent of a drive letter on windows, i.e. a mount point.

    For convenience, passing a filename should be treated like passing the directory containing it. (This should happen for all operating systems)

    Also for convenience, passing a directory that is not a mount point should be treated like passing the next mount point upwards the directory tree. (This should also happen for all operating systems.)

    Detecting a mount point depends on the operating system, but a general solution for Unix exists: compare the dev fields of stat($dir) and lstat("$dir/.."), if they differ, you found a mount point. Note that this method fails to detect bind mounts on Linux (according to mountpoint.c from util-linux).

    Knowing the mount point for a filesystem, you "only" have to find out if that filesystem is mounted case-sensitive or case-insensitive. And that depends on the operating system.

    For bug-compatibility to the existing File::Spec::Unix, calling case_tolerant() without arguments could continue to return false.

    Fixing case_tolerant() for Windows

    case_tolerant() should also accept directories and files deep inside a volume, as required for the fixed File::Spec::Unix->case_tolerant()

    As far as GetVolumeInformation() is concerned, mount points are either drive letters or server shares. That can easily be handled by a regexp.

    Detecting NTFS volume mount points needs more work. See https://docs.microsoft.com/en-us/windows/win32/fileio/volume-mount-points.

    GetVolumeInformationByHandleW() looks promising, but requires at least Vista / Server 2008, and it requires that you pass a file handle, not just a path.

    Fixing case_tolerant() for Cygwin

    case_tolerant() should also accept directories and files deep inside a volume, as required for the fixed File::Spec::Unix->case_tolerant()

    1. Check if the argument looks like a cygwin path
    2. If it does, find the cygwin mount point for the argument and check the mount options.
    3. Else, load File::Spec::Win32, pass the argument to File::Spec::Win32->case_tolerant() and return whatever that method returns

    Especially, do not check for Cygwin or Cycwin functions before you know you have to work with a cygwin path.

    Alexander

    --
    Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
New Monk Discussion
Solving possible missing links
3 direct replies — Read more / Contribute
by talexb
on Jul 16, 2019 at 09:59

    This node was up for moderation recently, and the cause was bitrot (out of date links).

    Would it be useful to go through the node database, and do a check for external links to see if they can be updated in the same way?

    Alex / talexb / Toronto

    Thanks PJ. We owe you so much. Groklaw -- RIP -- 2003 to 2013.

The on-going riddle wrapped in a mystery...
6 direct replies — Read more / Contribute
by footpad
on Jul 12, 2019 at 13:40

    The story of paco, as many experienced monks know, has long been an enigma in the Monastery, a source of ongoing curiosity and speculation (click through for more).

    Today, the speculation grew curiouser, as newly-discovered evidence seemed deepen the mystery:

    1. Begin by visiting the venerable's home node and noting the date of last visit.

    2. Next, note the post date of this node and then note its Approval nodelet values.

    Miracle? Impersonation? Gallifreyan shenanigans? Something else entirely?

    Who knows? \_(ツ)_/

    So...it remains a right mystery suitable for a lazy Friday hobnob over cherry pies.

    --f

    Update: Update links to nodes to help play the legend forward.

Log In?
Username:
Password:

What's my password?
Create A New User
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (3)
As of 2019-07-19 01:26 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?