Lenovo ideapad a1

Introduction

After resisting for a while I finally got hold of my first tablet: a Lenovo Ideapad A1. I bought it to perform the following tasks:

• Remote control for my XBMC setup at home.
• Read PDFs on the sofa, in bed, etc.
• Have a viable alternative to the laptop in limited-mobility environments such as airport terminals, airplane/train/bus seats, etc. All I wanted in these circumstances was to read PDF documents, edit notes and todo lists, etc.

I initially wanted the black-covered version, but finally ordered the white-cover version (get rid of a few fingerprints on the back).

The price is astonishingly cheap: 155 €. What you get:

• A 7" tablet with a weight of ~400 g. You can hold it for hours without tiring your hands.
• Texas Instruments 3622 processor, 1 GHz clockspeed, 512 Mb RAM, 16 Gb Flash memory. Swift enough for most routine applications.
• Connectivity: WLAN, Bluetooth, GPS. No 3G/UMTS.
• Android 2.3.4, which is not the most recent, but most software will still run on it.
• MicroSD card slot, MicroUSB plug, microphone, loudspeaker, 3.5 mm audio jack, power button, reset button.
• Battery life of 5 to 8 hours depending on usage.

I have had it for half a week and am very satisfied with the purchase. In what follows I point out a few issues I have had and a list of tips&tricks, which will be updated regularly.

Here is a pic running GO launcher (I was changing the lower icons at the moment) with my frequently used apps and a custom background (a pic I took at the Danube in Vienna)

High-frequency noise

Occasionally, a high-pitched noise will appear. This systematicall happens after unlocking the screen. It is audible only in very quiet atmospheres and becomes irritating after a while. This seems to be a general issue for this pad. Solutions I have found (trial and error and forum searches):

• Press the volume-up or volume-down button.
• Settings --> Sound --> Screen loc sounds (select). Using this option, a sound is produced when the screen is unlocked. This wipes away the high-pitch noise.
  
  

Reading 2-column PDFs

Research journal articles are frequently printed in two columns. This makes them extremely tedious to read on a tablet screen. I have found no free android app which automatically rearranges 2-column PDFs into single-column PDFs suitable for display in small screens. The only solution I could find (thanks to Julio) is k2pdfopt. This program does exactly the aforementioned task: 2column ---> 1column. White margins are cropped out, so you don't have to fiddle around with zoom in/out every time you want to change a page or go to the next column.

Bookmarking PDFs

I haven't found a free PDF reader capable of handling bookmarks. The closest I have come to is using Acrobat Reader. It remembers the current position when you exit. Next time you load the document, you are brought to the position where you left it. That's already something.

Synchronizing Google Tasks

Sync with Google works out of the box (calendar, mail, contacts). However, tasks were a bit more tedious. I finally settled for Any.do.

Frequently used apps

• Arxiv.org mobile: to browse the arxiv.org on the go, on the sofa, etc.
• DS Audio to stream from my Synology DS411j directly to my tablet.
• XBMC remote as a remote control for an XBMC session running on a computer with a TV monitor + audio system which serves as my media center at home.
• Dropbox. I keep my notes and papers to read synced with Dropbox (in my linux machines I just create symbolic links in ~/Dropbox pointing to the corresponding directories and files). Dropbox for android has the offline reading and editing capability, as opposed to Google Docs as of March 18, 2012.

Still pending

• Test VPN.
• Find a git repository browser.
• Test GPS
  

Get output of a system call (with arguments) into a gnuplot string

Let there be a program e2t which accepts four numerical double-precision arguments (E, Ug, Ur, Ud) and which writes a string to stdout.

In order to call the command from a gnuplot script and to capture the output string we can do the following:

E=500
Ug=20
Ur=20
Ud=5
str=sprintf("e2t %f %f %f %f", E, Ug, Ur, Ud)

So far we have defined the string we would enter in a regular shell session. We now issue the system call and capture the output in the string variable tof:

tof=system(str)

Arch Linux on the ASUS eee 1101HA

The problem in installing linux in this netbook is that its graphics chipset is the Intel Poulsbo Chipset, also known as Intel GMA 500, and Intel System Controller Hub US15W. This hardware was not developed by Intel, they only licensed it. As a result, standard Intel drivers do not work with this graphics chipset. A number of alternative drivers exist, each with its pros and cons.

UPDATE [July 1, 2012] - ARCH LINUX WITH NATIVE RESOLUTION, FINALLY!!


Today I have picked up my old ASUS Eee 1101ha from the closet and installed arch linux again. To my surprise, native resolution is supported out of the box without doing anything.

The important thing is to install ONLY the driver package xf86-video-fbdev. Get rid of all other xf86-video-* packages.

You don't need any 915resolution* package from AUR. Uninstall them if you had them installed.

The user mrElendig in freenode.net told me that some users are complaining about sudden black-outs which last about 1 second. I have so far not been a victim of this  malfunctioning.

