Linux-Development-Apps Digest #403, Volume #7    Tue, 15 May 01 03:13:13 EDT

Contents:
  Re: Public Domain CODEC ("Year0.com")
  Re: compiling for multi processors (Grahame Kelly)
  Updated version of UPS debugger available (Rod Armstrong)
  Re: capturing spawned program output in C (Ya!Right!)
  gtk_signal_connect() and passing user data ("IPEUser")
  Re: gtk_signal_connect() and passing user data ("IPEUser")
  Getting Open-Source Applications Promoted ([EMAIL PROTECTED])
  Re: key press (Floyd Davidson)
  Re: How do I kill a task that does not want to get removed from ps x with kill? 
(Rolf Magnus)
  Re: How do I kill a task that does not want to get removed from ps x with kill? (Kaz 
Kylheku)
  Re: key press (Kaz Kylheku)
  Re: key press (Kaz Kylheku)
  Re: key press (Kaz Kylheku)
  Re: key press (Kaz Kylheku)
  Re: Two questions on .so libs (Kaz Kylheku)
  Re: Two questions on .so libs (Kaz Kylheku)
  Re: Public Domain CODEC (Rolf Magnus)
  Re: Public Domain CODEC (Rolf Magnus)

----------------------------------------------------------------------------

From: "Year0.com" <[EMAIL PROTECTED]>
Crossposted-To: misc.writing.screenplays,alt.movies.independent
Subject: Re: Public Domain CODEC
Date: Mon, 14 May 2001 23:17:56 -0400

"Wickerman : Year 0"...available on Freeview divx cd
www.year0.com

Pat Crean <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I don't mind ignoring him --- I do find it annoying having to ignore him
> TWICE because nobody is smart enough to notice that
> comp.os.linux.development.apps is duplicated in the address list.  Please
> adjust your cross posts if you reply to any of these posts.
>
> Thanks
>
>
> "Anthony Stephens" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > The thing is, Jaeger posts his crap all the time in
> misc.writing.screenplays
> >
> > Best thing to do is ignore him. He is incapable of rational thought and
> thinks
> > that everyone in Hollywood has an agenda to stifle creativity. He thinks
> this
> > because he can't get anyone to pay for his movie, which, frankly, is
> stupid, or
> > at best, poorly written. But rather than acknowledge that he lacs talent
> and
> > needs to work on his writing skills, he attacks the "Hollywood Jews"
> instead.
> >
>
>
>



------------------------------

From: [EMAIL PROTECTED] (Grahame Kelly)
Subject: Re: compiling for multi processors
Date: Tue, 15 May 2001 03:40:26 GMT

        Steve Connet <[EMAIL PROTECTED]> writes:
> Is there anything special you have to do in your code or
> compiling/linking when your app is going to run on a multi-processor
> machine as opposed to a single processor machine?
> In particular, an app that uses X?

Not really. The only thing that a application developer needs to
keep in mind is in using multi-threading SMP complexity increases.
Hence some of the libraries you may utilise (eg.Libc, KDE or X) may not
be necessarily thread safe and if they are, they may not be thread
safe when used in SMP (especially with regards to resource lockout).

I have read that many issues abound (both in the kernel, device driver
module and at user level) which can and do present reliability issues.

I am sure someone more technically aware of these issues will post a followup
to clear the air.

Cheers, Grahame

-- 

------------------------------

From: Rod Armstrong <[EMAIL PROTECTED]>
Crossposted-To: comp.unix.programmer,comp.sys.sun.apps,comp.unix.solaris
Subject: Updated version of UPS debugger available
Date: Thu, 10 May 2001 15:37:17 -0700
Reply-To: [EMAIL PROTECTED]

From: <[EMAIL PROTECTED]>
Subject: Updated version of UPS debugger available
Summary: version 3.36 released
Keywords: UPS debugger C/C++

   The 3.36 release of the UPS debugger is now available. It is
