If I die unexpectedly, my wife will be able to (a) easily see the new documents coming in, and (b) easily see the old documents that I have on file. I use hanging folders, with each business' documents going back in time five years.
Repeat the following to yourself. "Xterm is broken." "Xterm is broken."
When you drag the mouse in xterm, it defines the PRIMARY selection. This has the same meaning as it does on the Mac and Windows, in GTK and in Mozilla: this text is significant for later. The text gets highlighted. Now what?
For everything else listed above, you run some sort of command and load that selection into the clipboard. As the ClipboardsWiki page mentioned above (http://freedesktop.org/Standards/ClipboardsWiki), PRIMARY is used as the argument to the "copy to clipboard" command.
Xterm doesn't provide any way of setting the clipboard. It doesn't provide any way of getting the clipboard contents. Instead the middle mouse button is a completely different command: "insert text at cursor". The argument to this command is, once again, PRIMARY. The clipboard is completely bypassed. No wonder it doesn't work correctly.
Various programs like rxvt and Emacs have inherited this broken behavior to be compatible with xterm. Luckily, modern terminal emulators like "gnome-terminal" have fixed it. You select the region with the mouse, then do an explicit copy to the clipboard. This can be with a right-click content menu, an entry on the menu-bar, or the chord "Ctrl-Shift-C". (Note that adding the "shift" modifier prevents it from conflicting with ordinary "Ctrl-C"). To paste at the cursor, there's an explicit command to read from the clipboard.
The Avant Stellar keyboard (http://www.cvtinc.com/products/keyboards/stellar. htm) also has buckling springs. They licensed the keyboard design of the Northgate Omnikey, and it has the same built-like-a-tank feel. Unlike the Omnikeys, the Stellar has Windows keys; I use them to get both Alt and Meta under X. You can also remap the Control and Caps Lock keys in hardware---they even ship you extra keycaps in case you do switch them. And the icing on the cake, the Stellar has another set of function keys down the left-hand side (XT-style) where you can actually reach them.
I hate the click action of mouse wheels. I've gotten to the point where I hoard Logitech Mouseman and Wingman mice. Three buttons, no wheel. I have a box full of them in my closet.
But what I use are PerfitMouse mice from Contour Design (http://www.contourdesign.com/perfit-new.htm). Three buttons across the top, multiple sizes, right- and left-handed versions. They're just now switching over to an optical version, with USB (plus PS/2 adaptor), and a wheel on the side for your thumb (my thumb is more flexible than any of my fingers; isn't yours?), and underneath it there's a two-way hat switch.
They're expensive. The new opticals are $110. But they treat my hand very well. I've bought three of the old versions for $90, and I've just bought the first of three of the new ones.
Read the last page of Exegesis 6 to see the Perl 5 version of the code. It's astonishingly simpler and clearer in Perl 6.
That particular piece of Perl 6 functionality would have to be expressed as that particular chunk of Perl 5 code to get a comparable effect. Fine.
My personal concern is in how in the preceeding 10 pages, he describes another umpteen "simpler and clearer" ways of achieving the same effect (most of which seem to have subtle gotchas).
Re:Some imp. stuff that I believe is missing, or?
on
Qt On DirectFB
·
· Score: 1
XFree86 4.3 should have the new Resize and Rotate extention (RandR):
The Resize and Rotate extension (RandR) is a very small X extension designed to allow clients to modify the size, accelerated visuals and rotation of an X screen. RandR also has provisions for informing clients when screens have been resized or rotated and it allows clients to discover which visuals have hardware acceleration available.
See http://keithp.com/~keithp/talks/randr/randr/ for the complete paper.
Note that the 4.3 release will not support depth switching. See http://keithp.com/~keithp/talks/randr/protocol.txt for an explanation. However, it should support depth-independence for applications, allowing you to move windows from a 32bpp display to an 16bpp display in a multi-head environment.
Re:DirectFB Inherently Insecure?
on
Qt On DirectFB
·
· Score: 5, Informative
Your X server also needs root access, and for much the same reasons. X needs to muck with the registers on your video card, for example. Nowadays, there's a little setuid program called "XWrapper" that gets access to everything it needs, then drops its privileges and loads the main X server on top of itself.
There is at least one project (KGI) that attempts to rationalize all this. It puts the privileged functionality in kernel space, then exposes it all in a safe manner. Linus has not been receptive to this design in the past, preferring the X mechanism.
Bart Massey and Jamey Sharp of Portland State have written XCB, a reimplementation of Xlib with an eye towards improved tunability (and an improved API). They were having problems coming up with an implementation that worked properly; the multi-threaded connection handling code was up to four designs and two implementations, all of them incorrect.
Massey and Robert Bauer of Rational ended up writing a Z specification for that portion of the code, and proved it correct. The C implementation of the spec is in the XCB distribution right now.
Massey and Bauer published a paper describing this effort for USENIX 2002. They conclude with the comment "[t]he sort of lightweight modeling described [above], that isolates a troublesome portion of the system for more detailed study, is especially appropriate[...]".
When I'm just writing text, I code in XHTML or XML. That's what they're designed to do, and they work well for it.
Tables are annoying, however, and structured vector graphics (objects with ports on their sides) are impossible. I've looked into Amaya for these features, and support for them is still too primitive.
Do any of the various free tools have a combination that can match Word-plus-simple-embedded-Visio? I've found that's all I need for 90% of my technical documentation.
We have powerful OO programming languages but we have to translate objects to rows of data to store in a table!
OO programming languages allow programmers to create vast, ad-hoc conglomerations of data, then hand-write ad-hoc code to traverse, read and manipulate those data structures.
The relational data model makes the relationships between different data explicit, and exposes those relationships in such a way that other programs can write all the code to traverse, read and manipulate them. This is the whole point of query languages; all the work of traversing the data structures, extracting fields and building temporary structures is done for you.
Note that it is possible to concisely specify certain types of hierarchical traversal, and have code generated for you. This is what XPath does, for example. But the relational model allows automation just about everywhere.
In addition, because all the data and relationships are exposed, the RDBMS can write code to enforce data consistency rules. RDBMS declarative rules can span datasets in ways that would require custom code in a normal programming language. In fact, if the data and relationships are correctly designed, certain types of inconsistency become impossible; this is what normalization is all about (also known as "Once and Only Once").
The problems are (a) SQL blows chunks as a relational query language, which means you have to use a second language for certain tasks, and (b) the second languages are even less suited to the relational model than SQL. So when people struggle to store their hand-crafted object graphs in a relational database, they blame the database.
Notes (because someone will want to bring these up):
Views provide polymorphism in the relational model. The view acts as a base class, containing a subset of field names (possibly renamed) from any number of datasets. The performance of a view is stricly up to the implementation. If your RDBMS can't update views, it's broken.
It's possible to represent a tree in a relational database by storing the nodes in one dataset, and the parent/child relationships in another dataset. However, this is an inconvenient representation for doing reasoning on. Chris Date has proposed an "EXPLODE" operator that would convert the two-dataset representation into a data-preserving, but larger, flattened representation that the DBMS could work with. (Note that the query engine wouldn't have to run a full EXPLODE on every query; behind the scenes it can do whatever tree walking it needs to for efficiency.
IMO any product that needs full time admin & tuning is a failure in TCO terms.
Compare this to the use of full-time operators for administration and tuning on mainframes in a recent article: Mainframe Operators Needed. The large companies using and buying mainframes would seem to approve of that particular TCO.
Why do you think so much effort been invested in areas such as advanced modelling tools but so little in improving debugging tools?
A debugger is going to help you find and fix the bugs that got through:
Requirements analysis
Specification analysis
Design analysis
Code analysis
Studies have shown repeatedly that the cost of fixing each bug increases at each stage. So if you are going to invest $1000 in new development tools, is it more economical to buy tools to detect bugs when they're cheap, or when they're expensive?
And the fact that most of this population has to either (a) drive in narrow corridors north/south between Puget Sound and two lakes, or (b) drive *across* or around the two aforementioned lakes. Did I mention that these are glacial lakes, really long and too deep to build normal bridges?
If you have lots of real text, and tags scattered lightly around your document, then XML is easy for humans to read. Think about how readable HTML1 documents were.
If you have little bits and pieces of data embedded into a massive element hierarchy, then deciphering it becomes a chore. Ant's config file falls in that category. So do most web pages nowadays, it seems.
Remember that XML (and SGML) was designed so humans could write documents with it. Config files are really outside of its original domain, and it's no wonder it's showing some problems. That's why I prefer to use SXML syntax when I'm dealing with XML-as-dataformat. I find it's better tuned for that application.
Make has problems with compiled inner-class files. The "$" in the file name gets interpreted as starting a Make variable. Yes, it's possible to quote them; it's still a pain in the butt to deal with.
Ant can run Java programs in its own JVM, speeding up compilation.
Ant comes with various support tools that you would have to roll yourself in Make.
If none of these have been an issue for you, then you probably don't need to switch.
IBM's Visual Age for Java used something similar, adapted from their Visual Age Smalltalk. My problem with VAJ was that you couldn't do anything in their environment except what they had specifically designed for you to do. If you have files in disk, you can run whatever tools you want on them. But in VAJ or Visual Studio.NET? "I dunno, what's in the context menu?"
To avoid flat text files, you'd need an interactive scripting language powerful enough to perform any task you'd care to think of (viz., Emacs). Plus you'd need enough support libraries available to you to interact with third-party utilities, and finally bindings for the abstract syntax trees of all the languages you want to program in, so you could manipulate them programatically.
XML's default-to-text nature makes writing documents easy, but you then have to work more to express code in i (e.g., XSLT). XML's verbose, redundant syntax is more robust in the face of errors, but Lisp editors have been effective at dealing with the concise S-Expression syntax.
For directly editing code or strongly hierarchical data, I think S-Expressions are a better choice. For directly editing text or weakly hierarchical data, I think XML is a better choice. Since a literate programming environment is much more likely to hide text markup (bold text, underlined hyperlinks) than code markup, I think the balance tips towards S-Expressions there.
Me. I've moved my titlebars to the left-hand side of windows. This gives me the maximum possible vertical space for editing. I use the offset to move the mouse cursor out of the window proper, so it doesn't obscure any text when I'm flipping into a window with Alt-TAB.
I can't see any reason to make it a full-blown Preference entry, though. A Lisp variable would be fine.
Slashdot Mirror
If I die unexpectedly, my wife will be able to (a) easily see the new documents coming in, and (b) easily see the old documents that I have on file. I use hanging folders, with each business' documents going back in time five years.
And it comes with additional keycaps for when you swap your Control and Caps Lock keys in firmware. No stupid air gap like the Unicomp Customizer has.
And it has function keys down the left hand side.
I have four of them.
There isn't?
http://www.contourdesign.com/pmo/index.htm
Three different left-hand sizes.
Or there's the Contour Design "Perfit Mouse", which is definitely not bargain-bin material:
http://www.contourdesign.com/pmo/index.htm
Three buttons across the top, and your thumb is next to a scroll wheel and a rocker switch on the side.
It comes in multiple sizes, including left-handed sizes.
Repeat the following to yourself. "Xterm is broken." "Xterm is broken."
When you drag the mouse in xterm, it defines the PRIMARY selection. This has the same meaning as it does on the Mac and Windows, in GTK and in Mozilla: this text is significant for later. The text gets highlighted. Now what?
For everything else listed above, you run some sort of command and load that selection into the clipboard. As the ClipboardsWiki page mentioned above (http://freedesktop.org/Standards/ClipboardsWiki), PRIMARY is used as the argument to the "copy to clipboard" command.
Xterm doesn't provide any way of setting the clipboard. It doesn't provide any way of getting the clipboard contents. Instead the middle mouse button is a completely different command: "insert text at cursor". The argument to this command is, once again, PRIMARY. The clipboard is completely bypassed. No wonder it doesn't work correctly.
Various programs like rxvt and Emacs have inherited this broken behavior to be compatible with xterm. Luckily, modern terminal emulators like "gnome-terminal" have fixed it. You select the region with the mouse, then do an explicit copy to the clipboard. This can be with a right-click content menu, an entry on the menu-bar, or the chord "Ctrl-Shift-C". (Note that adding the "shift" modifier prevents it from conflicting with ordinary "Ctrl-C"). To paste at the cursor, there's an explicit command to read from the clipboard.
Yes. Yes I do. The Contour Design PerfitMouse. Read my previous comment:
http://slashdot.org/comments.pl?sid=78118&cid=6940 304
The Avant Stellar keyboard (http://www.cvtinc.com/products/keyboards/stellar. htm) also has buckling springs. They licensed the keyboard design of the Northgate Omnikey, and it has the same built-like-a-tank feel. Unlike the Omnikeys, the Stellar has Windows keys; I use them to get both Alt and Meta under X. You can also remap the Control and Caps Lock keys in hardware---they even ship you extra keycaps in case you do switch them. And the icing on the cake, the Stellar has another set of function keys down the left-hand side (XT-style) where you can actually reach them.
I hate the click action of mouse wheels. I've gotten to the point where I hoard Logitech Mouseman and Wingman mice. Three buttons, no wheel. I have a box full of them in my closet.
But what I use are PerfitMouse mice from Contour Design (http://www.contourdesign.com/perfit-new.htm). Three buttons across the top, multiple sizes, right- and left-handed versions. They're just now switching over to an optical version, with USB (plus PS/2 adaptor), and a wheel on the side for your thumb (my thumb is more flexible than any of my fingers; isn't yours?), and underneath it there's a two-way hat switch.
They're expensive. The new opticals are $110. But they treat my hand very well. I've bought three of the old versions for $90, and I've just bought the first of three of the new ones.
Lois McMaster Bujold is a newbie?
With three Hugos and two Nebulas?
I'd add Alastair Reynolds to that list (Revelation Space).
That particular piece of Perl 6 functionality would have to be expressed as that particular chunk of Perl 5 code to get a comparable effect. Fine.
My personal concern is in how in the preceeding 10 pages, he describes another umpteen "simpler and clearer" ways of achieving the same effect (most of which seem to have subtle gotchas).
XFree86 4.3 should have the new Resize and Rotate extention (RandR):
See http://keithp.com/~keithp/talks/randr/randr/ for the complete paper.
Note that the 4.3 release will not support depth switching. See http://keithp.com/~keithp/talks/randr/protocol.txt for an explanation. However, it should support depth-independence for applications, allowing you to move windows from a 32bpp display to an 16bpp display in a multi-head environment.
Your X server also needs root access, and for much the same reasons. X needs to muck with the registers on your video card, for example. Nowadays, there's a little setuid program called "XWrapper" that gets access to everything it needs, then drops its privileges and loads the main X server on top of itself.
There is at least one project (KGI) that attempts to rationalize all this. It puts the privileged functionality in kernel space, then exposes it all in a safe manner. Linus has not been receptive to this design in the past, preferring the X mechanism.
Go check the website again. They have software for 2000/XP now. No NT, though.
Bart Massey and Jamey Sharp of Portland State have written XCB, a reimplementation of Xlib with an eye towards improved tunability (and an improved API). They were having problems coming up with an implementation that worked properly; the multi-threaded connection handling code was up to four designs and two implementations, all of them incorrect.
- zxcb.pdf
Massey and Robert Bauer of Rational ended up writing a Z specification for that portion of the code, and proved it correct. The C implementation of the spec is in the XCB distribution right now.
Massey and Bauer published a paper describing this effort for USENIX 2002. They conclude with the comment "[t]he sort of lightweight modeling described [above], that isolates a troublesome portion of the system for more detailed study, is especially appropriate[...]".
XCB Wiki: http://xcb.wiki.cs.pdx.edu/
XCB/Z Paper: http://xcb.wiki.cs.pdx.edu/pub/XCB/WebHome/usenix
When I'm just writing text, I code in XHTML or XML. That's what they're designed to do, and they work well for it.
Tables are annoying, however, and structured vector graphics (objects with ports on their sides) are impossible. I've looked into Amaya for these features, and support for them is still too primitive.
Do any of the various free tools have a combination that can match Word-plus-simple-embedded-Visio? I've found that's all I need for 90% of my technical documentation.
We have powerful OO programming languages but we have to translate objects to rows of data to store in a table!
OO programming languages allow programmers to create vast, ad-hoc conglomerations of data, then hand-write ad-hoc code to traverse, read and manipulate those data structures.
The relational data model makes the relationships between different data explicit, and exposes those relationships in such a way that other programs can write all the code to traverse, read and manipulate them. This is the whole point of query languages; all the work of traversing the data structures, extracting fields and building temporary structures is done for you.
Note that it is possible to concisely specify certain types of hierarchical traversal, and have code generated for you. This is what XPath does, for example. But the relational model allows automation just about everywhere.
In addition, because all the data and relationships are exposed, the RDBMS can write code to enforce data consistency rules. RDBMS declarative rules can span datasets in ways that would require custom code in a normal programming language. In fact, if the data and relationships are correctly designed, certain types of inconsistency become impossible; this is what normalization is all about (also known as "Once and Only Once").
The problems are (a) SQL blows chunks as a relational query language, which means you have to use a second language for certain tasks, and (b) the second languages are even less suited to the relational model than SQL. So when people struggle to store their hand-crafted object graphs in a relational database, they blame the database.
Notes (because someone will want to bring these up):
Views provide polymorphism in the relational model. The view acts as a base class, containing a subset of field names (possibly renamed) from any number of datasets. The performance of a view is stricly up to the implementation. If your RDBMS can't update views, it's broken.
It's possible to represent a tree in a relational database by storing the nodes in one dataset, and the parent/child relationships in another dataset. However, this is an inconvenient representation for doing reasoning on. Chris Date has proposed an "EXPLODE" operator that would convert the two-dataset representation into a data-preserving, but larger, flattened representation that the DBMS could work with. (Note that the query engine wouldn't have to run a full EXPLODE on every query; behind the scenes it can do whatever tree walking it needs to for efficiency.
IMO any product that needs full time admin & tuning is a failure in TCO terms.
Compare this to the use of full-time operators for administration and tuning on mainframes in a recent article: Mainframe Operators Needed. The large companies using and buying mainframes would seem to approve of that particular TCO.
A debugger is going to help you find and fix the bugs that got through:
Studies have shown repeatedly that the cost of fixing each bug increases at each stage. So if you are going to invest $1000 in new development tools, is it more economical to buy tools to detect bugs when they're cheap, or when they're expensive?
And the fact that most of this population has to either (a) drive in narrow corridors north/south between Puget Sound and two lakes, or (b) drive *across* or around the two aforementioned lakes. Did I mention that these are glacial lakes, really long and too deep to build normal bridges?
It's alllll about the ratio.
If you have lots of real text, and tags scattered lightly around your document, then XML is easy for humans to read. Think about how readable HTML1 documents were.
If you have little bits and pieces of data embedded into a massive element hierarchy, then deciphering it becomes a chore. Ant's config file falls in that category. So do most web pages nowadays, it seems.
Remember that XML (and SGML) was designed so humans could write documents with it. Config files are really outside of its original domain, and it's no wonder it's showing some problems. That's why I prefer to use SXML syntax when I'm dealing with XML-as-dataformat. I find it's better tuned for that application.
Make has problems with compiled inner-class files. The "$" in the file name gets interpreted as starting a Make variable. Yes, it's possible to quote them; it's still a pain in the butt to deal with.
Ant can run Java programs in its own JVM, speeding up compilation.
Ant comes with various support tools that you would have to roll yourself in Make.
If none of these have been an issue for you, then you probably don't need to switch.
IBM's Visual Age for Java used something similar, adapted from their Visual Age Smalltalk. My problem with VAJ was that you couldn't do anything in their environment except what they had specifically designed for you to do. If you have files in disk, you can run whatever tools you want on them. But in VAJ or Visual Studio .NET? "I dunno, what's in the context menu?"
To avoid flat text files, you'd need an interactive scripting language powerful enough to perform any task you'd care to think of (viz., Emacs). Plus you'd need enough support libraries available to you to interact with third-party utilities, and finally bindings for the abstract syntax trees of all the languages you want to program in, so you could manipulate them programatically.
Then again, S-Expressions are not XML.
XML's default-to-text nature makes writing documents easy, but you then have to work more to express code in i (e.g., XSLT). XML's verbose, redundant syntax is more robust in the face of errors, but Lisp editors have been effective at dealing with the concise S-Expression syntax.
For directly editing code or strongly hierarchical data, I think S-Expressions are a better choice. For directly editing text or weakly hierarchical data, I think XML is a better choice. Since a literate programming environment is much more likely to hide text markup (bold text, underlined hyperlinks) than code markup, I think the balance tips towards S-Expressions there.
"WHO THE FSCK WANTS TO CONFIGURE THAT?!"
Me. I've moved my titlebars to the left-hand side of windows. This gives me the maximum possible vertical space for editing. I use the offset to move the mouse cursor out of the window proper, so it doesn't obscure any text when I'm flipping into a window with Alt-TAB.
I can't see any reason to make it a full-blown Preference entry, though. A Lisp variable would be fine.
If the code is such a security issue that they can't release it to the public, the federal government should require an immediate security lockdown: