These are chat archives for pybee/general

1st
Jun 2018
Amir Yalamov
@AmirYalamov
Jun 01 03:17
Hello everyone! My name is Amir Yalamov and I am a student going into 2nd year The University of Western Ontario. I have not contributed to open-source before, but I heard that The BeeWare Project is a great place for first time open-source contributors. I love back-end development, and I am looking to contribute to the VOC project. Looking forward to it!
Russell Keith-Magee
@freakboy3742
Jun 01 03:18
@AmirYalamov Welcome! If you haven’t already found it, we’ve got a guide to your first VOC contribution: https://pybee.org/contributing/how/first-time/what/voc/
If you need any pointers or help, just ask!
Amir Yalamov
@AmirYalamov
Jun 01 03:20

As of now, I have a question regarding setting up my environment; on the "Your First VOC Contribution", it says "Work through that guide until you can run the VOC test suite - once you've been able to run the test suite without any failures". After running the entire test suite, in the terminal I got Ran 14189 tests in 4118.098s

FAILED (errors=1, expected failures=971, unexpected successes=1)
Test failed: <unittest.runner.TextTestResult run=14189 errors=1 failures=0>
error: Test failed: <unittest.runner.TextTestResult run=14189 errors=1 failures=0>`

Russell Keith-Magee
@freakboy3742
Jun 01 03:20
Ok - the unexpected success is the only thing that is odd there
If you search for “unexpected success” in the test log, it should point at a single test - which one is it?
Amir Yalamov
@AmirYalamov
Jun 01 03:26
Is it "test_tuple" based on the line test_tuple (tests.builtins.test_set.BuiltinSetFunctionTests) ... unexpected success ?
Russell Keith-Magee
@freakboy3742
Jun 01 03:27
That’s the line… interesting that you get an unexpected pass, though...
It sounds like it might be a set ordering issue. (Which… also sounds like a really good first contribution!)
So - step 1 - find the not_implemented reference for that test, and delete it from thest test_tuple file.
Step 2, re-run that test, and confirm it still passes
Step 3, submit a pull request.
At this point, you’ll probably get a test failure, because of an ordering issue. When you’ve reached that point, let us know and we’ll get you to the next step.
Amir Yalamov
@AmirYalamov
Jun 01 03:41
After deleting the not_implemented reference from the test_tuple file, I still get the following: FAILED (expected failures=3, unexpected successes=1)
Test failed: <unittest.runner.TextTestResult run=17 errors=0 failures=0>
Russell Keith-Magee
@freakboy3742
Jun 01 03:41
Is it the same unexpected success line?
Amir Yalamov
@AmirYalamov
Jun 01 03:43
Yes, "unexpected success" still appears for the same test_tuple line.
Russell Keith-Magee
@freakboy3742
Jun 01 03:44
Ok - so time for the “silly errors” check: (1) did you save the test file before re-running the tests, (b) are you editing the test_tuple.py file in builtins, not datatypes
Amir Yalamov
@AmirYalamov
Jun 01 03:47
I have done both 1) and 2).
Russell Keith-Magee
@freakboy3742
Jun 01 03:50
And you’re still getting the unexpected success?
Amir Yalamov
@AmirYalamov
Jun 01 03:51
This is what my test_tuple.py file in builtins looks like:
from .. utils import TranspileTestCase, BuiltinFunctionTestCase


class TupleTests(TranspileTestCase):
    pass


class BuiltinTupleFunctionTests(BuiltinFunctionTestCase, TranspileTestCase):
    functions = ["tuple"]
When I run $ python setup.py test -s tests.builtins.test_set.BuiltinSetFunctionTests in the terminal I still get the test_tuple (tests.builtins.test_set.BuiltinSetFunctionTests) ... unexpected success line.
Russell Keith-Magee
@freakboy3742
Jun 01 03:53
Hang on - you’ve deleted all the not_implemented entries?
… and also… /me facepalms.
You need to edit test_set, not test_tuple.
Sorry -I mistyped, and sent you down the wrong path
Amir Yalamov
@AmirYalamov
Jun 01 03:58
No worries! I fixed the test_tuple.py file to have all the original implemented entries, and deleted the test_tuple reference from the test_set.py file. That fixed the problem! Now I get OK (expected failures=3) in the terminal.
^After running the tests
Russell Keith-Magee
@freakboy3742
Jun 01 04:00
Ok - so, that’s now working on your machine. The catch is that we’re dealing with set ordering, which can be inconsistent between machines. So - submit that change as a PR, and wait to see what the CI server says.
What will probaly happen is that the same tests will fail on CI - so the task will be to work out what change is needed to make the test pass on both your machine and CI.
Amir Yalamov
@AmirYalamov
Jun 01 04:20
Ok cool, just submitted a pull request a few minutes ago. Out of curiosity, what exactly does a CI server do?
Russell Keith-Magee
@freakboy3742
Jun 01 04:21
It runs the tests. It’s essentially a pre-merge check - an opportunity to do all the things that must be done before a patch is accepted.
(and, to do so in a known, reliable environment)
(CI is Continuous Integration)
Amir Yalamov
@AmirYalamov
Jun 01 04:24
Thanks for the good explanation :)
Stanton
@stantonxu
Jun 01 05:16

@freakboy3742 @obulat I would like to implement the on_exit handler on Mac, like what @obulat did for winforms, but after I looked into it and tried to implement in the on_close(self) in the Window.py for cocoa, it doesn't work.

For winforms, why did you implement it in winforms_FormClosing(...), but not in on_close(self). Is there any special reason? Why the implementation in on_close(self) for cocoa doesn't work? could you give me some hint?

I am referring to PR#522
Russell Keith-Magee
@freakboy3742
Jun 01 05:18
@stantonxu winforms_FormClosing is a window system event handler. It’s attached to the Winforms “FormClosing” event. If you want to implement the same behavior on Cocoa, you need to work out what the Cocoa event for a closing window is, and attach a handler to that.
on_close() is the internal to toga event handler. It’s what you invoke when the window is closed.
Stanton
@stantonxu
Jun 01 05:20
thanks for quick response, I don’t quite understand the difference when you say, event for a closing window and handler to invoke when the window is closed.
Russell Keith-Magee
@freakboy3742
Jun 01 05:21
Toga is an abstraction layer. It presents a consistent API for connecting to Operating System signals.
Those signals are different on Mac and on Windows.
On Windows, a closing window triggers the “FormClosing” signal. On macOS, it’s something else
(I don’t actually know what it is off the top of my head, but I can guarantee it will exist)
Stanton
@stantonxu
Jun 01 05:23
Thanks. I will try to find out and work on it.
the “FormClosing” is for app close or window close?
Russell Keith-Magee
@freakboy3742
Jun 01 05:23
Window
(Winforms calls a "Window” a “Form”)
Stanton
@stantonxu
Jun 01 05:24
so for macOS, I need to find the window close API, but not the app close API, right?
Russell Keith-Magee
@freakboy3742
Jun 01 05:24
Correct
Stanton
@stantonxu
Jun 01 05:25
but on Mac, window close doesn’t mean app exit, usually app just minimized. on Windows, window close almost equals to app exit
Russell Keith-Magee
@freakboy3742
Jun 01 05:25
Open up Microsoft Word. Open two documents. Close one of them. Did Word exit?
Stanton
@stantonxu
Jun 01 05:26
aha, make sense
Stanton
@stantonxu
Jun 01 05:51
@freakboy3742 PR#535 submitted for merge approval
pybee/toga#535
Russell Keith-Magee
@freakboy3742
Jun 01 06:21
The reason is set ordering. So - have a poke around the test suite looking for “substitutions = {…}”, and see if you can work out how to make the test pass. If you get stuck, let me know.
ArchKudo
@ArchKudo
Jun 01 06:26
@freakboy3742 Ah, I see😅... Anyways thanks for replying! Also I have a pr open in comb, would be great if you could give some feedback!
Stanton
@stantonxu
Jun 01 16:45
@freakboy3742 , before I look into pybee/toga#535 for update, just want to clarify something with you. the pybee/toga#522 that @obulat implemented is for window close on Windows platform, but not for app close, right? the one I implemented on Cocoa is also for window close but not app close. That’s consistent I think. please correct me if I am wrong.
OK, I read @obulat ’s code again, I think I understand the different now. So we want to implement it for the main_window close.
not app, not every window