William John Poser

Show:

What's happening?

  • Freshmeat link?

    I don't find any Freshmeat link on the project page. How about adding one for people who might want to subscribe?.

    2009-06-11 22:18:58 UTC in General purpose dynamic array - Judy

  • error in inverse example

    In the example of the character set inverse you have: inverse([\x40-\5A]) = [\x00-\x40\x5B-\U12FFFF] I think that this should be: inverse([\x40-\5A]) = [\x00-\x3F\x5B-\U12FFFF] since character ranges are closed on both sides.

    2009-03-31 00:28:23 UTC in Lexical Analyzer Generator Quex

  • incorrect packaging

    The Unix tarball is incorrectly created: it expands directly into bin and lib directories rather than into a single directory. This is inconvenient and violates the standards used by repackagers such as Debian. Ideally the tarball should conform to the GNU standards as it is very useful to have the change log etc.

    2008-10-13 17:43:56 UTC in Transcriber

  • Comment: Sox cannot read .wav files

    I've got a fix, although I don't entirely understand why it works. The problem appears to result when startread calls findChunk at line 783 of wav.c. This error is apparently triggered by the call lsx_seeki(ft, (sox_ssize_t)len, SEEK_CUR); at line 777, which in the usual case has len=0. Modifying lsx_seeki to return immediately when passed a len of 0 solves the problem. What I don't understand...

    2008-08-11 22:33:48 UTC in SoX - Sound eXchange

  • Sox cannot read .wav files

    I am getting the same problem as that reported in closed bug 1823791. Whenever sox tries to read a .wav file, it reports that it is unable to locate the data chunk. This happens on files that I know to be well-formed, including files generated by sox itself. This is with Sox 14.1.0 on GNU/Linux 2.6.3 on i686 compiled with gcc 4.0.1. The error message is: sox formats: can't open input file...

    2008-08-10 06:28:29 UTC in SoX - Sound eXchange

  • audiospace

    billposer registered the AudioSpace project.

    2008-05-08 16:30:49 UTC in AudioSpace

  • todouble returns 0.0 when it should not

    There appears to be a bug in math::bigfloat::todouble, which returns 0.0 when it should not. This is illustrated by the following. package require math::bigfloat namespace import ::math::bigfloat::* set foo [fromstr 317.22 4] In 8.4.1.4 the following prints 317.220, but in 8.5 it prints 0.000. set sr [todouble $foo] puts [format "%6.2f" $sr] If I convert the bigfloat to a string...

    2008-05-08 16:03:44 UTC in tcllib

About Me

  • 2003-12-28 (6 years ago)
  • 939324
  • billposer (My Site)
  • William John Poser

Send me a message