In Kentucky, students may be able to learn coding instead of a foreign language.
Legislation in the Kentucky Senate would let students use computer programming courses to satisfy foreign-language requirements.
The bill passed the Senate Education Committee on a 10-1 vote last week in a move forward.
This is not as crazy as it sounds. My friend Wlofie (who lives in Sweden) considered me multilingual even if I didn't think so, because I knew multiple computer languages (various assembly languages, C, Lua, some Pascal, Fortran, Perl, Lisp, Forth and Erlang, plus having written my own back in college) even if I only spoke one language (English). This, from a guy who spoke at least four languages fluently.
Sigh. Why not twenty-five years ago? I could have saved myself years of anguish attempting to learn German (really? six different forms of the article the?) had this been the case when I was in school.
Then again, I would have missed out on a teacher that sent students on daily donut runs …
At work, I test the various components of “Project: Wolowizard.” These tests usually require
running multiple copies of a program on a single computer. I use Lua (with help from a module)
to start and monitor the programs being tested. The code starts
N copies, and if any of the programs crash, the reason is
logged. It's fairly straight forward code.
Now, one of the compents of “Project: Wolowizard” was updated to support a new project (“Project: Sippy-Cup”) and that component is occasionally crashing on an assert, but the problem is: there are no core files to check.
And I've spent the past two days trying to figure out why there are no core files to check.
The first culprit—have we told the system not to generate core
files? Yup. The account under which the program runs (
has a core file size limit of zero bytes. There are a few ways to fix this,
and I picked what to me, was the simplest solution: in the Lua script that
runs the programs, set the core file size to “unlimited.” And this is easy
enough to do:
proc = require "org.conman.process" proc.limits.hard.core = "inf" proc.limits.soft.core = "inf"
Slight digression: you can set various resource limits for things like
maximum memory usage to core file size. The hard limit normally can't be
changed, but the soft limit can—any process an lower a limit. But a
process running as
root can raise a limit, and raise the hard
limit. Since the program I'm running is running as root, setting both the
hard and soft limits to “infinity” is easy.
But there was still a disturbing lack of core files.
I checked the code of the Lua module I was using, and yes, I flubbed the parsing code. I made the fix, my tests showed I got the logic right, installed the updated module and still, no core files.
I did a bunch more tests and checked off the following reasons for the lack of core files: it wasn't because the program dropped permissions; it wasn't because the program couldn't write the core file in its current working directory; and the program is not setuid. It was clear there was something wrong the module.
I was able to isolate the issue to the following:
struct rlimit limit; lua_Number ival; /* ... */ if (lua_isnumber(L,3)) ival = lua_tonumber(L,3); /* ... */ if (ival >= RLIM_INFINITY) ival = RLIM_INFINITY; limit.rlim_cur = ival;
lua_Number is of type
double (a floating
point value), and
imit.rlim_cur is some form of integer.
ival was properly
HUGE_VAL (the C floating point
equivalent of “infinity”) but
limit.rlim_cur was 0.
But it worked on my home system just fine.
Then it dawned on me—my home system was a 32-bit system! That was the
system I did the patch and initial test; the systems at work are all 64-bit
systems. Some digging revealed that the definition of
RLIM_INFINITY on the 64-bit system was
((unsigned long int)(~0UL))
or in other words: the largest unsigned long integer value. And on a 64-bit system, an unsigned long integer is 64-bits in size.
I do believe I was bit by an IEEE 754 floating point implementation detail.
Lua treats all numbers as type
double, and on modern
systems, that means IEEE 754
floating point. A
store 53-bit integers without loss, and on a 32-bit system, you can pass
integer values into and out of a
double without issue (32 being
less than 53) and because I did my initial testing of the Lua
module on a 32-bit system, there was no issue.
But on a 64-bit system … it gets interesting. Doing some empirical
testing, I found the largest integer value you can store into a
double and get something out is
18,446,744,073,709,550,591 (and what you get out is
18,446,744,073,709,549,568—I'll leave the reason for the discrepancy for
the reader); anything larger, you get zero back out.
So, no wonder I wasn't getting any core files! I was inadvertantly setting the core file size to zero bytes!
Off to fix the code …
One of the tasks I do at work every day is to pull the latest updates of the several source repositories I have checked out and view the changes. It keeps me up to date. One particular change caught my eye:
r4245 | XXXXXXX | 2014-03-12 11:36:38 -0400 (Wed, 12 Mar 2014) | 1 line update for Daylight Savings Time
We have networked computers, running the latest operating systems, and we're still manually updating the time zone? (Okay, to be fair, this is code to test code, but still …)
Now granted, getting the time zone information in a portable manner is not always that easy. In C, there is no direct way to obtain the timezone, and thus, you need to do something like:
time_t now; struct tm slocal; struct tm sgmt; time_t local; time_t gmt; double zone; now = time(NULL); slocal = *localtime(&now); sgmt = *gmtime(&now); local = mktime(&slocal); gmt = mktime(&sgmt); zone = difftime(local,gmt);
zone is the number of seconds from UT; divide by 3,600 to get the time zone
(well, the quotient is the timezone, the remainder needs to be multiplied by
3,600 then divided by 60 to get the minutes).
And that's just to be “portable”—
POSIX (read: most
modern Unix systems these days) include a way to obtain the timezone more
directly, just call
tzset() and the global variables
extern char *tzname and
extern long timezone
You don't need to hardcode a timezone.
But I was curious, and I checked the log for the file in question:
r4245 | XXXXXXX | 2014-03-12 11:36:38 -0400 (Wed, 12 Mar 2014) | 1 line update for Daylight Savings Time ------------------------------------------------------------------------ r3889 | XXXXXXX | 2013-11-04 13:21:02 -0500 (Mon, 04 Nov 2013) | 1 line Support for XXXXXXXX. Changed the Manual UTC offset constant to reflect DST change. Ran a couple tests and they were all passing after making the change. ------------------------------------------------------------------------ r3245 | XXXXXXX | 2013-03-07 15:20:00 -0500 (Thu, 07 Mar 2013) | 1 line Fixing utc offset for day-light savings shift. ------------------------------------------------------------------------ r2923 | XXXXXXX | 2012-11-05 11:30:04 -0500 (Mon, 05 Nov 2012) | 1 line Adjust time offset value for daylight savings. ------------------------------------------------------------------------ r1827 | XXXXXXX | 2012-03-12 12:08:41 -0400 (Mon, 12 Mar 2012) | 1 line Update for daylight savings time. ------------------------------------------------------------------------ r1154 | XXXXXXX | 2011-11-14 19:28:32 -0500 (Mon, 14 Nov 2011) | 1 line Remove unneeded constants. ------------------------------------------------------------------------ r1091 | XXXXXXX | 2011-11-04 19:32:51 -0400 (Fri, 04 Nov 2011) | 1 line Adjusting UTC_OFFSET for day light savings.
And the punchline? The comment above the timezone constant:
// UTC Offset (for now until this can be automated)
which was added in April of 2011.
There are some plumbing issues at Chez Boca (sometimes, the water backs up into the bathrooms) that have required some trained intervention to fix, although now we can pretty much manage the situation. But still, it happens just often enough that we felt it required a bit more investivation.
So we called Johnson Plumbing & Air (disclaimer: I know the owner, and am good friends with the owner's son) to take a look. They arrived today with their PipeCam™, a specialized plumber's snake with a small flashlight shaped camera (and lights) on the end.
Considering the age of the house (built in the early 70s) and the material of pipe (cast iron), the pipe appeared to be in decent shape, and it wasn't quite as nasty as I expected it to be.
The PipeCam™ made it easy to isolate which branch of the plumbing had issues. They snaked the camera from an access point next to the front door up into the house. At the first junction, they had Bunny turn on the garage sink to confirm that branch of the plumbing. At the second junction, a four-way intersection, it was easy enough to test the master bathroom (left branch), the kitchen (straight ahead) and the guest bathroom (right branch). The water came quickly from the master bathroom and kitchen, while the water from the guest bathroom took its own sweet time to come though carrying a large wodge of bathroom tissue (splat—“Eeeew!”).
And they were able to locate the junction inside the house with the use of this odd looking gun:
They pointed it towards the ground and based on the sounds emitted, they could locate the camera and even tell the direction the camera was pointed in. It's a pretty cool setup.
The upshot—there's a dip in the pipe from the junction to the guest bathroom where water (and … um … “particulate matter”) accumulates. If too much … um … “particulate matter” accumulates, you get a blockage. The best solution, which does not involve tearing up the floor of the family room, is to run new pipes around the outside of the house to the main sewer at the street.
Whatever your reason, if you are showing someone the official editions of Star Wars for the first time (no Phantom Edits), you have to make a decision about which order to show the films.
Now I'd like to modify this into what I've named Machete Order on the off chance that this catches on because I'm a vain asshole.
Next time you want to introduce someone to Star Wars for the first time, watch the films with them in this order: IV, V, II, III, VI
Notice something? Yeah, Episode I is gone.
I recently discovered my college-aged brother-in-law's girlfriend had never seen any Star Wars films and wanted to watch them all over winter break. Armed with the new Blu-rays, we all went about watching them, and I showed them in Machete Order. It actually works even better than I originally anticipated—it's almost as if this is somehow the intented order. There's a great pattern here, taking the viewer on a series of emotional ups and downs. IV ends with a victory that seems to have some sinister undertones, then V is dark and unresolved with a cliffhanger, II ends with victory with sinister undertones, then III is dark and unresolved with a cliffhanger again. It works incredibly well, and when III ended everyone demanded we immediately watch VI to see how everything gets tied up.
I asked her if she found Jar-Jar annoying and she asked “who’s Jar Jar?”—Mission accomplished.
There's not much to say about this other than “you must read this” (that is, if you at all a fan of Star Wars). The new ordering of viewing makes “Return of the Jedi” a much better film than it deserves to be (it's the weakest of the original trilogy) and resolves both Luke's and Anakin's storylines from the previous four films.
A few years ago I mused about bootstrapping a development system under MS-DOS from the command line. Now, I personally haven't done that, but I can see how it could be done.
But Edmund Evans came close to doing just that (link via Hacker News). He “cheated” by having a program that converted hex codes to binary. It's not that bad though, under Linux, you have a bit of an easier time generating binary data:
/bin/echo -e "\177\105\114\106\001\001\001\000..." >hex1
(it's coincidental that this method also uses octal values instead of hex—Unix began life in an octal environment).
That small quibble aside, Edmund did the bootstrapping procedure pretty much how I envisioned it.
And in following a few more links from the Hackers News commentary, I see that Kragen Sitaker referenced my previous entry and did the initial bootstrap (making a program to read text into binary) from the MS-DOS command line (how odd—that mailing list with only one member).
Twenty years ago, back when I was in college, my friends and I would often eat at the Boca Diner. The primary reason: it was open 24-hours and it wasn't Denny's. It's not that Denny's is bad, but really, it's the type of place that you end up at, not a place you set out to go to (if you get my drift). Also, the food was better and it had a wider selection. And it didn't hurt anything that it was a few blocks closer to FAU.
Alas, that was then—this is now. The Boca Diner is still around, but it is no longer 24-hours (so I want to know how can it still call itself a “diner?”, but I digress) and thus, we are back to Denny's, the type of place you end up at, not a place you set out to go.
But a few days ago Bunny noticed The Flashback Diner, south of the Boca Diner by about a mile, that is open 24-hours. This is a place we had to try out.
This is no ordinary diner.
Marble topped tables. Straight back chairs. Low mood lighting. An actual bar! It even has a glass waterfall for crying out loud!
And I'm still not sure how I feel about the television sets in each booth.
And the menu doesn't exactly scream diner either. The food is too upscale for a diner. And the prices are a bit high for a diner. I'm beginning to wonder why this place bills itself as a diner. I mean, the only thing it has so far in common with a diner is that it's open 24-hours. I mean, I could almost buy this if it were in Las Vegas, but we're not—we're in Boca Raton, Florida. Yeah, it's an upscale type of town, but not quite this upscale … I think.
Anyway, we place our orders. Bunny ordered the pain perdu avec saucisse and I ordered the poisson-frites. I'll admit, the food looked good.
Bunny's meal was really good, and with hindsight being 20/20, I should have ordered that. The fish-n-chips … well … this was the first time I actually had to return a fish-n-chips order back because it was basically sushi-n-chips. The manager was very apologetic, took my meal off the check and returned with properly cooked fish-n-chips. The second dish was okay; I think their choice of fish (dolphin) was ill-suited for this application (cod is more appropriate) and I doubt I'll order this again.
The desserts though … oh my!
We're talking an embedded pastry shop here. Gigantic cakes. Huge cookies. Donuts. Muffins. Pies. It was a fantastic selection of desserts. What we did order (turtle cheesecake) was, in the words of Bunny, “to die for.”
It was heartening to see we weren't the only patrons there at 10:30 pm on a Monday night, and it was even better to see several parties arrive after us. It wasn't crowded, but it was lively enough to think they'll keep the place open 24-hours for a long time to come.
And we'll definitely go back.
We believe these changes will also help prevent a fire resulting from an extremely high speed impact that tears the wheels off the car, like the other Model S impact fire, which occurred last year in Mexico. This happened after the vehicle impacted a roundabout at 110 mph (177kmh), shearing off 15 feet (4.5m) of concrete curbwall and tearing off the left front wheel, then smashing through an eight foot tall buttressed concrete wall on the other side of the road and tearing off the right front wheel, before crashing into a tree. The driver stepped out and walked away with no permanent injuries and a fire, again limited to the front section of the vehicle, started several minutes later. The underbody shields will help prevent a fire even in such a scenario.
Wow. That's certainly a far cry from the Ford Pinto.