http://permalink.gmane.org/gmane.comp.lib.ncurses.bugs hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.lib.ncurses.bugs/4147 <pre> dialog turns on xterm mouse support if ncurses thinks it is available. That's if $TERM contains "xterm" or if the kmous string in the corresponding terminal description looks like xterm's, e.g., kmous=\E[M, You could define a non-mouse description and compile that with tic... </pre> Thomas Dickey 2010-03-12T11:35:50 http://permalink.gmane.org/gmane.comp.lib.ncurses.bugs/4146 <pre>On Tue, 09 Mar 2010 12:56:04 +0100, Bernhard Rosenkraenzer &lt;bero&lt; at &gt;arklinux.org&gt; wrote: a the Comparing what happens when I build it for x86_64 with what happens when building it for arm, the difference that matters is that the native build passes -D_GNU_SOURCE while the crosscompiler build doesn't. If I force -D_GNU_SOURCE into BUILD_CCFLAGS, the problem goes away. ttyl bero </pre> Bernhard Rosenkraenzer 2010-03-09T12:18:01 http://permalink.gmane.org/gmane.comp.lib.ncurses.bugs/4145 <pre>Hi, ncurses 5.7 compiles and works fine on x86_64, but when I try to crosscompile it to armv6j-unknown-linux-gnueabi, I get (while compiling a tool that is run on the x86_64 build machine, not even while building the arm lib): gcc -o make_hash -DHAVE_CONFIG_H -I../ncurses -I. -I./../include -I../include ./tinfo/make_hash.c In file included from ./tinfo/make_hash.c:40:0: ../ncurses/curses.priv.h:559:2: error: expected specifier-qualifier-list before ‘cchar_t’ ../ncurses/curses.priv.h:615:2: error: expected specifier-qualifier-list before ‘cchar_t’ ../ncurses/curses.priv.h:909:2: error: expected specifier-qualifier-list before ‘cchar_t’ In file included from ./tinfo/make_hash.c:40:0: ../ncurses/curses.priv.h:1689:1: warning: parameter names (without types) in function declaration ../ncurses/curses.priv.h:1690:31: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘_nc_to_widechar’ ../ncurses/curses.priv.h:1724:48: error: expected declaration specifiers or ‘.</pre> Bernhard Rosenkraenzer 2010-03-09T11:56:04 http://permalink.gmane.org/gmane.comp.lib.ncurses.bugs/4144 <pre>(If this isn't the proper forum for my question let me know if there is a better place.) I'm writing a bash script using dialog as the UI and would like to disable/ignore mouse clicks/events. Is this possible to do from the command-line? I do not see any mention of this in the dialog man page. Any help is greatly appreciated. Please cc me to any replies as I am not a member of the list. Thanks Josh </pre> Josh Hunt 2010-03-09T01:40:47 http://permalink.gmane.org/gmane.comp.lib.ncurses.bugs/4143 <pre>_______________________________________________ Bug-ncurses mailing list Bug-ncurses&lt; at &gt;gnu.org http://lists.gnu.org/mailman/listinfo/bug-ncurses </pre> Thomas Dickey 2010-03-07T00:41:28 http://permalink.gmane.org/gmane.comp.lib.ncurses.bugs/4142 <pre> The change then didn't actually work (portably for sure), and none of the platforms that I could test on had a C runtime that could exercise the change (and need it...). By coincidence, I hit the same issue with vile this week (predictably, for glibc on amd64). So I worked through the kinks in the configure check to make it usable, and can add that to ncurses. </pre> Thomas Dickey 2010-03-03T21:41:48 http://permalink.gmane.org/gmane.comp.lib.ncurses.bugs/4141 <pre>Compiling ncurses-5.7 on macosx-x86_64, I find that it segfaults frequently within _nc_printf_string() in printw(). The reason seems to be the way that the va_list is used twice (once to compute the buffer's length, and once to actually format the string). Like some other architectures with a register passing convention, va_list on this machine is a (pointer to a) structure, not a simple pointer to stack memory as it is on an i386 or vax, and so the implicit copy made by a function call doesn't actually keep the caller's argument pointer from being modified by the callee. The solution is pretty simple, to use va_copy() to explicitly make a copy of the argument pointer. It looks like an (unrelated?) use of va_copy was added and then reverted in 20061202/20061217, though, so I'm not sure what issue needs to be dealt with in order to use va_copy(). (Perhaps just an autoconf test for its existence?) I'd guess that this problem affects other architectures too --- I've had to make similar changes in</pre> Wim Lewis 2010-03-03T06:59:28 http://permalink.gmane.org/gmane.comp.lib.ncurses.bugs/4140 <pre>_______________________________________________ Bug-ncurses mailing list Bug-ncurses&lt; at &gt;gnu.org http://lists.gnu.org/mailman/listinfo/bug-ncurses </pre> Thomas Dickey 2010-02-28T01:39:52 http://permalink.gmane.org/gmane.comp.lib.ncurses.bugs/4139 <pre> Televideo's terminals don't have a lot of consistency across versions. Other than contacting the manufacturer directly, I don't think so. All they seem to have on their website for download is the spec-sheet. http://www.televideo.com/TeleVideo/TeleVideo_995_Alpha_new.htm http://www.televideo.com/TeleVideo/TeleVideo_995-65_Terminal_new.htm google found a _user_ manual on scribd, but I doubt that is useful (I just read through it now). http://www.scribd.com/doc/4896617/televideo-tvi-99565-users-manual-guide </pre> Thomas Dickey 2010-02-27T21:31:34 http://permalink.gmane.org/gmane.comp.lib.ncurses.bugs/4138 <pre>I have a Televideo 995 and also what I believe to be the latest version of the terminfo data installed on my Fedora 10 system. There is no entry for the 995 in my terminfo data. If I try to use something like tvi955 or tvi970 I have problems with the vi editor turning off the blinking cursor mode. I then have to reset the terminal. The terminal setup feature has a choice of 995, 955 or 950 "personalitys". My choice of any of these three doesn't seem to make a difference in the problem I mentioned or in keyboard capabilities. Do you have any more information on this particular terminal or possibly you can tell me where to look? </pre> Jim Eitel on s1598 2010-02-27T20:55:01 http://permalink.gmane.org/gmane.comp.lib.ncurses.bugs/4137 <pre>This diff fixes a typo. Regards, Tim --- man/wresize.3x.origSat Feb 25 22:47:06 2006 +++ man/wresize.3xSat Feb 27 17:43:41 2010 &lt; at &gt;&lt; at &gt; -41,7 +41,7 &lt; at &gt;&lt; at &gt; window to adjust its dimensions to the specified values. If either dimension is larger than the current values, the window's data is filled with blanks that have the current background rendition -(as set by \fBwbkgndset\fR) merged into them. +(as set by \fBwbkgdset\fR) merged into them. .SH RETURN VALUE The function returns the integer \fBERR\fR upon failure and \fBOK\fR on success. It will fail if either of the dimensions less than or equal to zero, </pre> Tim van der Molen 2010-02-27T16:56:41 http://permalink.gmane.org/gmane.comp.lib.ncurses.bugs/4136 <pre>Hi. I'm trying to create a modified libncurses so that an AI can "see" what is on the screen, and "type" commands. Then I inject the modified libncurses into arbitrary curses-using binaries via LD_PRELOAD. The goal is to replicate Rog-o-matic - http://www.cs.princeton.edu/~appel/papers/rogomatic.html - a 1984 expert system that played Rogue. The only way that I've found to hook the AI's "eyes" into libncurses is via _tracedmp "newscr". However, that means turning on tracing, which puts lots of information out into the trace file, and it seems a little clumsy. Is there a better place to modify to see each new screen? Johnicholas diff -Naur a/ncurses/trace/lib_tracedmp.c b/ncurses/trace/lib_tracedmp.c --- a/ncurses/trace/lib_tracedmp.c 2008-08-16 15:30:56.000000000 -0400 +++ b/ncurses/trace/lib_tracedmp.c 2010-02-23 12:36:54.000000000 -0500 &lt; at &gt;&lt; at &gt; -38,6 +38,7 &lt; at &gt;&lt; at &gt; #include &lt;curses.priv.h&gt; #include &lt;ctype.h&gt; +#include "soar-curses-link.h" MODULE_ID("$Id: lib_tracedmp.c,v 1.31 2008/08/16 19:30:56 tom Exp $")</pre> Johnicholas Hines 2010-02-25T18:33:23 http://permalink.gmane.org/gmane.comp.lib.ncurses.bugs/4135 <pre> curses as such doesn't do _that_, since it operates on either the whole screen, or on a single line. Instead, you could use the lower-level terminfo calls to do some of this (move the cursor, write text using the terminal capabilities that make it bold, colored or whatever you need). But there's a part that isn't in either - determining where the cursor was orginally on the screen. That could be done as in the resize program (bundled with xterm), which reads the vt100-style cursor position report. Even with those, you'd still be limited to working with relatively static shell prompts (even when flushing I/O) since interrupting another program that sends escape sequences to the terminal, such as a text editor would make occasional messes on the screen. That's all doable - enjoy... </pre> Thomas Dickey 2010-02-25T01:45:54 http://permalink.gmane.org/gmane.comp.lib.ncurses.bugs/4134 <pre>_______________________________________________ Bug-ncurses mailing list Bug-ncurses&lt; at &gt;gnu.org http://lists.gnu.org/mailman/listinfo/bug-ncurses </pre> Ahmed Raafat 2010-02-25T01:13:53 http://permalink.gmane.org/gmane.comp.lib.ncurses.bugs/4133 <pre>Hi everybody, Let me introduce myself. I am a French professor (of physics) at the university of Toulouse, and as a hobby, I build gnu/linux systems from scratch. May seem weird. Well, some repair old cars. I build systems... Right now, I am trying to build a whole system by faking cross compilation, in order to insulate the new system executables and (specially) libraries from the old. That is how I found the following bug in ncurses: When cross-compiling, the variable ac_cv_func_mkstemp is set to yes or no depending on whether mkstemp can be linked or not, while in a native build, it is the variable cf_cv_func_mkstemp which is used. This results in HAVE_MKSTEMP not being set in the case of cross-compiling, even if mkstemp can be linked. I do not know if it is on purpose. However the logic is clearly wrong... Here is a patch: ---------------------------- --- ncurses-5.7.old/aclocal.m4 2010-02-23 12:33:35.000000000 +0100 +++ ncurses-5.7/aclocal.m4 2010-02-23 12:18:53.000000000 +0100 &lt; at &gt;&lt; at &gt; -372</pre> Pierre Labastie 2010-02-23T18:57:16 http://permalink.gmane.org/gmane.comp.lib.ncurses.bugs/4132 <pre>_______________________________________________ Bug-ncurses mailing list Bug-ncurses&lt; at &gt;gnu.org http://lists.gnu.org/mailman/listinfo/bug-ncurses </pre> Thomas Dickey 2010-02-21T02:28:23 http://permalink.gmane.org/gmane.comp.lib.ncurses.bugs/4131 <pre>Hi Thomas, dear colleagues, the file man/form_field_opts.3x in the latest ncurses release (5.7) contains a syntax error: According to groff_man(7), the .TP macro must be followed by a line of text, to be used as a label, so putting it right before .SH is wrong. While groff(1) just ignores the problem, mandoc(1) aborts compilation and prints an error message, so i needed to fix this in the OpenBSD tree. Certainly not a big deal, but it would be nice if we could keep in sync. Thank you for maintaining ncurses! Yours, Ingo Index: form_field_opts.3 =================================================================== RCS file: /cvs/src/lib/libform/form_field_opts.3,v retrieving revision 1.10 diff -u -r1.10 form_field_opts.3 --- form_field_opts.312 Jan 2010 23:22:07 -00001.10 +++ form_field_opts.317 Feb 2010 23:29:39 -0000 &lt; at &gt;&lt; at &gt; -108,7 +108,6 &lt; at &gt;&lt; at &gt; System error occurred (see \fBerrno\fR). .SH SEE ALSO \fBcurses\fR(3), \fBform\fR(3). -.TP 5 .SH NOTES The header file \fB&lt;form.h&gt;\fR automatically includes </pre> Ingo Schwarze 2010-02-17T23:51:23 http://permalink.gmane.org/gmane.comp.lib.ncurses.bugs/4130 <pre>_______________________________________________ Bug-ncurses mailing list Bug-ncurses&lt; at &gt;gnu.org http://lists.gnu.org/mailman/listinfo/bug-ncurses </pre> Thomas Dickey 2010-02-14T00:02:09 http://permalink.gmane.org/gmane.comp.lib.ncurses.bugs/4129 <pre>_______________________________________________ Bug-ncurses mailing list Bug-ncurses&lt; at &gt;gnu.org http://lists.gnu.org/mailman/listinfo/bug-ncurses </pre> Thomas Dickey 2010-02-07T01:45:36 http://permalink.gmane.org/gmane.comp.lib.ncurses.bugs/4128 <pre>_______________________________________________ Bug-ncurses mailing list Bug-ncurses&lt; at &gt;gnu.org http://lists.gnu.org/mailman/listinfo/bug-ncurses </pre> Thomas Dickey 2010-01-31T01:33:46 http://permalink.gmane.org/gmane.comp.lib.ncurses.bugs/4127 <pre> generally yes. Someone else from your company has been trying to cross-compile shared-libraries, and not succeeding. (The configure script doesn't know about that combination). </pre> Thomas Dickey 2010-01-28T09:56:47 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lib.ncurses.bugs