Please do not reply to this email- if you want to comment on the bug, go to the URL shown below and enter your comments there.
Changed by [EMAIL PROTECTED] http://bugzilla.ximian.com/show_bug.cgi?id=76218 --- shadow/76218 2005-09-27 12:14:26.000000000 -0400 +++ shadow/76218.tmp.14964 2005-09-27 12:23:54.000000000 -0400 @@ -10,12 +10,13 @@ Component: C# AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] QAContact: [EMAIL PROTECTED] TargetMilestone: --- URL: +Cc: [EMAIL PROTECTED],[EMAIL PROTECTED] Summary: Tokenizer/Seekable stream bugs. > > Please download this: > > http://primates.ximian.com/~miguel/tmp/fileCopier.tar.bz2 @@ -120,6 +121,19 @@ When I saw this patch for the first time on the list, I remember asking Atsushi about the performance implications of adding more tests to the pipeline. But it turned out that his path consumed less memory and was faster than our extra layer (SeekableStream) which impacts every read. + +------- Additional Comments From [EMAIL PROTECTED] 2005-09-27 12:23 ------- +I have a rewrite that gives up any hope of trying to match up with the +underlying Stream -- so no more bugs due to us guessing the number of +bytes a given number of chars occupied originally. + +For the gain in simplicity, we lose the ability to seek arbitrarily in +the file. We can only seek within 1024 chars, effective limiting our +lookahead to that. It's much cheaper than the old code, and supports +almost arbitrary (upto 1024 chars) seeks. If a parser cannot decide +in 1024 bytes, it might as well give up ;-) + +Patch attached. _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
