funced does not seem to make the function available #16
Milestone
Comments
|
Cool, I never knew about 'funded' or 'funcsave' |
|
s/funded/funced Darn you autocomplete. |
|
At least in fish and not fishfish ;) |
|
Uh, this also seems to work after your fixes on |
|
Yes, this ought to have been fixed by the changes in https://github.com/ridiculousfish/fishfish/issues/18 |
DarkStarSword
added a commit
to DarkStarSword/fish-shell
that referenced
this issue
Sep 10, 2012
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>
Closed
floam
added a commit
to floam/fish-shell
that referenced
this issue
Jul 24, 2016
Fish assumed that it could use could use tparm to set colors
as long as the color was under 16 or max_colors from terminfo
is 256 (term256_support_is_native):
if (idx < 16 || term256_support_is_native()) {
// Use tparm to emit color escape
writembs(tparm(todo, idx);
If a terminal has max_colors = 8, here is what happenened, except it was
inside fish:
> env TERM=xterm tput setaf 7 | xxd
00000000: 1b5b 3337 6d .[37m
> env TERM=xterm tput setaf 8 | xxd
00000000: 1b5b 3338 6d .[38m
That second escape is not valid. Colors 8 through 16 ought to be \e[90m.
This is what caused "white" not to work in fish-shell#3176 in Terminal.app, and
obviously isn't good for real low-color terminals either.
So we replace the term256_support_is_native(), which just checked if
max_colors is 256 or not, with a function that takes an argument and
checks terminfo for that to see if tparm can handle it. We only use this
test, because otherwise, tparm should be expected to output garbage:
...
/// Returns true if we think tparm can handle outputting a color index
static bool term_supports_color_natively(unsigned int c) { return max_colors >= c; }
...
if (term_supports_color_natively(idx) {
And if that's not true, the "forced" colors no longer use the fancy
format for colors under 16, as this is not going to be compatible with
the low color terminals:
else {
char buff[16] = "";
snprintf(buff, sizeof buff, "\x1b[%d;5;%dm", is_fg ? 38 : 48, idx);
I added an intermediate formatter that can handle colors 0-16:
else {
// We are attempting to bypass the term here. Generate the ANSI escape sequence ourself.
char buff[16] = "";
if (idx < 16) {
snprintf(buff, sizeof buff, "\x1b[%dm", ((idx > 7) ? 82 : 30) + idx + !is_fg * 10);
} else {
snprintf(buff, sizeof buff, "\x1b[%d;5;%dm", is_fg ? 38 : 48, idx);
}
Restores harmony to white, brwhite, brblack, black color names.
We don't want "white" to refer to color color fish-shell#16, but to the
standard color fish-shell#8. fish-shell#16 is "brwhite".
Move comments from output.h to output.cpp
Nuke the config.fish set_color hack for linux VTs.
Sync up our various incomplete color lists with bright hex values
being given for colors 0-8. Perplexing!
Using this table:
http://www.calmar.ws/vim/256-xterm-24bit-rgb-color-chart.html
Fixes fish-shell#3176
floam
added a commit
to floam/fish-shell
that referenced
this issue
Jul 24, 2016
Fish assumed that it could use could use tparm to set colors
as long as the color was under 16 or max_colors from terminfo
is 256 (term256_support_is_native):
if (idx < 16 || term256_support_is_native()) {
// Use tparm to emit color escape
writembs(tparm(todo, idx);
If a terminal has max_colors = 8, here is what happenened, except it was
inside fish:
> env TERM=xterm tput setaf 7 | xxd
00000000: 1b5b 3337 6d .[37m
> env TERM=xterm tput setaf 8 | xxd
00000000: 1b5b 3338 6d .[38m
That second escape is not valid. Colors 8 through 16 ought to be \e[90m.
This is what caused "white" not to work in fish-shell#3176 in Terminal.app, and
obviously isn't good for real low-color terminals either.
So we replace the term256_support_is_native(), which just checked if
max_colors is 256 or not, with a function that takes an argument and
checks terminfo for that to see if tparm can handle it. We only use this
test, because otherwise, tparm should be expected to output garbage:
...
/// Returns true if we think tparm can handle outputting a color index
static bool term_supports_color_natively(unsigned int c) { return max_colors >= c; }
...
if (term_supports_color_natively(idx) {
And if that's not true, the "forced" colors no longer use the fancy
format for colors under 16, as this is not going to be compatible with
the low color terminals:
else {
char buff[16] = "";
snprintf(buff, sizeof buff, "\x1b[%d;5;%dm", is_fg ? 38 : 48, idx);
I added an intermediate formatter that can handle colors 0-16:
else {
// We are attempting to bypass the term here. Generate the ANSI escape sequence ourself.
char buff[16] = "";
if (idx < 16) {
snprintf(buff, sizeof buff, "\x1b[%dm", ((idx > 7) ? 82 : 30) + idx + !is_fg * 10);
} else {
snprintf(buff, sizeof buff, "\x1b[%d;5;%dm", is_fg ? 38 : 48, idx);
}
Restores harmony to white, brwhite, brblack, black color names.
We don't want "white" to refer to color color fish-shell#16, but to the
standard color fish-shell#8. fish-shell#16 is "brwhite".
Move comments from output.h to output.cpp
Nuke the config.fish set_color hack for linux VTs.
Sync up our various incomplete color lists with bright hex values
being given for colors 0-8. Perplexing!
Using this table:
http://www.calmar.ws/vim/256-xterm-24bit-rgb-color-chart.html
Fixes fish-shell#3176
floam
added a commit
to floam/fish-shell
that referenced
this issue
Jul 24, 2016
Fish assumed that it could use could use tparm to set colors
as long as the color was under 16 or max_colors from terminfo
is 256 (term256_support_is_native):
if (idx < 16 || term256_support_is_native()) {
// Use tparm to emit color escape
writembs(tparm(todo, idx);
If a terminal has max_colors = 8, here is what happenened, except it was
inside fish:
> env TERM=xterm tput setaf 7 | xxd
00000000: 1b5b 3337 6d .[37m
> env TERM=xterm tput setaf 9 | xxd
00000000: 1b5b 3338 6d .[39m
The first escape is good, that second escape is not valid.
Bright colors should start at \e[90m:
> env TERM=xterm-16color tput setaf 9 | xxd
00000000: 1b5b 3931 6d .[91m
This is what caused "white" not to work in fish-shell#3176 in Terminal.app, and
obviously isn't good for real low-color terminals either.
So we replace the term256_support_is_native(), which just checked if
max_colors is 256 or not, with a function that takes an argument and
checks terminfo for that to see if tparm can handle it. We only use this
test, because otherwise, tparm should be expected to output garbage:
...
/// Returns true if we think tparm can handle outputting a color index
static bool term_supports_color_natively(unsigned int c) { return max_colors >= c; }
...
if (term_supports_color_natively(idx) {
And if that's not true, the "forced" colors no longer use the fancy
format for colors under 16, as this is not going to be compatible with
the low color terminals:
else {
char buff[16] = "";
snprintf(buff, sizeof buff, "\x1b[%d;5;%dm", is_fg ? 38 : 48, idx);
I added an intermediate formatter that can handle colors 0-16:
else {
// We are attempting to bypass the term here. Generate the ANSI escape sequence ourself.
char buff[16] = "";
if (idx < 16) {
snprintf(buff, sizeof buff, "\x1b[%dm", ((idx > 7) ? 82 : 30) + idx + !is_fg * 10);
} else {
snprintf(buff, sizeof buff, "\x1b[%d;5;%dm", is_fg ? 38 : 48, idx);
}
Restores harmony to white, brwhite, brblack, black color names.
We don't want "white" to refer to color color fish-shell#16, but to the
standard color fish-shell#8. fish-shell#16 is "brwhite".
Move comments from output.h to output.cpp
Nuke the config.fish set_color hack for linux VTs.
Sync up our various incomplete color lists with bright hex values
being given for colors 0-8. Perplexing!
Using this table:
http://www.calmar.ws/vim/256-xterm-24bit-rgb-color-chart.html
Fixes fish-shell#3176
floam
added a commit
to floam/fish-shell
that referenced
this issue
Jul 24, 2016
Fish assumed that it could use could use tparm to set colors
as long as the color was under 16 or max_colors from terminfo
is 256 (term256_support_is_native):
if (idx < 16 || term256_support_is_native()) {
// Use tparm to emit color escape
writembs(tparm(todo, idx);
If a terminal has max_colors = 8, here is what happenened, except it was
inside fish:
> env TERM=xterm tput setaf 7 | xxd
00000000: 1b5b 3337 6d .[37m
> env TERM=xterm tput setaf 9 | xxd
00000000: 1b5b 3338 6d .[39m
The first escape is good, that second escape is not valid.
Bright colors should start at \e[90m:
> env TERM=xterm-16color tput setaf 9 | xxd
00000000: 1b5b 3931 6d .[91m
This is what caused "white" not to work in fish-shell#3176 in Terminal.app, and
obviously isn't good for real low-color terminals either.
So we replace the term256_support_is_native(), which just checked if
max_colors is 256 or not, with a function that takes an argument and
checks terminfo for that to see if tparm can handle it. We only use this
test, because otherwise, tparm should be expected to output garbage:
/// Returns true if we think tparm can handle outputting a color index
static bool term_supports_color_natively(unsigned int c) { return max_colors >= c; }
...
if (term_supports_color_natively(idx) {
And if terminfo can't do it, the "forced" colors no longer use the fancy
format, when handling colors under 16, as this is not going to be compatible with
the low color terminals. This looks like an escape for 256-aware
terminals.
else {
char buff[16] = "";
snprintf(buff, sizeof buff, "\x1b[%d;5;%dm", is_fg ? 38 : 48, idx);
I added an intermediate formatter that can handle colors 0-16:
else {
// We are attempting to bypass the term here. Generate the ANSI escape sequence ourself.
char buff[16] = "";
if (idx < 16) {
snprintf(buff, sizeof buff, "\x1b[%dm", ((idx > 7) ? 82 : 30) + idx + !is_fg * 10);
} else {
snprintf(buff, sizeof buff, "\x1b[%d;5;%dm", is_fg ? 38 : 48, idx);
}
Restores harmony to white, brwhite, brblack, black color names.
We don't want "white" to refer to color color fish-shell#16, but to the
standard color fish-shell#8. fish-shell#16 is "brwhite".
Move comments from output.h to output.cpp
Nuke the config.fish set_color hack for linux VTs.
Sync up our various incomplete color lists and fix all color values.
Colors 0-8 are assumed to be brights - e.g. red was FF0000. Perplexing!
Using this table:
<http://www.calmar.ws/vim/256-xterm-24bit-rgb-color-chart.html>
Fixes fish-shell#3176
floam
added a commit
to floam/fish-shell
that referenced
this issue
Jul 24, 2016
Fish assumed that it could use tparm to emit escapes to set colors
as long as the color was under 16 or max_colors from terminfo was 256::
if (idx < 16 || term256_support_is_native()) {
// Use tparm to emit color escape
writembs(tparm(todo, idx);
If a terminal has max_colors = 8, here is what happenened, except
inside fish:
> env TERM=xterm tput setaf 7 | xxd
00000000: 1b5b 3337 6d .[37m
> env TERM=xterm tput setaf 9 | xxd
00000000: 1b5b 3338 6d .[39m
The first escape is good, that second escape is not valid.
Bright colors should start at \e[90m:
> env TERM=xterm-16color tput setaf 9 | xxd
00000000: 1b5b 3931 6d .[91m
This is what caused "white" not to work in fish-shell#3176 in Terminal.app, and
obviously isn't good for real low-color terminals either.
So we replace the term256_support_is_native(), which just checked if
max_colors is 256 or not, with a function that takes an argument and
checks terminfo for that to see if tparm can handle it. We only use this
test, because otherwise, tparm should be expected to output garbage:
/// Returns true if we think tparm can handle outputting a color index
static bool term_supports_color_natively(unsigned int c) { return max_colors >= c; }
...
if (term_supports_color_natively(idx) {
And if terminfo can't do it, the "forced" escapes no longer use the fancy
format when handling colors under 16, as this is not going to be compatible with
low color terminals. The code before used:
else {
char buff[16] = "";
snprintf(buff, sizeof buff, "\x1b[%d;5;%dm", is_fg ? 38 : 48, idx);
I added an intermediate format for colors 0-15:
else {
// We are attempting to bypass the term here. Generate the ANSI escape sequence ourself.
char buff[16] = "";
if (idx < 16) {
snprintf(buff, sizeof buff, "\x1b[%dm", ((idx > 7) ? 82 : 30) + idx + !is_fg * 10);
} else {
snprintf(buff, sizeof buff, "\x1b[%d;5;%dm", is_fg ? 38 : 48, idx);
}
Restores harmony to white, brwhite, brblack, black color names.
We don't want "white" to refer to color color fish-shell#16, but to the
standard color fish-shell#8. fish-shell#16 is "brwhite".
Move comments from output.h to output.cpp
Nuke the config.fish set_color hack for linux VTs.
Sync up our various incomplete color lists and fix all color values.
Colors 0-8 are assumed to be brights - e.g. red was FF0000. Perplexing!
Using this table:
<http://www.calmar.ws/vim/256-xterm-24bit-rgb-color-chart.html>
Fixes fish-shell#3176
floam
added a commit
to floam/fish-shell
that referenced
this issue
Jul 25, 2016
Fish assumed that it could use tparm to emit escapes to set colors
as long as the color was under 16 or max_colors from terminfo was 256::
if (idx < 16 || term256_support_is_native()) {
// Use tparm to emit color escape
writembs(tparm(todo, idx);
If a terminal has max_colors = 8, here is what happenened, except
inside fish:
> env TERM=xterm tput setaf 7 | xxd
00000000: 1b5b 3337 6d .[37m
> env TERM=xterm tput setaf 9 | xxd
00000000: 1b5b 3338 6d .[39m
The first escape is good, that second escape is not valid.
Bright colors should start at \e[90m:
> env TERM=xterm-16color tput setaf 9 | xxd
00000000: 1b5b 3931 6d .[91m
This is what caused "white" not to work in fish-shell#3176 in Terminal.app, and
obviously isn't good for real low-color terminals either.
So we replace the term256_support_is_native(), which just checked if
max_colors is 256 or not, with a function that takes an argument and
checks terminfo for that to see if tparm can handle it. We only use this
test, because otherwise, tparm should be expected to output garbage:
/// Returns true if we think tparm can handle outputting a color index
static bool term_supports_color_natively(unsigned int c) { return max_colors >= c; }
...
if (term_supports_color_natively(idx) {
And if terminfo can't do it, the "forced" escapes no longer use the fancy
format when handling colors under 16, as this is not going to be compatible with
low color terminals. The code before used:
else {
char buff[16] = "";
snprintf(buff, sizeof buff, "\x1b[%d;5;%dm", is_fg ? 38 : 48, idx);
I added an intermediate format for colors 0-15:
else {
// We are attempting to bypass the term here. Generate the ANSI escape sequence ourself.
char buff[16] = "";
if (idx < 16) {
snprintf(buff, sizeof buff, "\x1b[%dm", ((idx > 7) ? 82 : 30) + idx + !is_fg * 10);
} else {
snprintf(buff, sizeof buff, "\x1b[%d;5;%dm", is_fg ? 38 : 48, idx);
}
Restores harmony to white, brwhite, brblack, black color names.
We don't want "white" to refer to color color fish-shell#16, but to the
standard color fish-shell#8. fish-shell#16 is "brwhite".
Move comments from output.h to output.cpp
Nuke the config.fish set_color hack for linux VTs.
Sync up our various incomplete color lists and fix all color values.
Colors 0-8 are assumed to be brights - e.g. red was FF0000. Perplexing!
Using this table:
<http://www.calmar.ws/vim/256-xterm-24bit-rgb-color-chart.html>
Fixes fish-shell#3176
floam
added a commit
to floam/fish-shell
that referenced
this issue
Sep 11, 2016
Fish assumed that it could use tparm to emit escapes to set colors
as long as the color was under 16 or max_colors from terminfo was 256::
if (idx < 16 || term256_support_is_native()) {
// Use tparm to emit color escape
writembs(tparm(todo, idx);
If a terminal has max_colors = 8, here is what happenened, except
inside fish:
> env TERM=xterm tput setaf 7 | xxd
00000000: 1b5b 3337 6d .[37m
> env TERM=xterm tput setaf 9 | xxd
00000000: 1b5b 3338 6d .[39m
The first escape is good, that second escape is not valid.
Bright colors should start at \e[90m:
> env TERM=xterm-16color tput setaf 9 | xxd
00000000: 1b5b 3931 6d .[91m
This is what caused "white" not to work in fish-shell#3176 in Terminal.app, and
obviously isn't good for real low-color terminals either.
So we replace the term256_support_is_native(), which just checked if
max_colors is 256 or not, with a function that takes an argument and
checks terminfo for that to see if tparm can handle it. We only use this
test, because otherwise, tparm should be expected to output garbage:
/// Returns true if we think tparm can handle outputting a color index
static bool term_supports_color_natively(unsigned int c) { return max_colors >= c; }
...
if (term_supports_color_natively(idx) {
And if terminfo can't do it, the "forced" escapes no longer use the fancy
format when handling colors under 16, as this is not going to be compatible with
low color terminals. The code before used:
else {
char buff[16] = "";
snprintf(buff, sizeof buff, "\x1b[%d;5;%dm", is_fg ? 38 : 48, idx);
I added an intermediate format for colors 0-15:
else {
// We are attempting to bypass the term here. Generate the ANSI escape sequence ourself.
char buff[16] = "";
if (idx < 16) {
snprintf(buff, sizeof buff, "\x1b[%dm", ((idx > 7) ? 82 : 30) + idx + !is_fg * 10);
} else {
snprintf(buff, sizeof buff, "\x1b[%d;5;%dm", is_fg ? 38 : 48, idx);
}
Restores harmony to white, brwhite, brblack, black color names.
We don't want "white" to refer to color color fish-shell#16, but to the
standard color fish-shell#8. fish-shell#16 is "brwhite".
Move comments from output.h to output.cpp
Nuke the config.fish set_color hack for linux VTs.
Sync up our various incomplete color lists and fix all color values.
Colors 0-8 are assumed to be brights - e.g. red was FF0000. Perplexing!
Using this table:
<http://www.calmar.ws/vim/256-xterm-24bit-rgb-color-chart.html>
Fixes fish-shell#3176
2 tasks
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
This works:
This does not work:
The function was never made available when using
funced.This also makes that you can't use
funcsavefor some function edited withfunced-- because the functions doesn't exist.The text was updated successfully, but these errors were encountered: