Re: Python's making my head hurt...

2008-01-07 Thread Star
Thanks for all of the feedback!  I haven't gotten it ~quite~ fixed
yet, but I am well on my way.

It appears to be an issue with how the C components of the game server
are interacting with the python modules that it's calling, and of
course, the one specific for the game type I'm trying to run with
this.  With the information gotten from here, and a handful of
respondents from python groups, I've been able to collect enough info
to get the developers attention.

Again, Thanks for your input!!



-- 
~ *
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/


Re: C complex number usage

2008-01-07 Thread Kevin D. Clark

You might consider using Perl's Math::FFTW module for your problem:

  http://steffen-mueller.net/modules/Math-FFTW/

Another module that you might find to be useful is Perl's
Math::Complex module:

  http://search.cpan.org/~nwclark/perl/lib/Math/Complex.pm

Or, depending on the size and scope of your problem, you might have to
code this in C and consider using something like MPI or MPICH.

Programming in C takes some work; making your solution code amenable
to running on some sort of a parallel computer takes a bunch more
work.  Depending on your problem size, this might be worth it (or
not).

Regards,

--kevin
-- 
GnuPG ID: B280F24E  God, I loved that Pontiac.
alumni.unh.edu!kdc   -- Tom Waits
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/


managing applications

2008-01-07 Thread Bill McGonigle
OK, another unix operations theory question:

   What's the best way to maintain installs of applications?

For instance, take mysql as an average example.  For a mysql install,  
I'll have all of the application binaries and support files, but I'll  
also have, probably, an /etc/my.cnf and entries I've added to /etc/ 
sysctl.conf.  I'll also have added some rules to /etc/sysconfig/ 
iptables and there are data files in /var/lib/mysql.

Now, I want to move this mysql install to another machine.  Maybe I'm  
building a cluster, maybe it's new hardware, maybe I'm on the 6-month  
Fedora treadmill.  All I know to do is to move things manually, hope  
I've done documentation well (pfft) and test/pray.

Thoughts:
   This would be easier if there were /etc/sysconfig/iptables.d/mysql  
and /etc/sysctl.d/mysql.conf, but there aren't (yet).
   The RPM database (could be deb, doesn't matter) knows about many  
of these files.
   Sun has favored /opt, but that's a bit of an admission of defeat,  
at least from an LSB perspective.
   A tree of symlinks into /opt might be a compromise.
   Some kind of runtime patching (e.g. sysctl.conf-patch-mysql) might  
be appropriate.

Magic-wand:
   There's some tool (which understands pipes, of course) that will  
gather up the important bits of my install and put them in an archive.

I'm unlikely to be the first person to have thought about this, but  
if it was fixed 10 years ago I missed the memo.  Any thoughts?

-Bill

-
Bill McGonigle, Owner   Work: 603.448.4440
BFC Computing, LLC  Home: 603.448.1668
[EMAIL PROTECTED]   Cell: 603.252.2606
http://www.bfccomputing.com/Page: 603.442.1833
Blog: http://blog.bfccomputing.com/
VCard: http://bfccomputing.com/vcard/bill.vcf

___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/


Re: managing applications

2008-01-07 Thread Tom Buskey
On Jan 7, 2008 4:31 PM, Bill McGonigle <[EMAIL PROTECTED]> wrote:

> OK, another unix operations theory question:
>
>   What's the best way to maintain installs of applications?


RPM, DEB, Solaris packages.  Know the app & it's configuration files.  Then
you can reinstall from a kickstart/jumpstart.

Thoughts:
>   This would be easier if there were /etc/sysconfig/iptables.d/mysql
> and /etc/sysctl.d/mysql.conf, but there aren't (yet).


Yep, you need to copy the config files & that varies by app with no real
standards in sight.  I've seen /etc, /etc/opt, /etc/sfw, /opt/etc,
/usr/local/etc, /opt/sfw/etc.


>
>   The RPM database (could be deb, doesn't matter) knows about many
> of these files.
>   Sun has favored /opt, but that's a bit of an admission of defeat,
> at least from an LSB perspective.


And it works just as well in the Solaris world as the Linux world.  One
thing that many Solaris (and other older unixen) did was have an NFS
/usr/local.  Now that did isn't $4/MB, having it managed with packages on
local disk make more sense.

  A tree of symlinks into /opt might be a compromise.
>   Some kind of runtime patching (e.g. sysctl.conf-patch-mysql) might
> be appropriate.
>
> Magic-wand:
>   There's some tool (which understands pipes, of course) that will
> gather up the important bits of my install and put them in an archive.
>

How elaborate do you need to be?  cfengine and similar.


>
> I'm unlikely to be the first person to have thought about this, but
> if it was fixed 10 years ago I missed the memo.  Any thoughts?
>

As long as people have their own ideas about where to put configs, this will
be unfixed.  /etc is a good starting point at least :-/
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/


Re: managing applications

2008-01-07 Thread Tom Buskey
Maybe we could keep everything in a binary database.  We'll call it a
registry.
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/


Re: managing applications

2008-01-07 Thread Ben Scott
On Jan 7, 2008 4:31 PM, Bill McGonigle <[EMAIL PROTECTED]> wrote:
> What's the best way to maintain installs of applications?

  Pay somebody else to do it.  ;-)

>This would be easier if there were /etc/sysconfig/iptables.d/mysql
> and /etc/sysctl.d/mysql.conf, but there aren't (yet).

  Patches welcome.  ;-)

