
I suppose it’s time to start thinking about my presentation on Android development on 24th March. I’ll bring a couple of my own devices (must remember a USB cable as well...). If I can have access to the demo machine about an hour before the presentation, I can install the Android SDK on it—I normally put that just in my own user directory. However, I’ve found I have trouble accessing connected devices unless I launch the ADB server as root. I can pull down various bits of sample code off GitHub and developer.android.com. I’ve been able to do Java compilations with OpenJDK as a replacement for Sun JDK. I assume we can project the desktop machine display for everyone to see, but I’m not so sure how we do that with an Android device. (My devices may speak some version of MHL, if that helps.) Or we could run sample apps on an emulator on the desktop machine?

I suppose it's time to start thinking about my presentation on Android development on 24th March.
My apologies, I'll be overseas for that meeting.
I'll bring a couple of my own devices (must remember a USB cable as well...). If I can have access to the demo machine about an hour before the presentation, I can install the Android SDK on it--I normally put that just in my own user directory. However, I've found I have trouble accessing connected devices unless I launch the ADB server as root.
The meeting room has a university-administered Windows machine, so you won't be able to use that for that purpose. However, you can access the projector with the VGA cable that is available.
I can pull down various bits of sample code off GitHub and developer.android.com. I've been able to do Java compilations with OpenJDK as a replacement for Sun JDK.
OK.
I assume we can project the desktop machine display for everyone to see, but I'm not so sure how we do that with an Android device. (My devices may speak some version of MHL, if that helps.) Or we could run sample apps on an emulator on the desktop machine?
Emulator is an option. Also, we can always just look over your shoulder. :-) Cheers, Peter -- Peter Reutemann, Dept. of Computer Science, University of Waikato, NZ http://www.cms.waikato.ac.nz/~fracpete/ Ph. +64 (7) 858-5174

On Fri, 14 Feb 2014 15:16:05 +1300, Peter Reutemann wrote:
The meeting room has a university-administered Windows machine, so you won't be able to use that for that purpose. However, you can access the projector with the VGA cable that is available.
So I’ll have to bring my own Linux machine? I don’t have a suitable laptop, but I could bring my main desktop machine. Will I able to get Internet access? Lawrence

So I'll have to bring my own Linux machine? I don't have a suitable laptop, but I could bring my main desktop machine. Will I able to get Internet access?
Forgot what I said about not being there, I thought you meant the February meeting. I can bring a laptop along that has internet access (just remind me the week before the meeting). Sorry about the confusion. Very busy ATM. Cheers, Peter -- Peter Reutemann, Dept. of Computer Science, University of Waikato, NZ http://www.cms.waikato.ac.nz/~fracpete/ Ph. +64 (7) 858-5174

Last nights wlug meeting included a presentation of a BASH command file. The file demonstrates many features of bash, and is suitable for analysis and educational purposes. The bash file is designed to download map tiles and then montage the tiles to create a single image. If you would like the bash file and the presentation material, they are available from this wlug blog... http://www.wlug.org.nz/blog/view/3709/review-of-a-bash-command-file cheers, Ian.

On Tue, 25 Feb 2014 15:09:34 +1300, Ian Stewart wrote:
http://www.wlug.org.nz/blog/view/3709/review-of-a-bash-command-file
Just a couple of thoughts: * Instead of echo line1 >file echo line2 >>file echo line3 >>file ...etc... How about { echo line1 echo line2 echo line3 ...etc... } >file * It’s easy to fix handling of the case where the output path might contain spaces: just put some double quotes in the right places.

{ echo line1 echo line2 echo line3 ...etc... } >file
“Here documents” in bash are also useful for this kind of work. In many ways, they’re better, because they preserve the formatting of the document completely: #!/bin/bash foo=“Some Variable" cat > file << EOF verbatim text here more verbatim text here, with preceding whitespace preserved no echo command needed expand some variable here: $foo EOF will produce a file that contains everything between the two EOFs exactly. It will still expand the contents of $foo out appropriately $ ./heredoctest.sh $ cat ./file verbatim text here more verbatim text here, with preceding whitespace preserved no echo command needed expand some variable here: Some Variable More on heredocs here: http://wiki.wlug.org.nz/HereDocuments

Lawrence and Daniel, Thanks for your suggestions on ways to improve the bash file. Along with the file, I have posted your suggestions as comments here: http://www.wlug.org.nz/file/view/3704/bash-command-file cheers Ian.
participants (4)
-
Daniel Lawson
-
Ian Stewart
-
Lawrence D'Oliveiro
-
Peter Reutemann