On Fri, Jun 10, 2016 at 7:10 PM, Joe Mistachkin
wrote:
>
> Scott Robison wrote:
> >
> > Okay, thanks for all the help. I've committed some new test cases that
> > demonstrate errors in the trunk invalid_utf8. 16 tests fail on trunk,
> > none fail on invalid_utf8_table branch (which of course does
Scott Robison wrote:
>
> Okay, thanks for all the help. I've committed some new test cases that
> demonstrate errors in the trunk invalid_utf8. 16 tests fail on trunk,
> none fail on invalid_utf8_table branch (which of course doesn't mean
> there aren't bugs, just that the sample data doesn't exer
On Fri, Jun 10, 2016 at 5:24 PM, Joe Mistachkin
wrote:
>
> Scott Robison wrote:
> >
> > So my expectation that it would automatically update the utf.test file is
> > incorrect? I'm supposed to manually integrate that file back to utf.test?
> >
>
> Yes and yes.
>
> >
> > If I want to specify a new
Scott Robison wrote:
>
> So my expectation that it would automatically update the utf.test file is
> incorrect? I'm supposed to manually integrate that file back to utf.test?
>
Yes and yes.
>
> If I want to specify a new test that should fail but does not currently,
> am I just supposed to manua
On Fri, Jun 10, 2016 at 4:23 PM, Joe Mistachkin
wrote:
>
> Scott Robison wrote:
> >
> > Also: Simply uncommenting the "createTestResults $tempPath 100" call
> doesn't
> > seem to be doing anything for me. Here is what I'm doing:
> >
>
> Here are the steps I just used here locally:
>
> 1.
Scott Robison wrote:
>
> Also: Simply uncommenting the "createTestResults $tempPath 100" call
doesn't
> seem to be doing anything for me. Here is what I'm doing:
>
Here are the steps I just used here locally:
1. Uncomment the "createTestResults" line.
2. Run "tclsh test\tester.tc
On Fri, Jun 10, 2016 at 3:27 PM, Scott Robison
wrote:
> On Fri, Jun 10, 2016 at 12:26 PM, Scott Robison
> wrote:
>
>> On Jun 10, 2016 6:04 AM, "Jan Nijtmans" wrote:
>> >
>> > 2016-06-10 10:12 GMT+02:00 Scott Robison:
>> > > FYI, my test code here (C++ harness) consisted of passing every
>> poss
On Fri, Jun 10, 2016 at 12:26 PM, Scott Robison
wrote:
> On Jun 10, 2016 6:04 AM, "Jan Nijtmans" wrote:
> >
> > 2016-06-10 10:12 GMT+02:00 Scott Robison:
> > > FYI, my test code here (C++ harness) consisted of passing every
> possible
> > > four byte buffer to the old function and my new functio
On Jun 10, 2016 6:04 AM, "Jan Nijtmans" wrote:
>
> 2016-06-10 10:12 GMT+02:00 Scott Robison:
> > FYI, my test code here (C++ harness) consisted of passing every possible
> > four byte buffer to the old function and my new function. My function
> > identifies the expected number of "strings" as val
2016-06-10 10:12 GMT+02:00 Scott Robison:
> FYI, my test code here (C++ harness) consisted of passing every possible
> four byte buffer to the old function and my new function. My function
> identifies the expected number of "strings" as valid UTF-8. I didn't eyeball
> each one to make sure the rig
On Fri, Jun 10, 2016 at 2:04 AM, Scott Robison
wrote:
> On Fri, Jun 10, 2016 at 1:37 AM, Joe Mistachkin
> wrote:
>
>>
>> Scott Robison
>> >
>> > Glad to be able to get to something before everyone else for a change.
>> :)
>> >
>>
>> Yes, thank you very much.
>>
>> Also, I know it's not a lot of
On Fri, Jun 10, 2016 at 1:37 AM, Joe Mistachkin
wrote:
>
> Scott Robison
> >
> > Glad to be able to get to something before everyone else for a change. :)
> >
>
> Yes, thank you very much.
>
> Also, I know it's not a lot of fun, but...
>
> It would be nice if some new tests covering these edge ca
2016-06-10 9:24 GMT+02:00 Scott Robison:
> On Fri, Jun 10, 2016 at 1:15 AM, Jan Nijtmans
> wrote:
>>
>> 2016-06-10 2:01 GMT+02:00 Scott Robison:
>> > I just committed
>> > a one line fix (with multiple lines of comments to clarify what the code
>> > is
>> > doing in the tricky part).
>>
>> Scott,
Scott Robison
>
> Glad to be able to get to something before everyone else for a change. :)
>
Yes, thank you very much.
Also, I know it's not a lot of fun, but...
It would be nice if some new tests covering these edge cases were added to
the "utf.test" file. The "generated section" in the fil
On Fri, Jun 10, 2016 at 1:15 AM, Jan Nijtmans
wrote:
> 2016-06-10 2:01 GMT+02:00 Scott Robison:
> > I just committed
> > a one line fix (with multiple lines of comments to clarify what the code
> is
> > doing in the tricky part).
>
> Scott, I owe you. Many thanks! You are completely right, this w
2016-06-10 2:01 GMT+02:00 Scott Robison:
> I just committed
> a one line fix (with multiple lines of comments to clarify what the code is
> doing in the tricky part).
Scott, I owe you. Many thanks! You are completely right, this was an
edge-case not covered for.
Regards,
Jan Nijtmans
_
On Thu, Jun 9, 2016 at 6:19 PM, Warren Young wrote:
> On Jun 9, 2016, at 6:01 PM, Scott Robison wrote:
> >
> > On Thu, Jun 9, 2016 at 2:12 PM, Warren Young wrote:
> > On Jun 9, 2016, at 6:25 AM, rosscann...@fastmail.com wrote:
> > >
> > > The bug:
> > > In lookslike.c, invalid_utf8() returns 'i
On Jun 9, 2016, at 6:01 PM, Scott Robison wrote:
>
> On Thu, Jun 9, 2016 at 2:12 PM, Warren Young wrote:
> On Jun 9, 2016, at 6:25 AM, rosscann...@fastmail.com wrote:
> >
> > The bug:
> > In lookslike.c, invalid_utf8() returns 'invalid' for the input 0xE0,
> > 0xB8, 0x94, which is the Thai chara
Thanks! That patch works for me.
Ross
On Fri, Jun 10, 2016, at 10:01 AM, Scott Robison wrote:
> On Thu, Jun 9, 2016 at 2:12 PM, Warren Young wrote:
>> On Jun 9, 2016, at 6:25 AM, rosscann...@fastmail.com wrote:
>> >
>> > The bug:
>> > In lookslike.c, invalid_utf8() returns 'invalid' for t
On Thu, Jun 9, 2016 at 2:12 PM, Warren Young wrote:
> On Jun 9, 2016, at 6:25 AM, rosscann...@fastmail.com wrote:
> >
> > The bug:
> > In lookslike.c, invalid_utf8() returns 'invalid' for the input 0xE0,
> > 0xB8, 0x94, which is the Thai character 'do dek' (U+0E14).
>
> I took a look at that code
On Jun 9, 2016, at 3:21 PM, rosscann...@fastmail.com wrote:
>
> - it's massive;
It’s also open source under one of the most liberal licenses available. Fossil
could just swipe the one header file it needs. It hasn’t changed since 2005,
so one may presume that it is stable.
> - it has depende
I'm new to this list, so take my opinion lightly, but I would hesitate
to introduce Boost into the fossil build if it's not there already.
Boost adds a long list of complications to any build it's part of:
- it's massive;
- it has dependencies between its modules, so even if you just want a
tiny pa
On Jun 9, 2016, at 6:25 AM, rosscann...@fastmail.com wrote:
>
> The bug:
> In lookslike.c, invalid_utf8() returns 'invalid' for the input 0xE0,
> 0xB8, 0x94, which is the Thai character 'do dek' (U+0E14).
I took a look at that code, and there is no possibility for it to be correct.
It doesn’t e
Hi Ross,
On 09 Jun 2016, at 14:25 , rosscann...@fastmail.com wrote:
> I've found what seems to be a minor bug in fossil (details below), and
> I'm not sure what the procedure is for reporting it. Can someone
> enlighten me?
you did the right thing: contact this mailing list for help. :)
I asked
rosscann...@fastmail.com wrote:
>
> The bug:
> In lookslike.c, invalid_utf8() returns 'invalid' for the input 0xE0,
> 0xB8, 0x94, which is the Thai character 'do dek' (U+0E14). This can be
> easily reproduced by trying to commit a file that contains those three
> bytes and nothing else - you will
Hi,
I've found what seems to be a minor bug in fossil (details below), and
I'm not sure what the procedure is for reporting it. Can someone
enlighten me?
The bug:
In lookslike.c, invalid_utf8() returns 'invalid' for the input 0xE0,
0xB8, 0x94, which is the Thai character 'do dek' (U+0E14). This c
26 matches
Mail list logo