currently at 

   http://www.concerto.demon.co.uk/UPS/src/ups-3.36.tar.gz 
   ftp://metalab.unc.edu/pub/Linux/devel/debuggers/ups-3.36.tar.gz 

   It is also available at other standard X11 sites, such as ftp.x.org.
See 
   the UPS web site for details: http://www.concerto.demon.co.uk/UPS 

   For those unfamilar with UPS, it is an UNIX source level debugger for 
   C, C++ and Fortran, using X11. It is small and self contained, not
layered 
   on any other debug code. 

   Most testing has been done on Sun Solaris systems, but it should
build 
   and work on various Linux flavors, such as Debian, Slackware and Red
Hat, 
   as well as FreeBSD. There is a beta port for BSD/OS as well. 

   The 3.36 version allows one to debug different targets within one
session,
   easily load libraries on the fly, and includes various bug fixes.

   Rod Armstrong 
   [EMAIL PROTECTED]

------------------------------

From: Ya!Right! <[EMAIL PROTECTED]>
Subject: Re: capturing spawned program output in C
Date: Tue, 15 May 2001 00:23:36 -0700

I remember asking the same question a while back, then I found the perfect 
book that answers all those pesky questions.
Advanced Programming in the UNIX Environment, by W. Richard Stevens
Published by Addion-Wesley
ISBN 0-201-56317-7

Hope this helps.

Joseph Virzi wrote:

> From within a program, written in C, I need to
> 
> a. launch another application which performs a printf
> b. capture the text
> 
> Example:
> 
> Say I have an application, "ADD", which performs a printf of the sum of
> the arguments passed. From the command line, it would look like this
> 
> $./ADD 45 65 29 <ENTER>
> RESULT=139
> 
> Now, I want to invoke this from another application and capture the
> "RESULT=139" into a character string for further processing:
> 
> Example:
> 
> char result_string[128];
> 
> main(int argc,char **argv)
> {
> 
>     xxxxxx("ADD 45 65 29");
> 
>     printf("return string from ADD = %s", result_string);
>     message_log(result_string);
> }
> 
> The question is what would xxxxxx() be, and how can I retrieve its
> output to stdout?
> 
> I could cheat and have ADD send the output to a file, which I then open
> and get the result. I know there's a better way, though.
> 
> Thanks in advance.
> 
> -Joe
> 
> 


------------------------------

From: "IPEUser" <[EMAIL PROTECTED]>
Crossposted-To: comp.unix.programmer
Subject: gtk_signal_connect() and passing user data
Date: Tue, 15 May 2001 14:26:39 +1000

Hi,

int i = 1456;
....
gtk_signal_connect(GTK_OBJECT(button), "button_press_event",
GTK_SIGNAL_FUNC(button_callback), (gpointer) i);
....

void button_callback(GtkWidget *widget, gpointer data)
{
    g_print("i: %i\n", data);
}

The above is an extract from a program I'm doing.  I seem to have a problem
passing data to my callback function.  The "g_print" does not print 1456 as
expected, but instead 134736392.  I have no idea why.

Any ideas?

[EMAIL PROTECTED]




------------------------------

From: "IPEUser" <[EMAIL PROTECTED]>
Crossposted-To: comp.unix.programmer
Subject: Re: gtk_signal_connect() and passing user data
Date: Tue, 15 May 2001 14:46:13 +1000


"IPEUser" <[EMAIL PROTECTED]> wrote in message
news:9c2M6.1270$[EMAIL PROTECTED]...
> Hi,
>
> int i = 1456;
> ....
> gtk_signal_connect(GTK_OBJECT(button), "button_press_event",
> GTK_SIGNAL_FUNC(button_callback), (gpointer) i);
> ....
>
> void button_callback(GtkWidget *widget, gpointer data)
> {
>     g_print("i: %i\n", data);
> }
>
> The above is an extract from a program I'm doing.  I seem to have a
problem
> passing data to my callback function.  The "g_print" does not print 1456
as
> expected, but instead 134736392.  I have no idea why.
>
> Any ideas?
>
> [EMAIL PROTECTED]
>

Oh, and:

