Re: Firewall (iptables) rule to limit Apache connections
On Wed, May 19, 2010 at 9:26 AM, Kevin D. Clark kevin_d_cl...@comcast.net wrote: Have you given any consideration to the fact that in HTTP 1.1 there are persistent connections and that the level of control offered to you by iptables might be too low-level for you to effectively manage the traffic that your system is dealing with? Hmmm. His reported complaint was that some clients are opening a high number of simultaneous TCP connections, thus eating up all the Apache worker processes. If the clients were well-behaved and just used HTTP keep alives, it wouldn't exhaust the Apache worker pool. So if these rude clients are well and truly the only problem, simply limiting the number of TCP connections from a single IP address would address that. Some advantages to using iptables include: Likely uses less resources than letting things hit Apache; possibly a more lightweight implementation; works with any web server. Disadvantages include: Won't work on non-Linux hosts; some hosting providers will let you tweak Apache but not the firewall; less fine-grained control (as Kevin notes). All that said, I'm not advocating any particular approach. I'm not familar with Apache's mechanisms for this in the first place, but I have dabbled in other kinds of network traffic control before, and I've learned it can be surprisingly tricky. Often a given technique will have unanticipated side-effects. Without knowing more I can't say what approach is best. -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Shot in the dark: Anyone ever use CLAPACK routines?
gnhlug-discuss-boun...@mail.gnhlug.org wrote on 05/19/2010 09:19:37 AM:
On 05/18/2010 08:13 PM, Bruce Labitt wrote:
As the subject line indicates - a total shot in the dark...
Prototyping Platform: Ubuntu 10.04 x86-64
Libraries: BLAS from ATLAS, CLAPACK
I'm trying to use some CLAPACK routines to perform matrix
manipulation,
in particular, the zgesvd routine to do a singular value decomposition
(SVD). My code is working for a 2x2 matrix, but it does not work for
a
9x9. I posted the code at the lapack-forum
http://icl.cs.utk.edu/lapack-forum/viewtopic.php?
f=2t=1839sid=a44c7f5bb3f4836d77568664db0e1c89
which works for a 2x2 and fails for a 9x9, with a Segmentation Fault.
I'm suspicious that it is 99% operator (me) error. (Fair guess :-P )
In particular, I'm worried about stuff like declaring:
doublecomplex A[m][m];
where doublecomplex is defined in f2c.h as struct{ double r; double i;
}
Is is better in general (more portable) to use something like
doublecomplex A[m*m] instead?
For those who may not know, CLAPACK is a C version of LAPACK, which
was
originally written in FORTRAN (gasp). It is the Linear Algebra
library
that both OSS and closed source use. I know that Numpy Scipy use
LAPACK, as well as MATLAB. I'm using CLAPACK because it can be built
entirely in C. (FORTRAN is not available on the 'final' platform)
If anyone has a few spare moments, I'd appreciate a quick look and any
helpful comments you may have. FWIW, I used valgrind and saw that
even
when I got the correct answer, there were tons of warnings and errors
reported. (These errors were DEEP inside of the CLAPACK library.)
Note: if anyone is adventurous enough to try this at home (or anywhere
else) you will need to change the libs and includes to point to your
blas and lapack libs. I built my BLAS using ATLAS with the nof77
option
(C only!), and linked to CLAPACK (which I also built). Most folks
would
just install the libs from their repositories...
Jerry replied
I've used CLAPACK, but as an underlying library for other things. My
company uses CLAPACK 3.0 in our product and I am unaware of any issues.
We do complex things like Stochastic systems. In addition about 99% of
our code is pure C++ with a very small amount of C Flex and Bison.
Additionally, the Python Numpy and Scipy packages use CLAPACK, and we do
use a bit of the lapack stuff in our Python modules. After looking at
your code, the first thing I looked for is initializations, and it does
appear that your initializations of matricies A and I are ok. I also
think that defining 'doublecomplex A[m][m]' is correct. I'm wondering if
your LDx values are correct. What happens if you define 'doublecomplex
A[m+1][m+1];' as well as I and C.
Jerry Feldman g...@blu.org
Boston Linux and Unix
PGP key id: 537C5846
PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB CA3B 4607 4319 537C 5846
==
Jerry, thank you for responding to my shot in the dark. I'm going to edit
your response and put it in order. The subject is arcane enough without
trying to unravel top posting. Indeed, I'm having trouble with the subject
matter itself. Please indulge me this time.
==
Jerry asked
I'm wondering if your LDx values are correct.
Bruce responded
Here is the documentation on zgesvd I found, which tell one how to set up
LDx (and everything else:
/* Fortran documentation from zgesvd.c */
/* ZGESVD computes the singular value decomposition (SVD) of a complex */
/* M-by-N matrix A, optionally computing the left and/or right singular
*/
/* vectors. The SVD is written */
/* A = U * SIGMA * conjugate-transpose(V) */
/* where SIGMA is an M-by-N matrix which is zero except for its */
/* min(m,n) diagonal elements, U is an M-by-M unitary matrix, and */
/* V is an N-by-N unitary matrix. The diagonal elements of SIGMA */
/* are the singular values of A; they are real and non-negative, and */
/* are returned in descending order. The first min(m,n) columns of */
/* U and V are the left and right singular vectors of A. */
/* Note that the routine returns V**H, not V. */
/* Arguments */
/* = */
/* JOBU(input) CHARACTER*1 */
/* Specifies options for computing all or part of the matrix U:
*/
/* = 'A': all M columns of U are returned in array U: */
/* = 'S': the first min(m,n) columns of U (the left singular */
/* vectors) are returned in the array U; */
/* = 'O': the first min(m,n) columns of U (the left singular */
/* vectors) are overwritten on the array A; */
/* = 'N': no columns of U (no left singular vectors) are */
/* computed. */
/* JOBVT (input) CHARACTER*1 */
/*
Open Source Video Codecs
Huge win today: 1. *Google will be releasing VP8 under an open source and royalty-free basis.* VP8 is a high-quality video codec that Google acquired when they purchased the company On2 http://www.on2.com. The VP8 codec represents a vast improvement in quality-per-bit over Theora and is comparable in quality to H.264. Cite: http://hacks.mozilla.org/2010/05/firefox-youtube-and-webm/ ... and much more news on that page. Check it out. -- Ted Roche Ted Roche Associates, LLC http://www.tedroche.com ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Shot in the dark: Anyone ever use CLAPACK routines?
On 05/19/2010 01:36 PM, bruce.lab...@autoliv.com wrote:
gnhlug-discuss-boun...@mail.gnhlug.org wrote on 05/19/2010 09:19:37 AM:
On 05/18/2010 08:13 PM, Bruce Labitt wrote:
As the subject line indicates - a total shot in the dark...
Prototyping Platform: Ubuntu 10.04 x86-64
Libraries: BLAS from ATLAS, CLAPACK
I'm trying to use some CLAPACK routines to perform matrix
manipulation,
in particular, the zgesvd routine to do a singular value decomposition
(SVD). My code is working for a 2x2 matrix, but it does not work for
a
9x9. I posted the code at the lapack-forum
http://icl.cs.utk.edu/lapack-forum/viewtopic.php?
f=2t=1839sid=a44c7f5bb3f4836d77568664db0e1c89
which works for a 2x2 and fails for a 9x9, with a Segmentation Fault.
I'm suspicious that it is 99% operator (me) error. (Fair guess :-P )
In particular, I'm worried about stuff like declaring:
doublecomplex A[m][m];
where doublecomplex is defined in f2c.h as struct{ double r; double i;
}
Is is better in general (more portable) to use something like
doublecomplex A[m*m] instead?
For those who may not know, CLAPACK is a C version of LAPACK, which
was
originally written in FORTRAN (gasp). It is the Linear Algebra
library
that both OSS and closed source use. I know that Numpy Scipy use
LAPACK, as well as MATLAB. I'm using CLAPACK because it can be built
entirely in C. (FORTRAN is not available on the 'final' platform)
If anyone has a few spare moments, I'd appreciate a quick look and any
helpful comments you may have. FWIW, I used valgrind and saw that
even
when I got the correct answer, there were tons of warnings and errors
reported. (These errors were DEEP inside of the CLAPACK library.)
Note: if anyone is adventurous enough to try this at home (or anywhere
else) you will need to change the libs and includes to point to your
blas and lapack libs. I built my BLAS using ATLAS with the nof77
option
(C only!), and linked to CLAPACK (which I also built). Most folks
would
just install the libs from their repositories...
Jerry replied
I've used CLAPACK, but as an underlying library for other things. My
company uses CLAPACK 3.0 in our product and I am unaware of any issues.
We do complex things like Stochastic systems. In addition about 99% of
our code is pure C++ with a very small amount of C Flex and Bison.
Additionally, the Python Numpy and Scipy packages use CLAPACK, and we do
use a bit of the lapack stuff in our Python modules. After looking at
your code, the first thing I looked for is initializations, and it does
appear that your initializations of matricies A and I are ok. I also
think that defining 'doublecomplex A[m][m]' is correct. I'm wondering if
your LDx values are correct. What happens if you define 'doublecomplex
A[m+1][m+1];' as well as I and C.
Jerry Feldman g...@blu.org
Boston Linux and Unix
PGP key id: 537C5846
PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB CA3B 4607 4319 537C 5846
==
Jerry, thank you for responding to my shot in the dark. I'm going to edit
your response and put it in order. The subject is arcane enough without
trying to unravel top posting. Indeed, I'm having trouble with the subject
matter itself. Please indulge me this time.
==
Jerry asked
I'm wondering if your LDx values are correct.
Bruce responded
Here is the documentation on zgesvd I found, which tell one how to set up
LDx (and everything else:
/* Fortran documentation from zgesvd.c */
/* ZGESVD computes the singular value decomposition (SVD) of a complex */
/* M-by-N matrix A, optionally computing the left and/or right singular
*/
/* vectors. The SVD is written */
/* A = U * SIGMA * conjugate-transpose(V) */
/* where SIGMA is an M-by-N matrix which is zero except for its */
/* min(m,n) diagonal elements, U is an M-by-M unitary matrix, and */
/* V is an N-by-N unitary matrix. The diagonal elements of SIGMA */
/* are the singular values of A; they are real and non-negative, and */
/* are returned in descending order. The first min(m,n) columns of */
/* U and V are the left and right singular vectors of A. */
/* Note that the routine returns V**H, not V. */
/* Arguments */
/* = */
/* JOBU(input) CHARACTER*1 */
/* Specifies options for computing all or part of the matrix U:
*/
/* = 'A': all M columns of U are returned in array U: */
/* = 'S': the first min(m,n) columns of U (the left singular */
/* vectors) are returned in the array U; */
/* = 'O': the first min(m,n) columns of U (the left
Re: Shot in the dark: Anyone ever use CLAPACK routines?
gnhlug-discuss-boun...@mail.gnhlug.org wrote on 05/19/2010 01:36:03 PM:
gnhlug-discuss-boun...@mail.gnhlug.org wrote on 05/19/2010 09:19:37 AM:
On 05/18/2010 08:13 PM, Bruce Labitt wrote:
As the subject line indicates - a total shot in the dark...
Prototyping Platform: Ubuntu 10.04 x86-64
Libraries: BLAS from ATLAS, CLAPACK
I'm trying to use some CLAPACK routines to perform matrix
manipulation,
in particular, the zgesvd routine to do a singular value
decomposition
(SVD). My code is working for a 2x2 matrix, but it does not work
for
a
9x9. I posted the code at the lapack-forum
http://icl.cs.utk.edu/lapack-forum/viewtopic.php?
f=2t=1839sid=a44c7f5bb3f4836d77568664db0e1c89
which works for a 2x2 and fails for a 9x9, with a Segmentation
Fault.
I'm suspicious that it is 99% operator (me) error. (Fair guess :-P
)
In particular, I'm worried about stuff like declaring:
doublecomplex A[m][m];
where doublecomplex is defined in f2c.h as struct{ double r; double
i;
}
Is is better in general (more portable) to use something like
doublecomplex A[m*m] instead?
For those who may not know, CLAPACK is a C version of LAPACK, which
was
originally written in FORTRAN (gasp). It is the Linear Algebra
library
that both OSS and closed source use. I know that Numpy Scipy use
LAPACK, as well as MATLAB. I'm using CLAPACK because it can be
built
entirely in C. (FORTRAN is not available on the 'final' platform)
If anyone has a few spare moments, I'd appreciate a quick look and
any
helpful comments you may have. FWIW, I used valgrind and saw that
even
when I got the correct answer, there were tons of warnings and
errors
reported. (These errors were DEEP inside of the CLAPACK library.)
Note: if anyone is adventurous enough to try this at home (or
anywhere
else) you will need to change the libs and includes to point to your
blas and lapack libs. I built my BLAS using ATLAS with the nof77
option
(C only!), and linked to CLAPACK (which I also built). Most folks
would
just install the libs from their repositories...
Jerry replied
I've used CLAPACK, but as an underlying library for other things. My
company uses CLAPACK 3.0 in our product and I am unaware of any
issues.
We do complex things like Stochastic systems. In addition about 99% of
our code is pure C++ with a very small amount of C Flex and Bison.
Additionally, the Python Numpy and Scipy packages use CLAPACK, and we
do
use a bit of the lapack stuff in our Python modules. After looking at
your code, the first thing I looked for is initializations, and it
does
appear that your initializations of matricies A and I are ok. I also
think that defining 'doublecomplex A[m][m]' is correct. I'm wondering
if
your LDx values are correct. What happens if you define 'doublecomplex
A[m+1][m+1];' as well as I and C.
Jerry Feldman g...@blu.org
Boston Linux and Unix
PGP key id: 537C5846
PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB CA3B 4607 4319 537C
5846
==
Jerry, thank you for responding to my shot in the dark. I'm going to
edit
your response and put it in order. The subject is arcane enough without
trying to unravel top posting. Indeed, I'm having trouble with the
subject
matter itself. Please indulge me this time.
==
Jerry asked
I'm wondering if your LDx values are correct.
Bruce responded
Here is the documentation on zgesvd I found, which tell one how to set
up
LDx (and everything else:
/* Fortran documentation from zgesvd.c */
/* ZGESVD computes the singular value decomposition (SVD) of a complex
*/
/* M-by-N matrix A, optionally computing the left and/or right singular
*/
/* vectors. The SVD is written */
/* A = U * SIGMA * conjugate-transpose(V) */
/* where SIGMA is an M-by-N matrix which is zero except for its */
/* min(m,n) diagonal elements, U is an M-by-M unitary matrix, and */
/* V is an N-by-N unitary matrix. The diagonal elements of SIGMA */
/* are the singular values of A; they are real and non-negative, and */
/* are returned in descending order. The first min(m,n) columns of */
/* U and V are the left and right singular vectors of A. */
/* Note that the routine returns V**H, not V. */
/* Arguments */
/* = */
/* JOBU(input) CHARACTER*1 */
/* Specifies options for computing all or part of the matrix U:
*/
/* = 'A': all M columns of U are returned in array U: */
/* = 'S': the first min(m,n) columns of U (the left singular
*/
/* vectors) are returned in the array U; */
/* = 'O': the first min(m,n) columns of U (the left singular
*/
Re: Shot in the dark: Anyone ever use CLAPACK routines?
Bruce Labitt writes:
If anyone has a few spare moments, I'd appreciate a quick look and any
helpful comments you may have. FWIW, I used valgrind and saw that even
when I got the correct answer, there were tons of warnings and errors
reported. (These errors were DEEP inside of the CLAPACK library.)
All of your code allocates space for your matrix arrays on the stack.
There is nothing wrong with this {per se}, but Valgrind is a heap
analysis tool. The stack is not the heap. If you want to use
Valgrind to gain some confidence that the matricies/arrays that you
are using are not being accessed incorrectly, then you will have to
allocate space for your arrays/matricies on the *heap*.
--kevin
--
alumni.unh.edu!kdc / http://kdc-blog.blogspot.com/
GnuPG: D87F DAD6 0291 289C EB1E 781C 9BF8 A7D8 B280 F24E
Wipe him down with gasoline 'til his arms are hard and mean
From now on boys this iron boat's your home
So heave away, boys.
-- Tom Waits
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Freebasing (data mining)
This is a cool tool for data cleanup and more (available on all platforms) http://code.google.com/p/freebase-gridworks/ A recursive and twist on the popular cultural word association Freebase on Richard Pryor on Freebase http://www.freebase.com/view/en/richard_pryor Greg Rundlett ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Shot in the dark: Anyone ever use CLAPACK routines?
Is there an equivalent tool for the stack?
On May 19, 2010 3:18 PM, Kevin D. Clark kevin_d_cl...@comcast.net wrote:
Bruce Labitt writes:
If anyone has a few spare moments, I'd appreciate a quick look and any
h...
All of your code allocates space for your matrix arrays on the stack.
There is nothing wrong with this {per se}, but Valgrind is a heap
analysis tool. The stack is not the heap. If you want to use
Valgrind to gain some confidence that the matricies/arrays that you
are using are not being accessed incorrectly, then you will have to
allocate space for your arrays/matricies on the *heap*.
--kevin
--
alumni.unh.edu!kdc / http://kdc-blog.blogspot.com/
GnuPG: D87F DAD6 0291 289C EB1E 781C 9BF8 A7D8 B280 F24E
Wipe him down with gasoline 'til his arms are hard and mean
From now on boys this iron boat's your home
So heave away, boys.
-- Tom Waits
___
gnhlug-discuss mailing list
gnhlug-disc...@mail.gnhl...
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Shot in the dark: Anyone ever use CLAPACK routines?
On 05/19/2010 02:34 PM, bruce.lab...@autoliv.com wrote:
gnhlug-discuss-boun...@mail.gnhlug.org wrote on 05/19/2010 01:36:03 PM:
gnhlug-discuss-boun...@mail.gnhlug.org wrote on 05/19/2010 09:19:37 AM:
On 05/18/2010 08:13 PM, Bruce Labitt wrote:
As the subject line indicates - a total shot in the dark...
Prototyping Platform: Ubuntu 10.04 x86-64
Libraries: BLAS from ATLAS, CLAPACK
I'm trying to use some CLAPACK routines to perform matrix
manipulation,
in particular, the zgesvd routine to do a singular value
decomposition
(SVD). My code is working for a 2x2 matrix, but it does not work
for
a
9x9. I posted the code at the lapack-forum
http://icl.cs.utk.edu/lapack-forum/viewtopic.php?
f=2t=1839sid=a44c7f5bb3f4836d77568664db0e1c89
which works for a 2x2 and fails for a 9x9, with a Segmentation
Fault.
I'm suspicious that it is 99% operator (me) error. (Fair guess :-P
)
In particular, I'm worried about stuff like declaring:
doublecomplex A[m][m];
where doublecomplex is defined in f2c.h as struct{ double r; double
i;
}
Is is better in general (more portable) to use something like
doublecomplex A[m*m] instead?
For those who may not know, CLAPACK is a C version of LAPACK, which
was
originally written in FORTRAN (gasp). It is the Linear Algebra
library
that both OSS and closed source use. I know that Numpy Scipy use
LAPACK, as well as MATLAB. I'm using CLAPACK because it can be
built
entirely in C. (FORTRAN is not available on the 'final' platform)
If anyone has a few spare moments, I'd appreciate a quick look and
any
helpful comments you may have. FWIW, I used valgrind and saw that
even
when I got the correct answer, there were tons of warnings and
errors
reported. (These errors were DEEP inside of the CLAPACK library.)
Note: if anyone is adventurous enough to try this at home (or
anywhere
else) you will need to change the libs and includes to point to your
blas and lapack libs. I built my BLAS using ATLAS with the nof77
option
(C only!), and linked to CLAPACK (which I also built). Most folks
would
just install the libs from their repositories...
Jerry replied
I've used CLAPACK, but as an underlying library for other things. My
company uses CLAPACK 3.0 in our product and I am unaware of any
issues.
We do complex things like Stochastic systems. In addition about 99% of
our code is pure C++ with a very small amount of C Flex and Bison.
Additionally, the Python Numpy and Scipy packages use CLAPACK, and we
do
use a bit of the lapack stuff in our Python modules. After looking at
your code, the first thing I looked for is initializations, and it
does
appear that your initializations of matricies A and I are ok. I also
think that defining 'doublecomplex A[m][m]' is correct. I'm wondering
if
your LDx values are correct. What happens if you define 'doublecomplex
A[m+1][m+1];' as well as I and C.
Jerry Feldman g...@blu.org
Boston Linux and Unix
PGP key id: 537C5846
PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB CA3B 4607 4319 537C
5846
==
Jerry, thank you for responding to my shot in the dark. I'm going to
edit
your response and put it in order. The subject is arcane enough without
trying to unravel top posting. Indeed, I'm having trouble with the
subject
matter itself. Please indulge me this time.
==
Jerry asked
I'm wondering if your LDx values are correct.
Bruce responded
Here is the documentation on zgesvd I found, which tell one how to set
up
LDx (and everything else:
/* Fortran documentation from zgesvd.c */
/* ZGESVD computes the singular value decomposition (SVD) of a complex
*/
/* M-by-N matrix A, optionally computing the left and/or right singular
*/
/* vectors. The SVD is written */
/* A = U * SIGMA * conjugate-transpose(V) */
/* where SIGMA is an M-by-N matrix which is zero except for its */
/* min(m,n) diagonal elements, U is an M-by-M unitary matrix, and */
/* V is an N-by-N unitary matrix. The diagonal elements of SIGMA */
/* are the singular values of A; they are real and non-negative, and */
/* are returned in descending order. The first min(m,n) columns of */
/* U and V are the left and right singular vectors of A. */
/* Note that the routine returns V**H, not V. */
/* Arguments */
/*
Re: Shot in the dark: Anyone ever use CLAPACK routines?
On 05/19/2010 03:22 PM, Bruce Labitt wrote: Is there an equivalent tool for the stack? Purify. Purify is a commercial product (expensive too) that instruments every load and store operation whether that be on the heap or the stack. While valgrind is a great tool, it does not compare to Purify. -- -- Jerry Feldman feldma...@comcast.net Boston Linux and Unix PGP key id: 537C5846 PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB CA3B 4607 4319 537C 5846 ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Shot in the dark: Anyone ever use CLAPACK routines?
[please don't top-post] Bruce Labitt writes: Is there an equivalent tool for the stack? I don't know of a reliable one. --kevin -- alumni.unh.edu!kdc / http://kdc-blog.blogspot.com/ GnuPG: D87F DAD6 0291 289C EB1E 781C 9BF8 A7D8 B280 F24E Wipe him down with gasoline 'til his arms are hard and mean From now on boys this iron boat's your home So heave away, boys. -- Tom Waits ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Shot in the dark: Anyone ever use CLAPACK routines?
Jerry Feldman writes: On 05/19/2010 03:22 PM, Bruce Labitt wrote: Is there an equivalent tool for the stack? Purify. Purify is a commercial product (expensive too) that instruments every load and store operation whether that be on the heap or the stack. While valgrind is a great tool, it does not compare to Purify. Unless Purify has improved a lot since the last time I used it (five years ago, I admit), then Valgrind is just as good as Purify in my book. In particular, at the time that I used it, Purify claimed to support this sort of checking for stack-based objects, but I never saw it work. Come to think of it, I have seen Insure++ work pretty well for this. --kevin -- alumni.unh.edu!kdc / http://kdc-blog.blogspot.com/ GnuPG: D87F DAD6 0291 289C EB1E 781C 9BF8 A7D8 B280 F24E Wipe him down with gasoline 'til his arms are hard and mean From now on boys this iron boat's your home So heave away, boys. -- Tom Waits ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Shot in the dark: Anyone ever use CLAPACK routines?
On 05/19/2010 04:03 PM, Kevin D. Clark wrote: Jerry Feldman writes: On 05/19/2010 03:22 PM, Bruce Labitt wrote: Is there an equivalent tool for the stack? Purify. Purify is a commercial product (expensive too) that instruments every load and store operation whether that be on the heap or the stack. While valgrind is a great tool, it does not compare to Purify. Unless Purify has improved a lot since the last time I used it (five years ago, I admit), then Valgrind is just as good as Purify in my book. In particular, at the time that I used it, Purify claimed to support this sort of checking for stack-based objects, but I never saw it work. Come to think of it, I have seen Insure++ work pretty well for this. I have not touched Purify in a number of years, but back in the 2000 - 2003 time frame I was part of a team that ported Purify to Tru64 Unix, and Purify did have full capability to instrument the stack. What Purify does is to instrument every load and store operation at the machine code level. It does not matter where the load and store is. If I recall, stack support is an option that you can turn on or off. A load/store operation makes no difference whether it is on the stack or on the heap. The issue is that you need to keep a memory bitmap to keep the status of every byte of memory. Several years ago, someone at a BLU meeting mentioned he was having a problem with some code in a phone switch, and his company and Verizon were pointing fingers, especially because a previous problem was theirs. He tried a number of different solutions, and after trying Purify, his company paid then $10,000 for a license. I'm not trying to sell Purify for IBM, but I certainly know how it works. Looks like Insure++ does a similar type of analysis that Purify does. -- Jerry Feldman g...@blu.org Boston Linux and Unix PGP key id: 537C5846 PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB CA3B 4607 4319 537C 5846 signature.asc Description: OpenPGP digital signature ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Shot in the dark: Anyone ever use CLAPACK routines?
Jerry Feldman writes: Several years ago, someone at a BLU meeting mentioned he was having a problem with some code in a phone switch, and his company and Verizon were pointing fingers, especially because a previous problem was theirs. He tried a number of different solutions, and after trying Purify, his company paid then $10,000 for a license. I'm not trying to sell Purify for IBM, but I certainly know how it works. Looks like Insure++ does a similar type of analysis that Purify does. You and I have bantered back and forth about Purify over the years. To be honest, when I was working on telco-class equipment, I was happy to have both Valgrind and Purify for my daily work. Both are excellent tools. I found bugs with Purify that I didn't find with Valgrind, and vice-versa. I'm a big fan of tools like this. Regards, --kevin -- alumni.unh.edu!kdc / http://kdc-blog.blogspot.com/ GnuPG: D87F DAD6 0291 289C EB1E 781C 9BF8 A7D8 B280 F24E Wipe him down with gasoline 'til his arms are hard and mean From now on boys this iron boat's your home So heave away, boys. -- Tom Waits ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Nokia N900
My experience with the n810 (I never installed any agps package) GPS was universally awful except in a few lucky circumstances when I randomly got a GPS signal. The n900 GPS is quite good and almost always acquires a signal quickly. Granted, it is not good when you are away from signals such as wifi or cell. Eric Tyson Sawyer wrote: On Sun, May 16, 2010 at 8:42 PM, David Rysdam da...@rysdam.org wrote: I was outside, I was still WiFi'd in to the house so it was using AGPS. Result: Invalid. [...] Conclusion: The N810 GPS hardware and/or software definitively sucks. Though I agree that the N810 is not as good a GPS is most others, once the AGPS package had bee installed my experience was much better than what you are reporting. You have not indicated if you had the AGPS package installed. Last I knew, it was not a standard package. If you didn't make a point to install it, its not there. Without it, it is my impression that you always get a cold start. Response to some other comments: It is well documented that GPS's typically assume that they are restarted near where they where last used. The documentation of every GPS I have ever bought says that if you turn it off and then transport it a long distance before turning it on again, it will take much longer to get a fix. The N810 without the AGPS package seems not able to do even this simple trick. Though I've never seen any problem with slow movement, I have seen (esp. on the N810) that highway speeds can hinder an initial fix. Cheers! Ty ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
