Okay - still not sure there is going to be enough bandwidth to pull
off livestreaming, but I'm going to attempt it. The URL to check will
be http://www.livestream.com/iwp9 starting at 9pm US EST. I'll be
recording the sessions to tape as well and depending on the quality of
the livestream will po
On Wed, Sep 30, 2009 at 05:48:24PM +1000, Bruce Ellis wrote:
> yes, i will post a link when i tidy it up.
>
> brucee
>
Any news on this?
--
Jake Todd
// If it isn't broke, tweak it!
pgpaKOlw8YOqI.pgp
Description: PGP signature
I must say, many thanks!
Ruda
2009/10/21 Russ Cox :
>> Ok, thanks, this seems to have solved it.
>> So the %nonassoc says to the parser that
>> (REP block) ATOM
>> is the right decision as opposed to
>> REP (block ATOM)
>> right?
>
> %token declares its arguments as tokens but
> does not give them
> Is this what you are trying to do?
>
> $ cat b.y <<'EOF'
> %token ATOM REP
> %%
> blocks: block | block blocks;
> block: ATOM | REP block | '[' blocks ']';
> %%
> EOF
> $ bison b.y
> $
My head is starting to spin, but I think that, possibly, yes.
Seems to be the simplest way how to do it. :)
Any
> Ok, thanks, this seems to have solved it.
> So the %nonassoc says to the parser that
> (REP block) ATOM
> is the right decision as opposed to
> REP (block ATOM)
> right?
%token declares its arguments as tokens but
does not give them any precedence level.
%left, %right, and %nonassoc also declar
Is this what you are trying to do?
$ cat b.y <<'EOF'
%token ATOM REP
%%
blocks: block | block blocks;
block: ATOM | REP block | '[' blocks ']';
%%
EOF
$ bison b.y
$
On Wed, 21 Oct 2009 19:52:41 +0200 Rudolf Sykora
wrote:
> Hello,
> sorry for an off-topic thing. But I guess somebody here could
> So the %nonassoc says to the parser that
> (REP block) ATOM
> is the right decision as opposed to
> REP (block ATOM)
> right?
... probably not exactly. the highest priority of ATOM is probably
also important, as I think of it now...
Ruda
2009/10/21 Skip Tavakkolian <9...@9netics.com>:
> i think this is what you want. untested:
>
> pair: REP ATOM
> | REP '[' block ']'
>
> block: pair
> | block pair
Thanks.
This would require there always be a REP before [ block ], which I
don't want (cf. ordinary expression (1+2) ).
2009/10/21 Russ Cox :
> To know how to decide, yacc needs a precedence
> for the thing being shifted and the rule. You've
> given precedences for each rule (REP block has
> REP's precedence, and block block has +'s thanks
> to the override) but not to ATOM.
>
> Concretely, when yacc sees REP block
> %token ATOM
> %left '+'
> %left REP
>
> block: ATOM
> | REP block
> | block block %prec '+'
> 5 block: REP block .
> 6 | block . block
>
> ATOM shift, and go to state 3
>
> ATOM [reduce using rule 5 (block)]
This says that yacc isn't sure how to deci
i think this is what you want. untested:
pair: REP ATOM
| REP '[' block ']'
block: pair
| block pair
> Hello,
> sorry for an off-topic thing. But I guess somebody here could help me...
> I have a problem with bison grammer
>
> Having
>
> %tokenATOM
> %left '+'
> %left R
... anywhere where I wrote 'grammer' I meant 'grammar' ...
On Wed, Oct 21, 2009 at 8:43 AM, Sam Watkins wrote:
> People do this stuff every day.
> Have you heard of a render-farm?
Yes, and some of them are on this list, and have actually done this
sort of work, as you clearly have not. Else you would understand where
the limits on parallelism are in p
Hello,
sorry for an off-topic thing. But I guess somebody here could help me...
I have a problem with bison grammer
Having
%token ATOM
%left '+'
%left REP
and a grammar:
block:ATOM
| REP block
| block '+' block
;
is ok. Having another grammer:
block:ATOM
|
On Wed, Oct 21, 2009 at 09:11:10AM -0700, Russ Cox wrote:
> > Can you give one example of a slow task that you think cannot benefit much
> > from parallel processing?
>
> Rebuilding a venti index is almost entirely I/O bound.
Perhaps I should have specified a processor-bound task. I don't know m
> Can you give one example of a slow task that you think cannot benefit much
> from
> parallel processing?
Rebuilding a venti index is almost entirely I/O bound.
You can have as many cores as you want and they
will all be sitting idle waiting for the disks. Parallel
processing helps only to the
I wrote:
>I calculated roughly that encoding a 2-hour video could be parallelized by a
>factor of perhaps 20 trillion, using pipelining and divide-and-conquer
On Tue, Oct 20, 2009 at 03:16:22AM +0100, matt wrote:
> I know you are using video / audio encoding as an example and there are
> probably
On Tue, Oct 20, 2009 at 8:53 PM, Enrico Weigelt wrote:
> So I added several block types: eg. blob (payload data) and inode
> (holding the tree).
>From these I infer that you've build an object store, not just a block sotre.
How close was it to this:
http://oceanstore.cs.berkeley.edu/publicatio
18 matches
Mail list logo
