From: Mike A. Harris <[EMAIL PROTECTED]>
> On Wed, 6 Sep 2000, John Summerfield wrote:
>
> >> This sort of thing is inherently a non-portable problem like
> >> detecting endianness and other such things. It is unlikely any
> >
> >Detecting endianness isn't hard to do portably. I did it about 20 y
On Wed, 6 Sep 2000, John Summerfield wrote:
>> Unlikely. GLINT crashed a lot, and was very buggy. A lot of
>> people (myself included) hated it.. Also it is a TCL/TK app,
>> which likely was why it was so buggy..
>>
>> The program became obsolete when GNOME/GTK/KDE/QT apps came out
>> to do t
On Tue, 5 Sep 2000, Frank Hale wrote:
>Date: Tue, 05 Sep 2000 21:32:19 -0400
>From: Frank Hale <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Content-Type: text/plain; charset=us-ascii
>Subject: XFree86-4.0.1-0.43.src.rpm
>
>I just built XFree86-4.0.1-0.43.src.rpm and everything went okay. Here
>is
On Wed, 6 Sep 2000, John Summerfield wrote:
>> This sort of thing is inherently a non-portable problem like
>> detecting endianness and other such things. It is unlikely any
>
>Detecting endianness isn't hard to do portably. I did it about 20 years ago,
>in COBOL, when coding for a Honeywell mi
On Tue, 5 Sep 2000, Thomas Dodd wrote:
>Follow the above link (at the end of most messages to this list)
>
>If you don't know your password, have it sent to you from
>that page, then you unsubscribe there.
>
>The old method probably still works too.
>
>To unsubscribe:
>mail -s unsubscribe [EMAIL
On Tue, 5 Sep 2000, Matt Wilson wrote:
>#include
>
>int main(void)
>{
>printf("%ld CPUs online\n", sysconf(_SC_NPROCESSORS_ONLN));
>return 0;
>}
>
>from shell:
>
>$ getconf _NPROCESSORS_ONLN
Drat! That is one thing that bugs me about Linux... You hunt
around looking for the wheel, and
At 05:39 9/6/00 +0800, John Summerfield wrote:
> > This sort of thing is inherently a non-portable problem like
> > detecting endianness and other such things. It is unlikely any
>
>Detecting endianness isn't hard to do portably. I did it about 20 years ago,
>in COBOL, when coding for a Honeywell
- Original Message -
From: John Summerfield <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, September 05, 2000 16:39
Subject: Re: SMP question ?
>
> >
> > This sort of thing is inherently a non-portable problem like
> > detecting endianness and other such things. It is unlik
Bill Nottingham wrote:
>
> XFree86 uses a different driver system. Drivers are implemented
> as loadable modules; there is only one server. (Both that server
> and the drivers are in the XFree86 package.)
>
Thank you for breaking that down for me. This is my first time messing
with the new 4.x
Frank Hale ([EMAIL PROTECTED]) said:
> I just built XFree86-4.0.1-0.43.src.rpm and everything went okay. Here
> is a listing of the RPMS it generated. Am I missing something, where are
> the XServer RPMS? For instance I don't see a MACH_64 XServer which I
> need to run my ATI card. Hopefully ther
Frank Hale wrote:
>
> RPM 4 depends on db3-devel? Where do I get that?
>
Sorry I found it.
--
ICQ: 7205161
http://sapphire.sourceforge.net - Yet another X11 Window Manager
___
Redhat-devel-list mailing list
[EMAIL PROTECTED]
https://listman.redha
I just built XFree86-4.0.1-0.43.src.rpm and everything went okay. Here
is a listing of the RPMS it generated. Am I missing something, where are
the XServer RPMS? For instance I don't see a MACH_64 XServer which I
need to run my ATI card. Hopefully there is a logical explanation.
-rw-rw-r--1 r
RPM 4 depends on db3-devel? Where do I get that?
--
ICQ: 7205161
http://sapphire.sourceforge.net - Yet another X11 Window Manager
___
Redhat-devel-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-devel-list
> Yeah it is possible..
> expect wants a tcl syntax. With tcl you can pass arguments to the
> script but non with $1, $2 like in bash.
> The argument is stored in a variable named argv (see man expect for
> details).
>
> In your case you should only make the change $1>$argv
Thanks, works
On Tue, 5 Sep 2000, Rick Teudt wrote:
> I am trying to figure out how to pass a command-line argument into an expect
> script.
>
> For example, suppose I have a script called update.exp. The first few lines
> of update.exp are as follows:
>
> #!/usr/bin/expect
>
> spawn $env(SHEL
It has been too long since I did expect programming but expect is really
an add on to TCL so you can't use bash/shell script type language you have to
get the arguments a la TCL.
Check out the expect
homepage http://expect.nist.gov/
it covers that question (and many others)
On Tue, 05 Sep 2000,
I am trying to figure out how to pass a command-line argument into an expect
script.
For example, suppose I have a script called update.exp. The first few lines
of update.exp are as follows:
#!/usr/bin/expect
spawn $env(SHELL)
expect "$ "
send -- "telnet node$1
>
> This sort of thing is inherently a non-portable problem like
> detecting endianness and other such things. It is unlikely any
Detecting endianness isn't hard to do portably. I did it about 20 years ago,
in COBOL, when coding for a Honeywell mini. The owners didn't know whether it
was beg
> Unlikely. GLINT crashed a lot, and was very buggy. A lot of
> people (myself included) hated it.. Also it is a TCL/TK app,
> which likely was why it was so buggy..
>
> The program became obsolete when GNOME/GTK/KDE/QT apps came out
> to do the job. You'd need to recode it to support the ne
> Whats up with RPM 3.0.5, I've been treading water for the last 3 or 4
> days using it. I kept getting packages that wouldn't build exiting with
> weird errors. Then after I switched back to RPM 3.0.4 things started
> working again. What changed so much in 3.0.5 that would break many
> src.rpms??
On Tue, 5 Sep 2000, Chris Garrigues wrote:
> In particular, it gives ugly backtraces if you have a kickstart file that
> worked just fine with RedHat 6.2.
>
> Incompatible changes are bad enough, but these failures should be more
> graceful and give more clue what's wrong.
I second that motio
In particular, it gives ugly backtraces if you have a kickstart file that
worked just fine with RedHat 6.2.
Incompatible changes are bad enough, but these failures should be more
graceful and give more clue what's wrong.
Where can I get information on the format of a kickstart file for rawhide
vergel wrote:
>
> I have that same question. I've been wanting to un sub for a while too.
>
> > JM wrote:
> >
> > Hello,
> >
> > How do I unsubscribe this [EMAIL PROTECTED]
> >
> > Thanks,
> >
> >
>
> ___
> Redhat-devel-list mailing list
> [EMAIL PROT
I have that same question. I've been wanting to un sub for a while too.
> JM wrote:
>
> Hello,
>
> How do I unsubscribe this [EMAIL PROTECTED]
>
> Thanks,
>
>
___
Redhat-devel-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailma
Hello,
How do I unsubscribe this [EMAIL PROTECTED]
Thanks,
from C:
#include
int main(void)
{
printf("%ld CPUs online\n", sysconf(_SC_NPROCESSORS_ONLN));
return 0;
}
from shell:
$ getconf _NPROCESSORS_ONLN
Cheers,
Matt
On Mon, Sep 04, 2000 at 09:08:25AM +0100, Mikael Aronsson wrote:
> Hi !
>
> What is the best way to detect the number of C
[EMAIL PROTECTED] wrote:
>
> I'm currently using the gcc that comes with RH 6.1. It did not
> recognize the std::vector.at(int idx) call, had to use
> std::vector[int idx] instead. Has the .at function been
> implemented in a later edition of gcc?
with everything other stan
I'm currently using the gcc that comes with RH 6.1. It did not
recognize the std::vector.at(int idx) call, had to use
std::vector[int idx] instead. Has the .at function been
implemented in a later edition of gcc?
Joe Kelch
[EMAIL PROTECTED]
[EMAIL PROT
I'm wanting to write a replacement C function for a few different
glibc calls for debugging purposes, and other uses as well.
The functions in mind are small, including straight kernel
syscalls, etc..
I'm looking at the glibc source and it goes way over my
head. Some of the functions appear to
Why is finding endianess non-portable ? How about...
unsigned int i = 1;
char *p;
p = (char *) &i;
if (*p == 0)
{
/* I'm a BIG end machine */
}
else
{
/* I'm a LITTLE end machine */
On Mon, 4 Sep 2000, Mikael Aronsson wrote:
>Yes I know, but what I was looking for was a portable system call that could
>be used from inside an application to detect the number of CPU's, how about
>other UNIX systems, do they have a proc/cpuinfo to ?
This sort of thing is inherently a non-porta
hello
http://www.promise.com/latest/latedrivers.htm#linuxu66 isn't for RAID IDE
card, it's only a patch for udma66. ;(
Promise isn't supplying a linux drivers for his fastrack IDE raid card ;(
Why are adaptec and promise so bad in linux supportsince linux is the
best os for pc atm they shoul
On Mon, 4 Sep 2000, Michel MENGIS wrote:
>the kernel 2.4 test7 isn't supporting IDE RAID card ;(
>but there is something interessting: "SCSI - ATA IDE Emulation" what's
>this?
It's been there since 2.0.31 or so, and is the ide-scsi.o driver
used for IDE CD writer drives under Linux.
--
Mik
On Mon, 4 Sep 2000, Mikael Aronsson wrote:
>What is the best way to detect the number of CPU's ?, I guess I
>could look in /proc/cpuinfo, but is there a better more
>portable way to do it ?
I don't believe so. /proc/cpuinfo is there for that purpose.
It'd be nice if Linux got a binary interfa
On Mon, 4 Sep 2000, Derek Tattersall wrote:
>Date: Mon, 4 Sep 2000 07:27:38 -0400
>From: Derek Tattersall <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Content-Type: text/plain; charset=us-ascii
>Subject: Re: SMP question ?
>
>* Mikael Aronsson ([EMAIL PROTECTED]) [000904 03:16]:
>>
>> Hi !
>>
>>
35 matches
Mail list logo
