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

Need to make Python scripts handle systems where python3 is the default #14

Closed
ridiculousfish opened this Issue May 30, 2012 · 10 comments

Comments

Projects
None yet
2 participants
@ridiculousfish
Member

ridiculousfish commented May 30, 2012

Currently fish's python scripts fail on systems where 'python' invokes Python3, like Arch Linux.

On these systems, we can get by with '#!/usr/bin/env python2' but that fails on OS X (which has no python2 symlink).

This bug tracks finding a resolution.

@adisbladis

This comment has been minimized.

Show comment
Hide comment
@adisbladis

This comment has been minimized.

Show comment
Hide comment
@adisbladis

adisbladis May 31, 2012

Contributor

I might add that this fix makes the scripts compatible with both python 2 and 3, so no matter which python "#!/usr/bin/env python" invokes this will work.

Contributor

adisbladis commented May 31, 2012

I might add that this fix makes the scripts compatible with both python 2 and 3, so no matter which python "#!/usr/bin/env python" invokes this will work.

@ridiculousfish

This comment has been minimized.

Show comment
Hide comment
@ridiculousfish

ridiculousfish Jun 1, 2012

Member

Thanks, you rock! I've merged this.

Member

ridiculousfish commented Jun 1, 2012

Thanks, you rock! I've merged this.

@ridiculousfish

This comment has been minimized.

Show comment
Hide comment
@ridiculousfish

ridiculousfish Jun 1, 2012

Member

I will leave this bug open to track the issue of other Python scripts, such as share/tools/web_config/webconfig.py .

Keeping these scripts compatible with Python2 and Python3 seems like it would be a lot of maintenance work. I would like to find a way to portable request Python2 (or 3) for all such scripts.

Member

ridiculousfish commented Jun 1, 2012

I will leave this bug open to track the issue of other Python scripts, such as share/tools/web_config/webconfig.py .

Keeping these scripts compatible with Python2 and Python3 seems like it would be a lot of maintenance work. I would like to find a way to portable request Python2 (or 3) for all such scripts.

@adisbladis

This comment has been minimized.

Show comment
Hide comment
@adisbladis

adisbladis Jun 2, 2012

Contributor

I think the effort should be to make the scripts python3 only.
Sure, python2 will be around for some considerable time to come but some GNU/Linux distributions (Arch Linux and Gentoo for example) are now shipped without python2.

I would like some external input on this so my efforts are not wasted.

Contributor

adisbladis commented Jun 2, 2012

I think the effort should be to make the scripts python3 only.
Sure, python2 will be around for some considerable time to come but some GNU/Linux distributions (Arch Linux and Gentoo for example) are now shipped without python2.

I would like some external input on this so my efforts are not wasted.

@ridiculousfish

This comment has been minimized.

Show comment
Hide comment
@ridiculousfish

ridiculousfish Jun 4, 2012

Member

We can't depend on Python 3 being installed at this point. It's not installed on too many OSes that matter, and I don't want to make Python 3 a requirement of fish, since we'd have to bundle it in installers, etc.

One thing we can do is make the fish wrapper functions that kick off the scripts (fish_update_completions, fish_config) invoke the Python scripts the correct way depending on the environment, by passing the script file directly to python or python2 as appropriate.

Another possibility is to ship both python2 and python3 versions of the scripts. Hopefully we can get the python2 scripts to the point that 2to3 does the conversion automatically, so it will be painless

Member

ridiculousfish commented Jun 4, 2012

We can't depend on Python 3 being installed at this point. It's not installed on too many OSes that matter, and I don't want to make Python 3 a requirement of fish, since we'd have to bundle it in installers, etc.

One thing we can do is make the fish wrapper functions that kick off the scripts (fish_update_completions, fish_config) invoke the Python scripts the correct way depending on the environment, by passing the script file directly to python or python2 as appropriate.

Another possibility is to ship both python2 and python3 versions of the scripts. Hopefully we can get the python2 scripts to the point that 2to3 does the conversion automatically, so it will be painless

@adisbladis

This comment has been minimized.

Show comment
Hide comment
@adisbladis

adisbladis Jun 5, 2012

Contributor

I have fixed the manpage parser for both versions in this merge request: https://gitorious.org/~ridiculousfish/fishfish/merge_requests/3

I intend to keep working on making all python scripts support both versions.

