The Manitoba UNIX User Group (MUUG) will be holding its next monthly
meeting on Tuesday, February 11. The meeting topic for this month is
as follows:
Raspberry Pi Real Time Clock
Wyatt Zacharias will be presenting the Raspberry Pi along with
a Real Time Clock circuit.
"A real-time clock is a computer clock that keeps track of the
current time. Although the term often refers to the devices in
personal computers, servers and embedded systems, RTCs are
present in almost …
[View More]any electronic device which needs to keep
accurate time."
For this month's RTFM topic, Trevor Cordes will be presenting
the history command, as found in (for example) bash(1) or tcsh(1).
The group holds its general meetings at 7:30pm on the second Tuesday of
every month from September to June. (There are no meetings in July and
August.) Meetings are open to the general public; you don't have to be a
MUUG member to attend.
*****************************************************************
Please note our *NEW* meeting location for this month: Room 1L08,
Lockhart Hall, University of Winnipeg, entrance on Ellice Ave.
between Spence St. and Balmoral St.
Parking is available on the surrounding streets and in the lots
on nearby streets. Look for signage once you're at the building,
or ask a security guard.
*****************************************************************
For more information about MUUG, and its monthly meetings, check out their
Web server:
http://www.muug.mb.ca/
Help us promote this month's meeting, by putting this poster up on your
workplace bulletin board or other suitable public message board:
http://www.muug.mb.ca/meetings/MUUGmeeting.pdf
--
Gilbert E. Detillieux E-mail: <gedetil(a)muug.mb.ca>
Manitoba UNIX User Group Web: http://www.muug.mb.ca/
PO Box 130 St-Boniface Phone: (204)474-8161
Winnipeg MB CANADA R2H 3B4 Fax: (204)474-7609
[View Less]
But after programming heavily in Perl for 22 years (!!!) I can safely say I pretty much have the quirks and syntax oddities nailed. This is the first time in a long time something like this one has bit me, and it's understandable because I rarely use the glob op.
If you don't like all the weirdness, the beauty of Perl is you can instead just program it as though it was C without malloc. I like choice.
-------- Original message --------
From: Sean Walberg <sean(a)ertw.com>
Date:2014/…
[View More]02/02 20:00 (GMT-06:00)
To: Continuation of Round Table discussion <roundtable(a)muug.mb.ca>
Subject: Re: [RndTbl] strange race condition on file entries
While I will always manage my life by the three great virtues, I must thank you for reminding me why I gave up slinging Perl. DWIM and all the sigils drive a man to an early grave, or at least a lot of nights debugging.
Sean
On Sun, Feb 2, 2014 at 1:10 PM, Trevor Cordes <trevor(a)tecnopolis.ca> wrote:
I forgot to post what *does* work. There are a few different
ways.
You can force the glob to return a list (hence no caching/iterating):
if (!@{[<$prefix-*>]}) {
That's sure ugly, but it makes sense. [] forces the <> to return list
and turns it into an anon array-ref. @ then derefs. {} is required by
the parser to make sense of it all. !@ then does its normal thing of
meaning "if there are zero elements in this array".
You could also force it to list by assigning to an array:
if (!(@a=<$prefix-*>)) {
But I hate using temp vars when we don't need to; when the results are
throwaway.
Strangely, using the normal "we want a list" syntax of just putting ()
around the expression doesn't work in this case. I'm not sure why:
if (!(<$prefix-*>)) { # doesn't work
Also strangely, while perl has a "scalar" function to force a scalar
(non-list) result, it doesn't have a "list" or "array" function to
force a list. The scalar docs say list isn't necessary as it's usually
the default/implied or can be forced with (). Woops, looks like I
found a corner case.
Ya, I could have been certain everything worked in the first place by
doing opendir and iterating through the results, like one would in
C, but the whole purpose of using perl is to do as much as possible in
as few characters and lines. Laziness is the #1 programmer virtue,
according to L.Wall and R.Schwarz.
_______________________________________________
Roundtable mailing list
Roundtable(a)muug.mb.ca
http://www.muug.mb.ca/mailman/listinfo/roundtable
--
Sean Walberg <sean(a)ertw.com> http://ertw.com/
[View Less]
I've noticed that many USB card readers are non-functional under Linux;
according to the kernel developers, it's because relatively few of them
implement the USB removable block storage class (protocol) correctly.
While there are lots of expensive card readers that work with Linux,
finding cheap ones is challenging.
I think, however, that I've found the ultimate *cheap* USB card reader
that works with Linux: the "Tech-1 USB 2.0 CARD READER" at Dollarama.
IIRC, it cost $2.
You'll almost …
[View More]certainly want to get a USB A-A extension cable for $1 or
$2 at the same time, since the card reader comes with a 1" cable...
--
-Adam Thompson
athompso(a)athompso.net
[View Less]
I'm running into a strange race condition, that appears to me to be a
Linux bug of some sort.
I'm doing, perl pseudocode:
system "process-file outputfileprefix"
# does work and puts it in files named outputfileprefix-0, outputfileprefix-1, etc
sleep 1;
if (!<outputfileprefix-[0-9]*>) {
warn "try #2\n";
sleep 2;
if (!<outputfileprefix-[0-9]*>) {
warn "try #3\n";
die;
}
}
# do something on outputfile*
For those that don't know <> is perl's glob op, which …
[View More]simply returns an
array of all the files matching the glob. !<> is thus true if no files
match the glob.
What is happening is that 10-30% of the time, I get a "try #2" output. I
haven't yet seen a try #3. Of course, having those retries (and sleeps)
in there at all should not be required: I had to add them as I was seeing
this program blow up in unexpected ways.
process-file does not do anything async'ly, AFAIK. The final thing it
does, the output that I need, is use the GD library to write a png file.
Only after that does process-file exit. There are no threads or forks,
unless GD is doing one, but even then the mini-program above should not
return from system until all threads and (non-daemonized) forks are done.
It appears the problem is process-file writes and closes a file, returns,
yet the directory entry doesn't become visible to the calling script for 0
to 3 seconds! I was under the impression that such UNIX OS actions were
guaranteed to occur reliably in sequence!
Note, the fs I'm using is local and normal harddisk-based. It is not on
NFS or SMB, which of course could show such results.
Comments? Ideas?
[View Less]