g_print("i: %i\n", * ((int *) data));

... prints 4, no matter if I pass (gpointer) i or (gpointer) &i);

It looks like no matter what I try to pass in, it's total crap.

*sigh*




------------------------------

From: [EMAIL PROTECTED]
Subject: Getting Open-Source Applications Promoted
Date: Tue, 15 May 2001 05:04:38 GMT

There is a lot of Open-Source products out there.  Some are easy to
use,  Some more difficult.  Open Country  http://www.opencountry.org
is trying to build a new delivery mechanism by simplfying installation
and launch of these applications.  As one of our engineers said
recently:  What I am trying to do now within the [open-source]
movement is: 

1. Expand the range and depth of development. Opening the doors of
Open Source to even more participants.

2. Create incentive to inovate.

3. Promote Open Source OS's as desktop/office/handheld OS of choice.

4. Take the best that the Cathedral has to offer and install it into
the bazaar.

5. Give business the "warm fuzzy" that it needs to promote the use of
Open Source software in thier day to day work (ie the desktop in the
cubicle)

6. Move the ability to use Open Source software from the geek to the
meek, in other words make it simple enough for my mother to use.

7. Create an organization that is as resposive to the community of
users as possible.

Did we succeed?

Use  the feedback forms at http://www.opencountry.org 


------------------------------

From: Floyd Davidson <[EMAIL PROTECTED]>
Subject: Re: key press
Date: 14 May 2001 21:06:36 -0800

Steve Connet <[EMAIL PROTECTED]> wrote:
>Rene Herman <[EMAIL PROTECTED]> writes:
>
>> Still, he does seem to have somewhat of a point. Getchar would be
>> completely useless to the OP.
>
>Ugh, I often forget about the differences between MS os's and *nix
>os's when writing some code.
>
>On MS os's a function exists in <conio.h> called kbhit(). You wait
>until kbhit() returns true then you getchar(). That's how you do it.
>
>Apparently in *nix os's it isn't that easy. You must use low level
>stuff in termios.h.
>
>The following link has code to simulate MS's kbhit() function:
>
>http://www.control.auc.dk/~jnn/c2000/programs/mm5/keyboardhit/msg02541.html

However, if you go back and read the original post...  this is
still not going to help a bit.  It didn't ask for a function to
get character by character raw keyboard input.  It did ask how
to detect both key down and key up.  That is a whole different
animal.  kbhit() and getchar() won't do.

-- 
Floyd L. Davidson         <http://www.ptialaska.net/~floyd>
Ukpeagvik (Barrow, Alaska)                 [EMAIL PROTECTED]

------------------------------

From: Rolf Magnus <[EMAIL PROTECTED]>
Subject: Re: How do I kill a task that does not want to get removed from ps x with 
kill?
Date: Tue, 15 May 2001 08:06:57 +0200

Roland Smith wrote:

> Normally only a reboot can solve this, AFAIK. Maybe if the driver for
> /dev/video is a module, unloading and reloading the module might help.

This probably won't work because the driver's usage count isn't 0 (the 
sleeping proces is still using it), so it cannot be unloaded.

------------------------------

From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: How do I kill a task that does not want to get removed from ps x with 
kill?
Reply-To: [EMAIL PROTECTED]
Date: Tue, 15 May 2001 06:18:23 GMT

On 14 May 2001 22:19:17 +0200, Roland Smith <[EMAIL PROTECTED]> wrote:
>I think this is mostly due to a faulty driver, that puts the program to
>sleep but doesn't wake it properly.
>
>Normally only a reboot can solve this, AFAIK. Maybe if the driver for
>/dev/video is a module, unloading and reloading the module might help.

How are you going to unload the module if the sleeping process holds a
reference? Unloading a module in which a process is sleeping could be
disastrous should that process ever wake, because then it's going to
want to continue executing the module's code.

------------------------------

From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: key press
Reply-To: [EMAIL PROTECTED]
Date: Tue, 15 May 2001 06:27:41 GMT

