similar to: int to string TypeError annoyance

Use the right macro, which should avoid the warnings seen with Perl headers on some architecture. --- generator/perl.ml | 2 +- perl/typemap | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/generator/perl.ml b/generator/perl.ml index 19cabb6..a665051 100644 --- a/generator/perl.ml +++ b/generator/perl.ml @@ -242,7 +242,7 @@ DESTROY (sv) HV *hv = (HV *) SvRV (sv);

Hello, I seem to have hit a bug with adding meta data to a stream via the C++ interface. I am using FLAC 1.2.1. I've had a look through the email list archive and can't spot anything similar. The Stream::set_metadata(Prototype) function takes a double pointer which implies that it is expecting an array of pointers to Prototype objects. For example: FLAC::Metadata::Prototype

I've found what looks like a bug in FLAC++ inside the Stream::set_metadata() method. It appears that the contained calls to FLAC__stream_encoder_set_metadata() are being passed arguments that point to local stack data (specifically the 'm' parameter which is a table that points to metadata objects). The code inside FLAC__stream_encoder_set_metadata() does nothing but store the given

Hi Rich, While I was looking at hivex today I ran coverity on it. It spotted one problem but missed a similar one nearby. The following are from Hivex.xs: (generated by generator.ml) void node_set_values (h, node, values) hive_h *h; int node; pl_set_values values = unpack_pl_set_values (ST(2)); PREINIT: int r; PPCODE: r = hivex_node_set_values (h, node,

Josh Coalson wrote: > [...] > why do you need one? all the fields are available though method > calls. just an example: I created an object of the type "FLAC::Metadata::VorbisComment". How will this find it's way to "FLAC::Stream::Encoder.set_metadata()" ??? Thomas

Hi, We are using the libFLAC++ library to encode FLAC files with Vorbis comments in them and have had the FLAC 1.1.2 version fail consistently (access violation or segmentation fault) on both Windows and Linux. We tracked this down to the metadata code in the C++ API. The problem is in src/libFLAC++/file_encoder.cpp. There are two problems - firstly, a C-style cast is hiding a bad conversion

I refer to a problem that appeared on the flac list last August that was either solved off-list or abandoned. (http://lists.xiph.org/pipermail/flac/2005-August/000468.html) The problem is with using the C++ encoder classes, particularly the FLAC::Encoder::File:set_metadata function. JC said that the developers version of how to add a simple metadata block looked right, but it did not work for

Hi, I'm sorry to say that I've found the libFLAC++ interface and documentation pretty slim and baffling. What I need to do is add some application-specific metadata to a FLAC file (i'm using the FLAC++ fileencoder). It is currently just a string of characters, which doesn't need to be null-terminated. I've looked through the docs, i've looked through the tests, and

Hi, I would like to use the nice C++ wrapper classes for FLAC metadata in a FLAC::Stream::Encoder, but I cannot find an interface to get a "FLAC__StreamMetadata *" from one of those objects. So, as the FLAC::Stream::Encoder.set_metadata() function takes a "FLAC__StreamMetadata **" - so how can I use this, how is this intended to work??? For me all those Metadata classes look

Carrying on this conversation: http://lists.tartarus.org/pipermail/xapian-discuss/2007-March/003513.html void TermGenerator::set_stopper(stopper) Stopper * stopper CODE: // FIXME: no corresponding SvREFCNT_dec(), but a leak seems better than // a SEGV! SvREFCNT_inc(ST(1)); THIS->set_stopper(stopper); It would be good to fix these FIXMEs. A class-level HASH could be

What the maximum filesize rsync can transfer? I'm trying to rsync one of my servers to another but the rsync is croaking on a file that's barely 1GB. Tips, hints, suggestions? rsync server is AIX 4.3.3 ML11 - rsync 2.6.3 rsync client is AIX 5.3 ML1 - rsync 2.6.4 Thanks -Jeff -- Jeff Schoby Unix/Network Admin City of Columbia, Missouri 573.874.6320

> > Olly Betts <olly at survex.com> wrote: > > > > > > The reverse order (ENQ_ASCENDING) is really fast - about 0.0001 seconds. > > > This is because in that case we can just stop once we've found 200 > > > matches. With a few million documents, that ENQ_ASCENDING sounds promising :) So, it looks like if I had ideal ordering, I could do

Requires patch 1 and 2 of the python series: https://www.redhat.com/archives/libguestfs/2017-January/msg00126.html This is the perl implementation along the same lines. We still haven't decided if patch 1 of the python series should change OCaml to report errno as reliable or not, but perhaps we can commit that patch as-is now and then touch things up further when we actually get set_error

I'm using libFLACC++ and libFLAC and I think that I'm using the calls in the typical order (see code below). But every monoe or stereo file that I send thru I get files that are the same sze as the orginal wave files. Doing a flac -a on the flac files I see that I get: frame=9 blocksize=4608 sample_rate=8000 channels=1 channel_assignment=INDEPENDENT subframe=0

Hi all, I've tried building RPMs for RHEL5 and hit this problem in Search::Xapian: make test fails on test 37: ok 34 - check PositionIterator ok 35 - create TermIterator ok 36 - check TermIterator dubious Test returned status 0 (wstat 11, 0xb) DIED. FAILED tests 37-65 Failed 29/65 tests, 55.38% okay $ xapian-config --version xapian-config - xapian-core 1.0.4 $ cat

Round 3 -- this time with working OCaml bindings. (I'm not on the list, please copy me on replies, thanks.) --- generator/generator.ml | 77 ++++++++++++++++++++++++++++++++++++++++- lib/hivex.c | 90 ++++++++++++++++++++++++++++++++++++++++++++++++ perl/t/201-setvalue.t | 54 ++++++++++++++++++++++++++++ 3 files changed, 219 insertions(+), 2 deletions(-) create mode 100644

Hi! I've been using a little C++ program I've written to encode flac files. The program does this in the usual way (I think), by inheriting a class from FLAC::Encoder::File, and passing it chunks of raw samples through process_interleaved()... Anyway, the program works beautifully, and I've now decided to try and add some metadata to the encoded flacs. Eventually, there will be vorbis

RHEL5 has autoconf 2.59 and automake 1.9.6. I've managed to build the whole Xapian family by reducing the requirement to 2.59/1.9.6 in configure.ac. Omega requires docdir which can be added by hand in docs/Makefile.am: docdir = ${datadir}/doc/${PACKAGE} if !MAINTAINER_NO_DOCS dist_doc_DATA = $(RSTHTML) endif All I've done is get these packages compiled - I haven't tested in any

Full_Name: Ed Borasky Version: 1.8.1 OS: Windows XP Professional Submission from: (NULL) (208.252.96.195) R 1.8.1 seems to be running into a memory allocation problem in the "aggregate" function. I have a rather large dataset (14 columns by 223,000 rows -- almost 40 megabytes) and a script that performs some processing on it. The system is a 768 MB Pentium 4. Here's the console

looks fine, I would suspect how the PCM sample are formatted and sent to process(), could you show that part of the code? Josh --- James Smith <jsmith@landmarkdigital.com> wrote: > > I'm using libFLACC++ and libFLAC and I think that I'm using the calls > in the > typical order (see code below). But every monoe or stereo file that > I send > thru I get files