Just one error left:
( cd /usr/src/tmp/7.2/src &&\
bison -y -d -v language.yacc &&\
sed -e 's/YY_COUNT_TYPE/unsigned int/' <y.tab.c >language.c &&\
mv y.tab.h language.h_src && rm y.tab.c)
language.yacc:2848.3-2856.14: invalid value: $3
the hack mentioned in the Grubba's mail doesn't work in this case.
the said autodocs fail to build. I don't have the exact error available
now, but it claims it cannot move the GL chapter after merging all the
chapters before it.
4
22
Wrong user
by Peter Bortas @ Pike developers forum
18 Oct '02
18 Oct '02
Whoever is checking in Pike stuff as "manual": Don't.
This is what happens whenever one tries to export the pike tree:
language.yacc:1590.3-1597.64: invalid value: $2
language.yacc:2472.3-2475.62: invalid value: $2
language.yacc:2514.3-2517.62: invalid value: $2
language.yacc:2567.3-2570.62: invalid value: $2
language.yacc:2591.3-2594.62: invalid value: $2
language.yacc:2616.3-2619.62: invalid value: $2
language.yacc:2848.3-2856.14: invalid value: $3
the offending lines all contain something like ...=$<number>2 or
...=$<number>3 in …
[View More]the last case. The interesting thing is that the last
rule contains also $<number>1 - and that passes.
Anybody has a clue about how to fix it? Pike 7.3 works fine with bison 1.50
[View Less]
One question would be what you're going to use if for IMHO. If speed
is at all important you don't want to use bzip2 anyway because it's A
LOT slower than gzip.
/ David Hedbor
Previous text:
>2002-10-16 17:14:
>Subject: Re: Bzip2 (Pike C Module documentation)
>--------------------------------------------------------------------
>Probably not, but I was curious if it would work better or worse then
>gzip. I think my chunks vary between 0.5 and 20k, and the bigger
>contains …
[View More]more eaily compressed data (more text strings) as well.
>
>bzip2 docs-->
>ftp://sources.redhat.com/pub/bzip2/docs/manual_toc.html
>
>
> / Brevbäraren
>
[View Less]
IIRC, the algorithms used by bzip works with fairly large blocks. So
if you need to sync often (say, two sync points less than a KB or so
apart, you probably shouldn't use bzip2).
/ Niels Möller ()
Previous text:
>2002-10-16 16:15:
>Subject: Re: Bzip2 (Pike C Module documentation)
>--------------------------------------------------------------------
>*reads docs*
>
>Reading the libbzip2 docs, it seems that the library is a tad hairy in
>this regard. There doesn't seem to …
[View More]be any real support for reading or
>writing partially synced bzip2'd streams. There is no sync command,
>only end. And the only support I can see about reading multiple ended
>compressions from one stream is to check whether there's data left in
>the "in" stream after decompression.
>
>(One should not confuse the high level interface that uses FILE* with
>reading/writing partially synced streams.)
>
>
> / Brevbäraren
>
[View Less]