On Tue, 15 May 2001 00:26:43 GMT, Steve Connet <[EMAIL PROTECTED]>
wrote:
>"Neil Butterworth" <[EMAIL PROTECTED]> writes:
>
>> Sorry, could you explain exactly how getchar() addresses the OP's
>> requirement?
>
>Must I also killfile you here in this newsgroup as well? You are such
>an annoyance. The majority of posts I've seen from you are
>condescending. Please, don't reply to my posts. You're a jerk.

So in other words, you cannot explain how getchar addresses the requirements
when asked to do so. That could be because getchar doesn't address the
requirements, and you aren't sufficiently creative to at least make up an
entertaining fiction.

Without doing special things, getchar will suspend the calling process by doing
blocking reads from the tty.  What's worse, the tty driver will block the
process until an entire line of input is obtained.

The original poster's requirement was stated in a way which makes it obvious
that a non-blocking or asynchronous input method is required: something is to
begin executing when a key is pressed, and stop executing when another key is
pressed.  

The getchar function can be used to obtain this behavior on POSIX systems
provided that a bunch of things are set up.  Now if someone asks me how, I may
just tell them without resorting to name calling.

------------------------------

From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: key press
Reply-To: [EMAIL PROTECTED]
Date: Tue, 15 May 2001 06:48:38 GMT

On Tue, 15 May 2001 00:26:43 GMT, Steve Connet <[EMAIL PROTECTED]>
wrote:
>"Neil Butterworth" <[EMAIL PROTECTED]> writes:
>
>> Sorry, could you explain exactly how getchar() addresses the OP's
>> requirement?
>
>Must I also killfile you here in this newsgroup as well? You are such
>an annoyance. The majority of posts I've seen from you are
>condescending. Please, don't reply to my posts. You're a jerk.

So in other words, you cannot explain how getchar addresses the requirements
when asked to do so. That could be because getchar doesn't address the
requirements, and you aren't sufficiently creative to at least make up an
entertaining fiction.

Without doing special things, getchar will suspend the calling process by doing
blocking reads from the tty.  What's worse, the tty driver will block the
process until an entire line of input is obtained.

The original poster's requirement was stated in a way which makes it obvious
that the detection of key press and release events is also required.
Some function is to begin executing when a key is struck, and then stop
executing when the key is released. Ever play games where, for instance,
your ship thrusts while you are holding down shift?

The getchar function can be used to obtain non-blocking input behavior on POSIX
systems provided that a bunch of things are set up in a standard way, but it
won't provide the individual press and release events.

------------------------------

From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: key press
Reply-To: [EMAIL PROTECTED]
Date: Tue, 15 May 2001 06:43:44 GMT

On Mon, 14 May 2001 18:47:33 +0200, R@FooN <[EMAIL PROTECTED]> wrote:
>hi all ,
>I'm using C++ to write a proggy to controle a robot,
>but I have a problem.
>I need something like ;
>if I press a key (arrow key) a function starts
> and stops when I release the key ??

If you write this under XWindow, you can obtain XEvents
representing key presses and releases.

------------------------------

From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: key press
Reply-To: [EMAIL PROTECTED]
Date: Tue, 15 May 2001 06:40:25 GMT

On Tue, 15 May 2001 02:26:45 GMT, Steve Connet <[EMAIL PROTECTED]>
wrote:
>Rene Herman <[EMAIL PROTECTED]> writes:
>
>> Still, he does seem to have somewhat of a point. Getchar would be
>> completely useless to the OP.
>
>Ugh, I often forget about the differences between MS os's and *nix
>os's when writing some code.
>
>On MS os's a function exists in <conio.h> called kbhit(). You wait
>until kbhit() returns true then you getchar(). That's how you do it.

Firstly, ``MS OS's'' do not come with programming tools.  They do not come with
anything called <conio.h>. Nor is there an entry point called ``kbhit'' in any
core system DLL shipped by Microsoft.  These things are features of a few
compilers, Microsoft's Visual C++ not among them.

