Menu
▾
▴
tcl-core
|
From: Kevin W. <kw...@co...> - 2019-10-05 21:44:39
|
On 10/4/19 4:03 PM, Donald G Porter via Tcl-Core wrote: > I am also looking for any alerts from developers of Tk or the other > bundled packages that the timing or contents of these snapshots of > development are not a fitting state for a release. Don't be shy. If > something pending should still go in, or something shaky should come > out, this is the time to say so. Current RC runs fine on macOS 10.4.6, no failures in test suites. We've been doing some work on a patch for the canvas to change some default appearance values; Jan has been backing parts of that patch out for 8.6 and I'm not sure if all of it has been merged to the release branch. Jan, can you provide a status update? Marc just committed a fix for a crash with the new Mac services API (crash in Python, not Tk); he or I will merge that in the next couple of days after some final testing. Marc, any other bugs that need fixing? The big update is that macOS 10.15 is supposed to be released in the next couple of days. I do want to test on that before we release just to make sure there are no showstoppers. Initial testing on the beta versions hasn't indicated any such issues, but it's always best to test on a live final release. --Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com |
|
From: Harald O. <har...@el...> - 2019-10-06 10:00:28
|
Am 05.10.2019 um 15:58 schrieb Francois Vogel:
> Le 05/10/2019 à 15:07, Harald Oehlmann a écrit :
>> Tk compilation:
>> All this is caused by the line:
>> DEBUG(unsigned owned:1); /* For debugging purposes. */
>> If I comment it out, it compiles well.
>
> Try building with the following line instead:
>
> DEBUG(unsigned owned:1;) /* For debugging purposes. */
>
> It should work.
Yes, it does, thank you.
>> ==== bind-34.2 -warp works relatively to the screen FAILED
>> ==== Contents of test case:
>>
>> # Contrary to bind-32.2, we're directly checking screen coordinates
>> event generate {} <Motion> -x 20 -y 20 -warp 1
>> update idletasks ; # DoWarp is an idle callback
>> set res [winfo pointerxy .]
>> event generate {} <Motion> -x 200 -y 200 -warp 1
>> update idletasks ; # DoWarp is an idle callback
>> lappend res {*}[winfo pointerxy .]
>>
>> ---- Result was:
>> 20 19 200 200
>> ---- Result should have been (exact matching):
>> 20 20 200 200
>> ==== bind-34.2 FAILED
>
> So the pointer coordinates are erroneously (20,19) when warping to
> (20,20), but they are correctly (200,200), when warping to (200,200)?
> There is a difference of 1 unit, in y only, but not always. How come...?
> That's strange. I don't reproduce this failure on my Vista system but I
> will think about this.
I can only say, that I did not move the mouse while testing. But the tcl
tests were running in parallel.
Thank you,
Harald
|
|
From: Jan N. <jan...@gm...> - 2019-10-06 20:59:53
|
Op za 5 okt. 2019 om 23:45 schreef Kevin Walzer:
> We've been doing some work on a patch for the canvas to change some
> default appearance values; Jan has been backing parts of that patch out
> for 8.6 and I'm not sure if all of it has been merged to the release
> branch. Jan, can you provide a status update?
Everything I planned is now on core-8-6-branch (both for Tcl and Tk),
so one more merge to the rc branch and everything is good to go IMHO.
Also the failures reported by Harald Oehlmann are corrected now
there. (Thanks, as always, Harald!!!!).
Sqlite 3.30.0 is just released, and I also fixed the use of the LL-prefix
there (not reported upstream yet, but I'll do that).
On my side, everything is good to go! I wanted to wait for SQLite 3.30.0,
and - indeed - I think it's wise to wait for MacOS Catalina (just a few
days, I think). I tested on all platforms I have available, and didn't
encounter any new issues. It's impressive that all tests on MacOS
now pass, thanks to Kevin and Marc!
If the "mac_service_init" and the "bug-d66e6fabad" branches (both for Tk)
could be finalised before the release, that would even be better.
Thanks!
Jan Nijtmans
|
|
From: Kevin W. <kw...@co...> - 2019-10-07 02:09:59
|
On 10/6/19 4:59 PM, Jan Nijtmans wrote: > If the "mac_service_init" and the "bug-d66e6fabad" branches (both for Tk) > could be finalised before the release, that would even be better. "mac_service_init" branch is now merged. Waiting for Catalina to come out for final production testing. -- Kevin Walzer Code by Kevin http://www.codebykevin.com |
|
From: Francois V. <fra...@gm...> - 2019-10-07 05:46:40
|
Le 06/10/2019 à 22:59, Jan Nijtmans a écrit : > If the "mac_service_init" and the "bug-d66e6fabad" branches (both for Tk) > could be finalised before the release, that would even be better. Just a note: "bug-d66e6fabad" branch is for 8.7 only, so independent from the release of 8.6.10. F. |
|
From: Donald G P. <don...@ni...> - 2019-10-07 15:36:46
|
On 10/6/19 4:59 PM, Jan Nijtmans wrote: > On my side, everything is good to go! I wanted to wait for SQLite 3.30.0, > and - indeed - I think it's wise to wait for MacOS Catalina (just a few > days, I think). Thanks to all the many testers and fixers. I will follow the advice above and hold the rc1 releases for sqlite3 3.30 and MacOS Catalina. Please keep working on any other issues as you can. -- | Don Porter Applied and Computational Mathematics Division | | don...@ni... Information Technology Laboratory | | http://math.nist.gov/~DPorter/ NIST | |______________________________________________________________________| |
|
From: Jan N. <jan...@gm...> - 2019-10-07 15:43:15
|
Op ma 7 okt. 2019 om 17:37 schreef Donald G Porter via Tcl-Core:
> Thanks to all the many testers and fixers. I will follow the advice above and hold the rc1 releases for sqlite3 3.30 and MacOS Catalina. Please keep working on any other issues as you can.
Well, sqlite 3.30.0 is available now! One less to wait for. ;-)
Thanks!
Jan Nijtmans
|
|
From: Marc C. <cul...@gm...> - 2019-10-08 20:32:49
|
Running the test suite on a VM with the Catalina "Gold Master" beta produced one segfault, about 20 hangs and around 100 test failures. This is not close to the nightmare that we saw with Mojave, but it is non-trivial. With a few small changes I was eventually able to eliminate the segfault, most of the hangs (leaving two from which one can escape by moving the mouse) and about 13 failures. While the changes were small, they were pretty hard to find and are very hard to explain. They are in the catalina_tests branch. I would be grateful if some of the experts on this list could review the changes and even more grateful to hear explanations of why they were needed. - Marc On Mon, Oct 7, 2019 at 10:37 AM Donald G Porter via Tcl-Core < tcl...@li...> wrote: > On 10/6/19 4:59 PM, Jan Nijtmans wrote: > > On my side, everything is good to go! I wanted to wait for SQLite 3.30.0, > > and - indeed - I think it's wise to wait for MacOS Catalina (just a few > > days, I think). > > Thanks to all the many testers and fixers. I will follow the advice above > and hold the rc1 releases for sqlite3 3.30 and MacOS Catalina. Please keep > working on any other issues as you can. > > -- > | Don Porter Applied and Computational Mathematics Division | > | don...@ni... Information Technology Laboratory | > | http://math.nist.gov/~DPorter/ NIST | > |______________________________________________________________________| > > > > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core > |
|
From: Jan N. <jan...@gm...> - 2019-10-08 21:47:36
|
Op di 8 okt. 2019 om 22:33 schreef Marc Culler <cul...@gm...>:
>
> Running the test suite on a VM with the Catalina "Gold Master" beta produced one segfault, about 20 hangs and around 100 test failures. This is not close to the nightmare that we saw with Mojave, but it is non-trivial.
>
> With a few small changes I was eventually able to eliminate the segfault, most of the hangs (leaving two from which one can escape by moving the mouse) and about 13 failures.
Well, in addition, I saw failures in entry/scale/spinbox tests.
Changing "update" in "vwait" appears to help there (although we should
- at least - implement a timeout there).
Indeed, something is different in the moment events fire. (since
Yesterday, I have Catalina installed on my iMac ... ). See also the
"catalina_more_tests" branch for a first shot.
However, I don't see the widget demo mis-behaving, so maybe we should
just accept the test-failures on Catalina as they are for now.
Opinions?
>
> While the changes were small, they were pretty hard to find and are very hard to explain. They are in the catalina_tests branch. I would be grateful if some of the experts on this list could review the changes and even more grateful to hear explanations of why they were needed.
Well, don't count me as expert on that ... , but I'm happy to do some
more testing.
Regards,
Jan Nijtmans
|
|
From: Kevin W. <kw...@co...> - 2019-10-09 02:43:05
|
On 10/8/19 5:47 PM, Jan Nijtmans wrote: > However, I don't see the widget demo mis-behaving, so maybe we should > just accept the test-failures on Catalina as they are for now. > Opinions? I'm trying to rebuild my toolchain on Catalina - just installed today - and will try to test in the next day or so. -- Kevin Walzer Code by Kevin http://www.codebykevin.com |
|
From: Marc C. <cul...@gm...> - 2019-10-09 03:43:51
|
I am not in favor of accepting test failures. - Marc On Tue, Oct 8, 2019 at 9:43 PM Kevin Walzer <kw...@co...> wrote: > On 10/8/19 5:47 PM, Jan Nijtmans wrote: > > However, I don't see the widget demo mis-behaving, so maybe we should > > just accept the test-failures on Catalina as they are for now. > > Opinions? > > I'm trying to rebuild my toolchain on Catalina - just installed today - > and will try to test in the next day or so. > > -- > Kevin Walzer > Code by Kevin > http://www.codebykevin.com > > > > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core > |
|
From: Donal K. F. <don...@ma...> - 2019-10-09 14:19:04
Attachments:
donal_k_fellows.vcf
|
On 09/10/2019 04:43, Marc Culler wrote: > I am not in favor of accepting test failures. Nobody is, but if we can't fix (or define a way to reliably skip when the test is known to fail for silly reasons unrelated to what is really being tested) then what other alternative is there? Donal. |
|
From: Brad L. <bra...@gm...> - 2019-10-09 17:56:40
|
Mac OS Catalina has a new security model. Anyone producing .pkg or .dmg files needs to check and make sure their installation process works. Fortunately, with a little research and much flailing around, my .pkg is working again. Python2, ruby, perl will be removed from the next release of Mac OS. Tcl (8.5.9) is not specifically mentioned, but I would not surprised if it got removed also. On Wed, Oct 9, 2019 at 7:20 AM Donal K. Fellows < don...@ma...> wrote: > On 09/10/2019 04:43, Marc Culler wrote: > > I am not in favor of accepting test failures. > > Nobody is, but if we can't fix (or define a way to reliably skip when > the test is known to fail for silly reasons unrelated to what is really > being tested) then what other alternative is there? > > Donal. > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core > |
|
From: Marc C. <cul...@gm...> - 2019-10-09 18:06:54
|
It is specifically mentioned when you run /usr/bin/wish $ /usr/bin/wish DEPRECATION WARNING: The system version of Tk is deprecated and may be removed in a future release. Please don't rely on it. Set TK_SILENCE_DEPRECATION=1 to suppress this warning. What changes did you have to make to your package?? - Marc On Wed, Oct 9, 2019 at 12:57 PM Brad Lanam <bra...@gm...> wrote: > Mac OS Catalina has a new security model. > Anyone producing .pkg or .dmg files needs to check and make > sure their installation process works. > > Fortunately, with a little research and much flailing around, my .pkg is > working again. > > Python2, ruby, perl will be removed from the next release of Mac OS. > Tcl (8.5.9) is not specifically mentioned, but I would not surprised if it > got removed also. > > > On Wed, Oct 9, 2019 at 7:20 AM Donal K. Fellows < > don...@ma...> wrote: > >> On 09/10/2019 04:43, Marc Culler wrote: >> > I am not in favor of accepting test failures. >> >> Nobody is, but if we can't fix (or define a way to reliably skip when >> the test is known to fail for silly reasons unrelated to what is really >> being tested) then what other alternative is there? >> >> Donal. >> _______________________________________________ >> Tcl-Core mailing list >> Tcl...@li... >> https://lists.sourceforge.net/lists/listinfo/tcl-core >> > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core > |
|
From: Marc C. <cul...@gm...> - 2019-10-09 18:10:06
|
And Tcl is mentioned when you run /usr/bin/tclsh: $ /usr/bin/tclsh WARNING: This version of tcl is included in macOS for compatibility with legacy software. In future versions of macOS the tcl runtime will not be available by default, and may require you to install an additional package. On Wed, Oct 9, 2019 at 1:06 PM Marc Culler <cul...@gm...> wrote: > It is specifically mentioned when you run /usr/bin/wish > > $ /usr/bin/wish > DEPRECATION WARNING: The system version of Tk is deprecated and may be > removed in a future release. Please don't rely on it. Set > TK_SILENCE_DEPRECATION=1 to suppress this warning. > > What changes did you have to make to your package?? > > - Marc > > On Wed, Oct 9, 2019 at 12:57 PM Brad Lanam <bra...@gm...> > wrote: > >> Mac OS Catalina has a new security model. >> Anyone producing .pkg or .dmg files needs to check and make >> sure their installation process works. >> >> Fortunately, with a little research and much flailing around, my .pkg is >> working again. >> >> Python2, ruby, perl will be removed from the next release of Mac OS. >> Tcl (8.5.9) is not specifically mentioned, but I would not surprised if it >> got removed also. >> >> >> On Wed, Oct 9, 2019 at 7:20 AM Donal K. Fellows < >> don...@ma...> wrote: >> >>> On 09/10/2019 04:43, Marc Culler wrote: >>> > I am not in favor of accepting test failures. >>> >>> Nobody is, but if we can't fix (or define a way to reliably skip when >>> the test is known to fail for silly reasons unrelated to what is really >>> being tested) then what other alternative is there? >>> >>> Donal. >>> _______________________________________________ >>> Tcl-Core mailing list >>> Tcl...@li... >>> https://lists.sourceforge.net/lists/listinfo/tcl-core >>> >> _______________________________________________ >> Tcl-Core mailing list >> Tcl...@li... >> https://lists.sourceforge.net/lists/listinfo/tcl-core >> > |
|
From: Brad L. <bra...@gm...> - 2019-10-09 18:23:03
|
And another good variable for bash to get rid of the message
about bash deprecation and zsh shell default:
export BASH_SILENCE_DEPRECATION_WARNING=1
put in your .bash_profile
Before, in PackageInfo, I had
install-location="/tmp"
and I moved or copied the package into its final install location
($HOME/Desktop/BallroomDJ.app).
Yes, that's not so normal, but it works for me.
Did not work so well with the new installer.
I don't have code-signing (can't afford that), not to mention, I don't use
XCode to generate the package.
So with Catalina I *must* install in the user home directory.
PackageInfo:
install-location="/tmp"
enable_localSystem="false"
enable_anywhere="true"
enable_currentUserHome="true"
This ignores install-location and installs to the desktop automatically.
I don't know if all of those new enable_* are needed, but it seems to work.
On Wed, Oct 9, 2019 at 11:06 AM Marc Culler <cul...@gm...> wrote:
> It is specifically mentioned when you run /usr/bin/wish
>
> $ /usr/bin/wish
> DEPRECATION WARNING: The system version of Tk is deprecated and may be
> removed in a future release. Please don't rely on it. Set
> TK_SILENCE_DEPRECATION=1 to suppress this warning.
>
> What changes did you have to make to your package??
>
> - Marc
>
> On Wed, Oct 9, 2019 at 12:57 PM Brad Lanam <bra...@gm...>
> wrote:
>
>> Mac OS Catalina has a new security model.
>> Anyone producing .pkg or .dmg files needs to check and make
>> sure their installation process works.
>>
>> Fortunately, with a little research and much flailing around, my .pkg is
>> working again.
>>
>> Python2, ruby, perl will be removed from the next release of Mac OS.
>> Tcl (8.5.9) is not specifically mentioned, but I would not surprised if it
>> got removed also.
>>
>>
>> On Wed, Oct 9, 2019 at 7:20 AM Donal K. Fellows <
>> don...@ma...> wrote:
>>
>>> On 09/10/2019 04:43, Marc Culler wrote:
>>> > I am not in favor of accepting test failures.
>>>
>>> Nobody is, but if we can't fix (or define a way to reliably skip when
>>> the test is known to fail for silly reasons unrelated to what is really
>>> being tested) then what other alternative is there?
>>>
>>> Donal.
>>> _______________________________________________
>>> Tcl-Core mailing list
>>> Tcl...@li...
>>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>>>
>> _______________________________________________
>> Tcl-Core mailing list
>> Tcl...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>>
>
|
|
From: Marc C. <cul...@gm...> - 2019-10-09 19:55:10
|
We are now getting 0 failures in the test suite when the catalina_more_tests branch is used on a macOS Catalina system (i.e. on my computer). We should run the tests on other macOS versions before merging. More importantly, we need to test the catalina_more_tests branch on other platforms for the following reason. When I looked at textDisp.test I was shocked at the overuse of the update command, especially given that our own wiki <https://wiki.tcl-lang.org/page/update> strongly advises against using it. I mean, really, what are you testing when you need to use commands like update ; update ; update and how exactly is that different from update ; update ; update ; update ? In textDisp.test I replaced hundreds of calls to update with calls to update idletasks without causing any new failures on the mac. In the end, there were only about 5 places where it seemed that update was needed. However, maybe "update ; update ; update" really is needed on some platform. Who knows? Also, Jan replaced some calls to update with calls to vwait and thereby eliminated some test failures. But, again, who knows about other platforms? There are several other test scripts that overuse update, but I used up all of my patience fixing textDisp.test and so I left many unnecessary calls to update in place. - Marc On Wed, Oct 9, 2019 at 1:22 PM Brad Lanam <bra...@gm...> wrote: > And another good variable for bash to get rid of the message > about bash deprecation and zsh shell default: > export BASH_SILENCE_DEPRECATION_WARNING=1 > put in your .bash_profile > > Before, in PackageInfo, I had > install-location="/tmp" > > and I moved or copied the package into its final install location > ($HOME/Desktop/BallroomDJ.app). > Yes, that's not so normal, but it works for me. > Did not work so well with the new installer. > > I don't have code-signing (can't afford that), not to mention, I don't use > XCode to generate the package. > So with Catalina I *must* install in the user home directory. > > PackageInfo: > install-location="/tmp" > enable_localSystem="false" > enable_anywhere="true" > enable_currentUserHome="true" > > This ignores install-location and installs to the desktop automatically. > I don't know if all of those new enable_* are needed, but it seems to work. > > On Wed, Oct 9, 2019 at 11:06 AM Marc Culler <cul...@gm...> wrote: > >> It is specifically mentioned when you run /usr/bin/wish >> >> $ /usr/bin/wish >> DEPRECATION WARNING: The system version of Tk is deprecated and may be >> removed in a future release. Please don't rely on it. Set >> TK_SILENCE_DEPRECATION=1 to suppress this warning. >> >> What changes did you have to make to your package?? >> >> - Marc >> >> On Wed, Oct 9, 2019 at 12:57 PM Brad Lanam <bra...@gm...> >> wrote: >> >>> Mac OS Catalina has a new security model. >>> Anyone producing .pkg or .dmg files needs to check and make >>> sure their installation process works. >>> >>> Fortunately, with a little research and much flailing around, my .pkg is >>> working again. >>> >>> Python2, ruby, perl will be removed from the next release of Mac OS. >>> Tcl (8.5.9) is not specifically mentioned, but I would not surprised if >>> it >>> got removed also. >>> >>> >>> On Wed, Oct 9, 2019 at 7:20 AM Donal K. Fellows < >>> don...@ma...> wrote: >>> >>>> On 09/10/2019 04:43, Marc Culler wrote: >>>> > I am not in favor of accepting test failures. >>>> >>>> Nobody is, but if we can't fix (or define a way to reliably skip when >>>> the test is known to fail for silly reasons unrelated to what is really >>>> being tested) then what other alternative is there? >>>> >>>> Donal. >>>> _______________________________________________ >>>> Tcl-Core mailing list >>>> Tcl...@li... >>>> https://lists.sourceforge.net/lists/listinfo/tcl-core >>>> >>> _______________________________________________ >>> Tcl-Core mailing list >>> Tcl...@li... >>> https://lists.sourceforge.net/lists/listinfo/tcl-core >>> >> |
|
From: Brad L. <bra...@gm...> - 2019-10-09 20:47:39
|
On Wed, Oct 9, 2019 at 12:55 PM Marc Culler <cul...@gm...> wrote: > When I looked at textDisp.test I was shocked at the overuse of the update > command, especially given that our own wiki > <https://wiki.tcl-lang.org/page/update> strongly advises against using > it. I mean, really, what are you testing when you need to use commands like > update ; update ; update > and how exactly is that different from > update ; update ; update ; update > ? > I think many of the tests do need an update call, as they must wait for something to be drawn or for an event to be processed. Whereas the wiki is mostly correct, I don't think it applies to testing. If the test needs a delay, it should be coded something like: set ::x 0 after 200 set ::x 1 vwait ::x update In your recent checkin, Marc, can the 0.25 seconds be changed to 0.1 seconds. 0.25 seconds can be noticeable, and I find 0.1 seconds works well when I need a no-cpu delay. |
|
From: Francois V. <fra...@gm...> - 2019-10-09 20:55:10
Attachments:
Vista_catalina_more_tests_10488a8c89.txt
|
Le 09/10/2019 à 21:54, Marc Culler a écrit : > We are now getting 0 failures in the test suite when the > catalina_more_tests branch is used on a macOS Catalina system (i.e. on > my computer). > > We should run the tests on other macOS versions before merging. More > importantly, we need to > test the catalina_more_tests branch on other platforms Wise suggestion! On Vista, core-8-6-branch shows zero failure, but catalina_more_tests at [10488a8c] <https://core.tcl-lang.org/tk/info/10488a8c899a0d8b> shows 55 failures. Full Tk tests log attached. > When I looked at textDisp.test I was shocked at the overuse of the > update command, especially given that our own wiki > <https://wiki.tcl-lang.org/page/update> strongly advises against using it. On my side when I saw the commit I was wondering how come 'update idletasks' could fix tests on Catalina since 'update' actually includes idle tasks updating (among other updates). Turns out that the reason you changed this was not to fix tests on Catalina, but it was triggered by the thoughts above. While it results in no regression on Catalina (tests still pass), there are a lot of new failures on Windows. Not tried on Linux yet. > I mean, really, what are you testing when you need to use commands like > update ; update ; update > and how exactly is that different from > update ; update ; update ; update > ? At some places I think the hope is that asynchronous lines updates in the text widget are finished before the test can go on. Clearly the case for instance in textDisp-19.14. This reason is even documented in the comments of textDisp-31.3 . Other places are really old things with at-the-time-good-reasons now lost, e.g. the second 'update' in textDisp-11.7 in textDisp.test dates back to 2003 when merging TIP #155: https://core.tcl-lang.org/tk/info/e58248ce5f8b5af2 Series of four 'updates' in a row are very old as well, and no reason appears to be detailed I think: https://core.tcl-lang.org/tk/info/94fbec76b1ff2c11 > There are several other test scripts that overuse update, but I used > up all of my patience fixing textDisp.test and so I left many > unnecessary calls to update in place. I would really welcome a way of not needing to use all those updates, for sure. Perhaps our patience could be better utilized at thinking at such a way? First thing that come to mind would be to rework tests by making use of <<WidgetViewSync>> in the cases we're waiting for asynchronous line metrics to be updated. Francois |
|
From: Brad L. <bra...@gm...> - 2019-10-09 23:10:48
|
Linux looks ok with the latest (85765a68, being the same as : 7369c288), compared to core-8-6-10-rc. Ubuntu 16.04, 64-bit bll@ubuntu1604-64:~$ diff w1.a w2.a 20a21,22 > ==== image-11.1 Tk_FreeImage procedure FAILED > ==== image-11.1 FAILED |
|
From: Marc C. <cul...@gm...> - 2019-10-09 23:26:41
|
I think I restored the old behavior of textDisp.test and textWind.test, while allowing macOS to use update idletasks where other platforms use update in textDisp.test. I ran the test suite on VMs running Sierra, High Sierra, and Mojave as well as on real hardware running Catalina. I got: Sierra - 1 failure: image-11.1, as expected High Sierra - 1 failure: image-11.1, as expected Mojave - 0 failures Catalina - 0 failures I also want to make sure that the catalina_more_tests branch builds cleanly on OSX 10.6 and OSX 10.9 but I haven't checked that yet. - Marc On Wed, Oct 9, 2019 at 6:10 PM Brad Lanam <bra...@gm...> wrote: > Linux looks ok with the latest (85765a68, being the same as : 7369c288), > compared to core-8-6-10-rc. > > Ubuntu 16.04, 64-bit > > bll@ubuntu1604-64:~$ diff w1.a w2.a > 20a21,22 > > ==== image-11.1 Tk_FreeImage procedure FAILED > > ==== image-11.1 FAILED > |
|
From: Jan N. <jan...@gm...> - 2019-10-10 08:51:09
|
Op do 10 okt. 2019 om 01:27 schreef Marc Culler:
> I ran the test suite on VMs running Sierra, High Sierra, and Mojave as well as on real hardware running Catalina. I got:
>
> Sierra - 1 failure: image-11.1, as expected
> High Sierra - 1 failure: image-11.1, as expected
> Mojave - 0 failures
> Catalina - 0 failures
Great progress! I backported the test-case changes (with some more
tweaks) back to core-8-6-branch, so more
people can verify that everything is correct on other platforms too.
Hopefully I didn't break any test-cases on
Catalina with that, didn't verify that yet ...
On Windows (Windows 10, build 17763), currently I see 6 test failures
in Tk. They are present
for a long time, so nothing to worry about, but anyway here they are:
==== bind-34.1 -warp works relatively to a window FAILED
==== Contents of test case:
# In order to avoid platform-dependent coordinate results due to
# decorations and borders, this test warps the pointer twice
# relatively to a window that moved in the meantime, and checks
# how much the pointer moved
wm geometry .top +200+200
update
event generate .top <Motion> -x 20 -y 20 -warp 1
update idletasks ; # DoWarp is an idle callback
set pointerPos1 [winfo pointerxy .t]
wm geometry .top +600+600
update
event generate .top <Motion> -x 20 -y 20 -warp 1
update idletasks ; # DoWarp is an idle callback
set pointerPos2 [winfo pointerxy .t]
# from the first warped position to the second one, the mouse
# pointer should have moved the same amount as the window moved
set res 1
foreach pos1 $pointerPos1 pos2 $pointerPos2 {
if {$pos1 != [expr {$pos2 - 400}]} {
set res 0
}
}
set res
---- Result was:
0
---- Result should have been (exact matching):
1
==== bind-34.1 FAILED
==== canvText-20.1 angled text bounding box FAILED
==== Contents of test case:
.c create text 2 2 -tag t -anchor center -text 0 -font {Helvetica 24}
set bb0 [.c bbox t]
.c itemconf t -angle 90
set bb1 [.c bbox t]
.c itemconf t -angle 180
set bb2 [.c bbox t]
.c itemconf t -angle 270
set bb3 [.c bbox t]
list [expr {$bb0 eq $bb2 ? "ok" : "$bb0,$bb2"}] [expr {$bb1 eq
$bb3 ? "ok" : "$bb1,$bb3"}] [expr {$bb0 eq [transpose $bb1] ? "ok" :
"$bb0,$bb1"}]
---- Result was:
{-10 -20 14 25,-10 -21 14 24} {-20 -10 25 14,-21 -10 24 14} ok
---- Result should have been (exact matching):
ok ok ok
==== canvText-20.1 FAILED
==== frame-2.8 toplevel configuration options FAILED
==== Contents of test case:
catch {destroy .t}
toplevel .t -width 200 -height 100
wm geometry .t +0+0
.t configure -use 0x44022
---- Result was:
can't modify -use option after widget is created
---- Result should have been (exact matching):
window "0x44022" doesn't exist
==== frame-2.8 FAILED
==== frame-12.3 FrameWorldChanged procedure FAILED
==== Contents of test case:
# Check reaction on font change
font create myfont -family courier -size 10
labelframe .f -font myfont -text Mupp
place .f -x 0 -y 0 -width 40 -height 40
pack [frame .f.f] -fill both -expand 1
update
set h1 [font metrics myfont -linespace]
set y1 [winfo y .f.f]
font configure myfont -size 20
update
set h2 [font metrics myfont -linespace]
set y2 [winfo y .f.f]
expr {($h2 - $h1) - ($y2 - $y1)}
---- Result was:
16
---- Result should have been (exact matching):
0
==== frame-12.3 FAILED
==== scrollbar-6.27 ScrollbarPosition procedure FAILED
==== Contents of test case:
.s identify [expr {[winfo width .s] / 2}] [expr {int(.4 / [.s delta 0 1])
+ [testmetrics cyvscroll .s]}]
---- Result was:
slider
---- Result should have been (exact matching):
trough2
==== scrollbar-6.27 FAILED
==== winWm-5.1 UpdateGeometryInfo: menu resizing FAILED
==== Contents of test case:
toplevel .t
frame .t.f -width 150 -height 50 -background red
pack .t.f
update
set result [winfo height .t]
menu .t.m
.t.m add command -label foo
.t configure -menu .t.m
update
lappend result [winfo height .t]
.t.m add command -label "thisisreallylong"
.t.m add command -label "thisisreallylong"
update
lappend result [winfo height .t]
---- Result was:
50 50 2
---- Result should have been (exact matching):
50 50 31
==== winWm-5.1 FAILED
Regards,
Jan Nijtmans
|
|
From: Francois V. <fvo...@fr...> - 2019-10-10 18:01:42
|
Le 10/10/2019 à 10:50, Jan Nijtmans a écrit : > On Windows (Windows 10, build 17763), currently I see 6 test failures > in Tk. They are present > for a long time, so nothing to worry about, but anyway here they are: > > ==== bind-34.1 -warp works relatively to a window FAILED > > ==== canvText-20.1 angled text bounding box FAILED > > ==== canvText-20.1 FAILED > > ==== frame-2.8 toplevel configuration options FAILED > > ==== frame-12.3 FrameWorldChanged procedure FAILED > > ==== scrollbar-6.27 ScrollbarPosition procedure FAILED > > ==== winWm-5.1 UpdateGeometryInfo: menu resizing FAILED > > ==== winWm-5.1 FAILED This I find quite strange. I have exactly zero failure on Windows: - Vista - Win10 (build 1803) with the tip of any of : - core-8-6-branch (that is [e70ffd7e]) - catalina_more_tests (that is [ddbb4881]) And you're saying these failures are "present for a long time"? Astonishing. I don't see any failures on the above systems for, I don't know exactly, more than one or two years. Any non-standard (fonts, system...) settings that you could have on your WIN10 that could create this? Some of the failures you show look really odd. F. |
|
From: Jan N. <jan...@gm...> - 2019-10-11 09:00:35
|
Op do 10 okt. 2019 om 20:01 schreef Francois Vogel:
> I have exactly zero failure on Windows:
> - Vista
> - Win10 (build 1803)
> with the tip of any of :
> - core-8-6-branch (that is [e70ffd7e])
> - catalina_more_tests (that is [ddbb4881])
>
> And you're saying these failures are "present for a long time"? Astonishing.
> I don't see any failures on the above systems for, I don't know exactly,
> more than one or two years.
>
> Any non-standard (fonts, system...) settings that you could have on your
> WIN10 that could create this?
> Some of the failures you show look really odd.
Bind-34-1 is fixed now, indeed it looks like a rounding error. Good hint!
The others could be Font-related, I'm not sure. I'll see if I can
investigate some more in the next days. But it's not blocking
for the upcoming release.
Regards,
Jan Nijtmans
|
|
From: Marc C. <cul...@gm...> - 2019-10-10 22:14:24
|
If no one objects I would like to merge the catalina_more_tests branch into
core-8-6-branch and close it. The changes would be:
UPDATE macosx/tkMacOSXColor.c
UPDATE macosx/tkMacOSXNotify.c
UPDATE tests/ttk/entry.test
I am not sure why the last one was not merged earlier, but I see no problem
with doing that.
- Marc
On Thu, Oct 10, 2019 at 3:51 AM Jan Nijtmans <jan...@gm...> wrote:
> Op do 10 okt. 2019 om 01:27 schreef Marc Culler:
> > I ran the test suite on VMs running Sierra, High Sierra, and Mojave as
> well as on real hardware running Catalina. I got:
> >
> > Sierra - 1 failure: image-11.1, as expected
> > High Sierra - 1 failure: image-11.1, as expected
> > Mojave - 0 failures
> > Catalina - 0 failures
>
> Great progress! I backported the test-case changes (with some more
> tweaks) back to core-8-6-branch, so more
> people can verify that everything is correct on other platforms too.
> Hopefully I didn't break any test-cases on
> Catalina with that, didn't verify that yet ...
>
> On Windows (Windows 10, build 17763), currently I see 6 test failures
> in Tk. They are present
> for a long time, so nothing to worry about, but anyway here they are:
>
> ==== bind-34.1 -warp works relatively to a window FAILED
> ==== Contents of test case:
>
> # In order to avoid platform-dependent coordinate results due to
> # decorations and borders, this test warps the pointer twice
> # relatively to a window that moved in the meantime, and checks
> # how much the pointer moved
> wm geometry .top +200+200
> update
> event generate .top <Motion> -x 20 -y 20 -warp 1
> update idletasks ; # DoWarp is an idle callback
> set pointerPos1 [winfo pointerxy .t]
> wm geometry .top +600+600
> update
> event generate .top <Motion> -x 20 -y 20 -warp 1
> update idletasks ; # DoWarp is an idle callback
> set pointerPos2 [winfo pointerxy .t]
> # from the first warped position to the second one, the mouse
> # pointer should have moved the same amount as the window moved
> set res 1
> foreach pos1 $pointerPos1 pos2 $pointerPos2 {
> if {$pos1 != [expr {$pos2 - 400}]} {
> set res 0
> }
> }
> set res
>
> ---- Result was:
> 0
> ---- Result should have been (exact matching):
> 1
> ==== bind-34.1 FAILED
> ==== canvText-20.1 angled text bounding box FAILED
> ==== Contents of test case:
>
> .c create text 2 2 -tag t -anchor center -text 0 -font {Helvetica 24}
> set bb0 [.c bbox t]
> .c itemconf t -angle 90
> set bb1 [.c bbox t]
> .c itemconf t -angle 180
> set bb2 [.c bbox t]
> .c itemconf t -angle 270
> set bb3 [.c bbox t]
> list [expr {$bb0 eq $bb2 ? "ok" : "$bb0,$bb2"}] [expr {$bb1 eq
> $bb3 ? "ok" : "$bb1,$bb3"}] [expr {$bb0 eq [transpose $bb1] ? "ok" :
> "$bb0,$bb1"}]
> ---- Result was:
> {-10 -20 14 25,-10 -21 14 24} {-20 -10 25 14,-21 -10 24 14} ok
> ---- Result should have been (exact matching):
> ok ok ok
> ==== canvText-20.1 FAILED
>
> ==== frame-2.8 toplevel configuration options FAILED
> ==== Contents of test case:
>
> catch {destroy .t}
> toplevel .t -width 200 -height 100
> wm geometry .t +0+0
> .t configure -use 0x44022
>
> ---- Result was:
> can't modify -use option after widget is created
> ---- Result should have been (exact matching):
> window "0x44022" doesn't exist
> ==== frame-2.8 FAILED
> ==== frame-12.3 FrameWorldChanged procedure FAILED
> ==== Contents of test case:
>
> # Check reaction on font change
> font create myfont -family courier -size 10
> labelframe .f -font myfont -text Mupp
> place .f -x 0 -y 0 -width 40 -height 40
> pack [frame .f.f] -fill both -expand 1
> update
> set h1 [font metrics myfont -linespace]
> set y1 [winfo y .f.f]
> font configure myfont -size 20
> update
> set h2 [font metrics myfont -linespace]
> set y2 [winfo y .f.f]
> expr {($h2 - $h1) - ($y2 - $y1)}
>
> ---- Result was:
> 16
> ---- Result should have been (exact matching):
> 0
> ==== frame-12.3 FAILED
>
>
> ==== scrollbar-6.27 ScrollbarPosition procedure FAILED
> ==== Contents of test case:
>
> .s identify [expr {[winfo width .s] / 2}] [expr {int(.4 / [.s delta 0
> 1])
> + [testmetrics cyvscroll
> .s]}]
>
> ---- Result was:
> slider
> ---- Result should have been (exact matching):
> trough2
> ==== scrollbar-6.27 FAILED
>
>
> ==== winWm-5.1 UpdateGeometryInfo: menu resizing FAILED
> ==== Contents of test case:
>
> toplevel .t
> frame .t.f -width 150 -height 50 -background red
> pack .t.f
> update
> set result [winfo height .t]
> menu .t.m
> .t.m add command -label foo
> .t configure -menu .t.m
> update
> lappend result [winfo height .t]
> .t.m add command -label "thisisreallylong"
> .t.m add command -label "thisisreallylong"
> update
> lappend result [winfo height .t]
>
> ---- Result was:
> 50 50 2
> ---- Result should have been (exact matching):
> 50 50 31
> ==== winWm-5.1 FAILED
>
> Regards,
> Jan Nijtmans
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>
|
Thanks for helping keep SourceForge clean.
X