Contributor

adisbladis commented Jun 5, 2012

I have fixed the manpage parser for both versions in this merge request: https://gitorious.org/~ridiculousfish/fishfish/merge_requests/3

I intend to keep working on making all python scripts support both versions.

@niemeyer niemeyer referenced this issue Jun 5, 2012

Closed

Segfault on ~ #34

@adisbladis

This comment has been minimized.

Show comment
Hide comment
@adisbladis

adisbladis Jun 5, 2012

Contributor

I have created a new merge request for the final python3 fixes here:
https://gitorious.org/~ridiculousfish/fishfish/merge_requests/4

After this is merged this ticket can be closed :)

Contributor

adisbladis commented Jun 5, 2012

I have created a new merge request for the final python3 fixes here:
https://gitorious.org/~ridiculousfish/fishfish/merge_requests/4

After this is merged this ticket can be closed :)

@adisbladis

This comment has been minimized.

Show comment
Hide comment
@adisbladis

adisbladis Jun 6, 2012

Contributor

Request merged, can someone with permission close this?

Contributor

adisbladis commented Jun 6, 2012

Request merged, can someone with permission close this?

@ridiculousfish

This comment has been minimized.

Show comment
Hide comment
@ridiculousfish

ridiculousfish Jun 6, 2012

Member

Closed

Member

ridiculousfish commented Jun 6, 2012

Closed

DarkStarSword added a commit to DarkStarSword/fish-shell that referenced this issue Sep 10, 2012

Remove wperror causing pthreads weirdness
I'm not entirely sure what is going on, but on one machine I run fish on
a couple of times a day I find an instance of fish using 100% CPU.
Killing it never kills an interactive session, so it is presumably
something fish is doing in the background.

strace shows it repeatedly calling sys_FUTEX with an invalid op (0xef).
Since the op is invalid, the kernel returns -ENOSYS, but pthreads keeps
spinning hoping for success and uses 100% CPU.

The backtraces always look similar to:

> (gdb) bt
> #0  __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:136
> fish-shell#1  0x00007f9739351861 in pthread_rwlock_rdlock ()
>     at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_rwlock_rdlock.S:120
> fish-shell#2  0x00007f973884e778 in __dcigettext (domainname=<optimized out>, msgid1=0xef <Address 0xef out of bounds>,
>     msgid2=0x0, plural=-1, n=0, category=<optimized out>) at dcigettext.c:460
> fish-shell#3  0x00007f97388a0ad8 in *__GI___strerror_r (errnum=5, buf=0x0, buflen=0) at _strerror.c:65
> fish-shell#4  0x00007f97388a09de in strerror (errnum=951726048) at strerror.c:33
> fish-shell#5  0x000000000050f15e in wperror(std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&) ()
> fish-shell#6  0x00000000004cfd0b in do_builtin_io(char const*, char const*) ()
> fish-shell#7  0x00000000004d1038 in exec(parser_t&, job_t*) ()
> fish-shell#8  0x00000000004f1ed8 in parser_t::eval_job(tokenizer*) ()
> fish-shell#9  0x00000000004f2629 in parser_t::eval(std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&, io_
> fish-shell#10 0x00000000004cfb9c in internal_exec_helper(parser_t&, wchar_t const*, block_type_t, io_chain_t&) ()
> fish-shell#11 0x00000000004d07bc in exec(parser_t&, job_t*) ()
> fish-shell#12 0x00000000004f1ed8 in parser_t::eval_job(tokenizer*) ()
> fish-shell#13 0x00000000004f2629 in parser_t::eval(std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&, io_
> fish-shell#14 0x000000000051fac0 in event_fire_internal(event_t const*) ()
> fish-shell#15 0x00000000005200c7 in event_fire(event_t*) ()
> fish-shell#16 0x00000000004f8a5e in proc_fire_event(wchar_t const*, int, int, int) ()
> fish-shell#17 0x000000000053ee7b in main ()

There is some weirdness here - in particular, the errnum passed to
strerror randomises (but is never sensible), the msgid1 is passed as
0xef (i.e. the same as the op passed to sys_FUTEX).

Until I better understand what is going on, remove the wperror call that
is present in every backtrace. I'll keep an eye on things and see if it
happens again.

Signed-off-by: Ian Munsie <darkstarsword@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment