Roundtable February 2014

roundtable@muug.ca

18 participants
24 discussions

MUUG Meeting, Feb 11, 7:30pm -- Raspberry Pi Real Time Clock
by gedetil＠cs.umanitoba.ca 04 Feb '14

04 Feb '14

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 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

1 0

Re: [RndTbl] strange race condition on file entries
by Trevor Cordes 03 Feb '14

03 Feb '14

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/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/

1 0

CF/SD/MMC readers under Linux
by Adam Thompson 03 Feb '14

03 Feb '14

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 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

2 2

strange race condition on file entries
by Trevor Cordes 03 Feb '14

03 Feb '14

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 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?

4 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

Roundtable February 2014