Many, many years ago I learned basic programming using BASIC (the version that came with PC DOS 5, I think). I even wrote the odd game, but it was all pretty awful. A few years later I learned Turbo Pascal, which was a fantastic experience compared to Basic. It felt all sciency and grown up, and it was my first experience with a real IDE. I even ended up buying a TP book, and became somewhat proficient. This must've been when I was around 18-19.I then stopped programming completely.
At around 30 years of age I decided it was time to get serious about programming again -- I was doing mass spectrometry and needed a simple program that could generate a series of solutions to the identity of a mass/charge ratio given a range of elements. I probably had a quick look at C and C++, but ended up getting a Python book and have been happy Python programmer ever since.
The problem is that I've never been a /good/ python programmer -- and in all these years I've never fully understood the use for (or, in all fairness, use OF) OOP. And at the moment it seems to be holding me back -- all the examples that I find of the use the threading module as well as writing GUIs (using e.g. wxPython) involve using classes. And I just don't understand them well enough to sort out what I need done.
Anyway, long story short: I've written a basic program for communicating with a Metrohm Titrino 736 GP via RS 232. It's found here: https://sourceforge.net/projects/pytitrino/
Currently:
* the code is a mess (see above)
* it works fine for doing monotonic and dynamic end point titrations (MET and DET)
* it saves data to a file, but does so silently (i.e. when you run you won't get any feedback that things are working properly...)
* it uses the thread (not threading) module
* I've managed to pass parameters back and forth between the thread and the main loop using Queue
There are probably much better solutions. One day I hope to be able to stick a GUI on top of it, but the more I look at it I get the impression that one writes the GUI first, then the engine...not that I'd know.
Anyway. That's what I've been up to. Anyone with a bit of programming experience, whom is in possession of an old-school Titrino (i.e. using RS 232) and wants to save $1.5k in software licenses may be interested in taking the sources and turning them into something useful.
Lindqvist - a blog about Linux and Science. Mostly.
03 July 2013
472. Briefly: Iranian PhD students in Australia
I'm not going to leave much in the way of a comment, but this doesn't seem to have been publicised enough. Searching the web quickly didn't bring this up at all, and it's a shame since it's important, in particular if you are an Iranian national thinking about doing a PhD in Australia.
About a week ago the faculty in the chemistry department at my university were informed that heavy restrictions in terms of access to instrumentation has been put in place for students from North Korea, Syria and Iran via Federal legislation.
While I don't think there are any students from North Korea or Syria around, there are several Iranian students at different stages of their PhD. In fact, I would say around 50% of our applicants are from India, 25% are from Pakistan and 20 % are from Iran (in terms of accepted students the ratio is very different)
In practical terms, this means that Iranian students in the department are not allowed to use:
FT-IR
UV-Vis
NMR
Mass spectrometers
Raman
dosimeters
OES/AAS
etc.
All of which are standard instruments which most chemists would find necessary to do research. In addition, they can hardly be considered as being cutting edge, trade secrets or anything like that -- commercial NMR instruments have been around since the 1950s, infrared an UV/Visible spectroscopy go much further back. Mass spectrometry is a standard tool which, although many of the current designs only go back to the 1980s (e.g. ESI), is so conceptually simple and innocuous, that (to me) restrictions on it doesn't make sense. And so on.
In addition, supervisors of Iranian students have been asked to draw up a risk management plan to prevent student access to the above instruments, which is a particular problem given that they are used in teaching as well, and are available on a walk-in basis to undergraduate students doing projects in research labs.
Currently, any supervisor who has an Iranian student needing to use any of the instruments above will need to assign another student to do these measurements for the Iranian national.
While this doesn't formally preclude Iranians from coming to Australia to do a PhD, we have been advised that we should reject any applicants at this point. This may change once the university has figured out exactly where they must draw the line in terms of restricting access to Iranians to different facilities, but for now it's a blanket ban.
My personal opinion is that while you'd be led by the media to think of anyone from North Korea, Syria and Iran as potential spies, these are real people too. Many Iranians would either be completely disinterested in politics, or actively antipathetic to their regime. And the best thing about democracies -- we shouldn't have any issues with them supporting their government either. So I don't really agree with this as a security measure to prevent nuclear proliferation, which must surely be the stated goal.
And if the idea is to put in place sanctions to promote regime change, then why limit the type of instrumentation that students can access? Or are we trying to punish the children of the leadership in Iran? Then why not limit the sanctions to those specifically? Top students tend to come from all socioeconomic classes.
The timing is also very odd, given the recent election of a moderate.
And why Iran and not Belarus, China, Zimbabwe etc.?
Again, I don't like putting opinion pieces on this blog (other than as minor parts/rants of posts with actual content) but I think this should be publicized more.
About a week ago the faculty in the chemistry department at my university were informed that heavy restrictions in terms of access to instrumentation has been put in place for students from North Korea, Syria and Iran via Federal legislation.
While I don't think there are any students from North Korea or Syria around, there are several Iranian students at different stages of their PhD. In fact, I would say around 50% of our applicants are from India, 25% are from Pakistan and 20 % are from Iran (in terms of accepted students the ratio is very different)
In practical terms, this means that Iranian students in the department are not allowed to use:
FT-IR
UV-Vis
NMR
Mass spectrometers
Raman
dosimeters
OES/AAS
etc.
All of which are standard instruments which most chemists would find necessary to do research. In addition, they can hardly be considered as being cutting edge, trade secrets or anything like that -- commercial NMR instruments have been around since the 1950s, infrared an UV/Visible spectroscopy go much further back. Mass spectrometry is a standard tool which, although many of the current designs only go back to the 1980s (e.g. ESI), is so conceptually simple and innocuous, that (to me) restrictions on it doesn't make sense. And so on.
In addition, supervisors of Iranian students have been asked to draw up a risk management plan to prevent student access to the above instruments, which is a particular problem given that they are used in teaching as well, and are available on a walk-in basis to undergraduate students doing projects in research labs.
Currently, any supervisor who has an Iranian student needing to use any of the instruments above will need to assign another student to do these measurements for the Iranian national.
While this doesn't formally preclude Iranians from coming to Australia to do a PhD, we have been advised that we should reject any applicants at this point. This may change once the university has figured out exactly where they must draw the line in terms of restricting access to Iranians to different facilities, but for now it's a blanket ban.
My personal opinion is that while you'd be led by the media to think of anyone from North Korea, Syria and Iran as potential spies, these are real people too. Many Iranians would either be completely disinterested in politics, or actively antipathetic to their regime. And the best thing about democracies -- we shouldn't have any issues with them supporting their government either. So I don't really agree with this as a security measure to prevent nuclear proliferation, which must surely be the stated goal.
And if the idea is to put in place sanctions to promote regime change, then why limit the type of instrumentation that students can access? Or are we trying to punish the children of the leadership in Iran? Then why not limit the sanctions to those specifically? Top students tend to come from all socioeconomic classes.
The timing is also very odd, given the recent election of a moderate.
And why Iran and not Belarus, China, Zimbabwe etc.?
Again, I don't like putting opinion pieces on this blog (other than as minor parts/rants of posts with actual content) but I think this should be publicized more.
02 July 2013
471. Debian Jessie -- gnome-shell bug
Update 3/7/2013:
there are now *gnome-bluetooth packages (3.8.1-2) in the jessie repos now. While I haven't looked closer at them, I presume that they fix this issue.
(on a different note: dist-upgrade currently removes gnome...)
Original post:
I've used debian testing since early 2011, and I've only had a few minor issues during that time.
However, sometimes things happen that reminds you that the Testing release is not meant for mission critical work (and makes me happy that I only use Jessie on my laptop, which I mainly use at home).
So...
Last night I did upgrade and dist-upgrade, which installed the following packages according to /var/log/apt/history:
Now what happens when I log in to gnome via gdm3 I get an empty desktop with no menus, no hot-spots or anything else indicating that things worked out. Alt+F2 doesn't work either, and conky doesn't start.
The only thing that does work is
* my keyboard shortcuts (I've mapped ctrl+shift+Down arrow to chromium)
* guake (which starts with gnome)
Looking at the debian forums the closest post seems to be (although erroneously labelled -- gdm3 DOES start): http://forums.debian.net/viewtopic.php?f=6&t=105393&p=504077&hilit=gnome+shell#p504077
That in turn led to this bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712861
My gnome-shell version is 3.4.2-8,
I don't understand how gnome-bluetooth causes this, especially given that I've disabled bluetooth in rcconf, but whatever it takes...
I tried applying the patch but it failed:
Instead, I ended up making the changes to /usr/share/gnome-shell/js/ui/status/bluetooth.js by hand (remember that you can always use the ttys using ctrl+Fx):
and then delete the Applet part in GnomeBluetoothApplet so that it reads
Then do it again:
At this point I rebooted and everything was back to normal (you can try simply doing 'sudo service gdm3 restart' instead of rebooting).
Anyway, done.
there are now *gnome-bluetooth packages (3.8.1-2) in the jessie repos now. While I haven't looked closer at them, I presume that they fix this issue.
(on a different note: dist-upgrade currently removes gnome...)
Original post:
I've used debian testing since early 2011, and I've only had a few minor issues during that time.
However, sometimes things happen that reminds you that the Testing release is not meant for mission critical work (and makes me happy that I only use Jessie on my laptop, which I mainly use at home).
So...
Last night I did upgrade and dist-upgrade, which installed the following packages according to /var/log/apt/history:
Start-Date: 2013-07-01 22:03:17 Commandline: apt-get dist-upgrade Install: p11-kit:amd64 (0.18.3-2, automatic), libgnome-bluetooth11:amd64 (3.8.1-1, automatic), libgcr-base-3-1:amd64 (3.8.2-3, automatic), libtasn1-6:amd64 (3.3-1, automatic), libgcr-ui-3-1:amd64 (3.8.2-3, automatic) Upgrade: libnm-gtk0:amd64 (0.9.8.2-1, 0.9.8.2-1+b1), libgcr-3-1:amd64 (3.4.1-3, 3.8.2-3), gir1.2-gcr-3:amd64 (3.4.1-3, 3.8.2-3), network-manager-gnome:amd64 (0.9.8.2-1, 0.9.8.2-1+b1), gnome-keyring:amd64 (3.4.1-5, 3.8.2-2), gcr:amd64 (3.4.1-3, 3.8.2-3), gnome-bluetooth:amd64 (3.4.2-1, 3.8.1-1), gir1.2-gnomebluetooth-1.0:amd64 (3.4.2-1, 3.8.1-1), gir1.2-gck-1:amd64 (3.4.1-3, 3.8.2-3) End-Date: 2013-07-01 22:03:29
Now what happens when I log in to gnome via gdm3 I get an empty desktop with no menus, no hot-spots or anything else indicating that things worked out. Alt+F2 doesn't work either, and conky doesn't start.
The only thing that does work is
* my keyboard shortcuts (I've mapped ctrl+shift+Down arrow to chromium)
* guake (which starts with gnome)
ps aux|grep gnome-shellreturns nothing, which might be a clue.
Looking at the debian forums the closest post seems to be (although erroneously labelled -- gdm3 DOES start): http://forums.debian.net/viewtopic.php?f=6&t=105393&p=504077&hilit=gnome+shell#p504077
That in turn led to this bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712861
My gnome-shell version is 3.4.2-8,
I don't understand how gnome-bluetooth causes this, especially given that I've disabled bluetooth in rcconf, but whatever it takes...
I tried applying the patch but it failed:
mkdir ~/tmp cd ~/tmp wget "http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=66;filename=GnomeBluetooth.patch;att=1;bug=712861" -O blue.patch sed -i 's_js/ui/status/bluetooth.js_/usr/share/gnome-shell/js/ui/status/bluetooth.js_g' blue.patch sudo patch -p0 < blue.patch
Instead, I ended up making the changes to /usr/share/gnome-shell/js/ui/status/bluetooth.js by hand (remember that you can always use the ttys using ctrl+Fx):
6 const Gio = imports.gi.Gio; 7 const GnomeBluetoothApplet = imports.gi.GnomeBluetoothApplet; 8 const GnomeBluetooth = imports.gi.GnomeBluetooth; 9 const Gtk = imports.gi.Gtk;
and then delete the Applet part in GnomeBluetoothApplet so that it reads
38 this._killswitch.connect('toggled', Lang.bind(this, function() {
39 let current_state = this._applet.killswitch_state;
40 if (current_state != GnomeBluetooth.KillswitchState.HARD_BLOCKED &&
41 current_state != GnomeBluetooth.KillswitchState.NO_ADAPTER) {
42 this._applet.killswitch_state = this._killswitch.state ?
43 GnomeBluetooth.KillswitchState.UNBLOCKED:
44 GnomeBluetooth.KillswitchState.SOFT_BLOCKED;
45 } else
46 this._killswitch.setToggleState(false);
Then do it again:
96 _updateKillswitch: function() {
97 let current_state = this._applet.killswitch_state;
98 let on = current_state == GnomeBluetooth.KillswitchState.UNBLOCKED;
99 let has_adapter = current_state != GnomeBluetooth.KillswitchState.NO_ADAPTER;
100 let can_toggle = current_state != GnomeBluetooth.KillswitchState.NO_ADAPTER &&
101 current_state != GnomeBluetooth.KillswitchState.HARD_BLOCKED;
102
At this point I rebooted and everything was back to normal (you can try simply doing 'sudo service gdm3 restart' instead of rebooting).
Anyway, done.
Subscribe to:
Posts (Atom)