headers
Ka-Ping Yee | 1 Sep 2000 01:16

Re: linuxaudiodev test does nothing

On Thu, 31 Aug 2000, Charles G Waldman wrote:
> Alas, even after fixing this, I *still* can't get linuxaudiodev to
> play the damned .au file.  It works fine for the .wav formats.
> 
> I'll continue hacking on this as time permits.

Just so you know -- i was definitely able to get this to work at
some point before when we were trying to fix this.  I changed
test_linuxaudiodev and it played the .AU file correctly.  I haven't
had time to survey what the state of the various modules is now,
though -- i'll have a look around and see what's going on.

Side note: is there a well-defined platform-independent sound
interface we should be conforming to?  It would be nice to have a
single Python function for each of the following things:

    1. Play a .wav file given its filename.

    2. Play a .au file given its filename.

    3. Play some raw audio data, given a string of bytes and a
       sampling rate.

which would work on as many platforms as possible with the same command.

A quick glance at audiodev.py shows that it seems to support only
Sun and SGI.  Should it be extended?

If someone's already in charge of this and knows what's up, let me know.
I'm sorry if this is common knowledge of which i was just unaware.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Barry A. Warsaw | 1 Sep 2000 01:22

Re: test_gettext.py fails on 64-bit architectures

>>>>> "MF" == Mark Favas <m.favas <at> per.dem.csiro.au> writes:

    MF> Close, but no cigar - fixes the miscalculation of BE_MAGIC,
    MF> but "magic" is still read from the .mo file as
    MF> 0xffffffff950412de (the 64-bit rep of the 32-bit negative
    MF> integer 0x950412de)

Thanks to a quick chat with Tim, who is always quick to grasp the meat
of the issue, we realize we need to & 0xffffffff all the 32 bit
unsigned ints we're reading out of the .mo files.  I'll work out a
patch, and check it in after a test on 32-bit Linux.  Watch for it,
and please try it out on your box.

Thanks,
-Barry
Permalink | Reply | 1 comment |
headers
Greg Stein | 1 Sep 2000 03:51

Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.200,2.201

On Thu, Aug 31, 2000 at 08:53:20PM -0400, Jeremy Hylton wrote:
> Any opinion on whether the Py_SetRecursionLimit should do sanity
> checking on its arguments?

-1 ... it's an advanced function. It's the caller's problem if they monkey
it up.

Cheers,
-g

--

-- 
Greg Stein, http://www.lyra.org/
Permalink | Reply | 0 comments |
headers
Greg Stein | 1 Sep 2000 04:12

Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.200,2.201

On Thu, Aug 31, 2000 at 05:02:01PM -0700, Tim Peters wrote:
> Update of /cvsroot/python/python/dist/src/Python
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv20859/python/dist/src/Python
> 
> Modified Files:
> 	ceval.c 
> Log Message:
> Supply missing prototypes for new Py_{Get,Set}RecursionLimit; fixes compiler wngs;
> un-analize Get's definition ("void" is needed only in declarations, not defns, &
> is generally considered bad style in the latter).

wtf? Placing a void in both declaration *and* definition is "good style".

static int foo(void) { ... }
int bar() { ... }

You're setting yourself up for inconsistency if you don't always use a
prototypical definition. In the above example, foo() must be
declared/defined using a prototype (or you get warnings from gcc when you
compile with -Wmissing-prototypes (which is recommended for developers)).
But you're saying bar() should *not* have a prototype.

-1 on dropping the "void" from the definition. I disagree it is bad form,
and it sets us up for inconsistencies.

Cheers,
-g

--

-- 
Greg Stein, http://www.lyra.org/
(Continue reading)

Permalink | Reply | 2 comments |
headers
Greg Ward | 1 Sep 2000 04:10
Favicon

ANNOUNCE: Distutils 0.9.2

