From jacoby at purdue.edu Wed Jul 6 06:30:59 2011 From: jacoby at purdue.edu (Dave Jacoby) Date: Wed, 06 Jul 2011 09:30:59 -0400 Subject: [Purdue-pm] YAPC::NA 2012 Message-ID: <4E146393.6070706@purdue.edu> It's at UW Madison http://blog.yapcna.org/ Not too far a drive. Maybe I'll go next year. -- Dave Jacoby Address: WSLR S049 Code Maker Mail: jacoby at purdue.edu Purdue University Phone: 765.49.67368 1006 days until the end of XP support From gizmo at purdue.edu Wed Jul 6 06:37:55 2011 From: gizmo at purdue.edu (Joe Kline) Date: Wed, 06 Jul 2011 09:37:55 -0400 Subject: [Purdue-pm] YAPC::NA 2012 In-Reply-To: <4E146393.6070706@purdue.edu> References: <4E146393.6070706@purdue.edu> Message-ID: <4E146533.40209@purdue.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/06/2011 09:30 AM, Dave Jacoby wrote: > It's at UW Madison > > http://blog.yapcna.org/ > > Not too far a drive. Maybe I'll go next year. > There is a 99.999% chance I'll be attending. It should be fairly awesome given the bar that this year's YAPC::NA was raised to. joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4UZTIACgkQb0mzA2gRTpkXOwCcDXrSXDSSHeKS8hAHtBaj2n/0 DQYAn1NwINuuQ0M4BS2X40lOXmzEiigz =sdcU -----END PGP SIGNATURE----- From westerman at purdue.edu Wed Jul 13 13:33:37 2011 From: westerman at purdue.edu (Rick Westerman) Date: Wed, 13 Jul 2011 16:33:37 -0400 (EDT) Subject: [Purdue-pm] Monger! Monger! Next Tuesday Jul 19th In-Reply-To: <753957607.57302.1310588996521.JavaMail.root@mailhub016.itcs.purdue.edu> Message-ID: <714315827.57315.1310589217417.JavaMail.root@mailhub016.itcs.purdue.edu> Just a reminder that there is a PM meeting next Tuesday, July 19th, in WSLR 116 during the noon hour. I'm not quite sure what we are going to have talks on but perhaps someone can come up with something neat. Or, as usual, we can have an interesting chat. -- Rick Westerman westerman at purdue.edu Bioinformatics specialist at the Genomics Facility. Phone: (765) 494-0505 FAX: (765) 496-7255 Department of Horticulture and Landscape Architecture 625 Agriculture Mall Drive West Lafayette, IN 47907-2010 Physically located in room S049, WSLR building From gizmo at purdue.edu Wed Jul 13 13:52:26 2011 From: gizmo at purdue.edu (Joe Kline) Date: Wed, 13 Jul 2011 16:52:26 -0400 Subject: [Purdue-pm] Monger! Monger! Next Tuesday Jul 19th In-Reply-To: <714315827.57315.1310589217417.JavaMail.root@mailhub016.itcs.purdue.edu> References: <714315827.57315.1310589217417.JavaMail.root@mailhub016.itcs.purdue.edu> Message-ID: <4E1E058A.60105@purdue.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I should be up for giving a summary of YAPC::NA 2011. joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org/ iEYEARECAAYFAk4eBYoACgkQb0mzA2gRTpk1ZgCglmlYh4u8BRp02OIrP8ELlGP7 jvoAnReDcFodsvx6g7z0fISVTn9IdICj =Rgly -----END PGP SIGNATURE----- From gizmo at purdue.edu Mon Jul 18 12:19:45 2011 From: gizmo at purdue.edu (Joe Kline) Date: Mon, 18 Jul 2011 15:19:45 -0400 Subject: [Purdue-pm] Monger! Monger! Next Tuesday Jul 19th In-Reply-To: <4E1E058A.60105@purdue.edu> References: <714315827.57315.1310589217417.JavaMail.root@mailhub016.itcs.purdue.edu> <4E1E058A.60105@purdue.edu> Message-ID: <4E248751.3080603@purdue.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Actually, it looks like I won't be able to make the meeting tomorrow. I'll do my talk on YAPC::NA 2011 next month. joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org/ iEYEARECAAYFAk4kh1EACgkQb0mzA2gRTpkrSgCcCjRw4oEY/kv8U6Q0vJBnvyXc Y2gAoKHMREVPAOY1iq4l6Y88RuqF9Z2z =6pny -----END PGP SIGNATURE----- From jacoby at purdue.edu Wed Jul 20 09:02:45 2011 From: jacoby at purdue.edu (Dave Jacoby) Date: Wed, 20 Jul 2011 12:02:45 -0400 Subject: [Purdue-pm] Module Question Message-ID: <4E26FC25.9050800@purdue.edu> I have modules that run on our servers, separated by purpose. So, Dave::First calls Dave::Second in order to get, for example, the SQL interfaces. And this also gets used on RCAC clusters, and I certainly don't want to have too much parallel development. Which is where 'use lib' starts to hurt. On our servers, it's use lib '/home/jacoby/lib' ; use Dave::First ':all' ; On RCAC servers, it's something way different. I can't do anything with Cwd, because that's not going to be ready until after the load library stuff happens, which is where I need it. Any suggestions? -- Dave Jacoby Address: WSLR S049 Code Maker Mail: jacoby at purdue.edu Purdue University Phone: 765.49.67368 992 days until the end of XP support From mark at ecn.purdue.edu Wed Jul 20 09:58:03 2011 From: mark at ecn.purdue.edu (Mark Senn) Date: Wed, 20 Jul 2011 12:58:03 -0400 Subject: [Purdue-pm] Module Question In-Reply-To: <4E26FC25.9050800@purdue.edu> References: <4E26FC25.9050800@purdue.edu> Message-ID: <26569.1311181083@pier.ecn.purdue.edu> > I have modules that run on our servers, separated by purpose. So, > Dave::First calls Dave::Second in order to get, for example, the SQL > interfaces. > > And this also gets used on RCAC clusters, and I certainly don't want > to have too much parallel development. Which is where 'use lib' starts > to hurt. > > On our servers, it's > use lib '/home/jacoby/lib' ; > use Dave::First ':all' ; > > On RCAC servers, it's something way different. I can't do anything > with Cwd, because that's not going to be ready until after the load > library stuff happens, which is where I need it. Any suggestions? Hi Dave, I'm not sure I understand the problem. The following has not been tested. How about using the Perl BEGIN { ... } so the code inside { and } would be run as soon as it has been read by the parser but before the rest of the code compiles? Or maybe, foreach (@possible_directory) { if (-e "$_/$filename") { do "$_/$filename"; last; } } Please summarize to the list once you've fourd the best solution. -mark From gizmo at purdue.edu Wed Jul 20 10:49:46 2011 From: gizmo at purdue.edu (Joe Kline) Date: Wed, 20 Jul 2011 13:49:46 -0400 Subject: [Purdue-pm] Module Question In-Reply-To: <4E26FC25.9050800@purdue.edu> References: <4E26FC25.9050800@purdue.edu> Message-ID: <4E27153A.4090909@purdue.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/20/2011 12:02 PM, Dave Jacoby wrote: > I have modules that run on our servers, separated by purpose. So, > Dave::First calls Dave::Second in order to get, for example, the SQL > interfaces. > > And this also gets used on RCAC clusters, and I certainly don't want to > have too much parallel development. Which is where 'use lib' starts to > hurt. > > On our servers, it's > use lib '/home/jacoby/lib' ; > use Dave::First ':all' ; > > On RCAC servers, it's something way different. I can't do anything with > Cwd, because that's not going to be ready until after the load library > stuff happens, which is where I need it. Any suggestions? > (forgot to reply-all) Dave, you want to do something with local::lib. It might help with a DarkPAN. DarkPAN is the Perl community lingo for modules used by organizations that don't escape into the light of CPAN or the Perl community. local::lib will also let you install modules that won't sully the system Perl and also handle any modules you create. joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org/ iEYEARECAAYFAk4nFToACgkQb0mzA2gRTpnTDwCggi0uTqiuRwdVH7wVtQe0u1Mh xskAn3fDjbqFkP1uhScyZkSC+cypx5kp =Ak3e -----END PGP SIGNATURE----- From yatcilla at purdue.edu Wed Jul 20 10:54:07 2011 From: yatcilla at purdue.edu (Doug Yatcilla) Date: Wed, 20 Jul 2011 13:54:07 -0400 Subject: [Purdue-pm] Module Question In-Reply-To: <4E26FC25.9050800@purdue.edu> References: <4E26FC25.9050800@purdue.edu> Message-ID: <20110720175407.GE7058@purdue.edu> On Wed Jul 20 12:02:45 2011, Dave Jacoby wrote: > I have modules that run on our servers, separated by purpose. So, > Dave::First calls Dave::Second in order to get, for example, the SQL > interfaces. > > And this also gets used on RCAC clusters, and I certainly don't want to > have too much parallel development. Which is where 'use lib' starts to > hurt. > > On our servers, it's > use lib '/home/jacoby/lib' ; > use Dave::First ':all' ; > > On RCAC servers, it's something way different. I can't do anything with > Cwd, because that's not going to be ready until after the load library > stuff happens, which is where I need it. Any suggestions? If there are only two systems and you keep your perl libraries in different directories on each system, you could put two "use lib" lines in your code listing both directories. Or, you could set the PERL5LIB shell environment variable to be the directory with your perl libraries. If you use this, you won't need the "use lib" line in your code. You login scripts could automatically set the PERL5LIB env var to the appropriate directory for the server or you could set it to all possible directories so the same PERL5LIB will work on any server you use. Regards, -Doug From jacoby at purdue.edu Wed Jul 20 10:58:29 2011 From: jacoby at purdue.edu (Dave Jacoby) Date: Wed, 20 Jul 2011 13:58:29 -0400 Subject: [Purdue-pm] Module Question In-Reply-To: <20110720175407.GE7058@purdue.edu> References: <4E26FC25.9050800@purdue.edu> <20110720175407.GE7058@purdue.edu> Message-ID: <4E271745.2060906@purdue.edu> On 7/20/2011 1:54 PM, Doug Yatcilla wrote: > If there are only two systems and you keep your perl libraries in > different directories on each system, you could put two "use lib" > lines in your code listing both directories. Rick suggested this, and this is what I'm going with now. > Or, you could set the PERL5LIB shell environment variable to be the > directory with your perl libraries. If you use this, you won't need > the "use lib" line in your code. You login scripts could > automatically set the PERL5LIB env var to the appropriate directory > for the server or you could set it to all possible directories so the > same PERL5LIB will work on any server you use. This is what programmers.stackexchange.com suggested, and I was starting to poke at it before Rick spoke to me. -- Dave Jacoby Address: WSLR S049 Code Maker Mail: jacoby at purdue.edu Purdue University Phone: 765.49.67368 992 days until the end of XP support From gizmo at purdue.edu Wed Jul 20 11:01:48 2011 From: gizmo at purdue.edu (Joe Kline) Date: Wed, 20 Jul 2011 14:01:48 -0400 Subject: [Purdue-pm] Module Question In-Reply-To: <20110720175407.GE7058@purdue.edu> References: <4E26FC25.9050800@purdue.edu> <20110720175407.GE7058@purdue.edu> Message-ID: <4E27180C.6030901@purdue.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/20/2011 01:54 PM, Doug Yatcilla wrote: > On Wed Jul 20 12:02:45 2011, Dave Jacoby wrote: >> I have modules that run on our servers, separated by purpose. So, >> Dave::First calls Dave::Second in order to get, for example, the SQL >> interfaces. >> >> And this also gets used on RCAC clusters, and I certainly don't want to >> have too much parallel development. Which is where 'use lib' starts to >> hurt. >> >> On our servers, it's >> use lib '/home/jacoby/lib' ; >> use Dave::First ':all' ; >> >> On RCAC servers, it's something way different. I can't do anything with >> Cwd, because that's not going to be ready until after the load library >> stuff happens, which is where I need it. Any suggestions? > > If there are only two systems and you keep your perl libraries in > different directories on each system, you could put two "use lib" > lines in your code listing both directories. > > Or, you could set the PERL5LIB shell environment variable to be the > directory with your perl libraries. If you use this, you won't need > the "use lib" line in your code. You login scripts could > automatically set the PERL5LIB env var to the appropriate directory > for the server or you could set it to all possible directories so the > same PERL5LIB will work on any server you use. > It would probably be preferable to do something in a BEGIN block with @INC rather than muck with a env var. I would give local::lib a try first. joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org/ iEYEARECAAYFAk4nGAwACgkQb0mzA2gRTplmLwCglTPlEUS5/9RPWJs1LECs0Gdw 0xEAn1yFjErvfCyH+LfRgwugYU50PJnh =4OLJ -----END PGP SIGNATURE----- From westerman at purdue.edu Wed Jul 20 13:39:34 2011 From: westerman at purdue.edu (Rick Westerman) Date: Wed, 20 Jul 2011 16:39:34 -0400 (EDT) Subject: [Purdue-pm] Dvorak vs. QWERTY In-Reply-To: <673960930.77822.1311193937884.JavaMail.root@mailhub016.itcs.purdue.edu> Message-ID: <1130368264.77830.1311194374648.JavaMail.root@mailhub016.itcs.purdue.edu> A followup to yesterday's meeting, I enclose a rather heavy article on why Dvorak keyboard may not be better than QWERTY. The article comes from the economic view of why, if Dvorak was so better, it did not displace QWERTY. http://www.utdallas.edu/~liebowit/keys1.html Basically the article says that the few studies that supposedly prove the superiority of Dvorak are potentially flawed. Also the article points out there were many more keyboards beside the QWERTY one during in the early years of the invention of the typewriter. With lots of competition between manufacturers and keyboards why did QWERTY win out ... unless it was the best or at least 'good enough'. -- Rick Westerman westerman at purdue.edu Bioinformatics specialist at the Genomics Facility. Phone: (765) 494-0505 FAX: (765) 496-7255 Department of Horticulture and Landscape Architecture 625 Agriculture Mall Drive West Lafayette, IN 47907-2010 Physically located in room S049, WSLR building From mark at ecn.purdue.edu Wed Jul 20 19:15:16 2011 From: mark at ecn.purdue.edu (Mark Senn) Date: Wed, 20 Jul 2011 22:15:16 -0400 Subject: [Purdue-pm] Dvorak vs. QWERTY In-Reply-To: <1130368264.77830.1311194374648.JavaMail.root@mailhub016.itcs.purdue.edu> References: <1130368264.77830.1311194374648.JavaMail.root@mailhub016.itcs.purdue.edu> Message-ID: <16671.1311214516@pier.ecn.purdue.edu> > A followup to yesterday's meeting, I enclose a rather heavy article on > why Dvorak keyboard may not be better than QWERTY. The article comes > from the economic view of why, if Dvorak was so better, it did not > displace QWERTY. > > http://www.utdallas.edu/~liebowit/keys1.html > > Basically the article says that the few studies that supposedly prove > the superiority of Dvorak are potentially flawed. Also the article > points out there were many more keyboards beside the QWERTY one during > in the early years of the invention of the typewriter. With lots of > competition between manufacturers and keyboards why did QWERTY win out > ... unless it was the best or at least 'good enough'. > > -- > Rick Westerman > westerman at purdue.edu The paper was published in 1990. Lots has happened in Biomechanics, Economics, Ergonomics, and Human Factors research since then. You may want to Google for "dvorak vs qwerty" for more up-to-date information. You may find the http://www.codesharp.co.uk/dvorak/Default.aspx web page interesting. This preceding paragraph had "Overall Effort" scores of 1048 for QWERTY and 817 for Dvorak using the web page. A "j" is very easy to type on a QWERTY keyboard but it is the least frequent letter in Fedora 15's /usr/share/dict/words dictionary---that doesn't make a lot of sense. The word "the" occurs relatvely frequently in English text. On a QWERTY keyboard two of the three keys needed are not on the home row---on a Dvorak keyboard they are all on the home row. I've checked to see if people not in the Purdue Human Factors and Ergonomic Society can attend the (tentative title) "Keyboard Evolution" talk I'm giving to them in September---will send out another note when I know one way or another. I'll also be putting the talk information on the web after that but in a different format. As far as I know as of right now, no one has done a definitive study for exactly how much effort it takes to type a "j" vs. typing a "k" for example. There are lots of metrics used but I've been unable to find definitive underlying science so metrics can be compared scientifically. My take on why QWERTY is more popular: it's hard to displace a technology that is already in place. Mice are commonly used for desktop computers---I find ITAC mouse-trak trackballs more comfortable and use those. For a person that buys a computer that comes with a QWERTY keyboard it takes extra effort to configure the computer to use Dvorak or buy a Dvorak keyboard----some people don't want to go to that effort or take the time to learn Dvorak even though it may save time and repetitive strain injuries in the future. -mark From mark at ecn.purdue.edu Thu Jul 21 04:28:11 2011 From: mark at ecn.purdue.edu (Mark Senn) Date: Thu, 21 Jul 2011 07:28:11 -0400 Subject: [Purdue-pm] Dvorak vs. QWERTY In-Reply-To: <16671.1311214516@pier.ecn.purdue.edu> References: <1130368264.77830.1311194374648.JavaMail.root@mailhub016.itcs.purdue.edu> <16671.1311214516@pier.ecn.purdue.edu> Message-ID: <18963.1311247691@pier.ecn.purdue.edu> Earlier I wrote: > I've checked to see if people not in the Purdue Human Factors and > Ergonomic Society can attend the (tentative title) "Keyboard Evolution" > talk I'm giving to them in September---will send out another note when I > know one way or another. I'll also be putting the talk information on the > web after that but in a different format. You may attend the talk. It hasn't been scheduled yet but I understand it will probably take place at Grisson Hall, Purdue University, West Lafayette, IN in late afternoon in late September. I'll send out another message with the details after they schedule the talk. -mark From gizmo at purdue.edu Mon Jul 25 08:28:35 2011 From: gizmo at purdue.edu (Joe Kline) Date: Mon, 25 Jul 2011 11:28:35 -0400 Subject: [Purdue-pm] for the dna folks Message-ID: <4E2D8BA3.3070709@purdue.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 A little genomics humor... http://www.smbc-comics.com/index.php?db=comics&id=2317#comic -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org/ iEYEARECAAYFAk4ti6MACgkQb0mzA2gRTpnwmwCfR4CotGvm/FWHya7ffysUydDl e+kAn3ryC4omKprRWW2pGFDMgYfnO91h =jkwK -----END PGP SIGNATURE-----