Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixes #290: pyPrint accepts any filelike, with sys.stdout fallback #90

Open
alanjds opened this issue Oct 6, 2018 · 4 comments
Open
Labels
imported PR Pull Request imported from google/grumpy

Comments

@alanjds
Copy link

alanjds commented Oct 6, 2018

google#304 opened on May 1, 2017 by @alanjds

Gets sys.stdout from SysmoduleDict['stdout'], that exists and could be replaced (after #70 got merged)

pyPrint allows any filelike *Object to be printed to.

TBD: Factor out the method invocation logic to some func (o *Object) Invoke(f *Frame, method *Str)

@alanjds
Copy link
Author

alanjds commented Oct 6, 2018

Comment by alanjds
Tuesday Jun 13, 2017 at 14:35 GMT


Have no idea why this is broke. Halp.
screen shot 2017-06-13 at 11 34 43

Left is OSX. Right is Linux

@alanjds
Copy link
Author

alanjds commented Oct 6, 2018

Comment by trotterdylan
Wednesday Jun 14, 2017 at 14:29 GMT


The types_test failure is because types.py defines ModuleType as type(sys) and types_test checks that it's the same type as go.grumpy.ModuleType. sys is now a different kind of object.

I would remove that line from types.py and add from __go__.grumpy import ModuleType to the top of that file.

The other issue is a transient failure due to a race condition in TestRunMain. I can trigger it reasonably consistently as follows:

$ GOPATH=$PWD/build go test grumpy -test.run=TestRunMain -count=100
--- FAIL: TestRunMain (0.00s)
	module_test.go:300: runMainRedirectStderr() failed: read |0: bad file descriptor
	module_test.go:300: runMainRedirectStderr() failed: read |0: bad file descriptor
	module_test.go:300: runMainRedirectStderr() failed: read |0: bad file descriptor
	module_test.go:300: runMainRedirectStderr() failed: read |0: bad file descriptor
FAIL
FAIL	grumpy	0.047s

I think this is similar to google#282. This is not due to your change. Just restart the build if you encounter that again.

@alanjds
Copy link
Author

alanjds commented Oct 6, 2018

Comment by alanjds
Friday Jun 16, 2017 at 16:37 GMT


OSX: Thanks. Will take a look on types.py. I had used the import errno; type(errno) on the "hack module" as errno is a so simpler module. Is this acceptable for you?

Linux: Good to know. However, how can I restart the build on Travis? Last time I had sent a pointless commit to trigger it, but this adds noise to the history.

@alanjds
Copy link
Author

alanjds commented Oct 6, 2018

Comment by alanjds
Friday Jun 16, 2017 at 23:19 GMT


I had hit another strange error here, on itertools_test.py:

NameError: name '__name__' is not defined
exit status 1

Bisected and found its root on f745cdb, but it makes no sense.

As this PR will not be merged until __getattr__ is working, will leave it as is. This seems as a symptom of another undiscovered bug on the module/types stuff.

@alanjds alanjds added the imported PR Pull Request imported from google/grumpy label Oct 6, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
imported PR Pull Request imported from google/grumpy
Projects
None yet
Development

No branches or pull requests

1 participant