Tim Janik | 8 May 14:54 2011

Beast API Documentation Online

Hey All,

this week, I managed to put the Beast reference documentation
back up. We're back to using Doxygen as suggested by Stefan.
These days Doxygen works *much* better than a couple years ago
(though one bug was found and reported while fiddling with it).
The docs are linked from the development page of the Beast site,
however, here're some useful links right away (it can finally
have docs per file which is really nice):

 	http://dev.testbit.eu/beast/latest/bseengine_8h.html
 	# BseEngine API

 	http://dev.testbit.eu/beast/latest/gslfilter_8h.html#a2330f06807663597b4b3b2c6e2cf7fdb
 	# gsl_filter_sine_scan()

The Rapicorn docs are up in a similar manner, these are generally
more up to date than Birnet docs, and will become more important
once the Birnet lib in Beast is replaced:

 	http://dev.testbit.eu/rapicorn/latest/rapicornutils_8hh.html

Rebuilding docs and uploading them is a one-liner for me now.
And docs don't need to be built during a beast build anymore,
which speeds up the build process.
That way, we could also get rid of old doxer now.

To test build the development docs, you now do:
 	make -C $PREFIX/beast/docs/dev
 	www-browser file:///$PREFIX/beast/docs/dev/html/latest/index.html
(Continue reading)

Stefan Westerfeld | 10 May 12:22 2011
Picon

MERGE: tools2cxx

   Hi!

I've modified the C sources in the tools/ directory to be compiled as C++
sources, please merge:

repo:   http://space.twc.de/public/git/stwbeast.git
branch: tools2cxx

   Cu... Stefan
--

-- 
Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan
Stefan Westerfeld | 12 May 13:27 2011
Picon

MERGE: bsescm2cxx

   Hi!

I've modified the C sources in the bsescm/ directory to be compiled as C++
sources, please merge:

repo:   http://space.twc.de/public/git/stwbeast.git
branch: bsescm2cxx

   Cu... Stefan
--

-- 
Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan
Tim Janik | 12 May 18:45 2011

Re: MERGE: bsescm2cxx

On Thu, 12 May 2011, Stefan Westerfeld wrote:

>   Hi!
>
> I've modified the C sources in the bsescm/ directory to be compiled as C++
> sources, please merge:
>
> repo:   http://space.twc.de/public/git/stwbeast.git
> branch: bsescm2cxx

Thanks a couple style things that need fixing still:

* Please use void* instead of gpointer where possible.

* Please use the following C++ish cast notation:
   +  gh_new_procedure ("bse-choice-match?", BseScmFunc (bse_scm_choice_match), 2, 0, 0);

* For sfi_glue_gc_add(), please investigate if changing
   the second argument to (void(*free_func)(void*)) is likely to
   reduce casts. The reason the second funciton pointer argument is
   just void* is convenience in C, but were're moving away from that
   so it doesn't make sense to keep convenince C stuff if it makes
   our C++ life harder.

* Please get rid o fthe extra space here:
   +  SignalData *sdata = (SignalData *) data;
   Should be:
   +  SignalData *sdata = (SignalData*) data;

>
(Continue reading)

Tim Janik | 13 May 02:02 2011

First release of wikihtml2man


First release of wikihtml2man, a wiki to man page converter.

Wikihtml2man is an easy to use converter that parses HTML sources,
normally originating from a Mediawiki page, and generates Unix Manual Page
sources based on it (also referred to as html2man or wiki2man converter).
It allows developing project documentation online, e.g. by collaborating
in a wiki. It is released as free software under the GNU GPLv3.

Technical details are given in its manual page:
 	http://testbit.eu/Wikihtml2man.1

See this for the complete announcement, motivation and uses:
 	http://timj.testbit.eu/2011/05/13/wikihtml2man-introduction/

Download location:
 	http://dist.testbit.eu/testbit-tools/testbit-tools-11.05.0.tar.bz2

Yours sincerely,
Tim Janik

---
http://lanedo.com/~timj/ - Founder and CEO of Lanedo GmbH.
Free software author and contributor on various projects.
Stefan Westerfeld | 13 May 17:11 2011
Picon

Re: MERGE: bsescm2cxx

   Hi!

On Thu, May 12, 2011 at 06:45:39PM +0200, Tim Janik wrote:
> On Thu, 12 May 2011, Stefan Westerfeld wrote:
> >I've modified the C sources in the bsescm/ directory to be compiled as C++
> >sources, please merge:
> >
> >repo:   http://space.twc.de/public/git/stwbeast.git
> >branch: bsescm2cxx
> 
> Thanks a couple style things that need fixing still:
> 
> * Please use void* instead of gpointer where possible.
> 
> * Please use the following C++ish cast notation:
>   +  gh_new_procedure ("bse-choice-match?", BseScmFunc (bse_scm_choice_match), 2, 0, 0);
> 
> * Please get rid o fthe extra space here:
>   +  SignalData *sdata = (SignalData *) data;
>   Should be:
>   +  SignalData *sdata = (SignalData*) data;

I've fixed these issues in the branch now.

> * For sfi_glue_gc_add(), please investigate if changing
>   the second argument to (void(*free_func)(void*)) is likely to
>   reduce casts. The reason the second funciton pointer argument is
>   just void* is convenience in C, but were're moving away from that
>   so it doesn't make sense to keep convenince C stuff if it makes
>   our C++ life harder.
(Continue reading)

Tim Janik | 14 May 00:56 2011

Re: MERGE: bsescm2cxx

