Re: [fossil-users] how to report bug in fossil

[Scott Robison]

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 doesn't mean
> > there aren't bugs, just that the sample data doesn't exercise a buggy
> > path, or that I did something wrong in adding the tests).
>
> Thanks for the new tests.
>
> >
> > But seriously, take a look at the new test cases. Let me know whether
> > you want to tweak your function or want me to merge mine to trunk.
> >
>
> Sure, I'll look at it.  I'm pretty sure we'll go with your function as
> it seems easier to understand and maintain.  Thanks for the bugfixes.


That'd be awesome. Much more satisfying to hack on fossil than some of the
other coding stuff I've done "for fun" in the past!

-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] how to report bug in fossil

[Joe Mistachkin]

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 exercise a buggy
> path, or that I did something wrong in adding the tests).

Thanks for the new tests.

>
> But seriously, take a look at the new test cases. Let me know whether
> you want to tweak your function or want me to merge mine to trunk.
>

Sure, I'll look at it.  I'm pretty sure we'll go with your function as
it seems easier to understand and maintain.  Thanks for the bugfixes.

--
Joe Mistachkin

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] how to report bug in fossil

[Scott Robison]

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 test that should fail but does not currently,
> > am I just supposed to manually tweak the desired expected output of
> > utf-check.txt before integration? That's how it is looking to me at the
> > moment.
> >
>
> Yes.
>

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 exercise a buggy path, or
that I did something wrong in adding the tests).

I've updated the invalid_utf8_table branch with performance optimizations.
Profiling the two versions (tip of both trunk & branch), on my machine with
my test data (all possible byte combinations up to 4 bytes in length) says
that mine is now faster. I show the tip of trunk version used about 130
billion cpu cycles vs 112 for the branch version.

HA! ;)

But seriously, take a look at the new test cases. Let me know whether you
want to tweak your function or want me to merge mine to trunk.

-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] how to report bug in fossil

[Joe Mistachkin]

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 manually tweak the desired expected output of
> utf-check.txt before integration? That's how it is looking to me at the
> moment.
>

Yes.

--
Joe Mistachkin

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] how to report bug in fossil

[Scott Robison]

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. Uncomment the "createTestResults" line.
> 2. Run "tclsh test\tester.tcl fossil.exe utf" from the checkout.
> 3. Results are located in "%TEMP%\utf-check.txt".
>
> If you add extra entries to the array prior to these steps, those new
> results
> should appear in the "utf-check.txt" file as well.
>

Okay, that was very helpful.

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?

If I want to specify a new test that should fail but does not currently, am
I just supposed to manually tweak the desired expected output of
utf-check.txt before integration? That's how it is looking to me at the
moment.

-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] how to report bug in fossil

[Joe Mistachkin]

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.tcl fossil.exe utf" from the checkout.
3. Results are located in "%TEMP%\utf-check.txt".

If you add extra entries to the array prior to these steps, those new
results
should appear in the "utf-check.txt" file as well.

--
Joe Mistachkin

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] how to report bug in fossil

[Scott Robison]

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
>> 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 right ones got through, but getting the
>> exact
>> > > right number is promising to me.
>> > >
>> > > Let me know if you see anything horridly wrong with my code. It's
>> 2am...
>> >
>> > It turns out that your code appears fine, it's just less efficient than
>> mine ;-)
>>
>> You are correct. I was going for correct and readable over fast and
>> wrong. {hides}
>>
>> > There were test-failures but all failures turned out to be errors in the
>> > expected test-outcome. I fixed those test-cases now, added more of
>> > them, and fixed the invalid_utf8() function in trunk. Now all tests pass
>> > with both trunk code and your code.
>> >
>> > Many thanks, Scott !  Once more, fossil got better than it was!
>>
>> Glad it's working. I'm all for faster correct code, too. I had run both
>> implementations through the profiler last night and knew my code was a few
>> percent slower, but figured optimization would narrow the gap when I was
>> alert enough to do more good.
>>
>> I'll take the current code and run it through my ugly test harness and
>> make sure it prints the right numbers in a bit.
>>
>
> The trunk version is still identifying certain sequences as valid. I've
> looked at the utf.test file but can't figure out where to put in cases
> which should fail. Can anyone give me a pointer on this?
>

Also: Simply uncommenting the "createTestResults $tempPath 100" call
doesn't seem to be doing anything for me. Here is what I'm doing:

1. Added four lines to the data array / list / whatever in utf.test
(appended them with numbers 201 through 204).
2. Uncommented the createTestResults call.
3. Change to an empty directory.
4. Run the test harness as "tclsh \dev\fossil\test\tester.tcl
\dev\fossil\win\fossil.exe".

The generated section remains unchanged. I'm probably missing some step,
but I can't figure it out.
-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] how to report bug in fossil

[Scott Robison]

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 function. My function
> > > identifies the expected number of "strings" as valid UTF-8. I didn't
> eyeball
> > > each one to make sure the right ones got through, but getting the exact
> > > right number is promising to me.
> > >
> > > Let me know if you see anything horridly wrong with my code. It's
> 2am...
> >
> > It turns out that your code appears fine, it's just less efficient than
> mine ;-)
>
> You are correct. I was going for correct and readable over fast and wrong.
> {hides}
>
> > There were test-failures but all failures turned out to be errors in the
> > expected test-outcome. I fixed those test-cases now, added more of
> > them, and fixed the invalid_utf8() function in trunk. Now all tests pass
> > with both trunk code and your code.
> >
> > Many thanks, Scott !  Once more, fossil got better than it was!
>
> Glad it's working. I'm all for faster correct code, too. I had run both
> implementations through the profiler last night and knew my code was a few
> percent slower, but figured optimization would narrow the gap when I was
> alert enough to do more good.
>
> I'll take the current code and run it through my ugly test harness and
> make sure it prints the right numbers in a bit.
>