...just in time for the Python 2.0b1 feature freeze, Distutils 0.9.2 has
been released.  Changes since 0.9.1:

  * fixed bug that broke extension-building under Windows for older
    setup scripts (not using the new Extension class)

  * new version of bdist_wininst command and associated tools: fixes
    some bugs, produces a smaller exeuctable, and has a nicer GUI
    (thanks to Thomas Heller)
		
  * added some hooks to 'setup()' to allow some slightly sneaky ways
    into the Distutils, in addition to the standard "run 'setup()'
    from a setup script"
	
Get your copy today:

  http://www.python.org/sigs/distutils-sig/download.html

        Greg
Permalink | Reply | 0 comments |
headers
Jeremy Hylton | 1 Sep 2000 04:40

static int debug = 0;

Quick note on BDFL-approved style for C code.

I recently changed a line in gcmodule.c from
static int debug;
to 
static int debug = 0;

The change is redundant, as several people pointed out, because the C
std requires debug to be initialized to 0.  I didn't realize this.
Inadvertently, however, I made the right change.  The preferred style
is to be explicit about initialization if other code depends on or
assumes that it is initialized to a particular value -- even if that
value is 0.

If the code is guaranteed to do an assignment of its own before the
first use, it's okay to omit the initialization with the decl.

Jeremy
Permalink | Reply | 3 comments |
headers
Greg Ewing | 1 Sep 2000 04:37
Picon
Picon
Favicon

Re: Pragmas: Just say "No!"

"M.-A. Lemburg" <mal <at> lemburg.com>:

> If it's just the word itself that's bugging you, then
> we can have a separate discussion on that. Perhaps "assume"
> or "declare" would be a better candidates.

Yes, "declare" would be better. ALthough I'm still somewhat
uncomfortable with the idea of naming a language feature
before having a concrete example of what it's going to be
 used for.

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
greg <at> cosc.canterbury.ac.nz	   +--------------------------------------+
Permalink | Reply | 3 comments |
headers
Guido van Rossum | 1 Sep 2000 05:54

Re: linuxaudiodev test does nothing

> A quick glance at audiodev.py shows that it seems to support only
> Sun and SGI.  Should it be extended?

Yes.

--Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)
Permalink | Reply | 0 comments |
headers
Guido van Rossum | 1 Sep 2000 06:00

Re: Namespace collision between lib/xml and site-packages/xml

> On July 26 I reported that the new xml package in the standard library
> collides with and overrides the xml package from the xml-sig that may be
> installed in site-packages. This is still the case. The new package does
> not have the same functionality as the one in site-packages, and hence
> my application (and others relying on similar functionality) gets an
> import error. I understood that it was planned that the new library xml
> package would check for the site-package version, and transparently hand
> over to it if it existed. It's not really an option to remove/rename the
> xml package in the std lib, or to break existing xml-based code...
> 
> Of course, this might be fixed by 2.0b1, or is it a feature that will be
> frozen out <wry smile>?
> 
> Fred's response was:
> "  I expect we'll be making the package in site-packages an extension
> provider for the xml package in the standard library.  I'm planning to
> discuss this issue at today's PythonLabs meeting." 

I remember our group discussion about this.  What's currently
implemented is what we decided there, based upon (Fred's
representation of) what the XML-sig wanted.  So you don't like this
either, right?

I believe there are two conflicting desires here: (1) the standard XML
package by the core should be named simply "xml"; (2) you want the old
XML-sig code (which lives in a package named "xml" but installed in
site-packages) to override the core xml package.

I don't think that's possible -- at least not without a hack that's
too ugly to accept.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Guido van Rossum | 1 Sep 2000 06:04

Re: Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.200,2.201

> You're setting yourself up for inconsistency if you don't always use a
> prototypical definition. In the above example, foo() must be
> declared/defined using a prototype (or you get warnings from gcc when you
> compile with -Wmissing-prototypes (which is recommended for developers)).
> But you're saying bar() should *not* have a prototype.
> 
> 
> -1 on dropping the "void" from the definition. I disagree it is bad form,
> and it sets us up for inconsistencies.

We discussed this briefly today in our group chat, and I'm +0 or
Greg's recommendation (that's +0 on keeping (void) in definitions).

--Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)
Permalink | Reply | 0 comments |

Gmane