similar to: smbclient -b parameter

Samba 2.0.7 running on Compaq Tru64 UNIX V5.0A with latest tru64 patches. "mget *" works OK, "mput *" or something like "mput *.bat" fails with the error message "find: bad option -maxdepth". Several questions - Anyone else come across this one? Would dropping back to 2.0.6 fix the problem? Could it be an issue with 2.0.7 on Tru64 V5? Regards, Brian

Samba 2.0.7 running on Compaq AlphaServer Tru64. Using smbclient to get files from a Windows 2000 Server. Nearly always we get a non-specific error code, sample below. When it does fail, it fails consistently. In the example below, whenever this particular get fails, it always fails at exactly the same point. The same is the case with other files and it doesn't seem to matter about the file

On Wednesday 16 December 2009 13:35, David Greene wrote: > > Please make BufferSize an 'unsigned' and default it to 8192. Please use > > PRESERVE_STREAM instead of 'false'. Here's an updated version of the circular buffer. Ok to check in? -Dave Index: include/llvm/Support/circular_raw_ostream.h

On Friday 18 December 2009 13:56, David Greene wrote: > On Friday 18 December 2009 13:53, David Greene wrote: > > > > + void releaseStream() { > > > > + // Delete the stream if needed. Otherwise, transfer the buffer > > > > + // settings from this raw_ostream back to the underlying > > > > stream. + if (!TheStream) > > >

On Dec 16, 2009, at 8:12 AM, David Greene wrote: >>> >>> What, specifically, do you want reviewed before I start checking in? >>> I'll be happy to prepare a patch that shows just that. >> >> I want a patch that does one thing (e.g. implements dbgs(), > > Ok, let's start with that. Here's the patch to add the circular raw_ostream. This

On Friday 18 December 2009 12:28, Chris Lattner wrote: > This is looking a lot better, here are some more comments: > > + /// current_pos - Return the current position within the stream, > > + /// not counting the bytes currently in the buffer. > > + virtual uint64_t current_pos() { > > I didn't notice this earlier, but is there any reason for current_pos

On Friday 18 December 2009 13:53, David Greene wrote: > > > + void releaseStream() { > > > + // Delete the stream if needed. Otherwise, transfer the buffer > > > + // settings from this raw_ostream back to the underlying stream. > > > + if (!TheStream) > > > + return; > > > + if (DeleteStream) > > > +

hy, here is my speex encoder/decoder .. the sampleRate i use is 16000 and quality,complexity are at 5. can someone take a look in to the code and see if there is something that is making that robot voice here is a link to colored and numbered code, same as below http://barvanjekode.gama.us/temp/1257361243.html thanx. code ----------------------- #include "codec.h"

On Wednesday 16 December 2009 13:19, Chris Lattner wrote: > + int BufferSize; > + std::vector<char> BufferArray; > + bool DelayOutput; > + std::vector<char>::iterator Cur; > > Please doxygenify these. Ok. > Instead of using a std::vector for BufferArray, please just new[] an array > since it is fixed size. Ok. > Why is BufferSize needed with

On Dec 17, 2009, at 3:41 PM, David Greene wrote: > On Wednesday 16 December 2009 13:35, David Greene wrote: > >>> Please make BufferSize an 'unsigned' and default it to 8192. Please use >>> PRESERVE_STREAM instead of 'false'. > > Here's an updated version of the circular buffer. Ok to check in? This is looking a lot better, here are some more

On Friday 18 December 2009 17:22, David Greene wrote: > On Friday 18 December 2009 13:56, David Greene wrote: > > On Friday 18 December 2009 13:53, David Greene wrote: > > > > > + void releaseStream() { > > > > > + // Delete the stream if needed. Otherwise, transfer the > > > > > buffer + // settings from this raw_ostream back to

Unfortunately I can't reproduce your memory leak reports. For example, here is the line about my production darkice instance from top: PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 27516 root 20 0 3564 3564 1340 S 95.6 1.3 47:06 darkice <p>this as after approx 50 minutes from start, but the memory load doesn't change for the whole 4 hours it

Hi, I have a model which has properties, these are your standard name/value pairs, but also have attributes that affect how I want to store them in ferret. I was using 0.9.5 with 0.2 of aaf, which seemed fine, I just copied and pasted (yes, I know, ick) the to_doc method and added code to iterate though the properties that that model had, and add relavent fields to the document. It seems

On Friday 18 December 2009 17:27, David Greene wrote: > > Here's the updated patch. > > Well, that didn't go through right. Here it is again. Argh! Stupid bug fixed. :) Index: include/llvm/Support/circular_raw_ostream.h =================================================================== --- include/llvm/Support/circular_raw_ostream.h (revision 0) +++

On Friday 18 December 2009 19:47, Chris Lattner wrote: > On Dec 18, 2009, at 3:46 PM, David Greene wrote: > > + /// circular_raw_ostream - A raw_ostream that saves its output in a > > + /// circular buffer. > > A better description would be "which *can* save its data to a circular > buffer, or can pass it through directly to an underlying stream if > specified

I''m adding tables to the storeconfigs database, to support my storereports plugin, and would like some guidance on handling the schema version. First prize would see my database extensions applied as migrations. But then ActiveRecord would want to bump the schema version. Any ideas on how to handle this gracefully so that I don''t confuse the hell out of puppet itself, on

The current code only works iff the tsize option is set. This patch fixes the handling of the OACK packet and makes the code work with all combinations of the tsize and blksize options. Signed-off-by: Sebastian Herbszt <herbszt at gmx.de> diff --git a/core/pxe.c b/core/pxe.c index 81d3e23..a4b8a14 100644 --- a/core/pxe.c +++ b/core/pxe.c @@ -913,8 +913,10 @@ static void pxe_searchdir(char

I wonder if anyone would have a comment on an experiment I have pretty much completed in my MFC/C++ project. With my simple libvorbis implementation, ogg decoding works just fine for files that are 10kb or larger. For anything smaller (actually, I don't have a 9kb file, so <= 8), it seems that I get an inaccurate value for ov_pcm_total. Though ov_read returns zero, I overflow the buffer

hy, recording and playback is working perfectly without speex. i have try to set samplerat from 6000 to 441000 and quality from 1 to 10 sam with complexy, but the best i can get is with 16000 samplerate, 5quality and 3complexy .. but still, the voice that came out is annoying, artificial, robot ,... Lp, Tim +--------------------------+ | email: rico at gama.us | | www: http://gama.us

Kristjan Gu?ni Bjarnason wrote: > I was looking more closely on the source for Darkice. I found the code for > calulating the buffersize somewhat strange. Your is snapshot taken from the > init function in CastSink.cpp : > > int bufferSize = bitRate ? (bitRate * 1024 / 8) * bufferDuration > : (128 * 1024 / 8) * bufferDuration; >