Re: [9fans] a bit OT, programming style question
> Would there be any merit to breaking the shell apart into a number of > smaller programs? Looking at GNU bash as an example (though I know GNU > is probably one of the worst places to look for "Unix style"), It is my > understanding that one program handles many things, such as keyboard > bindings (which I believe in turn requires bash to read in cbreak or raw > or whatever and do it's own line editing), glob expansion, aliases, > history, syntax parsing, command execution, job control, etc. etc. > > IMO this results in a more complex program than necessary. Keyboard > bindings for example; why couldn't they be handled by a program that > just does keyboard bindings + line editing, and writes finalized lines > to the shell. This in turn could also allow bindings to be more easily > customized (such as binding autocomplete to Ctrl+F instead of tab) > depending on its implementation. fwiw, plan 9 handles key bindings in #κ. the shell hasn't a clue. rio (or acme) handles the editing. again, the shell hasn't a clue. and autocomplete? yup. same story. hapless rc hasn't a clue. rc is proof that ignorance is bliss. - erik
[9fans] a bit OT, programming style question
Not exactly related to Plan 9, but I don't know any other place full of people much smarter than myself who put value in the "Unix philosophy", and this idea is partially inspired by something I read about rio/rc. Would there be any merit to breaking the shell apart into a number of smaller programs? Looking at GNU bash as an example (though I know GNU is probably one of the worst places to look for "Unix style"), It is my understanding that one program handles many things, such as keyboard bindings (which I believe in turn requires bash to read in cbreak or raw or whatever and do it's own line editing), glob expansion, aliases, history, syntax parsing, command execution, job control, etc. etc. IMO this results in a more complex program than necessary. Keyboard bindings for example; why couldn't they be handled by a program that just does keyboard bindings + line editing, and writes finalized lines to the shell. This in turn could also allow bindings to be more easily customized (such as binding autocomplete to Ctrl+F instead of tab) depending on its implementation. Does this make sense? Is it more work than it's worth? Has it already been done (I know filename completion is handled by rio rather than rc for example)? Sorry if this is too off-topic for 9fans.
Re: [9fans] Virtual PC + Win64 = i/o errors
> fossil(#S/sdC0/fossil)...version...time... > command 30 > data f0caaaf8 limit f0cab8f8 dlen 8291 status 0 error 0 > lba 605536 -> 605536, count 16 -> 16 (16) > 0x00 0x06 0x6A 0x3D 0x09 0xE0 0x58 > 0x40: E307 0x42: Cx48: 00 > 0x4A: > fossil: diskWriteRaw failed: /dev/sdC0/fossil: score 0x5529: date Sun Apr > 5 > 06:37:19 PDT 2009 > part=data block 21801: i/o error many thanks to bhuntsman for having the patience to put up with my crappy code. it turns out that this is due to some poor timing on the part of virtual pc. virtual pc asserts an interrupt while the virtual controller is busy. then virtual pc refuses to reassert the interrupt, though the condition is not handled. this problem only hapens in pio mode. (it just occurs to me in writing this up that i had not considered that this might be an edge vs. level irq problem. and i'm ignorant enough of virtual pc to not even know if that's a stupid idea or not.) in any event, replacing the big tsleep with a loop of smaller tsleeps and checking for missed irqs seems to help pio commands. i also added a kernel variable to plan9.ini, sdXXdma=on. that might be overkill, but i was worried about fossil/venti needing to do a lot of disasterously slow i/o before cpurc/termrc gets a chance to run. i'd like to hear if anyone finds that this is necessary. one thing that is not yet done is a similar approach with packet io. i'd like to test it with actual hardware rather than guessing. what i've got so far is on sources in the contrib package quanstro/sd. i'd like to hear if this works (or doesn't) for anybody else. - erik
Re: [9fans] double click selects a word
2009/4/6 erik quanstrom : >> is there any good reason for a double click (in rio, sam, acme, ...) >> to select a word (probably) defined by sth. like >> /[a-zA-Z0-9_]+/ >> and not sth. white-space delimited instead? > > acme is for programming. the existing behavior is > much better for programming where strings are generally > delimited by ". rxvt-unicode has an option where you can have the selection grow on subsequent clicks. ie, double click selects a word, another click widens the selection to a whitespace seperated token, another click widens the selection to the whole line, then sentence/paragraph/etc/etc. I only ever used it for 5 minutes in between the feature being introduced and me working out how to turn it off, but it may be a way to get the best of both worlds, if awkwardly. -sqweek
Re: [9fans] Fwd: New Chip (SEAforth 40C18) - New Challenge
What a shame - tho there is a certain charm in owning a custom computer that can't be replicated. Hopefully there will be a firesale of stuff. There can't be many in the wild, mine is serial number 30 - what's your Jeff? brucee On Tue, Apr 7, 2009 at 4:00 AM, maht wrote: > > SeaForth is dead already > > http://colorforth.com/vTPL.htm > > http://colorforth.com/S40.htm > > > Bruce Ellis wrote: >> >> Please share your experience. >> >> http://groups.google.com/group/casella >> >> brucee >> >> On Thu, Mar 19, 2009 at 8:45 PM, Pavel Klinkovsky >> wrote: >> >>> >>> I am playing with the FORTHdrive (SEAforth-24 chip) for half a year. >>> We are testing it for a signal processing. >>> >>> I can confirm it is a wonderful chip. >>> But it needs a little bit different view to the programming. ;-) >>> >>> Pavel >>> >>> >>> >> >> >> > > >
Re: [9fans] typed sh (was: what features would you like in a shell?)
> but forcing compability seems worse. where are these decisions > centralized? how do you change decisions? can you override > these decisions (cast)? how does the output of, say, awk get > typed? The output of awk is a byte stream, same as its input. The same holds for any program. If you want to give it some other type then you need at least a casting mechanism. You probably also want a splitting mechanism, with a regular expression for the field separator. -- John Stalker School of Mathematics Trinity College Dublin tel +353 1 896 1983 fax +353 1 896 2282
Re: [9fans] Fwd: New Chip (SEAforth 40C18) - New Challenge
"It's just a flesh wound." On Apr 6, 2009, at 1:00 PM, maht wrote: SeaForth is dead already http://colorforth.com/vTPL.htm http://colorforth.com/S40.htm
Re: [9fans] Fwd: New Chip (SEAforth 40C18) - New Challenge
SeaForth is dead already http://colorforth.com/vTPL.htm http://colorforth.com/S40.htm Bruce Ellis wrote: Please share your experience. http://groups.google.com/group/casella brucee On Thu, Mar 19, 2009 at 8:45 PM, Pavel Klinkovsky wrote: I am playing with the FORTHdrive (SEAforth-24 chip) for half a year. We are testing it for a signal processing. I can confirm it is a wonderful chip. But it needs a little bit different view to the programming. ;-) Pavel
Re: [9fans] typed sh
> > but rather that using text streams makes > > A|B possible for any A and any B and any input. > What is this "text" of which you speak ? ASCII EBCDIC UTF-16 UTF-8 > ISO8859 etc. etc. etc. there's got to be a latin term parallel to reducto ad absurdum that means the opposite. make the problem gratituiously harder until no sensible statements can be made at all. or maybe it's the opposite of divide and conquer. accrete and be subjugated? ☺. by the way, tcs works fine for me. - erik
Re: [9fans] typed sh (was: what features would you like in a shell?)
On Mon, 06 Apr 2009 12:02:21 EDT erik quanstrom wrote:
> > If program A outputs numbers in big-endian order and B
> > expects input in little-endian order, A|B won't do the "right
> > thing".
>
> non-marshaled data considered harmful. film at 11. âº
In effect you are imposing a constraint (a type discipline).
Even if the programs themselves check such constraints, the
compatibility idea exists.
> what i said was not that A|B "makes sense" for all A and B
> and for any data but rather that using text streams makes
> A|B possible for any A and any B and any input. the output
> might not be useful, but that is a problem on a completely
> different semantic level, one that computers are usually no good at.
> alsi, i don't think that "type compatability" is sufficient
> to insure that the output "makes sense". what if A produces
> big-endian times in ms while B expects big-endian times in µs.
In effect you are saying that text streams allow nonsensical
pipelines as well as sensible ones and anything other than
text streams would imply giving up freedom to create sensible
pipelines as yet unthought of. No disagreement there but see
below.
> > Even for programs like wc have a concept of a
> > 'character' and if the prev prog. produces something else you
> > will be counting something meaningless.
>
> that's why plan 9 uses a single character set.
>
> but forcing compability seems worse. where are these decisions
> centralized? how do you change decisions? can you override
> these decisions (cast)? how does the output of, say, awk get
> typed?
I am not suggesting forcing anything; I am suggesting
experimenting with s-expr streams (in the context of "typed
sh" idea). I don't know if that buys you anything more or if
you give up any essential freedom. My guess is you'd build
something more scalable, more composable but I wouldn't
really know until it is tried. I imagine s-expr-{grep,awk}
would look quite different from {grep,awk}. May be you'd end
up with something like a Lisp machine.
Re: [9fans] typed sh
but rather that using text streams makes A|B possible for any A and any B and any input. What is this "text" of which you speak ? ASCII EBCDIC UTF-16 UTF-8 ISO8859 etc. etc. etc.
Re: [9fans] typed sh (was: what features would you like in a shell?)
> If program A outputs numbers in big-endian order and B > expects input in little-endian order, A|B won't do the "right > thing". non-marshaled data considered harmful. film at 11. ☺ what i said was not that A|B "makes sense" for all A and B and for any data but rather that using text streams makes A|B possible for any A and any B and any input. the output might not be useful, but that is a problem on a completely different semantic level, one that computers are usually no good at. alsi, i don't think that "type compatability" is sufficient to insure that the output "makes sense". what if A produces big-endian times in ms while B expects big-endian times in µs. > Even for programs like wc have a concept of a > 'character' and if the prev prog. produces something else you > will be counting something meaningless. that's why plan 9 uses a single character set. but forcing compability seems worse. where are these decisions centralized? how do you change decisions? can you override these decisions (cast)? how does the output of, say, awk get typed? - erik
Re: [9fans] typed sh (was: what features would you like in a shell?)
On Mon, 06 Apr 2009 07:09:47 EDT erik quanstrom wrote: > > Nitpick: the output type of one command and the input type of > > the next command in the pipeline has to match, not every > > command. > > i think this is wrong. there's no requirement > that the programs participating in a pipeline are compatable > at all; that's the beauty of pipes. If program A outputs numbers in big-endian order and B expects input in little-endian order, A|B won't do the "right thing". Even for programs like wc have a concept of a 'character' and if the prev prog. produces something else you will be counting something meaningless. Perhaps it is impossible to capture such type compatibility in anything but runtime IO routines but the concept exists. > you can do things > that were not envisioned at the time the programs were > written. That comes from composability. > > To go beyond simple char streams, one can for example build a > > s-expr pipeline: a stream of self identifying objects of a > > few types (chars, numbers, symbols, lists, vectors). In Q > > (from kx.com) over an IPC connection you can send strings, > > vectors, dictionaries, tables, or arbitray Q expressions. But > > there the model is more of a client/server. > > or ntfs where files are databases. not sure if streams > can look the same way. May be not. What I was getting at was that one can do a lot with a small number of IO types -- no need for "type profligacy"! [Unless your definition of profligacy is anything more than one.] The nice thing about s-expr is that you have a syntax for structured IO and its printer, parser are already written for you. Anyway, a typed sh would be an interesting experiment.
Re: [9fans] double click selects a word
ok then. :) r > one man's `usually' is another man's `never'. > it's one reason i use 9term on linux. > we probably both say ``what were they thinking??'' about > contrary effects.
Re: [9fans] double click selects a word
>Double clicking e.g. on 'text.txt' only selects 'text' or 'txt', while >one usually wants the whole. The same with absolute paths like >'/usr/ruda/lib/profile', etc. In linux a double-click usually >highlights the whole and usually this is what I want. one man's `usually' is another man's `never'. it's one reason i use 9term on linux. we probably both say ``what were they thinking??'' about contrary effects.
Re: [9fans] Virtual PC + Win64 = i/o errors
>do you have a way of compiling kernels? Sure do! The original copy of the same VM in question still runs fine on it's original host... Thanks much!! -Ben <>
Re: [9fans] way OT but shocking none the less
>...SGI... was purchased for just $25M by Rackable Systems I saw that. It's a sad day when such an icon of the computer industry gets bought by some company I've never heard of for a (relatively) piddly little sum... <>
Re: [9fans] Virtual PC + Win64 = i/o errors
> How exactly would I enable that on an already-installed VM? > Would a modified plan9.ini on a floppy > image do the trick? unfortunately, there's no *justusedma=1 plan9.ini option. that would be far to easy. i think you will need to modify the kernel to make progress. do you have a way of compiling kernels? or at least sticking a new kernel into 9fat? - erik
Re: [9fans] double click selects a word
> is there any good reason for a double click (in rio, sam, acme, ...) > to select a word (probably) defined by sth. like > /[a-zA-Z0-9_]+/ > and not sth. white-space delimited instead? > Double clicking e.g. on 'text.txt' only selects 'text' or 'txt', while > one usually wants the whole. The same with absolute paths like > '/usr/ruda/lib/profile', etc. In linux a double-click usually > highlights the whole and usually this is what I want. acme is for programming. the existing behavior is much better for programming where strings are generally delimited by ". - erik
[9fans] double click selects a word
Hello all is there any good reason for a double click (in rio, sam, acme, ...) to select a word (probably) defined by sth. like /[a-zA-Z0-9_]+/ and not sth. white-space delimited instead? Double clicking e.g. on 'text.txt' only selects 'text' or 'txt', while one usually wants the whole. The same with absolute paths like '/usr/ruda/lib/profile', etc. In linux a double-click usually highlights the whole and usually this is what I want. Would changing this behaviour break anything? Thanks Ruda
Re: [9fans] typed sh (was: what features would you like in a shell?)
> Nitpick: the output type of one command and the input type of > the next command in the pipeline has to match, not every > command. i think this is wrong. there's no requirement that the programs participating in a pipeline are compatable at all; that's the beauty of pipes. you can do things that were not envisioned at the time the programs were written. > To go beyond simple char streams, one can for example build a > s-expr pipeline: a stream of self identifying objects of a > few types (chars, numbers, symbols, lists, vectors). In Q > (from kx.com) over an IPC connection you can send strings, > vectors, dictionaries, tables, or arbitray Q expressions. But > there the model is more of a client/server. or ntfs where files are databases. not sure if streams can look the same way. - erik
[9fans] way OT but shocking none the less
On March 9th SGI was delisted from NASDAQ and on April 1st it was purchased for just $25M by Rackable Systems. Google will tell you more if you want. -Steve