Secondly, kbhit() polls the BIOS keyboard buffer, whereas getchar() reads from
the stream stdin. Now I haven't worked with any Borland compiler for MS-DOS
for more than ten years, or anything resembling <conio.h>, but from my foggy
recollection, it's not inconceivable that the FILE * stream may have characters
in it, yet the keyboard buffer be empty.  In general, you probably don't want
to be mixing <conio.h> and <stdio.h>.  If you use kbhit() to detect the
presence of keyboard input, I think there is a function called getch() which
can then be used to dequeue it, rather than getchar().

>The following link has code to simulate MS's kbhit() function:

That would be _Borland's_ kbhit() function. Give credit where it's
due, even for lousy inventions.

------------------------------

From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: Two questions on .so libs
Reply-To: [EMAIL PROTECTED]
Date: Tue, 15 May 2001 06:51:31 GMT

On Mon, 14 May 2001 14:27:30 -0700, Doug Smith <[EMAIL PROTECTED]> wrote:
>Hello.  I had a couple of questions on .so files.
>
>one - can I export functions by an ordinal instead of by name as with win32
>dll's?  If so, how?

Why would you want to emulate a braindamaged dynamic linking technology?
What is it that you can't accomplish without these ordinals?

>two - can I choose to not export (hide) functions in a .so?  ie - can I have
>internal functions that are not exposed?  If so, how?

Yes, take a look at linker scripts, described in the GNU info documentation
for ``ld''. In particular, version scripts are what you are after.

Version scripts do a lot more than control the visibility of symbols, but they
can be used to just accomplish that.

------------------------------

From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: Two questions on .so libs
Reply-To: [EMAIL PROTECTED]
Date: Tue, 15 May 2001 07:01:05 GMT

On Tue, 15 May 2001 01:19:27 GMT, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
>But then I believe on my mini-libs on a boot/rescue floppy, all of the 
>/lib/lib*.so files have been stripped to save space, so obviously linkage
>must happen some other way.

There is a separate set of symbols for dynamic linkage. These dynamic
symbols are not removed by strip. You can view them with ``nm --dynamic
<name_of_stripped_so>''. 

>Therefore, my logic tells me that there must be some kind of ".LIB" 
>equivalent in Linux which maps "printf" to an ordinal in the real libc.so,

Resolution is based on symbols, not on any such indices.

------------------------------

From: Rolf Magnus <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,alt.movies.independent
Subject: Re: Public Domain CODEC
Date: Tue, 15 May 2001 09:07:04 +0200

Bobby Kanaeaupuni Richardson wrote:

> Divx is nothing compared to the Windows Media 8 format (Which of course
> happens to be hacked from MPEG4 and Divx).  But it gets better and better
> than Divx every day since Windows Media is supported by the worlds biggest
> software company.  Encode a film in Divx and Windows Media 8, do a side by
> side comparison.  You'll get more quality, more frames per a second, and a
> smaller file size.

And a Windoze-only video file. I'll wait a few months 'till OpenDivX is 
ready.

------------------------------

From: Rolf Magnus <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,alt.movies.independent
Subject: Re: Public Domain CODEC
Date: Tue, 15 May 2001 09:07:04 +0200

Bobby Kanaeaupuni Richardson wrote:

> Divx is nothing compared to the Windows Media 8 format (Which of course
> happens to be hacked from MPEG4 and Divx).  But it gets better and better
> than Divx every day since Windows Media is supported by the worlds biggest
> software company.  Encode a film in Divx and Windows Media 8, do a side by
> side comparison.  You'll get more quality, more frames per a second, and a
> smaller file size.

And a Windoze-only video file. I'll wait a few months 'till OpenDivX is 
ready.

------------------------------


** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: [EMAIL PROTECTED]

You can send mail to the entire list by posting to the
comp.os.linux.development.apps newsgroup.

Linux may be obtained via one of these FTP sites:
    ftp.funet.fi                                pub/Linux
    tsx-11.mit.edu                              pub/linux
    sunsite.unc.edu                             pub/Linux

End of Linux-Development-Apps Digest
******************************

Reply via email to