As the day progresses...
I've decided to keep a log of everything that comes my way on my journal today. I hardly ever post so this will be a good exercise for me.

Fist one that has roled my way. A group of us get together to eat lunch every friday, we decide where we are going to go in mail. I have just received this:

731 Apr 1 XXXX XXX (1193) No friday lunch today
--

Subject: No friday lunch today

...Unless some of us want to go. Ok that's as close as I get to an April
Fools joke.

I have no preference today. Any ideas that aren't too lame? :)

---
And look here was number two:

HPC Users' Newsletter Number 0401 April 1, 2005

This newsletter discusses programming, commands, tools, applications,
and other issues of importance to users of high-performance computer
systems.

Topics:
- Massively Parallel COBOL
- The Arctic History of Computers
- ClosedMP
- Energy Woes Spur Research in Methane Supercomputer
(I'm sure Foofs would love to read the last one.)


------------------------------------------------------------------------
-- Massively Parallel COBOL --
------------------------------------------------------------------------
The editors of the HPC Users' Newsletter recently sat down for an
interview with Bill Franklin. Bill is the founder and CEO of Chatanika
Software of Olnes, Alaska. Chatanika software recently released version
3.0 of their popular COBOL compiler known as COBOLMP.

Editor: You've just released version 3.0 of your massively parallel
COBOL compiler, COBOLMP. Is there still a market for COBOL
compilers?

Bill: Absolutely. COBOL is more popular than ever. We are finding more
and more people in the scientific community moving back to COBOL from
other programming languages.

Editor: What is it about COBOL that makes it so popular with
scientists?

Bill: COBOL tends to be very wordy, but we are finding that a large
number of scientists appreciate this feature of the language. A line
of code in COBOL is basically self-documenting and doesn't require any
comments. Though COBOL code is generally longer than a similar code
in C or Fortran, we have found that, with comments, the C and Fortran
codes come within an order of magnitude of the length of the COBOL.

Editor: Is there anything else that would make someone choose COBOL over
say, C or Fortran?

Bill: There are very few ambiguities in COBOL. I remember when I was
trying to learn C, I could never tell if the asterisk (*) meant
multiply, a pointer, or a pointer pointer. COBOL is much more
straightforward: multiply is "MULTIPLY." I often find myself drawn
into the narrative of a COBOL code, it reads like good fiction.
Editor: How does your compiler support parallelism?

Bill: We currently support PVM, and hope to have MPI and OpenMP ready
for version 4.0.

Editor: Well, we want to thank you for the great interview. Is there
anything more you want to say?

Bill: My father told me when I was a young boy, "There are certain days
in April when you shouldn't believe everything you hear."

------------------------------------------------------------------------
-- The Arctic History of Computers --
------------------------------------------------------------------------

Despite historians' efforts, some interesting history of computers is
being lost as the early developers die off. As a reminder, the earliest
computers were ASCC (1944), ENIAC (1946), EDVAC (1952), EDSAC (1949),
LEO (1951), UNIVAC (1951), GENIAC (1955), and RAMAC (1957).

The Arctic connection, in particular, has been lost and it is time we
honor it. Younger historians have forgotten that early computers
required enormous cooling. Most large computers were refrigerators with
enough electronics to prevent freezing. Thirty ton air conditioners
were commonly needed once these machines moved from their Alaskan
development sites to locations Outside that lacked our ideal weather. Of
course not all pioneering computer work was done in Alaska. Seymour Cray
did his early work in Minnesota and Wisconsin.

ASCC, which was not a true electronic computer, but an elaborate,
relay-based calculator, was initially developed at Naskak, on St.
Lawrence Island. Its name, like those of most early machines was
Anglicized from the location where it was built.

Try pronouncing "ASCC" and you'll see it rhymes with "Naskak."

Not surprisingly, the origin of the ENIAC is the Neenivik. Alaska's
Neenivik River has been renamed the Galova, so etymologists researching
names easily miss the connection.

The exact origin of the EDVAC is obscure, but it's likely derived from
Avak, a river in the north, or Sevak, a camp on St. Lawrence Island.
The EDSAC took its name from Isiak, a port on Unalaska. LEO, the name
of the commercial version of EDSAC is named for Leo Island in
Southeast. ["Southeast" is Alaskan for what "Outsiders" call "The
Panhandle."]

The UNIVAC I was actually developed on the shores of Nunavak Lake in
Northern Alaska near Barrow and named from the transliteration of the
Inupiaq name, which means "walrus on the ice." Curiously, the UNIVAC II
team was different from the UNIVAC I's. Unimak Island in the Aleutians
provided the name for UNIVAC II.

The GENIAC, like many early computers, was named for a hydrologic
feature, reflecting the water cooling needed during the warmer months of
the year. Genius Lake was the code name in the GENIAC project.

Another etymology that reflects both changes in orthography and mangling
by a corporate marketing department, is RAMAC, which is derived from
Nerka Lake, north of Dillingham. Nerka was called by its Russian name,
Pamiak. It still is not possible to determine exactly when the Pamiak
was shortened and misspelled RAMAC, but it seems probable that the
Russian letter "R," which is written like "P," played a part in this
mangling.

------------------------------------------------------------------------
-- ClosedMP --
------------------------------------------------------------------------
[ We received this announcement this morning... ]

> The ClosedMP Standards Committee would like to take this opportunity to
> express its excitement in unveiling our latest C and Fortran
> Implementations. Here's a ClosedMP sample code for parallelizing the
> Navier-Stokes solver:
>
> !CLOSEDMP$ DO PARALLELIZE
> call navier_stokes()
> !CLOSEDMP$ END DO PARALLELIZE
>
> Unfortunately, ClosedMP is, well, closed. Thus, we can't share the
> Standard, the implementations, our web site, or even our email address.

------------------------------------------------------------------------
-- Energy Woes Spur Research in Methane Supercomputer --
------------------------------------------------------------------------
For Immediate Release
April 1, 2005
Fairbanks, AK

Computer visionary Bart Bartoski received a grant this morning from
the U.S. Agency of Foresighted and Radical Technologies (AFART) to
commmence simulations of his Methane Supercomputer.

According to Bartoski, there's sufficient methane generated in
Washington DC alone to sustain exaflops of computational power. And
the effluent from his supercomputer can be tapped to power both itself
and staff facilities. This is a "win win," as the global energy
supply tightens.

Similar to PIM, or "processor in memory," computers, data storage, as
well as computation, all occur within the methane molecule.

As Bartoski explained in a PowerPoint Presentation to the AFART
Committee on Appropriations, the single covalent bonds joining carbon
to carbon and carbon to hydrogen in the methane (CH4) molecule are
formed by the end-on overlap of electron orbitals, so that each carbon
atom is the center of a tetrahedron. Thus, the inherent processor
density and 3D parallelism are "absolutely unbelievable." The
subcommittee was rendered speechless and it promptly approved
Bartoski's grant request, and encouraged him to "get going!"

Bartoski plans his simulations of the Methane Supercomputer to run on
a heterogeneous network of Cray X1 MSPs, IBM SP4 nodes, and one Apple
iPod (the "Front End"). It will produce either a working design, or at
least concepts for next year's grant review, scheduled again for
April 1st.

------------------------------------------------------------------------
-- Quick-Tip Q & A --
------------------------------------------------------------------------
A:[[ I often find myself comparing versions of source files trying to
[[ figure out what changed between the versions. Good old-fashioned
[[ diff works just fine, but there's got to be a more modern solution.
[[ Do you know of any text editors or other tools that have file
[[ comparison functionality built in?

#
# From Burt Carson:
#

I usually don't use diff. Everything I need is right there in awk.

#
# Dale Park:
#

I've written a perl script which indexes the documents, producing a new,
and exceptionally fast, perl script. Running this second perl script
performs the desired diff. (Requires the yacc and lex perl modules.)


#
# Thanks to Harold Falcetto:
#

What do you mean, "versions"? I keep only one copy of everything--the
correct one--and I never need diff.

#
# From the Editors:
#

Heck, we just print out the two files, line them up, grab a couple beers
and a highlighter.

Q: [Thanks to Raoul Mercer for this question.]

I have mastered "vi," but sometimes there's no choice but to use
"Word." Is there a way to control Word using vi key-strokes?


[[ Answers, questions, and tips graciously accepted. ]]


---

Number three was chasing the Update Journal button around. I'm sure there is more to come, stay tuned.