> I think my wrists seized up just thinking about programming in XML.
Don't worry; that's just a natural RefleX.
Ha-ha...
> the other problem with both volume and audioctl will come with multiple
> streams. in1 and out1 might work, but it starts to look ugly. usbaudio
> appears to ignore multiple inputs or outputs.
i'm not entirely sure what you mean by "streams" in this context. multiple
inputs or outputs? if so, m
> Anthony:
> The one for audioctl is reasonably regular and comprehensive; it'd be
> nice to standardize our audio interfaces around that.
my concern with audioctl is multiple channels. for now control-left and
control-right are fine (if clunky), with 5.1 (or 7.1) audio that becomes
control^(1 2 3
cinap_len...@gmx.de wrote:
you have to implement flush in the 9p server.
--
cinap
Ah ...
I've just (re)read the 9p(2) man page ... it seems clear now.
Thank you very much, cinap :-)
Subject:
[9fans] Tread and alarm
Why not go with Esperanto subtitles so it is consistent and universal?
If not Klingonese is a good backup.
I will not buy this record; it is scratched.
There are actual Hungarians on this mailing list, I am sure that we
can be of assistance :)
can they do hungarian subtitles?
erik quanstrom wrote:
The client is (really?) suspended until Tread, but the read() sys call
cannot be interrupted by alarm().
i didn't understand your errata
If the are no available data, the file server doesn't do
r->ofcall.count = 0;
response(r, nil);
but just enqueue the Req and pro
you have to implement flush in the 9p server.
--
cinap
--- Begin Message ---
Hi, all
In a user space file server (9p(2)/9pfile(2)/...) I postpone the Rread
response if there are no available data,
in order to implement a suspensive read().
The client is (really?) suspended until Tread, but th
> The client is (really?) suspended until Tread, but the read() sys call
> cannot be interrupted by alarm().
i didn't understand your errata, so to clarify,
read(2) is interruptable with a note (modulo the
file server, but that's a different story). here's a
program that demonstrates:
; 8.read
Errata: ... alarm note is received after Rread, as if the ...
sorry :-)
Adriano Verardo wrote:
Hi, all
In a user space file server (9p(2)/9pfile(2)/...) I postpone the Rread
response if there are no available data,
in order to implement a suspensive read().
The client is (really?) suspended
It seems like that would be a reasonable approach, to translate one older
interface to the next, if needed, as a compatibility FS. In fact, one such
compatibility FS could serve several translations. The best way to deal is
to force everyone to update now, or cease functioning, in my opinion. Th
It does. And eliminates deadly embraces when servers misbehave.
No wuckers.
brucee
On Thu, Oct 28, 2010 at 2:54 AM, Venkatesh Srinivas
wrote:
> Oh, no, it wasn't meant as a defense! It was much more a 'hmm, only two
> hours can produce fairly solid performance gains; perhaps this deserves a
> m
Hi, all
In a user space file server (9p(2)/9pfile(2)/...) I postpone the Rread
response if there are no available data,
in order to implement a suspensive read().
The client is (really?) suspended until Tread, but the read() sys call
cannot be interrupted by alarm().
It seems to me that the
would it be hard to provide the backward compatibility via a user fs
-- at least until apps are updated to the new structure?
On Wed, Oct 27, 2010 at 11:58 AM, Anthony Sorace wrote:
> I've misplaced my USB audio kit, but I'm reasonably sure I read from
> /dev/audio (and a cursory reading of the
I will not buy this record; it is scratched.
On Wed, Oct 27, 2010 at 12:45 PM, Bela Valek wrote:
> There are actual Hungarians on this mailing list, I am sure that we
> can be of assistance :)
>
> On Mon, Oct 18, 2010 at 4:41 PM, wrote:
>> can they do hungarian subtitles?
>>
>> --
>> cinap
>>
>
There are actual Hungarians on this mailing list, I am sure that we
can be of assistance :)
On Mon, Oct 18, 2010 at 4:41 PM, wrote:
> can they do hungarian subtitles?
>
> --
> cinap
>
>
> -- Forwarded message --
> From: Eric Van Hensbergen
> To: Fans of the OS Plan 9 from Bell L
> I think the major change writing for the kernel is I am responsible for
> keeping the Path in the Chan up to date as the I get service
> fscreate, fsclone (just bump refernce count), and fswalk.
>
> I'am not sure how I should leave the Path of walk if the walk fails?
the best way to approach th
I've misplaced my USB audio kit, but I'm reasonably sure I read from /dev/audio
(and a cursory reading of the source suggests that ought to work). Is there any
reason to do otherwise? I don't know what audioin is intended to buy. Given
that it's never been in audio(3), I'm not sure it's importan
I have written a few file servers under lib9p and lib9pfile,
I am now trying to write a kernel file server and just a little
unsure about the differences.
I think the major change writing for the kernel is I am responsible for
keeping the Path in the Chan up to date as the I get service
fscreate,
On Wed, Oct 27, 2010 at 8:50 AM, Charles Forsyth wrote:
>>Sorry that wing-commander can't package it for today.
>
> sorry old boy, it wasn't LMF: at first we thought it was a wizard wheeze, but
> one of the sprogs had a prang with the bally old semantics and the other
> brass hats ordered it bac
On Wed, Oct 27, 2010 at 9:53 AM, Gorka Guardiola wrote:
> On Wed, Oct 27, 2010 at 3:50 PM, Charles Forsyth
> wrote:
>>>Sorry that wing-commander can't package it for today.
>>
>> sorry old boy, it wasn't LMF: at first we thought it was a wizard wheeze,
>> but one of the sprogs had a prang with
> - why do you assume that the old interface was not considered
> sufficient?
if volume were sufficient, there was no reason to add audioctl.
> - if you read usb(4) the first sentence on usb audio notes the
> interface is backwards compatable.
it notes that the names are backwards compatable, but
On Wed, Oct 27, 2010 at 3:50 PM, Charles Forsyth wrote:
>>Sorry that wing-commander can't package it for today.
>
> sorry old boy, it wasn't LMF: at first we thought it was a wizard wheeze, but
> one of the sprogs had a prang with the bally old semantics and the other
> brass hats ordered it bac
I'm reaching out for Vaughan right now.
You might google for that if that's an unknown...
On Wed, Oct 27, 2010 at 3:53 PM, Gorka Guardiola wrote:
> On Wed, Oct 27, 2010 at 3:50 PM, Charles Forsyth
> wrote:
>>>Sorry that wing-commander can't package it for today.
>>
>> sorry old boy, it wasn't L
>Sorry that wing-commander can't package it for today.
sorry old boy, it wasn't LMF: at first we thought it was a wizard wheeze, but
one of the sprogs had a prang with the bally old semantics and the other brass
hats ordered it back to the boffins
> i am not offering to change the interface, but to implement a simpler
> third interface (as usbaudio implements volume). poor diction on my part.
>
> the point is that there are currently two semi-incompatable interfaces,
> do people consider the current two adequate? (apparently volume was not,
kk, gotta get a stretch of time to babysit ripping the tapes. We are
about halfway through.
-eric
On Wed, Oct 27, 2010 at 1:16 AM, Bruce Ellis wrote:
> more! please.
>
> your data fiend,
>
> brucee
>
> On Tue, Oct 26, 2010 at 2:04 AM, Eric Van Hensbergen wrote:
>> http://www.arl-extern
On Wed, Oct 27, 2010 at 08:30:29AM -0400, Tristan Plumb wrote:
>
> i am not offering to change the interface, but to implement a simpler
> third interface (as usbaudio implements volume). poor diction on my part.
>
No one is going to "reject" your efforts, although it may be harder
to get them "a
> Changing a device's file format in a backwards-incompatible way
> is not something to be done lightly. In addition to changing all
> drivers you'd have to change every user program that reads from
> or writes to them, even ones that you don't know exist.
i am not offering to change the interfac
28 matches
Mail list logo
