Linux-Development-Sys Digest #600, Volume #6 Thu, 8 Apr 99 18:13:52 EDT
Contents:
Switchbox + mouse = braindead mouse? ([EMAIL PROTECTED])
Re: Programming tools for Linux/Unix: Editor, IDE, Frontend to GCC. (Dan Mercer)
BASIC compiler for Linux? (AC)
Re: BASIC compiler for Linux? ("John E. Garrott")
gdb + linuxthreads + kernel 2.2.x = fixed :) ("Paul Archard")
Re: Serial driver for EIB protocol (Olav Woelfelschneider)
Q: auto shutdown & power on with APM with ATX mb ? (Basile STARYNKEVITCH)
Newbie (Craig Christensen)
Newbie (Craig Christensen)
Sockets (David L. Bilbey)
Re: Sockets? connect? (Arthur Chien)
Re: Idea: Make a seperate "i686" tree for Redhat Linux 6.0 (Frank v Waveren)
Re: Programming tools for Linux/Unix: Editor, IDE, Frontend to GCC. (Shimpei
Yamashita)
Re: BASIC compiler for Linux? ("Clint Byrum")
Re: How about /dev/web? (Alexander Viro)
Re: signal_pending ??? (Martin Recktenwald)
Re: Idea: Make a seperate "i686" tree for Redhat Linux 6.0 (Alexander Viro)
Re: Idea: Make a seperate "i686" tree for Redhat Linux 6.0 (Johan Kullstam)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Switchbox + mouse = braindead mouse?
Date: Thu, 08 Apr 1999 16:55:38 GMT
I have a belkin switchbox connected up to a
linux box. Occasionally (rare) when switching
to the linux box, my mouse goes brain dead.
The *only* solution to recover from this state
is to reboot the box.
Having written MS-mouse drivers before *and*
looking at the kernel source, I think I know
what the problem is.
I hesitate to make any changes to the kernel
unless I can (reliably) reproduce the problem
to test. As stated, this only occurs "rarely"
on my box and I cannot reproduce it "on demand"
1. Has anyone else experienced this problem?
2. Does anyone know how to reliably reproduce
the problem?
If you know how to reliably reproduce the problem,
please post your reply AND email it to me.
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (Dan Mercer)
Crossposted-To:
comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.help,comp.unix.programmer
Subject: Re: Programming tools for Linux/Unix: Editor, IDE, Frontend to GCC.
Date: 8 Apr 1999 19:24:50 GMT
In article <[EMAIL PROTECTED]>,
Nix <$}xinix{[email protected]> writes:
> [EMAIL PROTECTED] (Dan Mercer) writes:
>
>> And I haven't had to learn a
>> language I don't need outside of my editor.
>
> You mean you've had to learn a language you can't use outside of your
> editor, don't you?
>
> Lack of genericity is not praiseworthy.
>
Genericity? That's a new one on me. To be clearer, to learn lisp
only to program my editor seems a waste of effort and neurons. That
hardly makes me limited in my knowledge, which I will stack against
anyones.
--
Dan Mercer
[EMAIL PROTECTED]
Opinions expressed herein are my own and may not represent those of my employer.
------------------------------
From: [EMAIL PROTECTED] (AC)
Subject: BASIC compiler for Linux?
Date: Thu, 08 Apr 1999 19:36:10 GMT
Hi,
Are there any BASIC compilers out there for Linux? All hints are
appriated!
/Anders
------------------------------
From: "John E. Garrott" <[EMAIL PROTECTED]>
Subject: Re: BASIC compiler for Linux?
Date: Thu, 08 Apr 1999 11:53:03 -0700
AC wrote:
>
> Hi,
>
> Are there any BASIC compilers out there for Linux? All hints are
> appriated!
>
> /Anders
http://212.55.205.69/~gemi/LDT/
hope this helps,
John
------------------------------
From: "Paul Archard" <[EMAIL PROTECTED]>
Crossposted-To: comp.programming.threads
Subject: gdb + linuxthreads + kernel 2.2.x = fixed :)
Date: Thu, 08 Apr 1999 19:55:24 GMT
After two solid days of differential testing, I found the problem that was
preventing me from debugging of threads under gdb. It isn't kernel version
related, but it is rather strange so I thought I would share it for the
common curiosity...
It appears that if you are trying to debug a program that links to
libpthread.so, and the symbols for that library are not loaded, the
debugging doesn't work. In my case, I was doing a "set auto-solib-add 0",
to avoid wading through all the libc and other system library stuff, and/or
getting messages from ddd about no source files, ending up in "space" etc.
Apparently, because the symbols for libpthread weren't loaded, the debugging
was not working properly.
Doing a manual load on the library using "sharedlibrary libpthread" solves
the problem. Threads are then detected and debuggable (?!).
Does anyone know if this behavior is "by design" or "by accident" ?
Thank you very much to the people who responded to my original post.
regards,
Paul Archard
=============
parch // get rid of the
@ // comments to
workfire // reveal the
.com // email address!
------------------------------
From: Olav Woelfelschneider <[EMAIL PROTECTED]>
Subject: Re: Serial driver for EIB protocol
Date: Thu, 8 Apr 1999 08:05:16 +0200
Vipin Malik <[EMAIL PROTECTED]> wrote:
VM> The serial driver should NOT be catching the interrupts and ports on
VM> bootup UNLESS some device is opening them.
It locks the io-ports, but keeps the interrupts free even if the device is
not in use. So you get only half of it...
To free a UART for your own use, type
setserial /dev/ttySx uart none
Fill in the device you want to use, of course.
Then your own device driver is free to use the uart. For writing drivers,
I strongly recommends Rubinis new book "Linux Device Drivers" published
by O'Reilly. It's great!
--
Olav "Mac" W�lfelschneider [EMAIL PROTECTED]
PGP fingerprint = 06 5F 66 B3 2A AD 7D 2D B7 19 67 3C 95 A7 9D AF
Mer mu� doch nur emol e bissje nochdenke. -- Mundstuhl
------------------------------
From: Basile STARYNKEVITCH <[EMAIL PROTECTED]>
Subject: Q: auto shutdown & power on with APM with ATX mb ?
Date: 08 Apr 1999 22:09:24 +0200
Hello All,
I have a new motherboard ASUSP5A (with AMD K6/400) in an ATX box (and
powersupply) kernel is 2.2.5 with APM (and distribution is Redhat5.2
with updates)
I would like to power off my machine with Linux (this is possible and
works with apm -s) and also to power it on at a given date. (This
seems possible thru the Award BIOS setup screen).
Does anyone have any clues or ideas?
--
Basile STARYNKEVITCH - 8 rue de la Faiencerie, 92340 BOURG LA REINE (France)
tel 01.46.65.45.53. email = basile point starynkevitch at wanadoo point fr
------------------------------
From: Craig Christensen <[EMAIL PROTECTED]>
Subject: Newbie
Date: Thu, 08 Apr 1999 15:55:18 -0400
I resized my resolution in XWindows and after rebooting it is gigantic
and I can't read anything. How do I resize to where I want it by using
XWindows and by using the root?
Please help, I am a newbie and am very frustrated.
Craig
[EMAIL PROTECTED]
------------------------------
From: Craig Christensen <[EMAIL PROTECTED]>
Subject: Newbie
Date: Thu, 08 Apr 1999 15:53:51 -0400
I resized my resolution in XWindows and after rebooting it is gigantic
and I can't read anything. How do I resize to where I want it by using
XWindows and by using the root?
Please help, I am a newbie and am very frustrated.
Craig
[EMAIL PROTECTED]
------------------------------
From: David L. Bilbey <[EMAIL PROTECTED]>
Subject: Sockets
Date: 8 Apr 1999 20:43:14 GMT
[ Article reposted from mtu.cs.questions ]
[ Author was David L. Bilbey <[EMAIL PROTECTED]> ]
[ Posted on 8 Apr 1999 20:42:50 GMT ]
I'm writing a program with sockets. I have reached a problem. recv() is a
blocking call, right? Right. So I've got a call to recv() which seems to
work most of the time. But now I am trying to send() from a server, and
the message gets there before the client calls recv(). It seems like it
gets there too early, because the recv() doesn't catch it...but if I put in
a bit of a delay (two nested for loops from 0 to 10000) before the send(),
the recv() will get it. Anyone have any idea what's going on here?
bilbey
--
"In the first castles, I bet a common mistake was putting the torture room
next to the master bedroom. Boy, you're just not going to get the good
sleep that way." --Jack Handey
--
"In the first castles, I bet a common mistake was putting the torture room
next to the master bedroom. Boy, you're just not going to get the good
sleep that way." --Jack Handey
------------------------------
From: Arthur Chien <[EMAIL PROTECTED]>
Subject: Re: Sockets? connect?
Date: Thu, 08 Apr 1999 20:13:11 GMT
Furthermore, the service port "kike" should be defined in both machines /etc/services
file and the numerical value should be identical. Othwewise, you will always get a
"Connection refused" error message from connect() call.
-Arthur
[EMAIL PROTECTED] wrote:
> Your "connect()" (in the client) has to connect to the address of the
> server. You have it hard-coded to use "name.sin_addr.s_addr=INADDR_ANY".
> This should be the address of the server, as returned by gethostbyname(),
> and never INADDR_ANY (except for in the server's code).
>
> -Mark Taylor
> [EMAIL PROTECTED]
> Revolutionary Server Software http://www.netmax.com/
>
> In article <[EMAIL PROTECTED]>,
> Papa Aquilino <[EMAIL PROTECTED]> wrote:
> > This is a multi-part message in MIME format.
> > --------------FEA1D1AD030EA2529CD956E0
> > Content-Type: text/plain; charset=us-ascii
> > Content-Transfer-Encoding: 7bit
> >
> > I want to connect to process throw a network TCP/IP (ethernet). I
> > Attached
> > two programs in that mail: server.c & client.c.
> >
> > Those programs work GOOD when I execute both in the same computer. But
> > when I
> > try to execute the programs in diferents computers the program client
> > says:
> >
> > Connection refused
> >
> > Because: function connect ( ... ) return -1
> >
> > Could someone help me please? Thanks to read my message.
> >
> > Please replay to : [EMAIL PROTECTED]
> > ____________________________
> > Enrique Cespedes Sanchez.
> > e-mail: [EMAIL PROTECTED]
> > Almeria.(Spain)
> >
> > --------------FEA1D1AD030EA2529CD956E0
> > Content-Type: text/plain; charset=us-ascii; name="cient.c"
> > Content-Transfer-Encoding: 7bit
> > Content-Disposition: inline; filename="cient.c"
> >
> > #include <stdio.h>
> > #include <signal.h>
> > #include <errno.h>
> > #include <sys/types.h>
> > #include <sys/socket.h>
> > #include <netinet/in.h>
> > #include <netdb.h>
> > #include <arpa/inet.h>
> > #include <string.h>
> >
> > #define BUFFER 40
> > #define HOST1 "papa.aquilino"
> > #define PUERTO "kike"
> >
> > extern int errno;
> > void error (int n);
> > char leer_chr (void);
> >
> > main ()
> > {
> > int i;
> > char frase[BUFFER],frase2[BUFFER];
> > struct hostent *hostrec;
> > struct servent *servrec;
> > struct sockaddr_in name, addr;
> > int retcode, sock, newsock, flag=0;
> >
> > // Obtener nombre del host local
> > if ((hostrec=gethostbyname (HOST1))==NULL)
> > error(1);
> >
> > // Obtener puerto local
> > if ((servrec=getservbyname(PUERTO,"tcp"))==NULL)
> > error(2);
> >
> > // Crear socket
> > if ((sock=socket (AF_INET, SOCK_STREAM,0))==-1)
> > error(3);
> >
> > // Actualizar nombre de socket
> > name.sin_port= servrec->s_port;
> > name.sin_family=hostrec->h_addrtype;
> > name.sin_addr.s_addr=INADDR_ANY;
> >
> > // Contactar con el servidor
> > if ((retcode=connect(sock,&name,sizeof(name)))==-1)
> > error(4);
> >
> > // Receive from Server
> > if ((retcode=recv(sock,frase,sizeof(char)*BUFFER,flag))==-1)
> > error(6);
> >
> > puts (frase);
> >
> > strcpy (frase2,"CLIENT: ready");
> >
> > // Send to Server
> > if ((retcode=send(sock,frase2,sizeof(char)*BUFFER,flag))==-1)
> > error(5);
> >
> > }
> >
> > void error (int n)
> > {
> > printf ("\nSe ha producido el error %d\n",n);
> >
> > perror (strerror(errno));
> > exit(1);
> > }
> >
> > --------------FEA1D1AD030EA2529CD956E0
> > Content-Type: text/plain; charset=us-ascii; name="server.c"
> > Content-Transfer-Encoding: 7bit
> > Content-Disposition: inline; filename="server.c"
> >
> > #include <stdio.h>
> > #include <signal.h>
> > #include <errno.h>
> > #include <sys/types.h>
> > #include <sys/socket.h>
> > #include <netinet/in.h>
> > #include <netdb.h>
> > #include <arpa/inet.h>
> > #include <ctype.h>
> >
> > #define BUFFER 40
> > #define HOST1 "papa.aquilino"
> > #define PUERTO "kike"
> >
> > extern int errno;
> >
> > inline void error (int n);
> >
> > main ()
> > {
> > char frase[BUFFER],fin=0,chr;
> > struct hostent *hostrec;
> > struct servent *servrec;
> > struct sockaddr_in name, addr;
> > int retcode, sock, newsock, len=0;
> >
> > if ((hostrec=gethostbyname (HOST1))==NULL) error(1);
> >
> > // Get local port -- Obtener puerto local
> > if ((servrec=getservbyname(PUERTO,"tcp"))==NULL) error(2);
> >
> > // Create socket -- Crear socket
> > if ((sock=socket (AF_INET, SOCK_STREAM,0))==-1) error(3);
> >
> > // Actualizar nombre de socket
> > name.sin_port= servrec->s_port;
> > name.sin_family=hostrec->h_addrtype;
> > name.sin_addr.s_addr=INADDR_ANY;
> >
> > // Enlazar nombre al socket
> > if ((retcode=bind(sock,&name,sizeof(name)))==-1)
> > {
> > close (sock);
> > error(4);
> > }
> >
> > // Listen -- Escuchar solicitudes
> > if ((retcode=listen(sock,1))==-1)
> > error(5);
> >
> > // Accept -- Aceptar solicitudes
> > memset (&addr, 0, sizeof(addr));
> > len = sizeof(addr);
> > if ((newsock=accept(sock,&addr,&len))==-1)
> > error(6);
> >
> > puts("\nClient found.\n");
> >
> > strcpy (frase,"SERVER: ready");
> > // Send to client
> > if (retcode = send(newsock,frase,sizeof(char)*BUFFER,0)==-1) error(9);
> >
> > // receive from client
> > if (retcode = recv(newsock,frase,sizeof(char)*BUFFER,0)==-1) error(7);
> >
> > puts (frase);
> >
> > // Close socket
> > printf ("\nSERVER: Closing ports: %d, %d\n",sock,newsock);
> >
> > if (close(newsock)==-1)
> > error(8);
> >
> > if (close(sock)==-1)
> > error(8);
> >
> > }
> >
> > inline void error (int n)
> > {
> > printf ("\nSe ha producido el error %d\n",n);
> > perror (strerror(errno));
> > exit(1);
> > }
> >
> > --------------FEA1D1AD030EA2529CD956E0--
> >
> >
>
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (Frank v Waveren)
Subject: Re: Idea: Make a seperate "i686" tree for Redhat Linux 6.0
Crossposted-To:
comp.os.linux.misc,linux.redhat.misc,alt.linux,alt.os.linux,comp.os.linux.hardware
Date: Thu, 08 Apr 1999 21:20:28 GMT
Old zeeland (actually called just zeeland) is a province in the south of holland.
In article <[EMAIL PROTECTED]>,
Johan Kullstam <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (who?) writes:
>
>> : In article <[EMAIL PROTECTED]>,
>> : Enkidu <[EMAIL PROTECTED]> writes:
>> : > This is a fiction. Redhat do *not* develop drivers.
>
>> stupid comment, but I cant help but chastise poor english, which I am a
>> master of (poor english for those not following very closely).
>> that do, it should be does.
>
> not if you're from a commonwealth country - which includes new zealand
> (where is the old zealand btw?). in *english* (as opposed to american
> english) redhat is a group entity and considered plural. therefore,
> redhat do.
>
--
Frank v Waveren
[EMAIL PROTECTED]
ICQ# 10074100
------------------------------
From: Shimpei Yamashita <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.help,comp.unix.programmer
Subject: Re: Programming tools for Linux/Unix: Editor, IDE, Frontend to GCC.
Date: Thu, 8 Apr 1999 23:05:34 +0100
Josh Stern <[EMAIL PROTECTED]> writes:
>
>Bill Zimmerly <[EMAIL PROTECTED]> wrote:
>
>>There were *MANY* other programming environments that combined compiler,
>>editor, and debugger before Turbo Pascal.
>>
>>None of them got the *INK* that TP got however. Why? I'll never know...
>
>Can you name one that was as good an implementation of all 3?
>Did it cost around $50 USD?
THINK Pascal on the Mac was very nice--slick interface, small and fast
compiler (very important when your main machine is a 1MB Mac Plus),
and an editor that spotted most syntax errors on the fly (a feature I
sorely missed after I started playing with C in college). I'm sure you
can still find people in comp.sys.mac.programmer.* groups who still
haven't forgiven Symantec for killing the product. It did cost more
than $50, though.
--
Shimpei Yamashita <http://www.submm.caltech.edu/%7Eshimpei/>
------------------------------
From: "Clint Byrum" <[EMAIL PROTECTED]>
Subject: Re: BASIC compiler for Linux?
Date: Thu, 8 Apr 1999 14:17:17 -0700
I don't know if you've ever heard of the "Pick" or "MultiValue" operating
system, but it has a very powerful BASIC type language. Try www.jbase.com
for a free 3 user license of jbase, which converts the jBASIC to c. Hope
that helps.
AC wrote in message <[EMAIL PROTECTED]>...
>Hi,
>
>Are there any BASIC compilers out there for Linux? All hints are
>appriated!
>
>/Anders
>
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Subject: Re: How about /dev/web?
Date: 8 Apr 1999 16:43:38 -0400
In article <[EMAIL PROTECTED]>,
Nix <$}xinix{[email protected]> wrote:
>[EMAIL PROTECTED] (Alexander Viro) writes:
>
>> layered fs support
>
>Oh, unionfs for Linux. Slobber, me want.
>
>As a matter of interest, how are you planning to do it? An additional
>layer of virtualisation on top of VFS (VVFS?) or what?
Not needed. When we'll have all fs-independent stuff in VFS (so that
all serialization was done in outside of filesystem drivers and they'ld
be fed with commutative requests) we will be able to do that. Easy.
Right now the worst obstacles being:
* waaay too fat struct inode (fs-dependent stuff embedded into it)
* lack of struct nameidata equivalent (lookup context)
* still some race prevention code lingering in filesystems
* inode-level locking on directories in cases when it should be done
on dcache level
* duplication of stuff between fs/namei.c and fs/nfsd/vfs.c
* extremely high-LI stuff in FAT-derived filesystems (they do all
sorts of bogus things with {d,i}cache
* lack of lookup unrolls (ahem... AFAIK nobody has it, but...)
Some of this stuff will be fixed in 2.2. The rest is 2.3 material. Actually
Linux VFS is better suited for layering than BSD one - we have namespace
well-separated from inode stuff and we already have most of race-prevention
code in VFS (BSD offloads it filesystems).
Once we'll have light-weight inodes and lookup atomicity (i.e.
all in-progress requests to fs drivers commutative with each other) the
rest will become trivial. If you'll look at BSD implementation you'll see
that large part of the cruft comes from lack of VFS-visible namespace.
Directory cache (closest thing available) is per-fs thing there. All that
BSD VFS really can see is a bunch of vnodes.
The point being: race-prevention and locking can be done in VFS
entirely on namespace level. There we have a non-local information and
life is much easier. BSD uses Heidemann's model and it was originally
intended to work with half of layers outside of the kernel. This part
is *not* used in BSD (thanks $DEITY!), but it hampers the whole design.
Big way. If you will remove that and separate serialization from layering
the latter will become *very* easy. Former will go to fs/{dcache,namei}.c.
IOW: we already have an additional layer ready to take almost all complexity
of BSD layering stuff. dcache, that is.
I hope to finish most of cleanup in 2.2, so that in 2.3 we could
do lookup unrolls and then go for layering proper. I'm afraid that any
attempt to touch VFS before we'll have kludges removed from fs drivers will
leave us with steaming pile of du^Wcode on hands, broken in all interesting
ways possible. Thanks $DEITY there is less filesystems than device drivers,
otherwise... <shudder>
--
There *is* something on port 23 but it ain't TELNET...
Zack Weinberg in Scary Devil Monastery.
------------------------------
From: Martin Recktenwald <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: signal_pending ???
Date: 08 Apr 1999 19:59:45 +0200
Vincent <[EMAIL PROTECTED]> writes:
> I have a program which use the signal_pending function. What is this
> function ?
A *program*? You're not talking about a kernel module or something
else that wants to become part of the kernel?
signal_pending() has been added in the late 2.1 development tree to
simplify checking for a pending signal. Where you used
if (current->signal & ~current->blocked) you should now write
if (signal_pending(current)
BTW.: Please don't do such silly cross-posting. If you do crosspost,
add a f'up.
Martin.
--
Sign the petition against spam:
http://www.politik-digital.de/spam/
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Crossposted-To:
comp.os.linux.misc,linux.redhat.misc,alt.linux,alt.os.linux,comp.os.linux.hardware
Subject: Re: Idea: Make a seperate "i686" tree for Redhat Linux 6.0
Date: 8 Apr 1999 17:07:45 -0400
In article <[EMAIL PROTECTED]>,
Johan Kullstam <[EMAIL PROTECTED]> wrote:
>not if you're from a commonwealth country - which includes new zealand
>(where is the old zealand btw?). in *english* (as opposed to american
^^^^^^^ - Zeeland.
Gaak... Across the North Sea (looking from England, that is).
Netherlands. Heck, they *really* don't teach history and geography
in schools, or what?
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
Crossposted-To:
comp.os.linux.misc,linux.redhat.misc,alt.linux,alt.os.linux,comp.os.linux.hardware
Subject: Re: Idea: Make a seperate "i686" tree for Redhat Linux 6.0
From: Johan Kullstam <[EMAIL PROTECTED]>
Date: 08 Apr 1999 17:47:23 -0400
[EMAIL PROTECTED] (Alexander Viro) writes:
> In article <[EMAIL PROTECTED]>,
> Johan Kullstam <[EMAIL PROTECTED]> wrote:
> >not if you're from a commonwealth country - which includes new zealand
> >(where is the old zealand btw?). in *english* (as opposed to american
> ^^^^^^^ - Zeeland.
>
> Gaak... Across the North Sea (looking from England, that is).
> Netherlands. Heck, they *really* don't teach history and geography
> in schools, or what?
the zealand (sj�lland) i found in my atlas is the english spelling of
the island that supports copenhagen (k�benhavn). but then i didn't
think the danes were very busy in the south pacific.
--
J o h a n K u l l s t a m
[[EMAIL PROTECTED]]
Don't Fear the Penguin!
------------------------------
** 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 (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
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-System Digest
******************************
