for (q = head; q; q = q->next)
It was useful to invoke this method when I needed to print the contents of the list. I just passed in the name of a function like this:
std::cout << e << std::endl;
I thought I could do a bit more advanced things by adding a void* argument, but there would be a little bit of work with that and it was not perfectly general.
The notion of lambdas also occurred to me but I did not think too hard about it since they are still new in C++ so I was like ... meh.
Then I kept thinking some more and I was like, uggh, the way I toss bits around, an additional arbitrary callback argument will be approximately as powerful as a temporary anonymous function, if not as syntactically pretty, and both of these are going to be more or less limited to doing only so much with the current object in the iteration.
The potential versatility suggested by this kind of element-iterator with arbitary callback suggests interesting possibilities that, well, ought to be a lot easier! It would be great if I could call traverse on a binary search tree and have it generate a dot file representing the relationships between nodes so a computer program could draw them nicely for me. In fact that kind of thing seems like what any traverse method worth its salt ought to have been meant for. But it's unpleasant to do in a general way and without unnecessarily abusing global state! A callback with three parameters (parent, left, right) is one option, but I don't want to be bound to the number 3. Maybe I can just do (a, b, NULL) for a two-parameter version. But why stop there? How about vararg? Or maybe a vector of arguments? These all seem very unsatisfying and ad-hoc to me!
It might be nice if some portion of the current stack frame could be made available to my callback function -- even in a safe and read-only way. I promise I do not want to break things, just know where I'm at so I can figure out where I'm going! Oughtn't there be a concise way to define a callback with read access to certain local variables belonging to the function invoking the callback?
How can I achieve such a thing in C or C++? I mulled over this for several days, toying in my head with various unimplementable thoughts and vacillating over whether the idea itself was good or not, or whether I was already overlooking any useful language feature that made this easy as cake, or whether I had dug myself into a tarpit of hopelessly unimprovable design? A binary search tree could be drawn any number of ways, but, darnit, why not with such a traverse method as described above? No world can be a happy one that has factories where one robot tosses doodads onto a conveyor belt and another operates a claw to inspect each, one by one, without knowing anything of the status or history or progress of the doodad-loading operation; else that claw-bearing robot be an uninterestingly simple one, and the factory incapable of producing anything of value.
I was completely flummoxed. This is so basic a need, and it tears at the fabric of my thoughts with such relentlessness, someone else must already have figured it out; I must rest my mind a short time before I drive myself crazier!
Though I may have permitted my brain a brief respite from the harrowing, I could not fully abandon the matter, in spite of the mounting practical reasons to do so. Before I was prepared to abandon all responsibility and set forth once more and finally forever down this path to ultimate insanity, the notion was abruptly thrust into my consciousness to consider the bigger picture. Bigger than binary trees -- what of the general class of graphs? Here, my mind began to spin again. It would not cut it to just pass references to the parent, left, and right nodes. Total parameter variability was necessary to account for the diversity of graph representations and characteristics! In the same instant that it occurred to me that the entire state of the invoking function must be fully accessible to the callback, a sharp blow glanced off my lower abdomen and I landed on my back, striking my head on the asphalt. Dizzy, I wheezed through a scowl and by the time I had lifted my head up, a formation of one thousand diiqs and calcnerds had begun rapidly marching towards me, brandishing brightly colored pugil sticks. A dark horse with a confident gait followed. It was the general, Adam. The head of each of the two advancing columns set down his weapon and appeared on either of my shoulders. They leaned in close to my ears as if to whisper. I could not fret over the decision to listen to one or the other because they both shouted in unison, startling me further. My mind was blank from fear and as I groped for comprehension, they boxed my ears and while I reeled they fluttered up in front of me and mocked me with gestures I could barely make out through the taste of tears and snot. They flew off into the sunset together, the army marching along under them. Parentheses formed in their wake, and I could not tell if they were opening or closing.
We also played with TheGun.exe which brings me no end of delight -- it does not have a config file, but its standalone configurator modifies the exe so that next time it runs the settings you configured are "default". "Played with" included loading it in Notepad.exe as well as vim and attempting to change some strings and observing it to fail loading, both in Windows 7 and Wine 1.32. Under Wine, at least, TheGun.exe would not save modifications to the very executable image responsible for the running process, but you could save them to a different file at least and run that, or attempt to. I suspect you probably just couldn't write to the exe of any running process. Near the top of the file there were some mentions of TheGun and I changed one to Horse and it would not load, sadly.
I found accessmaincomputerfile.net the other day and was inspired to try my hand at some immersive or attention-grabbing GUI components. Movie GUIs are overkill and extreme and make "real" GUIs look like the 20th century -- the ones I get excited about anyhow. The other ones I get excited about are the ones that are too real such as Trinity+nmap or SunOS in the new Tron movie. These aren't very exciting to see on your normal computer though since, well, they already are on your normal computer.
My first step is to implement a clock applet resembling the screenshot from Darkstar. I am running XFCE4 in Arch right now so I am going to target this environment. Adam was very helpful to me in gathering some information and getting started on setting up the build environment and sharing his perspective on how it might work. I have successfully compiled the original clock applet now. There are five options, each of which is based from a .c file in the xfce4-panel source tree, so my intent is to add clock-darkstar.c as an important part of finagling a sixth option into the mix.
After doing all this hard work I decided making a XFCE plugin did not really further my goals and it would probably be more fun and tasty to pursue another avenue that did not necessarily require XFCE for example.
I already have some experience with SDL so I am going to bark up that tree.
As much as I want to learn new things, what I really want is to have a sweet new Darkstar (1974) clock applet. Now I am abusing the term "clock" and "applet" since this beastmaster can be so much more! A clock for starters, but the view implies so many fiddly knobs! Every text field is completely configurable in a number of ways. Good grief I am already in over my head before I even hit the water!
I am going to nuke my copy of the xfce4-panel out of spite and also to make sure I have a lot of headache to go through in case I forget that I am doing this with SDL and not making a xfce4 plugin.
I am also listening to Voltaire right now. Background music, not advice.
EDIT: here is a great link to what I have accomplished thus far https://jonathanstone.homeip.net/darkstar.tgz.
Labels: movie guis
silly shell tricks
xkb and xmodmap: a big mess
I thought that I would take a moment to write down the steps that it took to get a mapping with an extensive and unusual Alt-gr map up and running (on Linux). What is available online is exceedingly unhelpfull.
1. I used Mod_switch rather than ISO_level3_Shift. ISO is the 'correct' choice, but by default N and J cannot be level shifted; fixing that requires xkb, and xkb is evilly difficult to use.
2. Speaking of xkb and evil, Mod_switch won't always work unless xkb is off. So in xorg.conf:
Option "XkbDisable" "true"
# Option "XkbRules" "xorg"
# Option "XkbModel" "latitude"
# Option "XkbLayout" "us"
Make sure to comment out all the xkb rules. In .xsession or .xinitrc or wherever you put scripts that run before your X session starts:
3. Edit .Xmodmap:
keycode 44 = j J plus
keycode 0x41 = Mode_switch
add mod3 = Mode_switch
(note that I use the spacebar as my Mode_switch; chances are you want someting different)
Mode_switch uses the third and fourth keysyms; 'j' and 'J' are the first and second, 'plus' is the third. space+j will return '+'.
Please understand that this is the wrong way to do this; the 'right' way is to use xkb. However, rolling your own xkb mapping is a major undertaking, while xmodmap is reasonably simple. Disabling xkb as I have done here is not reccomended generally, and can apparently cause problems if you use compositing. Nevertheless, this solution works for me.
I don't want a super-efficient language, or a minimal language, or a super-readable language. I want a language that is fun.
The most controversial way I can put it is probably also the best: there is a quote.
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." – Brian W. Kernighan
My design philosophy is this: I want a language in which I can code as cleverly as possible. Because I enjoy it. To hell with anything else.
Clone of Existing Game with 3D Enhancement
I got the idea to do this from a discussion with Montana about "solving" the game -- i.e. figuring out where you could place your ball to ensure that you "won". He suggested something about Einstein's light cones and thus this idea was born.
I have never done 3D graphics before except in QBasic like ten years ago so this will be challenging and interesting.
Right now I have successfully cloned the behavior of the original game. The balls bounce, collide, grow, shrink and die predictably, and all parameters (initial size, color, growth rate, target growth size, waiting duration, shrink rate, and number of balls) are completely customizable within reasonable limits i.e. no negative radii.
With regard to shininess, I hope to do some transparency/alpha blending so the balls don't just overlap, also when bouncing off the edges the sprites flicker because the collision logic is funky however they ultimately careen off at the correct angle and stop flickering when they get away from the edge. Also maybe sound at some point? However these are all ancillary to my chief interest, which is representing the time dimension spatially.
Haskell -> Arc
At the same time, compile time type checking has probably detected more than it's share of bugs in my code. It's a tradeoff. Whether it's a net win or loss is hard for me to say; I've done very little functional programming without strong typing. I don't like Java style strong typing, but the ML type system is a different beast. Having spent the better part of a year working in Haskell, I'm due to try a new programming language, so I'm going to move to Lisp for a while.
Unfortunately for me, the essays that convinced me to finally a Lisp were on Arc, an arguably incomplete dialect. It has almost nothing in the way of libraries. After looking at Arc, though, Common Lisp looks warty and Scheme's lack of unhygenic macros is disturbing for a power language. So I'll start with Arc, though I may well have to move to Common Lisp if I get frustrated with what I can't do (though I do have something of a backup plan in the works for that; more on that later, if it comes to pass).
Picking up on loose ends, blogwise, my tron lightbike FRP game fell apart when I had trouble working out a definition of the behavior of the walls trailing behind the players. I couldn't find a way to define a behavior that was a list of snapshots of another behavior at points dictated by a third behavior, and I couldn't help feeling that it was more natural to define it procedurally (though that may just be what I'm more used to). I ended up being frustrated enough that I put it down and never came back to it.