On 13.05.2011 17:11, Stefan Westerfeld wrote:
>> * For sfi_glue_gc_add(), please investigate if changing
>>    the second argument to (void(*free_func)(void*)) is likely to
>>    reduce casts. The reason the second funciton pointer argument is
>>    just void* is convenience in C, but were're moving away from that
>>    so it doesn't make sense to keep convenince C stuff if it makes
>>    our C++ life harder.
>
> I can reduce the number of casts in shell/bsescm* by changing the signature,
> however there is quite a bit of C code that either will not compile at all or
> will compile with warnings if I do this (for instance in sfi/sfiglue.c or the
> generated beast-gtk/bstgenapi.c), so overall a lot of new casts need to be
> added elsewhere. I'd suggest to delay this change until more of the remaining
> code is already C++ified.

Hm, if we go like this then we end up with lots of C++-ified code that
needs fixing after we've turned everything into C++. I.e. essentially
demanding a 2 phase approach, which I'd like to avoid since it could
allmost double our work. We should avoid any approach that forces us to
introduce either a lot of C or a lot of useless C++ casts. One way
is to port sfiglue along with the code you did. Another is the 
following, if something is just an issue on the language layer (i.e. not 
affecting ABI or semantics), I'd rather see us special case C++ vs. C in 
some very few selected places, that allow easy cleanups. E.g.:
#ifdef __cplusplus
void sfi_glue_gc_add (void(*)(void*));
#else /* !__cplusplus */
void sfi_glue_gc_add (void*);	// FIXME: remove C-legacy
#endif /* __cplusplus */

(Continue reading)

Stefan Westerfeld | 16 May 11:47 2011
Picon

Re: MERGE: bsescm2cxx

   Hi!

On Sat, May 14, 2011 at 12:56:25AM +0200, Tim Janik wrote:
> On 13.05.2011 17:11, Stefan Westerfeld wrote:
> >>* For sfi_glue_gc_add(), please investigate if changing
> >>   the second argument to (void(*free_func)(void*)) is likely to
> >>   reduce casts. The reason the second funciton pointer argument is
> >>   just void* is convenience in C, but were're moving away from that
> >>   so it doesn't make sense to keep convenince C stuff if it makes
> >>   our C++ life harder.
> >
> >I can reduce the number of casts in shell/bsescm* by changing the signature,
> >however there is quite a bit of C code that either will not compile at all or
> >will compile with warnings if I do this (for instance in sfi/sfiglue.c or the
> >generated beast-gtk/bstgenapi.c), so overall a lot of new casts need to be
> >added elsewhere. I'd suggest to delay this change until more of the remaining
> >code is already C++ified.
> 
> Hm, if we go like this then we end up with lots of C++-ified code that
> needs fixing after we've turned everything into C++. I.e. essentially
> demanding a 2 phase approach, which I'd like to avoid since it could
> allmost double our work. We should avoid any approach that forces us to
> introduce either a lot of C or a lot of useless C++ casts. One way
> is to port sfiglue along with the code you did. Another is the
> following, if something is just an issue on the language layer (i.e.
> not affecting ABI or semantics), I'd rather see us special case C++
> vs. C in some very few selected places, that allow easy cleanups.
> E.g.:
> #ifdef __cplusplus
> void sfi_glue_gc_add (void(*)(void*));
(Continue reading)

Tim Janik | 16 May 23:44 2011

Re: MERGE: fix subnormal test on AMD64 (2nd attempt)

Hi Stefan.

This change aparently caused a regression on MIPS, please
see this bug report:
 	https://bugzilla.gnome.org/show_bug.cgi?id=649669

On Sun, 9 Jan 2011, Stefan Westerfeld wrote:

>   Hi!
>
> Since on AMD64, denormals are treated as zero (a feature of SSE math), the
> subnormals test breaks. My previous merge request was not accepted, because it
> didn't check the CPU status registers, but just assumed that if a certain
> calculation resulted in 0, CPU would be in DAZ mode.
>
> So in my new attempt to fix this, I check the CPU status registers. I also
> check if the SSE unit is actually used for floating point math by checking
> x86_64 and FLT_EVAL_METHOD defines.
>
> repo:   http://space.twc.de/public/git/stwbeast.git
> branch: subnormals2-amd64
>
>   Cu... Stefan
> -- 
> Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan
> _______________________________________________
> beast mailing list
> beast <at> gnome.org
> http://mail.gnome.org/mailman/listinfo/beast
>
(Continue reading)

timj | 16 May 23:35 2011
Picon

Re: Gsl FFT <-> FFTW compatibility

Hi Stefan,

thanks for working on this.
Attached you will find 4 patches which you can apply with git-am.
These are your fft branch patches rebased onto current master plus
documentation fixes where recent changes introduced conflicts.

Unfortunately the code can't be merged as is (thus this email)
because of the following issues:

* testfft.c - buffer overrun in line 200: memcpy (dft_in, ref_fft_in, MAX_FFT_SIZE * sizeof (dft_in[0]));
   from glibc:
 	Checking reference fft for size 2: [*** buffer overflow detected ***:
/opt/src/beast/bse/tests/.libs/lt-testfft terminated
   This is possibly because MAX_DFT_SIZE != MAX_FFT_SIZE.
   Why's there a MAX_DFT_SIZE in the first place?

* Why does gsl_power2_fftsc() contain this line?
   /* { unsigned int i; for (i = 0; i < n_values << 1; i++) rivalues_out[i] *= (double) n_values; } */

* Why does gsl_power2_fftar(), an AnalysisReal function now contain
   a call to a *synthesis* function? gsl_power2_fftsc

* Why does gsl_power2_fftsr(), a SynthesisReal function now contain a
   call to an *analysis* function? gsl_power2_fft*analysis_skip2

For the latter two, should there possibly be some a<->s or analysis<->synthesis
renames in place, to fix the obvious consistency discrepancy?

On Wed, 13 Oct 2010, Stefan Westerfeld wrote:
(Continue reading)


Gmane