Like all good Mac people, I do my diagramming in OmniGraffle. I just upgraded to the most recent Pro version and started creating new diagrams for a project at work. I went to check them into our Subversion repository and.... crap. My "graffle" files were now directories and the Icon file has a carriage return in its name. Subversion not so happy. Fortunately I'm not the first to have encountered this. Here's a note from David Glasser's blog
Just type the following line in your terminal: defaults write com.omnigroup.OmniGraffle PrivateGraffleFlatFile 0 (Or if you run OmniGraffle Pro, you apparently should do defaults write com.omnigroup.OmniGrafflePro PrivateGraffleFlatFile 0 This will make OmniGraffle make all future files as the flat-file format and never sneakily turn into bundle format. Hooray!
..and there are numerous threads about this if you Google them out. I haven't tried this tip yet, but wanted to get it into the blog before I forget it.
I've been playing with Unicode support in SBCL lately, so I keep an ear out on the mailing lists for gotchas. On comp.lang.lisp, SBCL+UFFI+MYSQL came up and here's the tidbit:
Yay! That's it! When I ran this: (stream-external-format *standard-output*) I got :LATIN-1 as a response. So, I exited SBCL and did: export LC_CTYPE=en_US.UTF-8 Started SBCL again and checked the external-format. Got :UTF-8. Promising! Ran my database setup stuff and executed a query that should return UTF-8 encoded data. It worked! "правда" in all its glory! :)
Moral of the story: Make sure you know what locale SBCL is using. You will get a reader error if SBCL is using Latin-1 and tries to read Unicode, but it's great to know why and how to fix it.
If you're the guy who says, "I'm the decider," you're not the decider. I appreciate Jon Carroll's take on the Bush administration and I realized yesterday it applies to software project leaders, along with a corollary: If you aren't the expert, it's best to lead with a question.
I've seen this syndrome a number of times in new project managers. Eager to make their mark, they begin by suggesting solutions rather than enquiring about the space around them and about the current situation.
Bear with me for a moment, because this won't make much sense at
first. This morning I was helping my son put his toy race track away.
You know, the kind with the long plastic strips and differently shaped
connectors that share some common portion. The "optimal" way to
separate track from connectors would have been to examine each piece,
noting the best part to hold onto and to pull it from its section of
track.
Being a lazy software guy, I just lightly wrapped my hand around the
whole bunch of them and drew back several times. Sometimes pieces
came apart, sometimes not. It probably took me 3 or 4 tries more than
the optimal method, but eventually got the job done. My technique
required no specialization or extra analysis, just a cheap
non-differentiated operation performed in parallel.
Return to the world of commercial software development. I bet you are
like me. You've written code that works but doesn't make you proud.
You did the simple, cheap thing, verified it works all the time (you
do write tests?) and checked it in. Now you have writer's remorse.
You want to take it back. You want to buy the time to make things
right.
Most young businesses don't have the luxury of "doing it right", of
finding the "optimal algorithm". Lack of money pressures them into
delivering early. We've all heard those stories. Anybody who reads
reddit, digg, even
Well established businesses, averse to risk, act much the same. They
don't want to spend time (again money) hunting for something that
might only give a 5-10% increase in whatever but costs 5 times as much
in developer time to discover. (Remember, people are the most
expensive resource you've got).
For businesses, where product is profit, an "optimal implementation"
would require too much upfront thought and experimentation (read as
cost). During that time we are failing the real task: delivering a
product that delights the customer. Sure, everyone wants the praise
of friends and collegues. Everyone wants to be the smartest.
Pragmatism is rarely lauded by geeks; elegance and cleverness are the
coins of the realm. Well kids, being clever is necessary but so is
delivering. Get the ugly first hack out there, the one that enables
users, that gives them power over the machine. With luck and if the
market smiles, you get the time and money to make it faster, prettier,
"optimal".
Who's left? Academia. After all, a young grad student can make his
bones on a new idea with no mouths to feed, just a thesis to prepare.
Hell, he may even still like the taste of Top Ramen. (Come on, who's
with me?).
I'm not sure where I'm going with this, but I want to admit that I'm
an engineer. A pragmatist. I find it more fulfilling to deliver and
to see the customer's reaction than to ceaselessly polish the knob,
hoping for an extra 5%.
Ok, I figured out what was causing SLIME to "hang" with the recent sbcl patches for non-ASCII filenames. The default coding system was "iso-latin1-unix". Either changing the value of slime-net-coding-system in Emacs at SLIME startup, or changing its initialization in slime.el fixes the problem.
(defvar slime-net-coding-system
(find-if 'slime-find-coding-system
'(utf-8-unix iso-latin-1-unix iso-8859-1-unix binary))
"*Coding system used for network connections.
See also `slime-net-valid-coding-systems'.")
Notice utf-8-unix comes first. Because it also appears in the list of slime-net-valid-coding-systems it will be chosen and all is golden.
agent.c:1658: warning: implicit declaration of function ‘timercmp’ agent.c:1658: error: parse error before ‘<’ token agent.c: In function ‘update’:
To fix this, add the following line at the top of config.h to ensure the definition of the timercmp macro is used from sys/time.h
#define NO_POSIX_C_SOURCE 1
This seems wrong, and I haven't checked how well the library works, but at least it compiles now and I'll post test results soon.
I've been doing some file-munging in Lisp lately, using sbcl on MacBook Intel. I have a number of artists & tracks with non-ASCII names and they give sbcl fits. Turns out filesys.lisp treats all the directory and file names as base-strings with base-char components. These are only guaranteed for simple ASCII.
An intrepid soul posted patches against sbcl 0.9.16 in CVS and I've been trying them with some success on OS X 10.4.7. I have found that they hang SLIME though. I suspect SLIME isn't expecting sbcl to return non-ascii. Time to delve deeper.
From sbcl-devel:
From: Yaroslav Kavenchuk Date: Fri, Aug 25 2006 8:00 pm Last version for non-ascii c-string's & pathnames (join in one patch) and couple derivative pathces: some changes for win32 and some offers for tests (for larger compatibility with win32). non-ascii & pathnames patch adapt for linux (need test on other platforms). Observations, offers and help are welcome!
Have you ever seen the following?
"warning: Insecure world writable dir /tmp, mode 041777"
Here's the explanation from ruby-talk:
That means you have world writable directory in your load path ($PATH) when you call external program (probably by using "system"). If you know what you are doing, you can shut the warning up by $VERBOSE=nil as Ara told in [ruby-talk:211832].
I thought I'd jot it down here, because it comes up so often and freaks people out.