The trunk version is still identifying certain sequences as valid. I've
looked at the utf.test file but can't figure out where to put in cases
which should fail. Can anyone give me a pointer on this?



-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] fossil ci -branch private

[Sergei Gavrikov]

Hi!

Could Fossil warn about spurious "private" check-ins? I rarely use
private branches but I use and a few times I did wrong check-ins as

fossil ci -branch private ...

IMO, it would be nice if Fossil warn that he/she (possible) misuses
privacy. Excuse my stupid request (wish you never see that your private
check-in is published :-)

Thanks for Fossil!

Sergei

smime.p7s
Description: S/MIME Cryptographic Signature
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] how to report bug in fossil

[Scott Robison]

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 valid UTF-8. I didn't
eyeball
> > each one to make sure the right ones got through, but getting the exact
> > right number is promising to me.
> >
> > Let me know if you see anything horridly wrong with my code. It's 2am...
>
> It turns out that your code appears fine, it's just less efficient than
mine ;-)

You are correct. I was going for correct and readable over fast and wrong.
{hides}

> There were test-failures but all failures turned out to be errors in the
> expected test-outcome. I fixed those test-cases now, added more of
> them, and fixed the invalid_utf8() function in trunk. Now all tests pass
> with both trunk code and your code.
>
> Many thanks, Scott !  Once more, fossil got better than it was!

Glad it's working. I'm all for faster correct code, too. I had run both
implementations through the profiler last night and knew my code was a few
percent slower, but figured optimization would narrow the gap when I was
alert enough to do more good.

I'll take the current code and run it through my ugly test harness and make
sure it prints the right numbers in a bit.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] how to report bug in fossil

[Jan Nijtmans]

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 right ones got through, but getting the exact
> right number is promising to me.
>
> Let me know if you see anything horridly wrong with my code. It's 2am...

It turns out that your code appears fine, it's just less efficient than mine ;-)

There were test-failures but all failures turned out to be errors in the
expected test-outcome. I fixed those test-cases now, added more of
them, and fixed the invalid_utf8() function in trunk. Now all tests pass
with both trunk code and your code.

Many thanks, Scott !  Once more, fossil got better than it was!

Regards,
   Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] SET option usability bug

[Tony Papadimitriou]

When giving the set command to change some option and you’re outside an open 
repo directory, the global setting is affected instead, even though the 
–-global option is not given.

So, one can very easily mess up their global setup by accidentally attempting 
to set a local option but either from the wrong directory or from right 
directory but with the repo being closed at the moment.

I think the –-global option should be required at all times to change the 
global version of the option as a safeguard against these kinds of mistakes.

Besides, the help screen seem to imply the same by not being clear about what 
happen when a repo is not open.

Options:
  --global   set or unset the given property globally instead of
 setting or unsetting it for the open repository only.

Thanks.___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] how to report bug in fossil

[Scott Robison]

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 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 file can be created
>> by
>> uncommenting the "createTestResults $tempPath 100" call.
>>
>
> I'm just about to commit and push a branch with a proposed new
> invalid_utf8 function. It will allow the "Modified UTF-8" NUL (C0 80)
> sequence, as well as the CESU-8 & WTF-8 variants described in the same
> wikipedia article. I'm including those because the current invalid_utf8
> function allowed them.
>
> My code isn't quite as efficient (profiler reports 5% diff). But I'm too
> tired to work on it further tonight. Look for "invalid_utf8_table" branch.
> You may very well see some optimization opportunities I haven't yet.
>

Branch committed. I'll run it against the existing test cases later, and
look at spiffing it up.

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 right ones got through, but getting the
exact right number is promising to me.

Let me know if you see anything horridly wrong with my code. It's 2am...

-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] how to report bug in fossil

[Scott Robison]

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 cases were added to
> the "utf.test" file.  The "generated section" in the file can be created by
> uncommenting the "createTestResults $tempPath 100" call.
>

I'm just about to commit and push a branch with a proposed new invalid_utf8
function. It will allow the "Modified UTF-8" NUL (C0 80) sequence, as well
as the CESU-8 & WTF-8 variants described in the same wikipedia article. I'm
including those because the current invalid_utf8 function allowed them.

My code isn't quite as efficient (profiler reports 5% diff). But I'm too
tired to work on it further tonight. Look for "invalid_utf8_table" branch.
You may very well see some optimization opportunities I haven't yet.

-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] how to report bug in fossil

[Jan Nijtmans]

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, I owe you. Many thanks! You are completely right, this was an
>> edge-case not covered for.
>
>
> Glad to be able to get to something before everyone else for a change. :)
>
> FYI: There is another problem, I think, with some invalid 4 byte sequences
> being accepted (F4 00 80 80, for example). I'm working on a proposed fix.

Yeah... after your fix, the following byte sequence is accepted as
valid while really it isn't:
\xE0\x80\x80
(discovered by simply running the test suite)

So, it's still not correct yet.

Regards,
Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] how to report bug in fossil

[Joe Mistachkin]

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 file can be created by
uncommenting the "createTestResults $tempPath 100" call.

--
Joe Mistachkin

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] how to report bug in fossil

[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, I owe you. Many thanks! You are completely right, this was an
> edge-case not covered for.
>

Glad to be able to get to something before everyone else for a change. :)

FYI: There is another problem, I think, with some invalid 4 byte sequences
being accepted (F4 00 80 80, for example). I'm working on a proposed fix.

-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] how to report bug in fossil

[Jan Nijtmans]

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
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users