03:32: #(2002 6 17 3 9)

I'm trying to use Nautilus, again.

Dammit.

Every time I try to use a desktop-metaphoric system, it strikes me, just how stupid the desktop-metaphor is. The fact is that, even if I manage to put something useful on the desktop..., well, I the fact is that I can't put anything useful on the desktop, because, if it goes on the desktop, it's always covered up! It can't be useful if it's always covered up--if I can never get at it, if I can never even see it.

A palette metaphor might be good. Add stuff to the palette, pull stuff from the palette. Mix stuff on the palette--I can't even mix things in a file-manager or on a desktop. Well, I could mix things on my desktop, but it'd be messy and be frowned upon by `civilised' society.

The key is that the palette would be just like any other item with which I (the user) interacts. It'd show up in the same lists. It'd be cyclable with the same keys. It'd be managable by the same management-primitives.

A meaningful and useful parent/child display-/window-relationship would be nice to have, too....

A general run-time display-extension mechanism would be really nice to have.

I wonder if, some day, I'll write a general display-system of some sort. I wonder if it'd be better best to build it atop X11, or atop some widget-set GTK+, or to interface directly to the hardware, or what.... Interfacing with the hardware, I'd need an X11-compatibility application. If I just implemented on top of X11, then I wouldn't have that problem. I also wouldn't need to write bit-twiddling hardware-driver code.

[7d2.6.11-00: meta-source]

[Reply]

14:20: #(2002 6 15 14 10)

I wonder how many uses of @paste are optimal, or even valid.

[7d2.6.0f-00: meta-source]

[Reply]

23:12: #(0x7d2 6 12)

Stroustrup seems really annoying. In the C++ Style and Technique FAQ, he #{writes:}#

Why can't I resume after catching an exception?

In other words, why doesn't C++ provide a primitive for returning to the point from which an exception was thrown and continuing execution from there?

Basically, someone resuming from an exception handler can never be sure that the code after the point of throw was written to deal with the excecution just continuing as if nothing had happened. An exception handler cannot know how much context to "get right" before resuming. To get such code right, the writer of the throw and the writer of the catch need intimate knowledge of each others code and context.

Why is that? Is it because this is some innate universal truth, or is it just because that's the way that C++ is designed (which would reduce the reason to `C++ doesn't have continuable exceptions because C++ doesn't have continuable exceptions')? Gotta love his frequent `if you want to know the answer, buy my book!' pseudo-answers, too....

He does provide a link to a discussion-log in which he (of course) says, `buy my book!', but also quotes from the book, which states, basically, that experience has demonstrated continuation-semantics to be un-necessary and continuation-implementations to be slow. So, the conclusion is that, if something is slow and not necessary, it should not be included in C++. Funny.

[7d2.6.0c-00: meta-source]

[Reply]

16:40: #(2002 6 11 16 36)

This ttn is an interesting fellow....

[7d2.6.0b-02: meta-source]

[Reply]

12:33: #(2002 6 11 1 15)

Hmm. The basis that `1 + 1 = 2' is apparently just that `.\ x = x + 1' is defined as meaning `the successor of x', for some arbitrary definition of `successor'. Sums using natural numbers other than 1 are found by inverting this function and applying it recursively until the number with which we are working is one.

I suppose that, at the heart of this, there is the presumption that one cannot `make new numbers', but that, rather, there is an infinite series of numbers (why would one need to make more, if one already has an infinite number of them?), and the `+1' function is just cadr.

Gee, maybe those set-theoretical guys are onto something....

And maybe it's time for sleep....

[7d2.6.0b-00: meta-source]

[Reply]