Re: [ANNOUNCE] London Perl M[ou]ngers October Social - 2012-02-02 - Somers Town Coffee House, Euston, NW1 1HS
On Mon, Jan 30, 2012 at 12:41:24PM +, Leo Lapworth wrote: The London.pm February social will be on Thursday the 2nd, at the Somers Town Coffee House, just around the corner from Euston station (now under new management). Somers Town Coffee House 60 Chalton Street Euston, NW1 1HS http://london.randomness.org.uk/wiki.cgi?Somers_Town_Coffee_House,_NW1_1HS This is today! I'll be there nice and early. You can recognize me as I will have Amelia, a stuffed camel, with me. I shall also be wearing orange. See you there, Leon.
Re: Perl problem - COM ports and filehandles
On Wed, Feb 01, 2012 at 11:59:17AM -0500, Darren Harwood wrote: good afternoon all, me=long time lurker, first time poster! It happens that there's a social meeting tonight near Euston station - you could also come and lurk at that: http://london.pm.org/pipermail/london.pm-announce/2012-January/000266.html (or not lurk, and claim a free beer (or beer-equivalent thing) if it's your first time.) (warning! there is code in the post below - but as a first time poster i have no idea how well that is going to format itself for your consumption...we'll seei apologise now if its a garbled mess. i did try to find posting advice on the london.pm website, but no joy) Something like: 1) jobs go to the jobs list at j...@london.pm.org 2) Perl is sometimes considered Off Topic, as a joking reference to how much other chat is on the list. ? Yes, there's not much advice. i am trying to convert a perl script from *nix to win32. i am having difficulty with a couple of things: 1) the unix script opens a filehandle to a device like this: open my $pipe, '+', '/dev/ttyUSB0' or die Couldn't open pipe for reading and writing; my $mb = myDevice::myObject-new($pipe); this filehandle is then referenced in the module via a mechanism containing: my $rin = ''; vec($rin,fileno($pipe),1) = 1; my ($nfound, $timeleft) = select($rin, undef, undef, $timeDelimiter_s); last if($nfound == 0); my $bytes; sysread($pipe, $bytes, $nfound); The intent of that code looks to be doing non-blocking reads from the serial port. And just the serial port - it's not using select to multiplex between more than one input device. my (clearly incorrect) approach was to substitute the open for a use Win32::SerialPort; (because the device is connected via a virtual serial port over usb) with the following: my $PortObj = tie (*FH, 'Win32::SerialPort', $Configuration_File_Name) || die Can't tie: $^E\n; which i would expect to allow me to code: my $mb = myDevice::myObject-new(FH); but perl complains about the FH bareword. using *FH in the new method allows the script to compile, but i am unsure of the impact!?! *that* part should be fine, but. with my (dodgy?) *FH, i then hit the problem: Can't locate object method FILENO via package Win32::SerialPort when it hits the line: vec($rin,fileno($pipe),1) = 1; and i go no further. i clearly dont have a valid filehandle in my FH at this point - but i'm not sure why or what alternate approach to use. (aside - how do i know if my tied filehandle is opened for input/output/both in this context?) i appreciate that the vec and fileno commands are quite rare (to me, they were brand spanky new) and primarily associated with low level tty operations - so perhaps they dont work the same on win32 as *nix? thoughts on equivalent code? Right. I don't know Win32 at all. But from what I can infer the Unix code is looking to read data from the serial port when data is available, but not block when it is not. It's using file handles and select() as the mechanism to do this. From the code you give I don't think that they are only an implementation detail. The fact that Win32::SerialPort provides a *tied* file handle strongly suggests that it's only emulating a file handle interface for compatibility. I don't think your code needs to use file handles, as I'm guessing that they aren't exposed externally. The documentation for Win32::SerialPort seems, um, big: https://metacpan.org/module/Win32::SerialPort but skimming it I can see that there's reference to non-blocking reads. I think you need to look to see what API Win32::SerialPort provides to do a non-blocking read natively, and use that. I have no idea about the answer to your other question. Nicholas Clark
Re: Perl problem - COM ports and filehandles
* Darren Harwood (darren.harw...@pb.com) [120201 17:08]:
i am trying to convert a perl script from *nix to win32.
i am having difficulty with a couple of things:
1) the unix script opens a filehandle to a device like this:
my ($nfound, $timeleft) = select($rin, undef, undef, $timeDelimiter_s);
thoughts on equivalent code?
my $ob = Win32::SerialPort-new ('COM8') || die;
The POSIX select() is supported under Windows, however... in its
minimal implementation: only network sockets... afaik.
See http://msdn.microsoft.com/en-us/library/ms740141%28v=vs.85%29.aspx
I expect the same is true for poll() (WSApoll on Windows)
And a COM port is not a socket, is it?
Even the UNIXes have different levels of support. They all support
pipes and devices, some do support file-io to be in there.
(warning: I never use Windows so this knowledge is only from
(outdated?) man-pages)
--
Regards,
MarkOv
Mark Overmeer MScMARKOV Solutions
m...@overmeer.net soluti...@overmeer.net
http://Mark.Overmeer.net http://solutions.overmeer.net
Re: Perl problem - COM ports and filehandles
Message: 1 Date: Wed, 1 Feb 2012 11:59:17 -0500 From: Darren Harwood darren.harw...@pb.com Subject: Perl problem - COM ports and filehandles To: london.pm@london.pm.org london.pm@london.pm.org Message-ID: 1ffef92edf70f14d992f400f4c6f70d8b5969b4...@pbi-namsg-03.mgdpbi.global.pvt Content-Type: text/plain; charset=us-ascii good afternoon all, ... i am trying to convert a perl script from *nix to win32. i am having difficulty with a couple of things: 1) the unix script opens a filehandle to a device like this: open my $pipe, '+', '/dev/ttyUSB0' or die Couldn't open pipe for reading and writing; my $mb = myDevice::myObject-new($pipe); I am not an expert in serial comms, but this looks like Unix systems programming in Perl, which makes it inherently less portable. There are USB abstractions in CPAN (Device::USB). See www.libusb.org. If you can port your code to the abstraction in Unix *first*, maybe it will be less painful to port to Win32. Ash
Re: 5 minimums for any perl script?
Leo Lapworth writes: I've been asked what would be a good minimum to have as a coding police for a company that isn't focused on Perl, but uses it occasionally. Hi. Thanks for posing such an interesting question, Leo, and for everybody who's contributed answers -- it's been useful to see the variety of views on this. When I contemplated it the coding policies I most care about a Perl dev team following turned out to be not very Perl specific: 1 Make lots of small commits, one for each separable bug, feature, refactoring, or whatever, and clearly described as much: make a commit whenever you have something which is an unambiguous improvement on the previous state, however small. (Unambiguous cos if adding a feature has temporarily broken a different one, that's not an improvement to somebody using the other feature; don't commit till you've sorted it out.) 2 If a database is involved, spend time thinking about the table design, preferably several of you together before any code is written. Make sure that it represents what it is you're actually storing. A poorly designed database forces all code that accesses it into awkward contortions to sort things out; it pretty much precludes you from ever writing clean code. Whereas if the database design is good but the code lousy, it's much easier to later clean up the code. 3 Don't hard-code host names, absolute file paths, or similar. Always find a way of making them relative to the current server or directory, so that it's easy to check out multiple instances of your codebase and run them. 4 When designing classes try to make each class be a noun which actually exists in the business requirements, not a made-up concept that's an artefact of a particular implementation. Try to make mutators be verbs that exist in the business requirements, rather than nouns which are attributes of the class. 5 Keep code under 80 characters wide. While this seems like a trivial issue, when I've encountered lines that are hundreds of lines long they also seem to suffer other issues, so forcing people to break lines up might make people think about them and the readability of the code a bit more. Shorter lines also generally diff more nicely. Those might be useful if you mean that the team in question only occasionally do any development at all (and happen to use Perl for it). But if it's a team of full-time developers who are adept at programming in other languages but only occasionally use Perl then they're probably on top of that kind of thing already and some more Perl-specific advice would be better. What'd be most useful to them depends which other languages they are most familiar with, and what level they've reached with Perl. (For example in many places use strict and use warnings goes without saying, quite literally: it doesn't need to be said in a coding policy cos everybody's doing it anyway.) But here's a go: 1 Write your Perl in a way which maps to the business requirements as closely as possible. Perl is a very expressive language, allowing you more freedom than most in how you express a particular instruction. For example, map, grep, statement modifiers, and regular expressions built into the language offer ways of expressing things not found in some other languages. Use this to your advantage, so that it's easier to see that the requirements and their implementation match. 2 Look on Cpan for everything. If you think a task is in any way common or might have been done before, check Cpan. Bother to install Cpan modules even for fairly small things which might not seem worth the hassle of installing a module -- because doing so means the module is then installed and available for use by other programs you write in the future too, and collectively it is worth it. For example it may not seem worth installing List::AllUtils just to avoid writing your own max function, but if you do install it then you have a handy library of common functions available. And if you use cpanm to install modules it isn't much hassle any more anyway. 3 Use strict and warnings, and act on them. If you get a warning, find out what it means. Then either fix the issue or (if you've determined it isn't actually an issue) deactivate the warning for that part of the code, with something like: no warnings qwuninitialized; Don't get into the habit of putting up with 'ignorable warnings' which you're used to seeing scrolling past, and therefore potentially missing new ones. 4 Design for testability. It can be awkward to graft tests into some Perl code which wasn't designed with testing in mind in the first place. So think about testing from the start, even if you write your tests later or don't test everything. In
Re: 5 minimums for any perl script?
On Thu, Feb 02, 2012 at 02:57:35PM +, Smylers wrote: 1 Make lots of small commits, one for each separable bug, feature, refactoring, or whatever, and clearly described as much: make a commit whenever you have something which is an unambiguous improvement on the previous state, however small. (Unambiguous cos if adding a feature has temporarily broken a different one, that's not an improvement to somebody using the other feature; don't commit till you've sorted it out.) But do commit at the end of the day, even if it's still broken. It's OK to break your dev branches usually, and you want to get the only copy of your work-in-progress off your personal desktop if only so it gets backed up. 2 Look on Cpan for everything. If you think a task is in any way common or might have been done before, check Cpan. s/If you think.*before,// There's plenty of *un*common things on the CPAN too. Some are rubbish, of course, but others are maintained by weirdo obsessives who have spent years agonising over the edge-cases. Bother to install Cpan modules even for fairly small things which might not seem worth the hassle of installing a module -- because doing so means the module is then installed and available for use by other programs you write in the future too, and collectively it is worth it. But do remember to list it as a dependency and make sure that you add it to whatever you use for automagically installing dependencies when you deploy a new version of the code, or add a new developer to your team. Think about how you'll cope with future versions of modules changing their behaviour - this could be as a bug fix, or as a new bug, or deprecating old behaviour which the author has decided to no longer support, or ... -- David Cantrell | A machine for turning tea into grumpiness It's my experience that neither users nor customers can articulate what it is they want, nor can they evaluate it when they see it -- Alan Cooper
Re: Laptop Recommendation
Mallory van Achterberg writes: Hi, Whenever you find what you like, let us know. When looking for a 13 laptop last fall things sucked... if you wanted Linux. The ThinkPad X220 is what I went with. Here's some notes on the candidates -- all lightweight laptops, about 12 screens, with 128 Gb SSD, 4 Gb ram, and similar processor options: * Macbook Air: Ruled out early on because maximum ram is 4 Gb. I'm buying something with 4 Gb now and hoping to use it for 4 years, so I'd like the possibility of sticking more ram in it later if 4 Gb turns out not to be enough or software continues to get hungrier. * Asus something-or-other: Ditto. * Dell Lattitude E6220: http://www.dell.com/uk/business/p/latitude-e6220/pd 12.5, 1.44 kg, has good reviews and is available with Ubuntu rather than Windows (if ordered by e-mail). I liked the idea of that, not because installing Ubuntu is hard but because I treat buying things as political activity, so I'd like my purchase to be counted somewhere in a tally of customers who want Linux laptops, and to support a supplier that offers them. Also, from previous laptops I already have a small collection of Dell power supplies, so everything else being equal I'd buy Dell again then leave a spare power supply in my bag and have the advantage of less scrabbling under desks. However, there's a report from an E6220 owner of full touchpad functionality not working under Linux: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/883928 The E6620 is certified to work with Ubuntu, but the touchpad isn't one of the components covered by the certification: http://www.ubuntu.com/certification/hardware/201101-7178:201102-7187:201102-7188/components When I asked the Dell salesperson about this he said that they don't support Ubuntu, and he couldn't tell me whether the touchpad would work on it. He didn't seem to grasp the point that I wasn't interested in spending £1200 on something without knowing whether it worked. So I tried again, with a Dell live chat on their website; same answer (but in worse English, from somebody even less well informed). Neither of them seemed in the slightest bit bothered that another customer had publicly posted a claim that their product doesn't work, nor did they make any attempt to contradict that claim, nor seem bothered they were losing a sale over it. Overall I don't think their sales staff told me anything that I hadn't read for myself on their website ... but discovering that was excruciating. On another question the salesperson told me a week ago he'd get back to me with an answer, and hasn't yet done so. Basically this sale was Dell's for them to lose, and they managed to lose it. * Lenovo ThinkPad X220: http://shop.lenovo.com/SEUILibrary/controller/e/gbweb/LenovoPortal/en_GB/catalog.workflow:expandcategory?issBase=ProductsCategoryissCategory=/Notebooks/ThinkPad%20notebooks/X%20Series/ThinkPad%20X220 12.5, 1.3 kg. Was about £130 more than the same spec of Dell E6220. Not available with Linux in the UK, and obviously won't work with my Dell power supplies. But in general ThinkPads have good Linux support. Lenovo UK don't have any sales staff or any way you can ask questions before purchase; this turns out to work in their favour, because it avoids the possibility their staff will be put me off the sale. What they do have is Cory Doctorow writing about running Ubuntu on his X220, in an article which is more informative than any salesperson I've encountered: http://www.guardian.co.uk/technology/2011/may/17/computing-opensource Last night it was starting to look like this might be the favourite anyway when I saw Lenovo had just started a sale on X-series laptops, offering 10% off till February 9th. This brought it down to the same price as the Dell, which made it an easy choice to buy one. So I'm grateful to Dell staff for drawing out this process so long that Lenovo's prices dropped! Unfortunately the actual sales process wasn't smooth. Taking payment is outsourced to Digital River, whose website timed out several times -- including one occasion when I couldn't be completely sure whether it had made the purchase; I guessed it hadn't because no confirmation e-mail had arrived. Trying again this morning I got through, but had to phone my credit card provider to authorize the transaction; it had initially been declined because my card provider thought it looked fraudulent. And then about an hour later Lenovo phoned me to confirm my contact details before they sent me the confirmation e-mail! Ordering from a website shouldn't involve 3 attempts and 2 phone calls, surely? * Samsung 900X3A: http://www.samsung.com/uk/consumer/pc-peripherals/notebook-computers/ultra-portable/NP900X3A-A01UK 1.31 kg, 13.3. It looks like Samsung have a terrible reputation for Linux support; a couple of separate people
Re: Laptop Recommendation
* Smylers (smyl...@stripey.com) [120202 17:57]: The ThinkPad X220 is what I went with. I am very satisfied with my X220 Tablet (with touch screen) Works out-of-the-box, but the tablet version is not as light as I wished for. -- Regards, MarkOv Mark Overmeer MScMARKOV Solutions m...@overmeer.net soluti...@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
Re: Laptop Recommendation
On 24 January 2012 08:01, Mallory van Achterberg stommep...@stommepoes.nl wrote: Many of the cheaper laptops I would have considered ran Optimus. Optimus is great... if you run Windows. http://jeffhoogland.blogspot.com/2010/09/nvidia-there-is-no-optimus-support-for.html I have an optimus laptop, and its not that bad. It takes a bit of effort at present to get it working, but when you manage to get it going, it works like a charm, and almost as good as it is in windows. https://github.com/Bumblebee-Project/Bumblebee ^ this runs as a daemon backgrounded with a seperate X session running on the GPU. And then to run something accelerated, you have to prefix starting it with a special command optirun ~/path/to/minecraft.sh for example. Its not supported stock anywhere yet that I can see, but there is certainly hope. Its certainly bloody good considering Nvidia are refusing to support it on Linux. -- Kent
Re: Laptop Recommendation
On Fri, Feb 03, 2012 at 08:05:25AM +1300, Kent Fredric wrote: On 24 January 2012 08:01, Mallory van Achterberg stommep...@stommepoes.nl wrote: Many of the cheaper laptops I would have considered ran Optimus. Optimus is great... if you run Windows. http://jeffhoogland.blogspot.com/2010/09/nvidia-there-is-no-optimus-support-for.html I have an optimus laptop, and its not that bad. It takes a bit of effort at present to get it working, but when you manage to get it going, it works like a charm, and almost as good as it is in windows. https://github.com/Bumblebee-Project/Bumblebee ^ this runs as a daemon backgrounded with a seperate X session running on the GPU. And then to run something accelerated, you have to prefix starting it with a special command optirun ~/path/to/minecraft.sh for example. Its not supported stock anywhere yet that I can see, but there is certainly hope. Its certainly bloody good considering Nvidia are refusing to support it on Linux. -- Kent It wasn't just the idea that Optimus wasn't going to support Linux, but also the many reports on forums where people had gotten machines before they knew better. Some folks had graphics while others had something horrible and unusable. Since I once was in a store and we used an Ubuntu 6 disc to check support and we saw absolutely no graphics at all (the machine was an MSIE I believe, and OpenSuse ended up having no problems at all with it) and that's scary if you're ordering a machine online rather than having it in your hands in a shop. -Mallory
Re: Laptop Recommendations
Lenovo (IBM) Thinkpad T400 works for me. 8 G. RAM, dual-core, SSD I don't know if anyone remembers IBM made some form of commitment to support Linux a few years ago. Lenovo took the business over. I'm sure there are newer and snazzier machines around, but this is the first laptop I've had which 'works out of the box' (after the SuSE installation). -- Ciao Richard Foley http://www.rfi.net/books.html On Wed, Nov 28, 2007 at 01:34:39PM +, Nigel Rantor wrote: Hail fellows, I think I'm in the market for a laptop. I've been looking at the Sony Vaios and I'm having a hard time not just going out and getting one. Looking at the SZ series (for teh size and 3G innit) but they only come with Vista, and it seems like not all of the hardware is supported under Linux. (yes, they do provide drivers for XP, but I really would rather not pay MS for Vista, it sends the wrong message, although I may still et one depending on feedback from this) Had a look at the Lenovo ThinkPad T6[01] and the newer models also seem to have some teething problems. Also, they look like a Kwik-Save cashier in comparison with the Vaio Basically, I'm looking for a really fast (well, fast as possible given size), light machine with 3G that can be plonked on a desk at work and hooked up to a monitor and used for development but can also be taken to the far out reaches of my g/fs flat that has no wifi, broadband or indeed telelphone line and still get online... Put it this way, I think if the SZ series came with XP (I need to run a couple of windows apps) and was fully compatible with Debian or Ubuntu I'd probably already have bought one. Any other recommendations that might fit the bill? n
