Okay did I mention how I sucked at the command line? This is part of
the journey towards stopping. Yes, I’m on a Mac and it’s not very *nix-y
in some ways but it’s enough for me for now.
Today’s story starts when I learned about
gdb
, the
pure-command-line GNU Debugger, which is incredibly cool. I have tried
and failed to learn how to use the debug function on many of my IDEs; I
found shotgunning printf
statements as needed faster. This
may well be the first time I found a command-line tool so much more
intuitive than the GUI-equipped programs. Wow.
Then I learned that for some reason the gdb
on this
computer was 6.3, which is 1.2~1.5 major versions behind (depending on
how you count) and missing a frustrating amount of features. (The one
that the current Code::Blocks installer installs is also something like
6.4. Blech.)
Note: My 2012 self wrote this. It is preserved for
historical interest and amusement, and does not reflect my current
beliefs or attitudes.
Hardware:
The laptop I’m typing this on is over two years old. This is not a
lot by some measures, but weird spontaneous glitches are starting to
accumulate to the point where they’re getting on my nerves. The internet
card still needs an extra reset to start working half the time, and
occasionally warrants a full reboot, which costs five minutes. The USB
ports are loopy, some windows just show up black when they feel like it,
and there’s a steadily climbing whir in the background. I’m kind of
anticipating the moment the whole thing just drops dead.
Well, I’m not about to run out of computers to use (there’s a noisy
XP desktop that also barely works despite handling all our print jobs,
but also one spanking new eight-core CPU laptop, which Dad considered a
valuable enough investment (?)) but such a loss is still not something
to be dismissed lightly. And the externalized cost is far more important
and chilling. Who knows how many kids in the Congo had to mine coltan,
or how much conflict has occurred over the crude oil, or what awful
conditions those sweatshop-assembly workers are going through? Annie
Leonard’s words still resonate with me from when we were first shown the
video a year ago. Which is more recent than this laptop, so that doesn’t
mean that much. I think a couple months ago I would have absolutely no
second thoughts about getting a new one, though. Yup, I’m in a quandary
(ha ha vocabulary) on the balance between desensitization and compulsive
hoarding of stuff.
There are two big elementary and middle school competitions around this part of the globe. Well, “big” according to “I’ve heard of it”, which is by no means an accurate measure of, well, anything. I don’t go out of my way to look for them any more, even though… hold on, am I still eligible? Whatever. But in any case, diverting any unnecessary energy from the olympiad-proof-training is probably not a good idea now.
Note: My 2009 self wrote this (except for the
insertions by my 2013 self). It is preserved for historical interest and
amusement, and does not reflect my current beliefs or attitudes.
Strange things:
(Ported from betaveros.stash. Wow, I get syntax highlighting and
footnotes! Probably years out of date though. I probably wrote this
somewhere in 2012–2014, but am editing this parenthetical in 2021.)
A quick brief guide. At least, that’s how I planned it.
A lot of stuff is in the package java.awt.datatransfer
.
Class Toolkit
is in java.awt
.
Some basic classes. The class Clipboard
is a clipboard,
obviously. Its content is/will be an instance of the class
Transferable
. Some content can be read as different types
of objects depending on what you want; to choose which type you use an
instance of DataFlavor
. It provides three basic ones:
DataFlavor.imageFlavor
,
DataFlavor.javaFileListFlavor
, and
DataFlavor.stringFlavor
.
Okay, now step by step. This is the low-level method.
- Get the default clipboard with
Clipboard clipboard = Toolkit.getDefaultToolkit().getSystemClipboard();
- Get a transferable with
Transferable content = clipboard.getContents(null);
- Check if
content
can be read as the kind of object you
want with
(content != null) && content.isDataFlavorSupported(someFlavor)
- If it does, get the object with
content.getTransferData(someFlavor)
.
If you just want a quick-and-dirty function:
static String getClipboard()
throws java.awt.datatransfer.UnsupportedFlavorException, IOException {
return (String) java.awt.Toolkit.getDefaultToolkit()
.getSystemClipboard()
.getData(java.awt.datatransfer.DataFlavor.stringFlavor);
}
1
Editor’s note: This is almost certainly years out of date. cabal has
v2 commands and stuff now? Sorry.
diagrams
is a
nifty Haskell library for making vector diagrams. I keep coming back to
it to generate graphics for puzzles:
I got sick of relearning it every time, and I think there’s some
small chance other people will find it useful too, so I wrote something
up. This post is a sort of reference that tries to compromise between
the quick start
tutorial and manual on one
hand, and the API reference on the other, to try to be deeper and more
comprehensive than the former, but also flow better and be easier to
navigate than the latter. Some types are just really intimidating when
fully written out…
circle :: (TrailLike t, V t ~ V2, N t ~ n, Transformable t) => n -> t
To avoid unhelpfully generic types, I will deal concretely with
two-dimensional diagrams that measure everything in Double
,
and will frequently abbreviate complex types with an asterisk, like I
will write V2*
for V2 Double
. I will introduce
these aliases along the way for easy greppability. They’re not legal
Haskell, of course.
This reference assumes basic-to-intermediate Haskell knowledge. Some
of the more intermediate stuff includes:
- Monoids, and that the Haskell
Monoid
operator is
<>
- Typeclasses. I will sometimes write fake type signatures as
abbreviations for typeclass restrictions: for example,
TrailLike
is a typeclass, and I might say or write that a
function returns TrailLike
when I really mean
TrailLike t => t
, any type t
that is in
that typeclass.
van Laarhoven lenses may help, but mostly I’ll try to black-box
them.
It seems like a rite of passage to create one of these because there
are so many Coq tactic cheat sheets out there and there’s just so much
to learn. Here’s mine.
This is mostly about tactics but I realized not really.
Links:
Coq
Tactics. Authoritative but dense.
Logical
Foundations (Software Foundations Volume 1). I think the order of
ideas makes pedagogical sense but also makes it hard for me to look up
particular tactics or concepts.
Other Coq cheat sheets found by Googling “Coq cheat sheets”:
Meta-notes: I cover a lot of weak tactics because I like knowing
exactly what my tools are doing. I try to use the variants of tactics
that explicitly name things produced when possible. I am sure there is
nomenclature I don’t understand precisely and use sloppily in this list;
I am also sloppy with metavariables. Even things that are correct might
be horrible style. There are likely other errors and omissions. They
might be fixed one day. I’m putting this up nevertheless because it’s
personally useful.
Things
I wish I knew but didn’t learn from Software Foundations or Coq tactic
cheat sheets
- The first two sections are not about tactics per se but how to find
theorems to use and how to use them. Knowing how to use all of these
query commands is super useful.
- To clean up repeating subexpressions with “local variables”, I find
remember expr as X eqn:Hname.
easier to work with than
set (X := expr).
pose proof expr as Hname.
adds expr
to the
context, with name Hname
. Modus ponens where you know
H1
and H2
, which is “H1
implies
H3
”, is just pose proof (H2 H1) as H3
.
- Software Foundations covers bullets and curly braces early, but I
like subgoal specification with
1:
, 2:
etc.,
which can really help limit nesting depth.
2: (tactic that solves subgoal 2).
If you want more
bullets, there are infinitely many, not just three. After -
+
*
you can use --
++
**
---
etc.
Bruce Lindbloom has a
ton of equations, but I just want the big ones on one page. We’ll assume
sRGB, which implies
using D65 as
white (if you’re using Bruce Lindbloom’s calculator to check your
implementation, make sure to set these).
RGB ↔︎ Linear RGB
Let \(\Xi\) (one of \(R\), \(G\), and \(B\)) be an RGB component in the range \([0, 1]\). (This is an obnoxious variable
choice, but I’m trying to not overload any variable names in this entire
post.) If you have RGB values in \([0,
255]\), divide them by 255. It can be converted to/from the
linearized component \(\xi\) (one of \(r\), \(g\), and \(b\)) as:
\[\xi = \begin{cases} \Xi/12.92 &
\text{if }\Xi \leq 0.04045 \\ ((\Xi + 0.055)/1.055)^{2.4} & \text{if
}\Xi > 0.04045 \end{cases}\]
\[\Xi = \begin{cases} 12.92\xi &
\text{if }\xi \leq 0.0031308 \\ 1.055v^{1/2.4} - 0.055 & \text{if
}\xi > 0.0031308 \end{cases}\]
This is called “companding”.
However, you can use \(\xi =
\Xi^{2.4}\) and \(\Xi =
\xi^{1/2.4}\) in a pinch.
Linear RGB ↔︎ XYZ
Convert between XYZ and linearized RGB. Again, this assumes sRGB and
D65.
\[\begin{align*}
X &= 0.4124564r + 0.3575761g + 0.1804375b \\
Y &= 0.2126729r + 0.7151522g + 0.0721750b \\
Z &= 0.0193339r + 0.1191920g + 0.9503041b
\end{align*}\]