Re: [9fans] Raw Input Driver
i think it is a mistake to reintroduce single even streams let alone `callbacks'. it's easy enough to provide a device (say /dev/scancode) or a consctl mode that gives you the raw keyboard codes. we used the former in inferno, but the latter might be more logical since it's a different mode of the same device. either way, it worked fine in native inferno. (i can't remember how much was in the hosted versions, but i thought there was support for scan codes in windows and x11.) the ordering problem is misleading: you need timely response for interactive applications; it's a reasonably straightforward application of real-time programming. (by the way, if you're passing low-level things like that across lossy wireless networks, you're possibly not addressing the most relevant problem first.) the effects you're trying to synchronise are typically changes to data structures inside a program (including effects on the display), so that's where the synchronisation and interlocking should be. it's not as though the underlying devices weren't separate streams; they are, and it makes sense for the view of them to reflect that. it also makes it easier to add new input devices. i see already you've got 'k' and 'm', with surprisingly different content, but what about that fingerprint thingy to unlock the cheats? or perhaps more to the point the 'w' for wheel and 'p' for pedals? you'll never finish. I include these for people that haven't seen them before: http://swtch.com/~rsc/thread/cws.pdf http://herpolhode.com/rob/lec5.pdf
Re: [9fans] Raw Input Driver
in the slow-network situation the thing you're responding to on the display might not be accurate (eg, feedback delayed) which low-level input merging won't address. (actually, the only time i have trouble with acme is when the mouse positioning is marginal and it slips. otherwise, no, i don't find things typed in a window where i didn't intend them.) >it's people realtime not real realtime. the former is an example of the latter. real-time is meeting deadlines. deadlines are always real, if you've got them. there isn't a distinction based on speed (ie, 1 usec is "real", but 10ms is not). any hard/soft distinction is typically based on whether the program can miss a deadline, and the consequences.
Re: [9fans] I can not remember if I sent this or not: MIPS-64 (sort
for the RISC processors, it should be relatively straightforward to do the 64-bit variant of ?[acl], given an existing 32-bit one, and i'd be surprised if the applications also didn't work immediately since they run in 64-bit mode on amd64. (anyway, they required relatively little work, and the compiler can help, because only long long and pointers are 64-bit, unlike gcc.) the kernel work is another matter; the essential 64-bit changes have been made, but you still need to adapt or change the 32-bit MIPS kernel implementation to suit, and write drivers. what does the device use for graphics? i'm sure i've booted a 32-bit MIPS kernel on a potentially 64-bit MIPS processor. set a bit or two and it works; i don't think there was much more than that.
[9fans] request for more GSoC project suggestions
There are GSoC project suggestions at http://gsoc.cat-v.org/ideas/ but I think more are needed, and that it would be especially good to have a further set of useful but simpler and smaller projects. Projects need to be non-trivial for GSoC, but shouldn't be hard enough that many of us would shun them (or indeed, have shunned them). Based on my experience several years ago, I'd also look for projects that are modular, so that the set of deliverables can be extended or reduced depending how things go. That worked well for the projects I was involved with. The problem with ports of the system or device driver writing, in my experience, is that satisfying though they are, and as necessary as they might be, they are typically quite hard to supervise, and will usually be fairly difficult for relative novices. There is quite a bit to learn for most students just to get started and be productive in the programming environment, although 9vx does make that much easier. Application-level projects are typically easier to supervise because they don't need specialised equipment, and many more people on this list and elsewhere can help with plausible advice, and also help debug when students are stuck. (Advice will sometimes be contradictory, but that's not a bad lesson to learn, too.) It's quite hard to help when special hardware or kernel-level debugging is involved. Because quite a bit in Plan 9 (or Inferno/9vx/p9p etc) is done at user-level that is done at kernel-level in other systems, that shouldn't narrow the scope much. I wrote "application-level" not just "user-level" earlier because I thought it would be good to have some interesting applications of the system. Of course, I don't mean to preclude system-level things when students are especially keen on that (as indeed I was during my school and university years). I don't know where the best place to suggest or discuss them would be, but I thought this list would reach nearly everyone interested.
Re: [9fans] request for more GSoC project suggestions
>A modern cfront is nearly impossible. Templates make it hella-hard. really? how is that?
Re: [9fans] request for more GSoC project suggestions
>GSoC isn't entirely about completing a >project: the scope of a project may just be laying groundwork or a >foundation for a later project which involves the porting. Based on the experience last time, I think it is better to have simpler projects that are straightforward, self-contained (but modular), and can actually be completed. They should not require a lot of specialised support, or ask a student to do something we haven't normally attempted ourselves. I don't think those characteristics make a project less interesting or challenging, but they do help both with supervision and providing the satisfaction of actually having got something useful done by the end of the summer. The GSoC project is quite a public thing for a student (though last time a few seemed not to realise that), and I know that potential employers look at them.
Re: [9fans] Inferno slow on Plan 9?
>anything graphical draws painfully slowly >(several seconds to paint the white rectangle while Charon is starting). that isn't normal, except when using it through drawterm. it's even fine for me in 9vx on Linux.
Re: [9fans] GSOC: Drawterm for the iPhone
>The difference between a VNC client and drawterm (from a rules >perspective) is difficult to see i supposed the difference was /mnt/term
Re: [9fans] Inferno slow on Plan 9?
> FWIW, native graphics applications (including Hyperglenda) are very fast... hmm. Inferno is a native graphics application.
Re: [9fans] fossil caching venti errors
i've seen that just recently, but thought it might have been a failing (very old) drive, or a power failure beyond the endurance of the UPS. if neither of those are true in your case, it might be worth a deeper look. i also found there is a persistent problem that `check fix' won't fix. (since it's my principal file server at home, i can't easily investigate more until i can transfer the service to a new drive, leaving the old drive for experiment.)
Re: [9fans] GSOC: Drawterm for the iPhone
>Inferno plug-in for Safari? We had a go at a plug-in for Firefox in gsoc2007. These things (like drawterm, or a hosted Inferno port) are either very easy or very hard. "very easy" because if the environment is suitable, the portability interface for hosted Inferno is basically trivial: 513 FreeBSD/os.c 477 Irix/os.c 539 Linux/os.c 528 NetBSD/os.c 798 Nt/os.c 524 OpenBSD/os.c 422 Plan9/os.c 437 Solaris/os.c it needs a way to create shared-memory processes; a way for them to block, be made ready, and exit; a way for a process to allocate more shared memory; a way to interrupt a process when blocked or in a system call (Nt loses badly there); and some trivia. if graphics is needed to get a basic system running: 755 MacOSX/win.c 795 Nt/win.c 564 Plan9/win.c 1620 port/win-x11a.c (no prizes for spotting the outlier there) for the original IE plugin, it was more involved: 840 Nt/ie-os.c 224 Nt/ie-win.c although most of the code in ie-os.c is the same as os.c; the ie-win just connects to separate code that actually links to IE: 1242 emu.cpp 54 factory.cpp 697 inferno.cpp 59 main.cpp (a lot of that is automatically generated; and there are now easier ways to do it, by the way) next to MacOSX, that's probably the biggest example of "hard". the firefox plug-in was potentially "hard" (because the people that define browser plug-in interfaces aren't good at defining operating systems) and became "very hard" because its ways are not our ways, and by the time the gsoc student realised that, it was too late. several people had earlier bounced off a plug-in for netscape. (i don't know the details because i wasn't involved.) with both firefox and netscape (and no doubt with Safari) it could well be that more knowledge or more effort would have it end up in the "fairly easy" or "not to hard" category, but so far that hasn't happened. obviously i'm leading up to say that perhaps Safari is much nicer to us than all the other browsers, but given its environment, i wouldn't start out with that assumption, especially a second time for GSoC. with both the Safari and some other suggestions, i think i'd be a little happier if more of the ground work had been done during the last few months and GSoC were completing the tasks or even exploring their application, not setting out.
Re: [9fans] segfree() - more details?
>in segattach(2) suggests that there is some mechanism to associate >disk file portions with memory segments (that being what Unix's MMAP >does, roughly), not really: it will read initial text and data from an image, but that's it. apparently if you segfree your data space it will reinitialise it from the image, effectively resetting it, but i'd be surprised if anything uses that.
Re: [9fans] segfree() - more details?
>OK, I believe you, but you're not telling me _how_ the "initial text >and data from an image" is specified. And that is really the bit I >want to know about :-) it's set by exec.
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] a bit OT, programming style question
set | wc -l 8047 well. certainly if you leave bash or even dash set as the shell, a terminal or 9term window takes ages on ubuntu. set the shell to p9p rc, 9term starts straight away and you're a better person for it.
Re: [9fans] fossil 'halt' command?
i'd have thought that soft updates ensure consistency, but a halt command ensures that all the changes are actually written.
Re: [9fans] security questions
>Conceptually, anyway. Why is everyone always so hell-bent on hair-splitting? :P probably the other options suggested by the careers advisor were theology and hairdressing.
Re: [9fans] Plan9 - the next 20 years
this discussion of checkpoint/restart reminds me of a hint i was given years ago: if you wanted to break into a system, attack through the checkpoint/restart system. i won a jug of beer for my subsequent successful attack which involved patching the disc offset for an open file in a copy of the Slave Service Area saved by the checkpoint; with the offset patched to zero, the newly restored process could read the file and dump the users and passwords conveniently stored in the clear at the start of the system area of the system disc. the hard bit was writing the code to dump the data in a tidy way.
Re: [9fans] Plan9 - the next 20 years
>For speed of light in fibre optic 30ms is about 8000km (New York to San >Francisco and back) >in that 30ms a 3.2Ghz P4 could do 292 million instructions i think that's just enough to get to dbus and back.
Re: [9fans] (no subject)
lcc is nothing like as hard to compile as gcc (which has got worse, much worse, over the years). funnily enough, my gcc bootstrap compilation is still going (on a multi-core linux machine). it started over an hour ago. bizarre.
Re: [9fans] P9P on Lemote Yeeloong
>I will be able to adjust the Plan 9 kernel sources to >compile under GCC to bootstrap Plan 9 on the Yeeloong. No doubt there >will be question that this list will be asked to assist with :-) since the hard part is writing drivers, just do a normal port using v[acl]. not fussing about with all the other things that will otherwise go wrong will allow you more time to write those drivers.
Re: [9fans] P9P on Lemote Yeeloong
>So you are a bit out of luck here on MIPS [for 64-bit compilers] 64-bit compilers for 64-bit RISC architectures are fairly easy, at least in the sense that we know what to do. amd64 wasn't quite as easy because it was non-RISC (and as weird as x86), had a completely different FP model, and was the first full 64-bit port, requiring some decisions about the model and (in the end) tweaks to /sys/src/cmd/cc. (alpha was a 64-bit processor but ran with 32-bit pointers.) that's all done. based on that, power64 was mostly done in about a week. it hasn't been much used since then, and might need a bit more work, but that will be small. i wouldn't expect much more is required for 64-bit mips.
Re: [9fans] Interview about Plan 9
my home and work mailboxes were overrun by spam, until quite recently, thousands of messages, so it might either have been overlooked or shunted into my spam box because of the character set choice. anyway, try again, just for fun at charles.fors...@gmail.com
Re: [9fans] Interview about Plan 9
> it might have been ... shunted into my spam box because of the character set > choice. and that's indeed where i found it, so i've also got the questions now.
[9fans] fossil
anyone else ever seen things like this from fossil? it seems a bit wayward... # on the fossil console, after `disk full' returned in errors: main: df main: 10,046,783,488 used + 35,180,756,598,784 free = 6,431,293,440 (156% used) main: snapclean 3600 main: df main: 3,000,909,824 used + 3,430,383,616 free = 6,431,293,440 (46% used) the server goes into `disk full' state. i think one underlying problem is that i haven't applied the change to remove floating-point calculations from fossil's timer routine, and thus at least sometimes it can never quite get to the right time to do the snapclean itself. even so, i've only seen this effect since i updated fossil in january after several years. i've had periodic `disk full' problems since then.
Re: [9fans] plan 9 regexp
>Of course, it broke down somewhat because the language of strings >necessarily all that well suited to describing trees whose elements >come from a completely different domain, but I still think the idea >has some merit. This was in 2003; I gather things like that are now >beginning to become somewhat common elsewhere. there are several varieties of tree automata that are better suited to working with trees.
Re: [9fans] Inferno wiki
i suspect it would ultimately make more sense to put this at inferno-os.something (and we've got a few)--- Begin Message --- Hi! I've brought up a wiki for Inferno, at http://inferno.makesad.us (tcp!inferno.makesad.us!wiki for Acme users). Its running wikifs on Inferno, appropriately enough. I'm importing content from the old canto.hopto.org Inferno wiki, as we speak. In the next few days, I should have all of it imported. Thanks to caerwyn for running the old wiki and helping me get this one running. Hopefully it'll be useful for people; come on over and contribute! -- vs--- End Message ---
Re: [9fans] simple question: multiple rename
>The Evolution of Conciousness in the Breakdown of the Bicameral Mind.doc it's not worth worrying about for that book (i think it's `Origin' not `Evolution') i am astounded it keeps resurfacing.
Re: [9fans] Different representations of the same
>The only drawback so far seems to be the fact that if one >needs flexibility, then every file becomes a subdirectory. >Not that it is scary or anything, but it smells too much >of resource forks (or may be I'm just too easily scared). it's the other way round: they ought to have represented collections of related data and metadata using directories instead of inventing rubbish like resource forks.
Re: [9fans] Guide to using Acme effectively?
>I think Tog's conclusions (the single set of studies put forth whenever this >thing >comes up) are poorly made ... it turns out that there is rather older work that supports much the same conclusion, which i probably saw mentioned in HCI Remixed, since that's one i've read recently.
Re: [9fans] Guide to using Acme effectively?
>I'm just not sure time is the right thing to measure. it wasn't just time, but included other aspects such as accuracy. ``but i want to be slow AND, overall, inaccurate!''
Re: [9fans] Guide to using Acme effectively?
>Also, you don't have the scrollwheel buckling and rolling around as you try to >mid-click. i found that with nearly all the ones i tried, but the small Gigaware wireless optical notebook mouse cat. number 26-284 from Radio Shack has a scrollwheel with enough resistance that it doesn't do that, and works well in acme. don't confuse that mouse with another larger Gigaware optical wireless mouse (different number) that hasn't got the same property!
Re: [9fans] Google finally announces their lightweight OS
"The software architecture is simple — Google Chrome running within a new windowing system on top of a Linux kernel." although most of the technology news reports i've seen today appear not to have read the googleblog (or at least, not that far into it).
[9fans] restricted remote address
h% 9fs sources srv tcp!sources.cs.bell-labs.com: mount failed: restricted remote address virgin media changed my IP address overnight. reverse lookup gives a subdomain of virginmedia.com, but presumably it's the IP address that sources is restricting?
Re: [9fans] Why does Acme only show text?
Oberon takes advantage of a structured text representation where both the interpretation and graphic representation of particular elements is provided by Oberon modules. One demonstration had a little animated cartoon character that could be cut and pasted into another frame, where it continued to move. Acme exploits one chunk of identical text being the same as any other, given particular meaning by the button used to select it and its frame or tag context (the context including a program sitting behind the frame). It's probably relatively easy to give over Acme frames to a program that draws, but is there a good way of providing something more than that, giving more of the `structural support' that Acme provides to text-oriented applications? Is it time to consider a possible role for structured text along Oberon lines? One of the reasons for porting Acme to Inferno originally was to try to explore those things in a slightly more flexible environment, but it didn't happen, partly for lack of time.
Re: [9fans] i/o on a hangup channel asymmetry
>perhaps i've been asleep at the swtch, but i don't recall seing writes >on closed channels terminate programs with a note. sys: write on closed pipe mainly to kill off a pipeline when the thing at the end has finished. i think that might be the only instance where a note is used.
Re: [9fans] new usb stack and implicit timeouts
disconnecting a usb device should result (eventually) in a suitable status on the relevant hub, and thus shouldn't require a timeout to get an error back to the user. devices that don't respond because they are in a bad state can be unplugged (if removeable). built-in devices on built-in hubs that get into a bad state probably need a usb or system reset, but some higher-level application (or human) timeout can interrupt a too-long delayed request. so far, i'd argue that a per-request timeout wasn't needed.
Re: [9fans] i/o on a hangup channel asymmetry
>not for network connections? i think pipe is the only case, and even that is suppressed for pipes that carry 9p, after mounting.
Re: [9fans] i/o on a hangup channel asymmetry
you don't really want to get "write error" printed from every process in a pipe line such as slowly-compute-big-file | dosomemore | andyetmore | sed -n '/something/;p;q' or even slowly-compute-big-file | badusageofsomething where the latter prints a "usage" message and quits. you want to make sure the previous commands in the pipeline stop, right away. (they might be in a script. they might even be costing money.) actually, if i were looking for something exceptional to fix, i'd get linux and the BSDs to stop thinking they still need character and block "special files" as special types of files in a physical file system, to represent devices.--- Begin Message --- On Jul 19, 2009, at 2:55 PM, Charles Forsyth wrote: not for network connections? i think pipe is the only case, and even that is suppressed for pipes that carry 9p, after mounting. one last kick of a dead horse: see that's exactly what I'm talking about -- all these exceptions and for what? I'm pretty sure if we change the devpipe today not to send a note nobody would even notice... Thanks, Roman.--- End Message ---
Re: [9fans] dcp - a deep copy script, better than dircp
>Before I say anythign daft, what's '+'? It does not appear to be special on my >system. it's interpreted by mkfs in its proto file to mean all the substructure of a directory. see mkfs(8).
Re: [9fans] i/o on a hangup channel asymmetry
>pipe would return -1 (and set a error condition) and the >applications were paying attention (and I'm pretty sure all >applications on Plan 9 would do a reasonable thing when >presented with -1 from a write). they only notice when the write occurs. suppose that takes several minutes of computation.
Re: [9fans] i/o on a hangup channel asymmetry
you're right. i wasn't thinking correctly.--- Begin Message --- On Mon, 2009-07-20 at 10:53 +0100, Charles Forsyth wrote: > >pipe would return -1 (and set a error condition) and the > >applications were paying attention (and I'm pretty sure all > >applications on Plan 9 would do a reasonable thing when > >presented with -1 from a write). > > they only notice when the write occurs. suppose that takes > several minutes of computation. Just to correct the statement of fact: same as true for the note -- it only gets sent when the write occurs. Thus -- there's no difference, really. Thanks, Roman. --- End Message ---
Re: [9fans] Does "as little software as possible" include a modern browser?
>if there is no real browser for the platform, >how will Plan 9 participate in the "cloud computing" (r)evolution? not using a browser. careful now. down with this sort of thing!
Re: [9fans] Woes of New Language Support
>the unicode proposal says that matches depend on (re, locale, input). >not just (re, input). i would think that is not acceptable. it's not just the unicode people. shell file name matching takes locale into account which often makes it case-independent (even with case-dependent file systems). i hate them all.
Re: [9fans] [limbo] I tried keyring, but it was the wrong number
sorry. i accidentally deleted the first line of that reply: it will be mpdiv via mpmod via mpexp via rsaencrypt, with a zero modulus (which suggests the key wasn't unpacked correctly). but if you make an entry in the bugs list ... etc
Re: [9fans] [limbo] I tried keyring, but it was the wrong number
if you make an entry in the bugs list at inferno-os.googlecode.com i'll look at it shortly.
Re: [9fans] Race condition in /sys/src/9/pc/trap.c?
just stop processes with s->ref > 1 from freeing parts of s with ibrk. it's not as if anything ever does in practice.
Re: [9fans] [limbo] I tried keyring, but it was the wrong number
>with a zero modulus (which suggests the key wasn't unpacked correctly). my deliberate mistake (it won't be using rsaencrypt but rsadecrypt) happened to highlight the actual problem, which is that strtosk shouldn't accept a string that looks to me (if not to it) like a public key not a private/secret one, producing something with plenty of zero mpint potential divisors. b00f!
Re: [9fans] Race condition in /sys/src/9/pc/trap.c?
this resulted in a little side discussion. to save someone else from having to break a strong oath about 9fans, i'll sum it up. the existing code handles this situation. when several processes share a segment, and any one of them decides to shrink the segment, all the processes must see the change before the pages are made available for re-use. any one of them could have any of those pages currently in their mmu state. and any must be removed from the mmu state local to the process, to ensure that no further access to the pages is possible before they are freed. the critical point is that it's irrelevant whether traps or syscalls are involved: ordinary store instructions are clearly bad enough. thus /sys/src/9/port/segment.c:/^mfreeseg contains (with s locked) /* flush this seg in all other processes */ if(s->ref > 1) procflushseg(s); and procflushseg finds all processes that share s, sets them all up to flush their mmu states, and also sets any processor running such a process to flush its state (that's picked up by a clock interrupt). procflushseg will not proceed until all processes and processors that might need to flush state have done so. (s remains locked throughout.) after the flush, no process or processor can have a reference to any of the pages in its mmu state. it is safe to free them, which mfreeseg does. now, a process might still be executing a system call or some other trap that might refer to that segment, to an address that's now been removed by another process. to access the memory, it must ultimately issue a load or a store instruction (even for syscalls, such as read or write). that instruction will trap, because as described above there is no longer a valid mmu mapping for that address within the process. normally, the trap will find the right page in the software mmu structures and install the map. in this case, however, it can't find the address, so it will raise an exception in the process (ie, send a note). (all such searches are done with the segment properly locked.)--- Begin Message --- just stop processes with s->ref > 1 from freeing parts of s with ibrk. it's not as if anything ever does in practice.--- End Message ---
Re: [9fans] Race condition in /sys/src/9/pc/trap.c?
>but my testcase crashes a uniprocessor system, so here is no >waiting for mmuflushes on other processors going on. it ensures mmuflushes in all other processes (sharing that segment) as well. in fact, the crash you describe just emphasises that point: the page reference no longer exists, hence the fault. the problem (which frankly doesn't bother me) is that fault386 is being overly cautious in assuming that a page fault that occurs in system mode but can't map a page successfully is necessarily a kernel bug: that's not true. it could just note the process instead. (it doesn't bother me because since unix days i've seen less than a handful of programs that SHRINK their existing data segments, and i think that's the only case that can cause the panic you're seeing.)
Re: [9fans] Race condition in /sys/src/9/pc/trap.c?
you can get similar effects by remapping things. i meant that it isn't likely to happen by accident, so am i bovvered? fault386 needs to be fixed mainly by or for people running a shared cpu server with hostile users (ie, students). for the rest of us it might be more useful to have the panic to prevent real kernel bugs (ie, just bad pointers in device driver implementations) from postnoting a process instead of stopping the system. having said that, it could be argued that even in that case a postnote to the invoking process would allow the rest of the system to run and `might not' mean that the broken driver has wrecked other data structures outside it in kernel memory.--- Begin Message --- > it ensures mmuflushes in all other processes (sharing that segment) as well. > in fact, the crash you describe just emphasises that point: > the page reference no longer exists, hence the fault. > > the problem (which frankly doesn't bother me) is that fault386 > is being overly cautious in assuming that a page fault that occurs > in system mode but can't map a page successfully is necessarily a kernel bug: > that's not true. it could just note the process instead. > (it doesn't bother me because since unix days i've seen less than a handful > of programs that SHRINK their existing data segments, and i think that's the > only case that can cause the panic you're seeing.) if this case is really not important, would it make sense to disallow shrinking segments? it might be worth it just to be able to define Eshrinkage. - erik--- End Message ---
Re: [9fans] Kernel crash bug
>maybe the kernel should use something like this to validate pointers >to null terminated strings? it could just call vmemchr correctly or vmemchr could be a touch more careful
Re: [9fans] another dual-atom motherboard: jetway nc92-330
>the extra 4 pins are not required, but >they do give one extra flexability in selecting a power >supply. the original uniprocessor intel atom board required the extra 4 pin connection to be made (or bodged).
Re: [9fans] Unexpected 8c warning message
>8c complains, there is **certainly** an algorithm error somewhere for certainties, (such as many type errors) 8c unlike some others generates fatal errors, not warnings. it's a warning because it can't be absolutely sure that you don't know what you're doing, or that you aren't particularly cunning (or obscure).
Re: [9fans] yet another installation guide
>Soldering iron (nice old temperature controlled Weller) breaks down (never >heard of)! that's amazing.
Re: [9fans] audio standards -- too many to choose from
> ... Inferno's implementation of mp3 in the kernel device file ... it does?
Re: [9fans] audio standards -- too many to choose from
>we have scsi and ata. >and that's enough for me. that's more than enough for me.
Re: [9fans] audio standards -- too many to choose from
>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, ...
Re: [9fans] audio standards -- too many to choose from
sorry, i did realise. i'm afraid i just couldn't resist slightly misquoting Flanders and Swann's `Song of Reproduction' (High Fidelity). http://www.amazon.com/Complete-Flanders-Swann-Georges-Brassens/dp/B06T4S/ref=pd_sim_b_1--- Begin Message --- Charles Forsyth wrote: >> 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, ... So if i instead said 24...@44.1khz would it make any difference on my argument? please. You are right, however 192kHz means the DAC bandwidth could support 4x 48kHz buffers, which is what it's used for. --- End Message ---
Re: [9fans] make slides in plan 9
i use html, then any browser will do, even ie6 for most things. i use an rc script and awk to take an outline format such as - burble - more burble - even more burble with some other conventions to allow embedded code fragments. it's obviously easy to link to other things to allow diversions and connect to expanded information on the rare instances that anyone is awake enough to ask about them. the same script can generate a summary of the slides in troff as handouts. since there are drawbacks to the powerpoint approach, even without cruft like clip art and transitions, i often simply write ordinary troff (-ms or -mpm), and then i can use pic, grap, eqn, tbl as needed.
Re: [9fans] Recursive structural expressions?
qed allowed naming of regular expressions using `e' and their recursive invocation using \E, with results suggested earlier. http://cm.bell-labs.com/cm/cs/who/dmr/qedman.html http://cm.bell-labs.com/cm/cs/who/dmr/qedman.pdf ``It should be noted that the ability to define regular expressions recursively makes the term "regular expression" a misnomer: it is not hard to see that expressions can be constructed to match exactly the members of any given context-free language.''
Re: [9fans] new sources
>How about we convince the mailing list software to stop >inserting Reply-To headers. please don't. it's a list, with reply to the list.
Re: [9fans] "Blocks" in C
>IMHO, I'd say C is C and I think it's better to leave >it as it is. If you want a language with extra features you can >probably find one. the blocks thing only works (apparently) by having two (visible) classes of function pointers. ugh. `clang' is apparently not just the name of the frontend but the sound it makes (cf. the `cricket bat' speech in Stoppard's `The Real Thing'). automatic memory management is more fundamental for application programming. i agree with nemo. every time i happen to see nick stoughton i suggest they should just STOP changing C. (it doesn't work. i'll probably stop suggesting it.) one thing that gets me is that i've had people fulminate about the few minor changes in Plan 9's C compilers, because `they are not standard', yet unlike the endless tinkering in the gcc (and now Apple) world they were made by someone who at least had some close connection with the original language (not to mention a sense of style).
Re: [9fans] "Blocks" in C
>Perhaps he [me?] can further elaborate. i certainly did not have comeau in mind.
Re: [9fans] problems when hwaccel off or in inferno
there's a bug in the control of the software cursor in plan 9, probably when loadimage is used. it can leave what my children call chicken tracks, as it updates the cursor. it shows up in at least vnc and inferno because they use the equivalent of loadimage on the screen to update their displays.
Re: [9fans] porting help please (gcc void pointer handling)
>is it valid just to add to make the porting non-destructive? >#ifdef Plan9 >#define void unsigned char >#endif not really, as a global define. it's legal to write Type *t; t = malloc(sizeof(*t)); and that won't work unless malloc returns a real void* (only void* is compatible with all types of data pointer). it's similar for void* as a formal parameter; it accepts any type of data pointer as an actual parameter, but uchar* will not.
Re: [9fans] nice quote
if people would leave off moaning about moaning, we'd clear the space for more moaning about lisp although the former did have the advantage that the messages were shorter and didn't quote the bulk of all previous messages. anyone written any software recently? at this point it probably doesn't matter whether it was for plan 9 or not.
Re: [9fans] porting help please (gcc void pointer handling)
you might consider using a sed script to change the CT_.* style #defines, and run the sed script from the mkfile/makefile, so although the porting is (in your sense) `destructive' it's done by changing the original source file automatically. you could sed (say) from a .h.orig to a .h using a single rule.
Re: [9fans] porting help please (gcc void pointer handling)
>I am trying to port nhc98 the bytecode haskell compiler. i see. that makes it much harder to try my suggestion. i wonder why the compiler doesn't generate char* (or unsigned char*) for those defines? perhaps directly changing that would be better. if it needed a void* result then #define CT_v249 ((void*)((char*)startLabel+464)) would make the addition portable (between byte-oriented machines, but that was anyway assumed) and leave the result void*
Re: [9fans] "Blocks" in C
we'd have been much better off if Apple had instead spent the time and effort writing a decent iTunes, or opening their platform interfaces enough that someone else could do it (and on Linux, not just Mac or Windows).
Re: [9fans] "Blocks" in C
> i mentioned that the pool library can act as a big > kernel lock a few weeks ago. i don't know if anyone > has thoughts on how to deal with this. it isn't really a `big kernel lock' in the linux sense. the big kernel lock was the device by which operating systems written with only a uniprocessor in mind were made to `work' on a multiprocessor. typically, the equivalent of qlock and qunlock of a single global lock were placed at strategic points to bracket (say) every system call that affected non-trivial state. then the developers started splitting the lock region. it's easier than thinking. processes would queue for use of the kernel (but they'd go to sleep, not spin). for the pool library it's a spin lock, which is intended to protect small blocks of code. really the effects of collision should not be as bad as they are. although it's probably good especially with many cores to have some processor-local allocation of cpu and memory resources without interlock, or make the main storage pool locks more refined, or using wait-free cleverness, and indeed there are schemes to do all those things, the big initial problem with the pool library is that it's remarkably slow. in fact, that's been my experience with every tree-based allocator i've had to use, so it's not just that pool is replete with error checking. an alternative allocator that uses quickfit on top of a variant of the simple allocator in kernighan and ritchie is roughly 30 times faster on some malloc-thrashing tests (i'm just remembering that from tests i did last year, so i might have the number wrong, but it's substantial). for a reasonable choice of block quantum it also has better fragmentation properties, which is amusing since that's supposed to be one of the advantages of the tree-based allocators.
Re: [9fans] Mounting Plan9 fs on Inferno
it does work, and you can authenticate to plan 9 using Inferno's factotum (or, if you're running Inferno on Plan 9, using Plan 9's factotum within Inferno). the "bad fversion conversion ..." suggests that whatever you're running with aux/listen1 is spitting out something else before starting the protocol. plan 9's exportfs, for instance, has an extra textual `protocol'. if the Plan 9 service is exportfs, you might be able to use Inferno's import(4) to approximate that for you.
Re: [9fans] inferno from hg does not build out of the box
>committing a ".emptydir" file in each directory would be easier. why bother making it .emptydir (ie, with the dot) when that makes it invisible on broken host systems (with the ls bug) but visible under inferno itself. more important, and the reason i didn't do that, if it's visible under inferno itself, it breaks the point of some of those directories being there, and empty: you're supposed to be able to enumerate services by listing names subsequently bound to them.
Re: [9fans] inferno from hg does not build out of the box
>Perhaps a rule in the mkfile which would check/create empty directories? perhaps. there are several alternatives, and no doubt i'll switch to use a mix as appropriate. the annoying thing is that previously, whether through tar, replica, or even subversion, a suitable skeleton would appear without having yet more procedures to know and to document. now some poxy but popular `control system' has to have its say.
Re: [9fans] mishandling empty lists - let's fix it
> cat - cat /fd/0
Re: [9fans] iwp9: getting from Atlanta to Athens
>[rog] i'd be up for driving, assuming my UK driving license is sufficient. >[bill]License should be no problem with any of the major rental agencies. i've never had any trouble, but note that with a UK licence, if you've got a photocard, you must also produce the paper part: the `licence' is actually the pair of them together. that's true in the UK, but US agencies also require it, at least the major ones. >>>at the end of the carpool lane (when you >>> see the big fry's electronics), head down 316 ... i suspect there would first be a stop at fry's if it's not too late.
Re: [9fans] IWP9 hack session
>Or is there a way via the usb port to get serial console (does not >seem so from block diagram) yes. the mini-usb connector is, in fact, a reverse rs232-usb device that puts the internal rs232 console on that external connector on usb. you can just plug it in to a usb connection on another machine, configure it as an rs232 device (on usb) and you're talking to the uboot console. (i think there's another usb device on the same connector that provides jtag.) the other, standard big usb connector is the device's own USB. thoughtful.
Re: [9fans] IWP9 hack session
>I'll try to get an european version here. the device itself still has a US style plug attached to it. the only difference is that it comes with one of those power leads with a figure-8 connector and a plug (UK in my case but presumably euro in yours). to use that, you need to unscrew the US style plug, and you'll find a figure-8 socket in there somewhere. in practice, it's just as easy to use a US-(UK|Euro) adapter plug. the internal power supply handles 120-240. (but i'd check it when you get it, just in case there's a variant that's 120-only, but i'd be surprised. well, a little surprised.)
Re: [9fans] iwp9: getting from Atlanta to Athens
this ought to have been better organised so we could all set off from the airport at once http://www.youtube.com/watch?v=YHa_jqxnn4o--- Begin Message --- I'll be in around 9pm or so the 20th, if I can give anyone a ride I will. ron--- End Message ---
Re: [9fans] iwp9: getting from Atlanta to Athens
International arrivals at ATL might be unprepared for the unusual procedure after immigration, baggage reclaim and customs. Having passed through customs, you reach a fork in the path with a choice between Atlanta and Transit Passengers. (I think it was left for Atlanta.) Then there's an extra surprise: you have to pass through security again! You have to put your checked bags (just retrieved from baggage reclaim) on a conveyor belt that takes them through the wall. You'll see them again at another baggage reclaim later. Because there's a lot of shouting and ordering about at this point, and it probably all came as a bit of a surprise, you might make two mistakes: don't put any bags you had on board on the belt (it will cause the system to stop until they track you down); before you sling your checked bags onto the belt, be sure to put any liquids you acquired from duty free into the bags. You can't take them through security! (They might jokingly suggest you can alternatively drink them there, but I suspect they won't let you do that.) What's going on? You're leaving international arrivals by entering the airport on the secure side for departures, because of construction. You'll take the transit train to the central baggage reclaim for domestic arrivals, where you can collect your bags once more.
Re: [9fans] Two suggestions for ape (was: egrep for Plan9)
it's /rc/bin/ape/ls that would change, not Plan 9's ls-proper. what does autoconf do with the `inode number'?
Re: [9fans] double wakeup disallowed
it isn't protecting against double wakeups, but instead detects a bug in the code. there's an invariant that the rendez and the process point to each other while the process is asleep. wakeup checks that invariant. there are three primitives (sleep, wakeup and note) and at different times in the past at least one of them has been wrong; it's wise to check the invariant. >and only disallows waking up a process that's not >sleeping or sleeping on another Rendez. but wakeup doesn't wakeup a particular process, it wakes up exactly the process sleeping on the given Rendez, so the situation can't arise.
Re: [9fans] double wakeup disallowed
>however the invarient that there is exactly one wakeup for >every sleep requires some careful accounting that >can be equally error prone.care not to double-interrupt. if a process p sleeps on r for condition f, and there are two wakeup(r), only the first wakeup does anything because by the time of the second, r doesn't refer to p any more. were you wanting r to retain memory of p so the second wakeup would ... presumably still not do anything? (because p wouldn't be in the right state.) if so, i don't see what you've gained. i must be missing something.
Re: [9fans] Scanners
>If Plan9 can 'plumb' a remote sound card, (a questionable example long >publicized) I'm sure it can do so with a mouse. it isn't plumbing, but export/import, and it's useful. i had a usable sound system on my r3000 indigo, but my PC had none. on the pc, i imported the indigo's /dev and played sounds that way. i could imagine uses even a continent away (alarm system imports remote /dev and announces trouble). next door might be more useful.
Re: [9fans] Scanners
> I don't know how hideously complicated it would be, to implement a module > interface that would support loading linux modules into whatever other OS > such as Plan 9. only as hideously complicated as the linux kernel interfaces might be, but sadly those are indeed hideously complicated. try tracing the source of a driver you care about (because that's the only way to help guess how the undocumented hardware might work). good luck. see you later. (much later.)
Re: [9fans] Scanners
>Reality is that the rate of introduction/change of hardware/silicon is too >fast >for any small - or even 'medium sized' team (FreeBSD for example) to keep up >with on their own... and that gap is widening. that's not usually the biggest problem, although it's true that lack of time can be a problem: it's the lack of (reasonably) accurate documentation (independent of the source of some convoluted driver written by someone who clearly doesn't do it for fun). in the days when you could download a register-level description from such-and-such a manufacturer, given enough incentive it was only a matter of time and effort to drive the chip. now, a fairly non-trivial psychic ability is needed too. i don't know why i'm replying to these. this topic has been re-hashed periodically, and if anyone is keen actually to implement any of these helpful bits of advice to test their ideas, i'm sure iwp9 would be a great venue to show the results.
Re: [9fans] SSH server
>If it is, there's a depth of cleverness in the new Plan 9 >security model that I had missed until now, namely the elimination of >the intermediate "superuser" step required by the Unix paradigm. indeed that's the point.
Re: [9fans] compiler double bug.
the fppc points to the offending instruction.
Re: [9fans] compiler double bug.
g = 4215866817.; x = (int)g; does g fit in (int)? (no, (int) is 32 bit signed.) if (int) is (uint) it will fit, and not trap.
Re: [9fans] compiler double bug.
#include
#include
void
main(void)
{
double g = 4215866817.;
print("%d\n", (unsigned int)g);
print("%d\n", (unsigned int)g);
exits("");
}
8c r.c
8l r.8
./8.out
-79100479
-79100479
no trap. it generates different code.
(obviously the %d should be %ud in this case, giving
doppio% 8.out
4215866817
4215866817
which looks like the right answer
the cast must be to an unsigned integer.
otherwise the resulting range is signed,
and that's more limited
Re: [9fans] compiler double bug.
i hadn't noticed the changed example. it's removing the cast, which probably isn't right, although in that particular case it's probably better that it should trap (because the result is wrong). what is the actual code in awk that's equivalent to that sequence?
Re: [9fans] compiler double bug.
those fixes really don't seem right to me. the problem is in getival or its callers. somewhere along the way, ULONG_MAX is converted to double and then back to int (directly or indirectly). that yields a trap. now, in the case int x; x = (uint)d; the compiler is wrong to eliminate the cast, but then again, if x isn't uint that's not going to work properly anyway (since x will go negative for big enough values of d). what's getival? there isn't one in the awk copies i can see.
Re: [9fans] compiler double bug.
oh! getival is yours? but it's in the changes on the - lines not the + lines. the diffs have crossed the equator! i think i understand now. so the original had statements such as: wc = (int)getfval(x); and for excessive values in x (that couldn't be represented as an int) there was a trap. that seems consistent with the behaviour defined below: 6.3.1.4 Real floating and integer When a finite value of real floating type is converted to integer type other than _Bool, the fractional part is discarded (i.e., the value is truncated toward zero). If the value of the integral part cannot be represented by the integer type, the behavior is undefined.[footnote 41] [41] The remaindering operation performed when a value of integer type is converted to unsigned type need not be performed when a value of real floating type is converted to unsigned type. Thus, the range of portable real floating values is (−1, Utype_MAX+1). so getival returning uint or ulong (or unsigned something-big-enough) avoids the problem and seems fine to me. there is, however, a bug in the compiler elsewhere, in that a suitable (uint) cast in a direct assignment int x = (uint)doubleval; is (apparently) discarded by the compiler, and it shouldn't be. that shouldn't affect your getival cases, though.
Re: [9fans] compiler double bug.
>the implicit conversion on return also appears botched.
both this:
uint
fun(void)
{
double g;
g = 4215866817.;
USED(g);
return g;
}
void
main(void)
{
uint x;
double g;
x = fun();
USED(x);
g = 1.;
exits("");
}
and this
double
fun(void)
{
return 4215866817.;
}
void
main(void)
{
uint x;
double g;
x = fun();
USED(x);
g = 1.;
exits("");
}
seemed to be correct.
but perhaps i misunderstood
Re: [9fans] rc shell UNIX port repository
> * who is maintaining the UNIX port of rc shell? (is it still >Tig?) (if so what's the email address?) if it's Byron Rakitzis' rc, it's not a `port' to UNIX of Plan 9's rc, but an independent implementation, with differences in the language, although it's quite usable and both versions are lightweight compared to the current sh implementations.
Re: [9fans] rc shell UNIX port repository
>(And if so, can I build [plan9port rc] and use it independent of the rest > of the tools?) building it standalone will be hard, although you can reduce the surrounding source considerably, since it uses mainly or only lib9 (plan 9 libc). a little experiment suggests that once built, you might get by with only rc's executable and its rcmain. you'll need to change rcmain not to refer to $PLAN9/bin/9, but that needs only a little text editing.
Re: [9fans] ideas for helpful system io functions
>bind '#j4.5' /mnt/joined > ... to get a (read-only) fd that satisfies reads from fd 4 >until eof, then fd 5. i wonder if there's a way of perverting fs(3)
Re: [9fans] ideas for helpful system io functions
> i wonder if there's a way of perverting fs(3) i made the comment fairly idly, so i shouldn't take it too seriously.
Re: [9fans] port/allocb.c question
>Is there any reason a locked increment is being used? good question. i thought it might be a new tradition. i don't think it's needed.
Re: [9fans] 10ed f77 manpage
http://man.cat-v.org/unix_8th/1/f77 i'd be surprised if subsequently it had changed much.
