Hello Paul,
On Sun, Nov 11, 2007 at 10:08:13PM +, Paul Cager wrote:
> I would say it's not _entirely_ the library developers' fault. JavaCC
> has always had a rather inconsistent use of Exceptions - ParseException
> (thrown for syntactic errors) extends Exception, but TokenMgrError
> (thrown
Michael Koch wrote:
> Hello,
> On Mon, Nov 05, 2007 at 10:49:29AM +0900, Sanghyeon Seo wrote:
>> In the original modifed file, ParseException extends CSSException
>> which extends RuntimeException, so it is an unchecked exception. But
>> unmodifed ParseException extends Exception by default, which
Hello,
On Mon, Nov 05, 2007 at 10:49:29AM +0900, Sanghyeon Seo wrote:
> Upstream modified ParseException.java after it was generated. Even the
> generated file says you can! ("You can modify this class to customize
> your error reporting...")
>
> In the original modifed file, ParseException exte
2007/11/5, Rene Engelhard <[EMAIL PROTECTED]>:
> When removing the generated files, re-building the parser and trying the
> build it fails, though (not at the &6 ;) ) when trying to build the
> stuff:
>
> http://zyklop.dyndns.org/~rene/flute-1.3-jfree_20061107-2_amd64.build
> http://zyklop.dyndns.o
Hi,
the recently accepted flutejava and flute-1.3-jfree packages use a
javacc generated parser - but they currently ship one pre-generated
which is not really the ideal way.
I don't feel comfortable uploading those to unstable with a parser not
being able to rebuilt/fixed if needed; this in turn
5 matches
Mail list logo