My setup on the eee 1101ha is now arch linux with xmonad and I could not be happier with this little devil! Let's see how the battery is performing after such a long time. In any event the screen and the keyboard of this netbook are excellent. This is a good machine to work with (provided you can perform demanding computations elsewhere).

Happy arching!

It is not straightforward to get the native 1366x768 resolution and to get decent video playbkack for an arbitrary linux distribution. If you're trying to get archlinux to run on this laptop, take a look at this arch forum post, which is now 18 pages long. Some people are satisfactorily reporting progress in getting this netbook running with archlinux and the kernel 3.0. I tried and couldn't succeed after one hour :(


If your time is short and you want to have a running Linux in your ASUS eee 1101HA right away, take one of the following:

1. Install Ubuntu 11.04 and follow these steps to install the (currently supported) emgd drivers. You will get smooth Youtube video playback (up to 240p or 360p in full screen, up to 480 in "normal-window" view) and a reasonably responsive experience.
2. Install Jolicloud, an Ubuntu-based distribution that is oriented towards social-network or cloud computing. Nevertheless you'll still be able to open your xterm and get work done. Video playback runs smoothly, but fullscreen just didn't work :(

I chose the first option:

I will think twice before updating...


Have fun!

Finding an available unit for writing to (or reading from) a file in Fortran

To open a file for reading or writing in Fortran, a unit number must be associated to it. For example, the statement

OPEN(33,FILE="foo.dat")

will associate unit 33 with the file foo.dat. However, the unit number 33 might already be associated to another file:

OPEN(33,FILE="bar.dat")
(...)
OPEN(33,FILE="foo.dat")
(...)
WRITE(33,*) "blablabla"

Compiling with either ifort or gfortran (even with the -Wall and -Wextra flags) will not produce a compilation error (nor warning), and "blablabla" will be written to foo.dat and not bar.dat. Although the behavior is actually the intended, such situations should be avoided to prevent confusion and stupid bugs and to promote sensible code.

With the keyword INQUIRE we can check whether a unit number is already associated:

LOGICAL :: ASS
(...)
INQUIRE(UNIT=33,OPENED=ASS)
IF (ASS) THEN
  WRITE(*,*) "ERROR: unit 33 already associated"
  STOP
ENDIF

Thus, we can write a function like the following to determine an available unit number to open a file in write mode, saving us from keeping unit-number lists in our head:

! Find available I/O unit and associate it to a file in
! write mode. Check for file I/O errors.
FUNCTION FOW_C(FNAME) RESULT(U)

  CHARACTER(LEN=*),INTENT(IN) :: FNAME

  INTEGER(4) :: U,OSTAT

  LOGICAL :: UOPEN
 
  U=33

  INQUIRE(UNIT=U,OPENED=UOPEN)

  DO WHILE (UOPEN)

    U=U+1

    INQUIRE(UNIT=U,OPENED=UOPEN)

  ENDDO

  OPEN(UNIT=U,FILE=FNAME,IOSTAT=OSTAT,ACTION="write")

  IF (OSTAT/=0) THEN

    WRITE(*,'(a)') "FOW_C(): Could not open file. Aborting."

  ENDIF

END FUNCTION FOW_C

The function tries to open unit 33. If unit 33 is already used, it tries unit 34, 35, ..., until an available unit number is found. Then, it tries to open the file for writing and to associate it to the available unit number. If something goes wrong  (disk full or the like), an error message is printed out and the execution of the program is stopped.

As far as I know there is no intrinsic function to obtain an available unit number for file I/O. The proposed function uses standard procedures, so it is in principle portable. It can be trivially extended to handle also reading (ACTION="read").

In practice we can use it as follows:

INTEGER(4) :: U1,U2
(...)
U1=FOW_C("bar.dat")
U2=FOW_C("foo.dat")
WRITE(U1,'(a)') "blablabla"
WRITE(U2,'(a)') "blublublu"
CLOSE(U1)
CLOSE(U2)

You can either do this or remember which unit numbers you have used. Using the proposed function has the additional advantage that I/O-errors are systematically controlled.

In a future post I will discuss how to organize your own library of functions and subroutines, so that you can code them once and make them available to all your Fortran programs.

Happy Fortranning!

First post!

I am starting this blog to keep track of neat tips&tricks I run into while carrying out my daily computing tasks as a PhD student in physics. I have so far kept track of them by writing plain text files in my $HOME/tipsandtricks directory, but I figured I might as well blog about these tricks and share them.

The posts in this blog will mainly be about linux, fortran, vim, gnuplot, cmake, git, fluxbox, etc., which are the tools that let me do my work without getting on my way. Generic posts about tech, science, and maybe life as a physics PhD student might also appear. Unfortunately, at my current department I have to use a few macs (which I hate with a passion) along with my linux machines (which I love), so occasional rants about mac are also to be expected ;)

Feel free to comment, extend, and correct.

Have fun!