Re: [9fans] Simplified Chinese plan 9
eris.discor...@gmail.com (Eris Discordia) writes: http://thinkzone.wlonk.com/Language/Korean.htm Interesting. I used to think Korean, too, uses a syllabary. Turns out it's expressed alphabetically. Expressing Japanese that way would create some space for confusion as there are certain sounds that never combine with certain other sounds, e.g. there are 'sa,' 'se,' 'so,' and 'su' syllables in which 's' is heard just like 's' in 'say' but there's no 'si'--there's only 'shi.' Actually, I belive that in Korean, si (시, if that displays for you at all) is pronounced shi. :P If there existed an 's' character and also characters for vowels the invalid combination 'si' could be created in writing. I wonder if Korean alphabet can be used to make invalid combinations or all possible combinations correspond to existing phonetic constructs. Some combinations don't occur. Especially there are dipthongs that don't occur. But that's not really strange or a problem. Consider the word: qimk. It doesn't work in English, but the Latin alphabet still functions.
Re: [9fans] nice quote
eris.discor...@gmail.com (Eris Discordia) writes: As for this direct question: I must say that the Lisp version is much simpler and clearer to me, while the C version is mildly baffling. Does that make me a wizard who can hardly read simple C code, or is it just a matter of what you and I are respectively more comfortable with? I'd like to concur with the implication that it's all a matter of what mindset one carries but I'm also tempted to exclaim since I find the C version straightforward--it closely follows how one would do a bubble sort on paper. Or perhaps even this assertion is shaped by my personal impressions. I don't have the two versions in front of me, but if I did I might say that the Lisp version is more similar to describing how to do a bubble sort, while the C version is more similar to doing it.
Re: [9fans] nice quote
eris.discor...@gmail.com (Eris Discordia) writes: Let me be a little pedantic. The 9fans know given the haphazard nature of a hobbyist's knowledge I am extremely bad at this, but then let me give it a try. FYI, it's been Lisp for a while. As long as Britannica and Merriam-Webster call it LISP I don't think calling it LISP would be strictly wrong. Has LISt Processing become stigmatic in Lisp/LISP community? Just the orthography. Indeed, my only encounter with LISP has been Scheme and through a failed attempt to read SICP. Next time you get a hankering to see what all the fuss is about, you could try a book like Practical Common Lisp (which can be read online at http://gigamonkeys.com/book/ ). SICP is a good book, but it's geared toward introducing fundamental programming concepts like abstraction with a minimum of language features, which is necessarily at odds with getting stuff done in a straightforward way. If you have a scrawny x86 on your desktop and are trying to implement, say, a bubble sort--yes, the notorious bubble sort, it's still the first thing that comes to a learner's mind--it seems C is quite apt for expressing your (embarrassing) solution in terms of what is available on your platform. Loops, arrays, swapping, with _minimal_ syntactic distraction. Simple, naive algorithms should end up in simple, immediately readable (and refutable) code. Compare two implementations and decide for yourself: http://en.literateprograms.org/Bubble_sort_(Lisp) http://en.literateprograms.org/Bubble_sort_(C) I must say that the Lisp version is much simpler and clearer to me, while the C version is mildly baffling. Does that make me a wizard who can hardly read simple C code, or is it just a matter of what you and I are respectively more comfortable with? The main benefits it had in AI were features that came from garbage collection and interactive development. More importantly, LISt Processing which used to be an element of the expert systems approach to AI and which is now defunct (as a way of making machines intelligent, whatever that means). While expert systems continue to exist the word causes enough reverb of failure to be replaced by other buzzwords: knowledge-based systems, automated knowledge bases, and whatnot. Don't assume that just because Lisp is useful for list processing that it's not useful for a wide variety of problem-solving approaches. I've seen many people get hung up on lists (and recursion), thinking that they are somehow the essence of Lisp programming.
Re: [9fans] audio standards -- too many to choose from
fors...@terzarima.net (Charles Forsyth) writes: Hardware 24...@192khz. the human ear can't hear as high as that still, it ought to please any passing bat! Hi-fi, hi-fi, ... If you're recording doing it at 24-bit will pay off in the mixing stage.
Re: [9fans] Using proportional fonts in Acme for Programming
Aaron W. Hsu arcf...@sacrideo.us writes: Secondly, if you do use proportional width fonts, why, and what troubles did you encounter; what benefits did you encounter? You can't very well engage in weird formatting tricks, but I'm not much a fan of those anyway. IMO, the more attractive letters and generally lesser character width more than make up for the inability to precisely align columns that don't contain whitespace. I just use tabs to give myself a semantic clue. Thirdly, would you continue using proportional width fonts in cases like Lisp code, where you very often see something like the following indentation scheme, No. Lisp indentation is hairy enough that I'd rather have the editor do it anyway (I'll take a structure editor too, if you please), so Acme is right out. Lisp code is so structurally complex that the indentation scheme I use in C doesn't work so well. I really want arguments to a function to begin at the same column, and for macro bodies to be indented by two characters precisely, so I don't get hopelessly lost. I just go on back to Emacs for Lisp coding. and how would you resolve these indentation problems with proportional width fonts if you did continue to use them? I'd make leading spaces inherit their width from the characters above. (let ((foo bar) (something else)) (some-func (called again) (with fun indentation) (and yet) (another))) So in this example, the first space on line two would have the width of (, the second the width of an l, and so on. But the space in something else uses whatever width is defined in the font, since spacing would get weird otherwise. You couldn't do (let ((foo bar) (something else)) ...) and expect proper alignment, but like I said, I don't like that trick anyway.
Re: [9fans] Why does Acme only show text?
eeke...@fastmail.fm (Ethan Grammatikidis) writes: On Wed, 15 Jul 2009 09:25:51 GMT Paul Donnelly paul-donne...@sbcglobal.net wrote: jason.cat...@gmail.com (Jason Catena) writes: I've been wondering for years now why Acme (and Wily, which I used first) only display text files. It seems to me that the content of an Acme window could be anything: a picture, a postscript or PDF file, a star chart, a web page. Keeping with the spirit of small parts brought together, Acme could outsource the displaying of the content to another program, place its output in the Acme window, and operate on it by sending commands from the tag to the rendering program. Hi, I don't know anything about anything, but it seems to me that it's more productive to look at the question the other way around: why not modify Rio to tile windows like Acme does? Acme is a text editor, so it's no surprise that it handles text only. You may be thinking too monolithically. The draw device multiplexes itself so it shouldn't take much coding for acme to provide draw in addition to the other files it provides in /mnt/wsys. Mouse is just as important as draw and will need a little more code. Not only would acme need to multiplex it but it would need to emulate rio's behaviour. To quote Rio's man page: Opening it turns off scrolling, editing, and rio-supplied menus in the associated window. That isn't 100% true, scrolling isn't actually disabled but is not naturally accessible and looks very messy when you force it. What is true is that rio ceases to interpret keys specially other than backspace and return (curiously), and mouse events on the window are blindly sent to the application. It still doesn't sound like a lot of code, but may take some careful thought. Maybe that's a summary of Plan 9 methodology. :) That's why Rio seems like a more apropos starting point to me. :) It seems to me that the primary task of this hypothetical program would be providing /dev/draw to the programs running under it. Changing Rio's window layout code and adding a command protocol strikes me as less monolithic than combining window system duties with everything Acme already does. I also take issue with the statement Acme is a text editor, that never sounds right, no more than describing Emacs as a text editor. It's natural to use Acme as a text editor and it provides many more text-editing facilities than Rio does, but it is also natural to use it as a file manager, shell window provider, email client, etc, etc. It provides more than Rio and it does it all with tiling windows and without menus, but that's just style. Rio windows could seriously use a search function and one or two other text-editor facilities wouldn't go amiss. It doesn't seem natural to me that Acme does not allow graphical programs in it's windows. Fair enough. I just meant to say that Acme has a fairly focused design, which is oriented around the notion of windows containing text. If I wanted windows to potentially contain something other that text I'd reevaluate the design based on that criterion. And what I think I'd do would be as I described above, with the addition of a program that behaved like a single Acme window. FWIW, I don't think Emacs's design is perfect for a general application host either, although it's certainly a great program despite that. It's not like I'm some master software architect (and I see Rob Pike, who certainly has a more informed perspective on this than me, was thinking along the lines of Acme with graphics). I'm just saying my instinct is to decompose further and take as much out of the graphics/command host as possible. There are trade-offs either way, and maybe it would be more productive after all to mod Acme.
Re: [9fans] Why does Acme only show text?
jason.cat...@gmail.com (Jason Catena) writes: I've been wondering for years now why Acme (and Wily, which I used first) only display text files. It seems to me that the content of an Acme window could be anything: a picture, a postscript or PDF file, a star chart, a web page. Keeping with the spirit of small parts brought together, Acme could outsource the displaying of the content to another program, place its output in the Acme window, and operate on it by sending commands from the tag to the rendering program. Hi, I don't know anything about anything, but it seems to me that it's more productive to look at the question the other way around: why not modify Rio to tile windows like Acme does? Acme is a text editor, so it's no surprise that it handles text only. If you want tiled windows you can display arbitrary graphics in... well, there's already an API for graphics (and input). If you wrote up a general API for sending commands to windows, then you could write a window system that tiled windows and provided tags to execute commands from. I think that would be a very good thing, FWIW. Not that there aren't other issues to consider to make the system as usable as Acme, for example how the “applets” in this system are going to interoperate with each other.
Re: [9fans] plan 9 interface color ergonomy
eeke...@fastmail.fm (Ethan Grammatikidis) writes: The only pale colours on the South Downs are the haze-blued hills of the North Downs in the far distance, and the sky when it's overcast. The middle and foreground are occupied by very strong greens, except for some fields near harvest time which are likely to be other strong colours. Curiously I like looking at those green hills much better than anything green on my computer screen, even pictures of the same. I can't account for that. Likely because your monitor can't produce the right shades of green. There's the trick where you stare at a red spot on your monitor for a while then look at a gray area, and you'll see an afterimage in a shade of teal your monitor can't match. I suppose staring at a magenta spot would do much the same thing for green.
Re: [9fans] Acme without Flamage
[EMAIL PROTECTED] (sqweek) writes: On Thu, Aug 21, 2008 at 5:06 PM, Paul Donnelly [EMAIL PROTECTED] wrote: The bear is indentation, since to make it work out it's necessary to use a fixed-width font (something I'd rather not do) and adjust it by hand, which needs to happen more often and by greater degrees than in a language like C. The chief issues being: (list (list 'a 'b 'c) (list 1 2 3)) ; ^ ; These need to line up. ; These need to line up. ; V (let ((a 3) (b 4)) (+ a b)) ; ^ ; Should be two spaces or so. Huh. I always thought lisp had a couple of simple indentation rules, but after spending a little time on fmtsexp.c it has become apparent that the two spaces or so is a special case for let! Not sure I care to try and deal with such cases, but maybe it is still somewhat useful: http://sqweek.dnsdojo.org/plan9/fmtsexp.c -sqweek A fairly complete description of the rules is that forms line up with other forms at the same level of nesting (the binding forms in the LET or the arguments to LIST), but anything using BODY FOO in its lambda list (BODY collects trailing arguments into FOO) gets two-space indentation for the body. Indeed, this is the reason BODY exists. DEFMETHOD, though, needs to be specially recognized. LOOP has special needs. It's easier to indent with a program running in or communing with your Lisp, since there's no other way to know, short of reading every file in a project, whether a given macro uses BODY or not.
