"Who gives a shit?" attitude -> better mental performance

This article was a big surprise to me. The gist is that using the executive function of your brain (switching from deliberation to implementation - making and acting on decisions) has a strong negative impact on all sorts of mental activities.
For example, deciding whether to have cake or cornflakes for breakfast could be enough to make you perform poorly at an interview later on.

A further implication of this (to me) is that people who coast through much of the day like zombies (especially in the morning), not making many decisions, are much better able to perform when they need to, because they haven't depleted those resources yet.

The moral of the story: if you want to improve your overall mental performance, get into the habit of saying "who gives a shit?" about irrelevant decisions like where to put the furniture or whether the curtains need to be washed again this week. Don't deliberate over mundane issues. Don't waste your energy. Just pick the first reasonable option. I'd like to know if strategies like this can minimise this effect, or if we really have to go around like cattle - I know I do, most of the time... Is that what girlfriends are for? To decide where the couch and TV should be and what washing powder to use, so that I can reserve my brain power selfishly for 'clever' use later (which rarely happens)? Seems a little unfair, really...

I have more questions. How do we recover from the effects? How long does it take? Can we speed it up? What about meditation, or induced alpha/theta/delta brainwaves (i.e. by listening to binaural beats, say)? Why does it happen?

Enough rambling (I guess...), I'm off to dodge some decisions! Probably.

(Auto-)Growing Panes

In another Swing-related weirdness note, it seems that a certain combination of apparently logical options regarding GridBagConstraints and a JTextArea will cause the JTextArea and enclosing JPanel to expand horizontally by gridBagContraints.ipadx pixels per step, forever.

After scratching my chin in confusion, I whittled out the following minimalish example that demonstrates the result:

import java.awt.Color;
import java.awt.GridBagConstraints;
import java.awt.GridBagLayout;

import javax.swing.BoxLayout;
import javax.swing.JFrame;
import javax.swing.JLabel;
import javax.swing.JPanel;
import javax.swing.JTextArea;
import javax.swing.SwingUtilities;
import javax.swing.border.LineBorder;

public class TextAreaExample {
 public JPanel createContentPane() {

  JPanel contentPane = new JPanel();

  JPanel mainPanel = new JPanel(new GridBagLayout());
  GridBagConstraints c = new GridBagConstraints();
  // ipadx > 0 causes textarea panel to grow horizontally forever if linewrap is set!
  c.ipadx = 1;

  JPanel leftPanel = new JPanel();
  leftPanel.add(new JLabel("Left"));
  mainPanel.add(leftPanel, c);

  JPanel logPanel = new JPanel();
  logPanel.setLayout(new BoxLayout(logPanel, BoxLayout.PAGE_AXIS));

  JLabel label = new JLabel("Hello");
  logPanel.add(label);

  // create misbehaving textarea
  JTextArea log = new JTextArea(10, 40);
  log.setLineWrap(true);
  log.setBorder(new LineBorder(Color.BLUE));
  logPanel.add(log);

  mainPanel.add(logPanel, c);

  JPanel rightPanel = new JPanel();
  rightPanel.add(new JLabel("Right"));
  mainPanel.add(rightPanel, c);

  contentPane.add(mainPanel);
  return contentPane;
 }

 private static void createAndShowGUI() {
  JFrame frame = new JFrame("JTextArea growth test");

  TextAreaExample demo = new TextAreaExample();
  frame.setContentPane(demo.createContentPane());

  frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
  frame.pack();
  frame.setVisible(true);
 }

 public static void main(String[] args) {
  SwingUtilities.invokeLater(new Runnable() {
   public void run() {
    createAndShowGUI();
   }
  });
 }
}

I can get around it by setting a preferred size on the JTextArea (a size of 0,0 seems to do the trick without changing the initial layout), but what the hell?

Swing and a miss

Does this method Javadoc from the Swing API confuse you? It confuses me:

