You would think you could use the web for working with Javascript. You'd be partially right.
There's lots of stuff to get your started. Lots of examples too. But thanks to minification, reading existing javascript source is getting a little more difficult. Worse for the novice however is the "magic" that libraries use. They're not very understandable to the mere mortal. I've been reading through spin.js which is less than 300 lines, and that includes three different ways of doing a spinner: css animations, setTimeout() opacity cycling, and VML for IE. But its full of css magic, and very short functions names.
I was trying to decompose it, and I remembered that there is another function similar to setTimeout(). setTimeout() calls the function once, and then spin.js anim() function calls again each time it completes its work. The other variant calls a function repeatedly at a prescribed interval.
At first I couldn't remember the second function, so I went looking on the web. I was certain that some reference for setTimeout() would mention the other version. If there is a page that connects them though, I sure couldn't find it. Thankfully, I not only remembered that there is this other version, but I finally remembered that I had used it in one of my projects to poll the address bar, when onhashchange is not defined. The function is setInterval(). When I went back to w3 schools, it was declared in the general list of window methods, but not associated in any way with setTimeout() or anything Timer based.
Blah.
Labels: dom, javascript, setInterval
Javascript tries to simplify some things. There's not more ints vs floats, there's just numbers for the novice (doubles for us old-timers). Kind of annoying when you want to write prime number code, or crypto software, and have it not suck. They also removed characters, and everything is a string.
Since everything is a string, they made a='x' the same as a="x", so you can use either quotes where-ever you want. You would think the same would apply for JSON, which is just javascript data. You'd be wrong.
I was hacking out a quick JSON dump from perl, and wanted to save myself some trouble and quote the variables inline with the formatting. In perl, single quotes means something different from double quotes. They're both strings, but perl only does variable lookup and escape sequences in double quotes, not single quotes. So I tried throwing out:
"{ 'id' : $id, 'title' : '$title', 'link' : '$path', 'sentinel' : 1 }"
And spent the next hour arguing with prototype.js over why I was not getting a data structure at the other end. The data was coming through in responseTEXT, but even trying to convert it after the fact was failing. Finally, in desperation I added a second line in perl:
$json_dat =~ s/'/"/g ;and low and behold, it worked.
blah.
?
I think that C++ was a pretty good language. I've written some pretty good stuff, even template things. But STL just did everything wrong. Take a look at the example of iterating through a list sometime, its terrible. My version looks like this in contrast:
edata_list::iptr p(mylist) ; while ( p ++ ) { p-> dosomething() ; }
Now they've added regex to C++, and its painful just to look at the examples:
std::tr1::cmatch res;
str = "<h2>Egg prices</h2>";
std::tr1::regex rx("<h(.)>([^<]+)");
std::tr1::regex_search(str.c_str(), res, rx);
std::cout << res[1] << ". " << res[2] << "\n";
Compare to what this would look like in perl:
my $str= "<h2>Egg prices</h2>"; my ($tagstr, $word1, $word2)= $str =~ /<h(.)>([^<]+)/ ; say $word1. ". ". $word2 ;Now, plenty of people have accused perl of being a write only language, but still, someone should have come up with something a little easier to type. Alas, guess we'll just all head over to javascript and get on with implementing solutions.
I've learned a couple computer languages in my time. I've even written some frighteningly large programs in several of them.
My first language was BASIC. And it was pretty cool, because you just typed a few things into memory and ran it. It was pretty quick to try things out. And typing things in from scratch was usually the way you did things because the external storage on those early machines were pretty sad. I remember working for three weeks on a more complicated game, loading my work in from a cassette tape, adding to it, and then saving out before the end of recess.
One afternoon, I discovered the horror which is magnetic media. I had worn out the first part of the tape that I had been using over and over, and my work was gone. We eventually upgraded the lab to also have a floppy drive, but these had similar problems in terms of reliability.
Still I pressed on. BASIC had a few drawbacks. First it was slow, and second it didn't have much in the way of support for more advanced data structures. It was great if your biggest worry was to keep a list of 10 numbers, but if you wanted to do bigger and better things, Pascal had the moves. It was also the language of choice if you were trying to pass the AP Computer Science exams. So I learned about references, and lists, and other good things and built some pretty large projects in Pascal ( once hard drives and larger memory computers came along ), but there was a new language coming along that was threatening to surpass everything that had come before it: C.
C was actually a pretty old language, but it was finally breaking out of its roots and spreading out to the modern micro platforms. Its big thing over the languages before it was pointers. Pointers are a shortcut for walking around in memory without a lot of overhead. All the languages before it had things like arrays, where you accessed an element by saying "val := my_array[i]" but there were costs to doing this. To find where val was coming from, the program had to multiply i by the size of each element of my_array and then add that to the base address of the block.
Compared to loading, adding, comparing, and clearing values; multiplying two things takes an eternity on a computer (even today). And often you were going to look at elements from my_array in order, from beginning to end, or some such, so there really wasn't any need for all that multiplying. C let you code your program to take advantage of that. You would say, "my * ptr= my_array" and then p would start out having the same address as the first element in my_array. Then you would say, "p ++" and the compiler would add the size of one element to the address in p (an add being much cheaper than a multiply) and you would be ready to look at the next element in my_array.
If you were trying to write fast code, like I was because I was doing computer graphics, then this was great. It was also dangerous, since you could add any value to p and then look and see what was there. Sometimes you ran off the end of the world and started trying to look at memory that didn't exist, which caused bad things to happen, but if you kept things in check, it was great.
C carried me forward for more than a decade, but you can only write so much code before things become un-manageable, and in C you were always writing pretty low level code. On top of C, an object structure was added, it was called C++. It was pretty cool because you could create these families of objects that could share code when it made sense, and specialize when they needed to. They also added another language into the pre-processor, called STL which was a code generating language that does amazing things, only some of which I understand.
I built an amazing networking library in C++ (after nine revisions), and some other cool generic algorithms, and used those to build some pretty large network servers and other cool processing tools, but it took a fair amount of work to get things done. Around the same time, my friend tim was playing with another language called Perl, which was heading in an entirely different direction then my language choices before.
First, it was interpreted (ya just like BASIC way back in the day). Second it had some amazing stuff built into it already, like string handling and regular expressions, and data structures like arrays and hash tables. Sure, you could build these things in C++, but Perl already had it done, and with memory handling, you didn't worry about allocating things or getting rid of them when you were done. You just simply started writing things like,
my $x_= { a => [ 1, 2, 4, ], b => [1, 2, 3], complex => [ { u => 1, v => -1 }, { u=> 2, v => 0 } ] } ;
my $yflat = [ grep { $_ > 0 } map { @$_ } values %$x_ ] ;
and it did all the work for you. (don't ask me to explain what ends up in $yflat, I just made it up as an example.)
So I had two pretty powerful languages at my disposal at that point, C++ for writing heavy iron server stuff, and Perl for writing data manipulation/database/text/web stuff. That caused me quite a problem.
I like to continually improve myself as much as the next ultra-geek, but I had mastered such power tools, that other newer things out there just didn't seem to have much appeal. Ruby happened upon the scene, but its performance was dismal. Python seemed to have a lot more traction than Perl, but it was like Perl with training wheels. Sure, I know better than to write if ( a= calc() ) { ... } most of the time, but sometimes that actually is the clearest way to do things, and its valid C and Perl, but not Python. Java suffered from the same problem, it was a language designed for people who were not very good programmers.
I tried looking for other languages to try out. Lua seemed interesting, and fit a niche on small embedded systems (like phones and video games), but didn't even support simple shortcuts like a += 10, requiring the longer form a= a +10. Ocaml seemed to have some neat ideas, and good performance, but I had already done some ML type stuff in Perl, and having to type my plus operator seems a little tedious.
So I was sort of coasting along, expanding my skills in other areas, like database SQL calls, and the like when the web started getting interesting. I had done a little copy and pasting of web scripts for the front end to one of our gianormous perl apps, and I went back and started looking at the pieces, thinking to myself, this new javascript could be interesting. Then I got a chance to help tim out again on another project, and I dived way in on javascript and prototype.js and made quite a mess out of things, but did get the demo done.
Its at this point, where I either move on or get serious. I had just enough knowledge and experience to be dangerous, so it was time to find out more. Thankfully these days there's so much information online that you can just go nuts without much effort. I learned how the javascript inheritance model is completely different from C++, and how javascript has nothing really to do with java, and is really a closer cousin to lisp than anything else. Now my head is full of even more ideas and I need to go bang them out on some projects to figure out what I actually know, and where I'm just fooling myself.
A book like this is probably something I'll wade into shortly.
Today I was playing with cygwin, and decided to cat all the source code on my machine to the screen. Something like this:
find . -name '*.c' -exec cat {} \;
No particular reason, and it didn't take that long since it was all coming off a solid state drive, though it did pause a couple times ... But the very last lines were:
int main(void) {
printf("hello world\n");
return 0;
}
Some pretty old code there.
Communicating between programs usually means across computers, especially when its a client program ( or web browser ), talking to a server somewhere else. For that you almost universally use a inet socket ( TCP, or UDP if you're a glutton for punishment).
There used to be a bunch of other protocols, but IP pretty much crushed them all. Ungerman Bass had its own SNA back when the internet was starting to form, Digital Equipment Corp had DECnet, IBM had SNA, and Novell Netware used IPX. But TCP/IP was good enough, pretty darn simple, and as we went from 1mbit to 10,000mbit, other things became the bottleneck. Sure if you run a telco, you may still wax on about ATM, but even the ATM network is carrying TCP traffic.
On a server however, you have a fair amount of traffic staying on the same machine, passing back and forth between different programs; usually a result of dividing a problem down into smaller parts that are hopefully harder to mess up. So you need a mechanism for setting up connections and passing messages.
Even in this case you could use INET sockets, but that's not your only option, nor is it the best choice for a number of reasons. First, there's a lot of overhead to INET sockets. Even if your packet isn't going to cross great distances, the operating system still does all the packet overhead like it would. This puts a limit on the number of packets you can read and write, especially a problem if your communications is a bunch of short messages. Secondly, when you create a INET service, it is visible to the network beyond your computer, allowing anyone running a portscan to find it. So speed and security are both good reasons to look elsewhere.
As the workstation market began to grow, and AT&T decided to wade back into the unix market; they added new kernel services to System V, called IPC ( inter process communication ). There were three parts: semaphores, shared memory and message queues. Semaphores allowed passing access or control between processes to a shared resource, shared memory seemed like a good way to avoid having to pass around large data sets when disk access was expensive, and message queues gave you both an orderly mechanism passing data, as well as atomically handling a message. Unfortunately at the time, all these data structures existed in kernel memory, and they were fixed in size ( originally compiled into the kernel settings ), so on a typical machine they were ridiculously small. One one HP machine with 64MB, the limits shown were 64 semaphores, 4k message queue, and 64k shared memory. Even today on a machine with 2GB of RAM, ipcs -l shows a queue size limit of 16k.
Moving on.
On unix, creating the raw socket() itself is protocol neutral. Its just that most everyone in the universe uses INET. You can also use sockets for RAW packets, ATM, Appletalk, IPX, X25; and one more format called AF_UNIX ( although its now refered to as AF_LOCAL for POSIX reasons, but the structs are still all un_ ). A AF_UNIX socket is for communicating locally on the machine. Originally, like INET sockets, there was a private namespace, using 32bit numbers which you used for the "port" number, but then they expanded it to also allow you to map the socket into the filesystem, so you would get a file that showed up like this:
% ls -lF total 0 srw------- 1 woolstar users 0 2009-06-26 23:46 agent.16975=ssh-agent uses this to allow ssh processes to authenticate against a stored key. Back when this first showed up, on some OS's you could actually just talk to this entry like it was an ordinary device. That was sort of the spirit of unix, everything was a file. You could open up /dev/serial0 the same way you would open up foo.txt. So back in the day, you could open this file mapped socket, send it some data, and then close it, and the interaction on the server side would look just like you had telnet'd in. Sadly, AF_UNIX sockets don't work like this any more. Even though they're sitting right there in the filesystem, you can't just echo "hi" > mytest.sock You have to use socket functions to connect to it and read and write to it.
Still, if you control both sides, the upside is definitely worth it. In some tests I did around 2001, for smaller packets on a single processor machine, AF_UNIX connections could out-run AF_INET by over ten to one. Also AF_UNIX allows some funky *magic* data to be passed between machines. Like one process can pass an open file handle over to another process. You can also authenticate your user id and group across an AF_UNIX connection and the kernel will validate you to the recipient. And as I mentioned before, AF_UNIX connections are only available on the machine, so there's no outside hacking into these services.
But for my current project, the lack of transparently using AF_UNIX sockets was a bummer, because I have a project I'm working on where a process runs and then opens up an external file to write log entries to. I want to have those entries go immediately into another process for processing, and so I wanted to throw a named socket into the file system and have the first program log to that "file". The first process is this big third part server that I didn't want to have to mess with, so spoofing a file would have been ideal. Luckily there's something else available now that will do it.
fifo(7) or named pipes
A fifo is like a queue, where you put several things in, and then pull them out. In this case the first thing you put in is the first thing that comes out ( First In First Out ... fifo). There's also FILO, but it doesn't make as good an acronym in my opinion. So the modern linux kernel allows you to create a named pipe in the file system, and as an improvement, you don't even have to have any active processes attached to either end. It could just be sitting there. Then when you want, you attach and try to read from it, which doesn't do much cause there's nothing in it. When someone else comes along and write to it, then the message shows up to the reader.
There are some caveats of course. If no one is hanging around waiting for the message, you can't write to the named pipe. The kernel isn't going to save things up for you. Also, if several processes are reading to a named pipe, you can't tell the difference. Its not like sockets where each connection will have its own file handle and you can tell the lifespan of each client. But for the purposes of log processing it will do just fine. At least I hope it will. I will have to get back to you on that.
There was a mouse down in the basement this weekend. The kids got all excited, until the mouse was smushed, and then they were all like, "papa, time to cleanup." Note for future adventures, smashing things are the most effective when hunting mice. Very hard to stab a mouse.
In the process of cornering the criter, I had to disturb a pile of wood pellet sacks from last winter's burning operation. I was saving those to count them, but I've done a terrible job of keeping track of how much I actually burnt per month.
I have some notes in twitter account, which turns out to be a terrible place to put anything you want to lookup later. Best I can find is numbers for January and March, 1,400 and 1,600; and 1,320 for April. Overall I had six tons, and there's about 18 bags left out of 300.
It seems I burn as much pellets as I have. So the lesson there for conservation, buy less pellets. Temperatures already getting down to 40s at night, so we'll see how that goes.
I get calls from my alumni association every once in a while for a donation, and once in a while I'll give a few dollars to be counted as a supporter. But I'm not an active alumni. Its not that I don't think the college is a good one, it is. There's just issues that have cut me off. One of which is long over, but the other, while completely solvable, sits between me and active participation.
My time at college was excellent. I was surrounded by a bunch of really smart people, had access to millions of dollars in equipment (what it took back in the stone age to have great computers--now you can get a really great computer at Sams club), and even had access to staff and faculty where I could just sit down and launch into a tirade, only to have my lack of understanding explained to me.
But the end of the eighties was also the ascendancy of Reagan and extreme conservatism, and it hit at college as well, with the Master of Student Houses running all over the student body, including banning the once a year all-house party (Interhouse). Students were no longer trusted young adults and future leaders, they were troublesome kids that needed to be policed. Luckily I got out of there just as it was getting bad.
Fast forward nearly twenty years later, and things have returned more towards the middle. Interhouse is back, and things seem a bit normal. The problem is, I've moved on, and need somehow to reconnect with things. To see what's happening on campus, with the students, with the faculty, with the institute. Something like the university's streaming theater, wich interesting lectures from people like Harry Gray ( a professor I actually liked when I was there ).
But I can't watch it, cause its in Real Video format.
Yes, I could go get the Real Video player and install it and all its associated spyware on my computer. But I'm not, and nobody else is going to anymore because Realvideo is so 90s. We moved past that to Flash video about ten years ago. And in fact, the future is to just let the user watch the file however he wants with a avi/mp4/ipod download. Its doesn't have to be HD. I'd watch Caltech events at 320x240, just like my John Stewart.
I even sent off a email to the director of the PR/Media department (who made this unfortunate video format choice in the first place), but I'm not holding my breath. The last media update on mr.caltech.edu was a entry about a radio broadcast in 1998; and a note about a lecture in the Biology department on October 2003.
I hope those memories from twenty years ago are not the last positive memories I have from college.
