I think my wrists seized up just thinking about programming in XML.
Don't worry; that's just a natural RefleX.
Ha-ha...
2010/10/28 Anthony Sorace a...@9srv.net:
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.
you're essentially replacing
f := open(name, ...)
...
close(f)
which runs as a sequential process, and subject to the usual rules for
sequential
composition, by
f := open(name, ...)
...
spawn clunk(f)
which introduces a race with an invisible
multiple inputs or outputs? if so, my first pass would be do something
like what #l does: #l0, #l1, c.
Wouldn't it be better to use #A0, #A1, ... for the case of multiple
audio devices instead of multiple in/outs in one device?
that would make sense to me, though if there's a ethernet card
no it is not, charles. i rarely disagree with you but the semantics
are preserved, except for changing the behaviour of existing races.
brucee
On Thu, Oct 28, 2010 at 11:12 PM, Charles Forsyth fors...@terzarima.net wrote:
you're essentially replacing
f := open(name, ...)
...
I keep hearing how 9vx is very unstable and have a lot of problems,
but after a few months working on it I have not received many bug
reports. Probably I won't know how to fix these problems, but at least
I'd like to have them documented. Also, I'm updating the autogenerated
kernel files and would
On Thu, Oct 28, 2010 at 2:12 PM, Charles Forsyth fors...@terzarima.net wrote:
you're essentially replacing
f := open(name, ...)
...
close(f)
which runs as a sequential process, and subject to the usual rules for
sequential
composition, by
f := open(name, ...)
Wouldn´t a better way be?:
f := open(name, ...)
tclunk(f);
spawn deallocfid(f); //and whatever needs to be done on Rclunk
Hmm, it would be more like sending the Tclunk and not waiting for the
response. That would mean
that the fid cannot be unmarked for reuse until the response is
One problem I have with delayed clunks is that when you have caches or the like,
close might fail. Not an issue on Inferno, but, I'd still like to be
able to get back in sync
at close time if only to be able to check that everything's ok and
safe in the server.
On Thu, Oct 28, 2010 at 4:30 PM,
On Thu, Oct 28, 2010 at 04:00:32PM +0200, yy wrote:
So, if you are using the 9vx version at
http://bitbucket.org/yiyus/vx32/ (or ron's version, which is almost
the same) and you have a reproducible way to crash it, could you
please fill an issue in bitbucket or send me an email? Thanks.
I
On Thu, Oct 28, 2010 at 9:41 AM, Francisco J Ballesteros n...@lsub.org wrote:
One problem I have with delayed clunks is that when you have caches or the
like,
close might fail. Not an issue on Inferno, but, I'd still like to be
able to get back in sync
at close time if only to be able to
Assuming messages are not reordered.
ah, the easy problems can be taken care of by using 1 clunker
and a clunk channel with a fixed buffer. i'd like to know
more about charles' correctness concerns. not that this particular
example is all that useful. cf. nemo
My argument is that I'd like
On Thu, Oct 28, 2010 at 04:56:02PM +0200, Francisco J Ballesteros wrote:
Be there caches of not, I've found that I want to be able to say
I'm done with this file, let me know if everything is done and ok.
You can, just not by using Tclunk.
Of course, if you use 9p with no cache, you know
Nowhere in the manual does it say that. The only protocol-defined way to be
sure that you are coherent is to use Twstat with all arguments NOP. (FWIW,
this may also be superior to checking that Tclunk did not Rerror because the
fid is still live if Twstat Rerrors.)
name 3 in-distribution
Yes, in general, agree, but this was about clunk usage and
semantics, and I think it's important to have the I'm done message
synchronous when you need that.
Btw, I think you mean Tstat, don't you?
I'm not sure Twstat would work that way in practice.
Hello,
I'm using Uriel's macros for creating slides with groff (I'm unable to
make p9p's troff to work). The slides look fine, but I can't add slide
numbers at the bottom of each slide (which I expected to get, since
the slide macros seem to modify the ms macro). I've been messing
around with
I have used the foils package on plan9 and on osx in the past.
/n/sources/contrib/steve/foils.tgz
or
http://plan9.bell-labs.com/sources/contrib/steve/foils.tgz
-Steve
On Thu, Oct 28, 2010 at 11:53 AM, Francisco J Ballesteros n...@lsub.orgwrote:
Yes, in general, agree, but this was about clunk usage and
semantics, and I think it's important to have the I'm done message
synchronous when you need that.
Btw, I think you mean Tstat, don't you?
I'm not sure
On Thu, Oct 28, 2010 at 8:12 AM, Charles Forsyth fors...@terzarima.netwrote:
you're essentially replacing
f := open(name, ...)
...
close(f)
which runs as a sequential process, and subject to the usual rules for
sequential
composition, by
f := open(name, ...)
Also, if that is racy, isn't this at least analogous?
i don't think so: that instance is entirely at the discretion of the programmer.
it would be analogous if the text of the program actually contained `spawn
clunk(f)',
but i was trying to represent the effects of the rewriting the system would
On Thu, Oct 28, 2010 at 4:18 PM, Charles Forsyth fors...@terzarima.netwrote:
the race is that there's nothing to say that the clunk completes before the
process continues on to do something more, including some action that
depends on the clunk completing,
such as simply repeating the open.
On Thu, Oct 28, 2010 at 4:55 PM, Nemo nemo.m...@gmail.com wrote:
i have decent servers that wait for clunk to operate on written data once
it's complete. all octopus spoolers do that.
Heh; when I wrote 'decent', I was recalling the old proposed QTDECENT qid
type. I didn't mean to impugn your
months ago, i did test an example on the system that just works, by the way,
and it did fail. it often takes a few attempts for it to fail,
because it depends on scheduling (often the system completes the clunk before
returning to the original process), but there's nothing to stop it failing
a number of weeks ago, to facilitate migrating many
hundreds of machines to a new network setup, i wrote a
simple and fairly bone-headed ndb database checker,
ndb/vrfy. it was amazingly effective, if provincial.
it catches all the classics like badly formatted eas,
duplicate eas, mistyped keys
On Thu, Oct 28, 2010 at 10:18 PM, Charles Forsyth fors...@terzarima.net wrote:
the race is that there's nothing to say that the clunk completes before the
process continues on to do something more, including some action that depends
on the clunk completing,
such as simply repeating the open.
i have no idea why the yacc source wasn't included.
here it is.
- erik%{
#include u.h
#include libc.h
#include bio.h
#include ip.h
typedef struct T T;
struct T{
T *next;
T *down;
char*s;
char*t;
int line;
char*file;
};
No! Open on an exclusive file has the same races. No problems on
Froggie .. no servers with clunk semantics. The first I encountered
was Bosch's video streamer. Nemo obviously has concerns.
Catch a run.
brucee
On Fri, Oct 29, 2010 at 10:51 AM, Gorka Guardiola pau...@gmail.com wrote:
On Thu,
27 matches
Mail list logo
