Hi Emmanuel and Java Maintainers,
Is there any chance of having this bug triaged by someone with deeper
understanding of antlr3 than me?
Cheers,
Balint
2015-03-07 10:58 GMT+01:00 Bálint Réczey :
> 2015-03-07 10:18 GMT+01:00 Emmanuel Bourg :
>> Le 07/03/2015 09:54, Bálint Réczey a écrit :
>>> Hi
2015-03-07 10:18 GMT+01:00 Emmanuel Bourg :
> Le 07/03/2015 09:54, Bálint Réczey a écrit :
>> Hi Emmanuel,
>>
>> 2015-02-24 13:44 GMT+01:00 Emmanuel Bourg :
>> Since then forked-daapd build started failing on mips and hppa as well
>> thus I opened a bug for the problems:
>> https://bugs.debian.org/
Le 07/03/2015 09:54, Bálint Réczey a écrit :
> Hi Emmanuel,
>
> 2015-02-24 13:44 GMT+01:00 Emmanuel Bourg :
> Since then forked-daapd build started failing on mips and hppa as well
> thus I opened a bug for the problems:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779973
>
> I'm not sure
Hi Emmanuel,
2015-02-24 13:44 GMT+01:00 Emmanuel Bourg :
> Le 24/02/2015 13:23, Thorsten Glaser a écrit :
>
>> Bálint Réczey dixit:
>>
>>> Not that I am lazy but I think instead of patching every package using
>>> antlr antlr itself should be patched to use higher default timeouts on
>>> slow plat
Le 24/02/2015 13:23, Thorsten Glaser a écrit :
> Bálint Réczey dixit:
>
>> Not that I am lazy but I think instead of patching every package using
>> antlr antlr itself should be patched to use higher default timeouts on
>> slow platforms.
>
> can we please get some sort of feedback on this?
> Re
Dear Java maintainers,
Bálint Réczey dixit:
>Not that I am lazy but I think instead of patching every package using
>antlr antlr itself should be patched to use higher default timeouts on
>slow platforms.
can we please get some sort of feedback on this?
Revisiting because the next forked-daapd b
Hi Thorsten,
2015-01-02 16:43 GMT+01:00 Thorsten Glaser :
> On Fri, 2 Jan 2015, Emmanuel Bourg wrote:
>
>> Le 02/01/2015 10:23, Thorsten Glaser a écrit :
>>
>> > Hm, so what can we do here? Increase the timeout in antlr3 for
>> > “slow” platforms? (Could it look at /proc/cpuinfo or something?
>> >
On Fri, 2 Jan 2015, Emmanuel Bourg wrote:
> Le 02/01/2015 10:23, Thorsten Glaser a écrit :
>
> > Hm, so what can we do here? Increase the timeout in antlr3 for
> > “slow” platforms? (Could it look at /proc/cpuinfo or something?
> > Except, that file is platform-specific… so a list of known to
> >
Le 02/01/2015 10:23, Thorsten Glaser a écrit :
> Hm, so what can we do here? Increase the timeout in antlr3 for
> “slow” platforms? (Could it look at /proc/cpuinfo or something?
> Except, that file is platform-specific… so a list of known to
> be slow platforms would help.) Or is this a GCJ vs. Op
Dixi quod…
>antlr3 RSP.g
>warning(205): RSP.g:1:8: ANTLR could not analyze this decision in rule Tokens;
>often this is because of recursive rule references visible from the left edge
>of alternatives. ANTLR will re-analyze the decision with a fixed lookahead of
>k=1. Consider using "options
10 matches
Mail list logo
