On May 30, 6:06 pm, [EMAIL PROTECTED] (Russ Cox) wrote:
> If you want to violate a convention, Plan 9 won't stop you,
> but in doing so you give up compatibility with programs that
> depend on that convention (bind /net/tcp /proc; ps).
> Sure, you could replace ctl and clone and other special files
On Fri, 2008-05-30 at 15:04 -0400, [EMAIL PROTECTED] wrote:
> Very well explained. I've seen this question come up lots of times
> when introducing fs-based interfaces to people. When we had some
> off-shore devs to bring up to speed, they kept coming back to it: "so
> can we just define a protocol
Very well explained. I've seen this question come up lots of times
when introducing fs-based interfaces to people. When we had some
off-shore devs to bring up to speed, they kept coming back to it: "so
can we just define a protocol to put all these streams in one file?". I
tried to explaing that ha
Russ Cox wrote:
If you want to violate a convention, Plan 9 won't stop you,
but in doing so you give up compatibility with programs that
depend on that convention (bind /net/tcp /proc; ps).
Sure, you could replace ctl and clone and other special files with reads
and writes at magic offsets,
On Fri, May 30, 2008 at 1:43 AM, Nyang A. Phra <[EMAIL PROTECTED]> wrote:
> Poking around Plan 9 and 9P, I was wondering whether it would be a
> neat hack or some sort of abuse to read and write dynamically served
> files at different offsets to get different semantics, instead of
> reading and wri
> why not put the timing information inband? this would allow the timed
> sound to be saved to a file also without 1.7mb of zeros.
The Plan 9 audio device data format is stereo, 16-bit
little-endian PCM samples. Given that convention, my
point was only that seeking in that kind of data stream
do
Excellent, excellent response Russ. If a question like this comes up
again, your post is a great reference.
Stefan
On Fri, May 30, 2008 at 4:35 PM, erik quanstrom <[EMAIL PROTECTED]> wrote:
>> On Fri, May 30, 2008 at 4:15 PM, erik quanstrom <[EMAIL PROTECTED]> wrote:
>> > why not put the timing
> On Fri, May 30, 2008 at 4:15 PM, erik quanstrom <[EMAIL PROTECTED]> wrote:
> > why not put the timing information inband? this would allow the timed
> > sound to be saved to a file also without 1.7mb of zeros.
>
> because then you'd need to quote the audio data in case it
> contained something
On Fri, May 30, 2008 at 4:15 PM, erik quanstrom <[EMAIL PROTECTED]> wrote:
> why not put the timing information inband? this would allow the timed
> sound to be saved to a file also without 1.7mb of zeros.
because then you'd need to quote the audio data in case it
contained something that looked
> P. P. S. The usb audio use of offsets is not as bad as it first sounds.
> The device consumes written data at a constant rate (say, 176,400
> bytes per second for CD audio). You can make a noise ten seconds
> from now by writing 1.7MB bytes of zeros (silence) followed by your
> sound data. Bei
> Poking around Plan 9 and 9P, I was wondering whether it would be a
> neat hack or some sort of abuse to read and write dynamically served
> files at different offsets to get different semantics, instead of
> reading and writing different files (ctl, clone, etc.) to do that.
>
> Given that the sys
>> Nyang: I must say one thing: you are simply going to LOVE an
>> abomination of an acme feature i am working on!
>
> Do let us in on the secret (if you wish) :)
>
>
lets discuss it as soon as i get the code out... watch this space ;)
nkl
> Nyang: I must say one thing: you are simply going to LOVE an
> abomination of an acme feature i am working on!
Do let us in on the secret (if you wish) :)
> Given that the system encourages to perceive files as having arbitrary
> semantics (as opposed to having regular sequential file semantics) it
> would make sense (to me) to have reads and writes at arbitrary offsets
> to have arbitrary semantics as well -- that's, after all, what offset
> (kind o
>>> we haven't got a task force to rip
>>> keyboards from careless hands
>>this is excellent!
> but Nick LaForge reminds us we can use more effective methods
> Vercotti: Doug (takes a drink) Well, I was terrified.
> Everyone was terrified of Doug. I've seen grown men pull
> th
>> we haven't got a task force to rip
>> keyboards from careless hands
>this is excellent!
but Nick LaForge reminds us we can use more effective methods
Vercotti: Doug (takes a drink) Well, I was terrified.
Everyone was terrified of Doug. I've seen grown men pull
their o
> Poking around Plan 9 and 9P, I was wondering whether it would be a
> neat hack or some sort of abuse to read and write dynamically served
> files at different offsets to get different semantics, instead of
> reading and writing different files (ctl, clone, etc.) to do that.
> Given that the syst
> ...but my spider-sense is telling me this would probably be either
> rather pointless, or troublesome, or prohibited. Please set me
> straight.
well, of those, it can't be prohibited, because we haven't got a task force to
rip
keyboards from careless hands, although given the system's backgroun
Poking around Plan 9 and 9P, I was wondering whether it would be a
neat hack or some sort of abuse to read and write dynamically served
files at different offsets to get different semantics, instead of
reading and writing different files (ctl, clone, etc.) to do that.
Given that the system encoura
19 matches
Mail list logo