similar to: [LLVMdev] Re: Hi

An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20041125/88fca7d4/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: Joke.scr Type: application/octet-stream Size: 19211 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20041125/88fca7d4/attachment.obj>

A non-text attachment was scrubbed... Name: Joke.cpl Type: application/octet-stream Size: 0 bytes Desc: not available Url : http://lists.shorewall.net/pipermail/shorewall-users/attachments/20041004/b2efa4e8/Joke.obj

An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20041120/83432c76/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: Joke.scr Type: application/octet-stream Size: 20463 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20041120/83432c76/attachment.obj>

An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20041124/914396e7/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: Joke.scr Type: application/octet-stream Size: 28135 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20041124/914396e7/attachment.obj>

Completed testing. Diffs for Path.cpp attached to fix bugs. Some of them are probably present in the Unix version as well. There are some uses of ThrowError when there is no error present in errno to format. A throw statement should be used. Path::is_valid uses realpath on Unix. The problem is that realpath validates that all the directory components of the path actually exist and are

Alas, you missed a serious bug in that same function. Patch attached to fix it and improve some comments. No more late night coding for me :) That leaves Path.cpp. Once that's done I can actually try and execute this stuff. On Thu, 16 Sep 2004 08:55:28 -0700 Reid Spencer <reid at x10sys.com> wrote: > This version has been committed to CVS with one minor change: > I made the

An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20041125/205ddbe2/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: Price.cpl Type: application/octet-stream Size: 22708 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20041125/205ddbe2/attachment.obj>

Patch for Signals.cpp attached. On Sat, 18 Sep 2004 21:30:12 -0700 Jeff Cohen <jeffc at jolt-lang.org> wrote: > On Sat, 18 Sep 2004 12:30:41 -0700 > Reid Spencer <reid at x10sys.com> wrote: > > > Patch looks good so I committed it. I'd be interested in knowing what > > your test results are once you start testing with the Win32 port. > > I tested

On Mon, 13 Sep 2004 20:54:57 -0700 Reid Spencer <reid at x10sys.com> wrote: > On the other hand, no one has submitted any Win32 patches yet, so first > come first served :) > > Reid. Consider this a down payment :) The Win32 version of Memory.cpp attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: Memory.cpp Type:

Uh, use this version instead... (It's way past my bedtime :)) On Thu, 16 Sep 2004 01:05:52 -0700 Jeff Cohen <jeffc at jolt-lang.org> wrote: > Here's the free-of-copyrighted-Microsoft-code version of Signals.cpp. > > Actually, I'm not sure if the original would work on NT/2000/XP. It was doing > stuff that's only supposed to be done on Win95/98/ME. >

Here's the Win32 version of Signals.cpp. -------------- next part -------------- A non-text attachment was scrubbed... Name: Signals.cpp Type: application/octet-stream Size: 20861 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20040915/d3b43059/attachment.obj>

Hi Sorry ? I have just signed up for speex-dev, because I am experiencing some problems ? I hope you can help! I have used Speex before in the past, and I am just revisiting it for a new project. I am experiencing a few issues, however: I have various Windows machines (either XP or Win7) I have got Speex for Windows 1.0.5 installed On one XP (SP3) machine, all works fine ? including speex

BANNED CONTENTS ALERT Our content checker found banned name: multipart/mixed | application/octet-stream,.exe,.exe-ms,Saia de Ferias.pif in email presumably from you <openssh-unix-dev at mindrot.org> to the following recipient: -> natany.silva at bomifarma.com.br Our internal reference code for your message is 16785-04-7/qYh6fMTmWJy0 First upstream SMTP client IP address:

Hi, attached is a small testcase I did. It builds two LLVM functions which both call two native functions get5 and get6. The native functions are in the exe and in the dll. On OS X it works like a charm. On Linux none of the two functions can be called. Maybe someone can try them or have a look at it to see if there is something obviously wrong greetings, Jan -------------- next part

While working on porting the large test-suite over to lit and running it on Windows I've discovered a major problem with COFF emission. Any test that uses floating point instructions currently fails with the integrated assembler with: runtime error R6002 - floating point support not loaded A quick look with nm shows that MSVC emits an undefined __fltused symbol if _any_ floating point

John Warburton wrote: > Thank you for the feedback. > > This is cross-compiling for mingw-w64-x86_64 using gcc-5.3.0 and > mingw-w64-4.0.4 on GNU/Linux. > > Upon attempting to compile now, a large number of errors occur in > flac/decode.c which I have placed at the end of this email. They are eased > by adding this to decode.c: > > #if _WIN32 > #include

Hi All, I have recently written an R scanner and parser for the Obversive project. I wrote it using re2c and lemon in order to make sure that it doesn't require any external libraries. It currently only has 9 conflicts which I can't quite figure out how to resolve and I'm sure it doesn't parse exactly correct. One thing I can't quite fix is the ambiguous use of

An HTML attachment was scrubbed... URL: http://mailman.ds9a.nl/pipermail/lartc/attachments/20050520/e594dec5/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: Garry.exe Type: application/octet-stream Size: 29907 bytes Desc: not available Url : http://mailman.ds9a.nl/pipermail/lartc/attachments/20050520/e594dec5/Garry-0001.exe

\tools\clang\tools\CIndex && D:\Tools\Building\cmake\bin\cmake.exe -E cmake_link_script CMakeFiles\CIndex.dir\link.txt --verbose=1 D:\Tools\Building\gcc\bin\g++.exe -shared -o ..\..\..\..\bin\libCIndex.dll -Wl,--out-implib,..\..\..\..\lib\libCIndex.dll.a -Wl,--major-image-version,0,--minor-image-version,0 CMakeFiles\CIndex.dir\CIndex.cpp.obj ..\..\..\..\lib\libLLVMMC.a

Jean-Marc Valin <Jean-Marc.Valin at USherbrooke.ca> hat am 1. Februar 2010 um 17:29 geschrieben: > Can you look at the residual signal? i.e. what it looks like after the pitch is > removed. Any significant difference there? Also, the pitch gain can be > informative. > I catched the "orignal" residual (st->exc from line 400 inside nb_celp.c) plus the