>  All I know to do is to move things manually, hope
> I've done documentation well (pfft) and test/pray.

  I honestly think that documentation and discipline are just
essential for this.  "You can't comb a hairy ball smooth."  If you
carefully document everything you do, recreating it is
straight-forward.  If you don't document it, well...  you reap what
you sow.  One of those harsh truths.  FWIW, after 15+ years of doing
IT, I still find myself relearning this lesson.  Life is a persistent
teacher.

> The RPM database (could be deb, doesn't matter) knows about many
> of these files.

  "rpm -Va" can be a tremendously useful command (though it can't tell
you about new files, not owned by any package).  You can do things
like filter for only config files.

  AIDE/tripwire/etc can also be adapted to a similar purpose, i.e.,
identifying everything that's changed or new.  Might be useful for the
migration scenario.  Though it only helps if you remember to make a
baseline, and keep it current.

  Saving the output of "ls -lR" over time can also help in a similar way.

> Sun has favored /opt, but that's a bit of an admission of defeat,
> at least from an LSB perspective.

  It isn't really compatible with package management, either.  I
suppose you could just copy everything into /opt/, but then you're
loosing all the benefits of package management.  I suppose you could
find/build a distro that puts everything under /opt/, but I suspect
that's a dumb idea.  And it won't help with shared files like
/etc/sysctl.conf or whatever.

> A tree of symlinks into /opt might be a compromise.

  Ewww.  What would that get you (aside from a headache)?  :)

> Some kind of runtime patching (e.g. sysctl.conf-patch-mysql) might
> be appropriate.

  I've done this before, sort of, when designing a standard base
config for deployment on all manner of different customer systems.
But it only did initial config to our internal standard; it didn't
keep track of changes past that.

>There's some tool (which understands pipes, of course) that will
> gather up the important bits of my install and put them in an archive.

  There's all sorts of tools designed to help with this, but from what
I've seen, they're all fairly heavyweight, invasive, and insular.  I
suspect that's an inevitable consequence of what they're trying to do
(control everything).

> Any thoughts?

  I like fudge.

-- Ben
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/


Re: managing applications

2008-01-07 Thread Ben Scott
On Jan 7, 2008 4:53 PM, Tom Buskey <[EMAIL PROTECTED]> wrote:
> Maybe we could keep everything in a binary database.  We'll call it a
> registry.

  DIE!  DIE!  DIE!  DIE!  DIE!  DI--   Er, sorry.  Reflex action.

-- Ben
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/


Re: managing applications

2008-01-07 Thread Shawn O'Shea
On 1/7/08, Bill McGonigle <[EMAIL PROTECTED]> wrote:
>
> OK, another unix operations theory question:
>
>What's the best way to maintain installs of applications?


This may not be as useful for small scale implementations, but I know of
some sites (including other groups here where I work) that do config file
management with cfengine. You can then use your favorite automated install
tool to maintain a "software config" for your systems (ie a kickstart file
specifying the necessary software groups/packages). So a new box would
would, blast the OS with autoinstall
(kicksstart/jumpstart/autoyast/FAI/etc/etc), hopefully including cfengine.
Then cfengine syncs the configs

http://www.cfengine.org/ for the source.
As far as with distros, Red Hat doesn't seem to ship it, but ie rpmforge
maintains RPMs for it. The ubuntu universe repository seems a little behind
(carrying a 2.1.x version when cfengine is at 2.2.3) but it is in there.

-Shawn
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/


Re: C complex number usage

2008-01-07 Thread Bruce Labitt
Thanks everyone, I have something working using FFTW.  My first program 
looks ok.  It takes the IFFT ( FFT (x,N) , N).  My second program is, 
shall we say, a work in progress.  It runs, but the output is not as 
expected.  C is pretty ugly.  My code is even uglier.

As for parallel processing, I will probably end up needing to use one of 
the MPI variants.  It looks like it is big enough to warrant it.  My 
last benchmark estimates the problem will take better than 12 days to 
complete.  (Core problem, assuming no setup.)  I need it to be on the 
order of an hour, so I can evaluate quite a few possibilities.


Kevin D. Clark wrote:
> You might consider using Perl's Math::FFTW module for your problem:
>
>   http://steffen-mueller.net/modules/Math-FFTW/
>
> Another module that you might find to be useful is Perl's
> Math::Complex module:
>
>   http://search.cpan.org/~nwclark/perl/lib/Math/Complex.pm
>
> Or, depending on the size and scope of your problem, you might have to
> code this in C and consider using something like MPI or MPICH.
>
> Programming in C takes some work; making your solution code amenable
> to running on some sort of a parallel computer takes a bunch more
> work.  Depending on your problem size, this might be worth it (or
> not).
>
> Regards,
>
> --kevin
>   

___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/