/**
* Sets the the vertical alignment.
*
* @param alignmentX the new vertical alignment
* @see #getAlignmentX
* @beaninfo
* description: The preferred horizontal alignment of the component.
*/
public void setAlignmentX(float alignmentX) {

As you can see, the method description and param seem to conflict directly with the beaninfo description. I was sure the first two are a typo, copied from the alignmentY equivalent, but let's have a look at setAlignmentY:

/**
* Sets the the horizontal alignment.
*
* @param alignmentY the new horizontal alignment
* @see #getAlignmentY
* @beaninfo
* description: The preferred vertical alignment of the component.
*/
public void setAlignmentY(float alignmentY) {

???

Also, using it is confusing and the docs don't seem very helpful. I created a JPanel using a vertical BoxLayout, so that as you .add(component)s they stack up beneath each other.
To the empty box panel I added a JLabel with the text "Log" and beneath that, a JTextArea which would hold the log output.

However, I noticed on running the program that the label was not left-aligned - instead, it was indented by about 40 pixels beyond the log textarea beneath. Worse still, when text appeared inside the JTextArea, the label above would jump horizontally right, bizarrely. So the most logical thing to do seemed to be to call label.setAlignmentX(Component.LEFT_ALIGNMENT) to keep the label aligned to the left side of its containing box.
Seemed to be the logical thing to do. But no, this caused no obvious change. Various combinations of this did nothing, until I made the same call on the textarea underneath.

So if you have a vertical box containing a label with a textarea underneath it and you want the LABEL to be left-aligned, you have to tell the TEXTAREA to left-align itself.

...WHAT?

The great antivirus scandal of 2008

This report is pretty scary. It's understandable that everybody overlooks the fact that virus scanners can be vulnerable, especially when they're built with lots of 3rd-party plugins (e.g. upx/zip/arj/rar/etc unpackers).

But the fact is, you can become automatically infected by a virus without running the infected program/trojan yourself; the virus scanner scans it automatically, but the file is designed to exploit a vulnerability in your virus scanner and you become infected.
That's a lot more dangerous than having no AV software and just being careful which programs you run...

Symantec is among the worst here, with about 32 vulnerabilities listed compared to 6 or 7 in FProt, AVG and BitDefender.
Personally, I think it serves AV vendors right for coding their products in languages as dangerous as C and C++, which are so vulnerable to buffer overflow mistakes. And nobody can code without mistakes. And the frequency of mistakes increases with code size, of course. They should have written their scanners/plugins in a better programming language (e.g. Lisp).

Update on Gambit-C Scheme benchmarks

Thanks to some helpful comments from a few people on my previous post about Gambit-C Scheme, I rebuilt and ran (with a larger minimum heap size specified) those few benchmarks I was bothered pulling off their site and the shootout site for SBCL (which is a very fast Common Lisp implementation I'm interested in using as a kind of reference).

The results in general are much better:

time ./fannkuch -:m20000 11 > output_fannkuch

real 0m9.931s
user 0m9.465s
sys 0m0.172s

time ./fasta -:m20000 25000000 > output_fasta

real 0m29.843s
user 0m25.220s
sys 0m2.700s

time ./binary-trees -:m20000 16 > output-binary-trees

real 0m2.770s
user 0m2.581s
sys 0m0.089s

time ./pidigits -:m20000 2500 > output 
real 0m3.322s
user 0m3.093s
sys 0m0.110s

A range of improvement is apparent, with binary-trees benefitting a lot and pidigits not really getting much better.
I picked a 20 meg heap because a) it seems wasteful for individual programs to reserve (and probably waste) huge chunks of memory, if you're running a lot of programs b) when I tried higher values up to 50 megs on the fasta benchmark, it was faster, but only by another .2 seconds or so; about 1-2%... and c) Most other languages, and in this case SBCL, don't seem to request more than about 20 megs for their initial heap size either.

Of note is the fact that the prebuilt version produced slightly faster code than the version I compiled myself, specifying the optimisations mentioned in the INSTALL.txt document. Not sure why... These numbers are for the Gambit I compiled myself, and I didn't feel like dumping it and re-installing the prebuilt version just yet.

Anyway, these are nice results!