similar to: PATCH for encode.c, format_input()

Hello, I have the following data.frame structure(list(Study = structure(c(1L, 2L, 3L, 4L, 5L, 6L, 7L, 8L, 9L, 10L, 11L, 12L, 13L, 14L, 15L, 16L, 17L, 18L, 19L, 1L, 2L, 3L, 4L, 5L, 6L, 7L, 8L, 9L, 10L, 11L, 12L, 13L, 14L, 15L, 16L, 17L, 18L, 19L, 1L, 2L, 3L, 4L, 5L, 6L, 7L, 8L, 9L, 10L, 11L, 12L, 13L, 14L, 15L, 16L, 17L, 18L, 19L, 1L, 2L, 3L, 4L, 5L, 6L, 7L, 8L, 9L, 10L, 11L, 12L, 13L, 14L,

With current settings, MSVS links debug version of flac.exe (and other .exe and .dll files) with the release version of libogg_static.lib. MSVS issues a "warning LNK4098: defaultlib 'libcmt.lib' conflicts with use of other libs; use /NODEFAULTLIB:library" What's the reason in this setting? What is better: * to change the settings so that MSVS will link debug .exe files with

FLAC__bitmath_ilog2_wide() function is still problematic: 1) it cannot be compiled with MSVS 2) it returns correct results only when compiles with GNUC 3) it mentions LGPL which isn't good for a BSD-licensed library Here's the patch that should fix these issues. (about LGPL -> CC0 change: http://lists.xiph.org/pipermail/flac-dev/2013-September/004356.html ) -------------- next part

lvqcl wrote: > Why? We can use vsnprintf_s for MSVS, and vsnprintf for MinGW. > > MSVS version of vsnprintf_s is located inside (statically linked) msvcp???.lib > or (dynamically linked) msvcp???.dll. They are part of MSVS runtime, and compatible > with WinXP. So it is safe to use it in FLAC. Oh, ok. I missed this bit. I know so very little about Windows. However, if you compile

MSVS profiler shows that the following code in stream_encoder.c takes several percent of CPU time: for(rice_parameter = 0, k = partition_samples; k < mean; rice_parameter++, k <<= 1) ; this code is equivalent to: rice_parameter = 0; k = partition_samples; while(k < mean) { rice_parameter++; k <<= 1; } The idea was to accelerate it:

SimplifyLibCalls.cpp is no longer part of Transforms\IPO and Transforms\Scalar\SimplifyCFG.cpp is renamed to SimplifyCFG.cpp or something to that effect ( I didn't look up the actual checkins ). Having fixed that, I still can't get through the build: Creating library C:\work\s\llvm\win32\\bin\Win32\Debug/opt.lib and object C:\work\s\llvm\win32\\bin\Win32\Debug/opt.exp 1>opt.obj : error

On Thu, Sep 1, 2016 at 1:30 PM, Aaron Ballman <aaron at aaronballman.com> wrote: > On Thu, Sep 1, 2016 at 1:23 PM, Nico Weber via cfe-dev > <cfe-dev at lists.llvm.org> wrote: > > As mentioned upthread, we're still on update 2 for various reasons. > > Do you mind elaborating on those reasons? Off the top of my head, clang-cl couldn't handle the code

Erik de Castro Lopo wrote: >> because MSVS2005 doesn't provide stdint.h. According to MSDN, >> uintptr_t is defined in "STDDEF.H and other include files". > > Does the rest of FLAC actually support those compilers? Yes. I removed this #include and all projects were successfully built with MSVS 2005 Express. > Is it worth > continuing to support them? * At

Ralph Giles wrote: >> With current settings, MSVS links debug version of flac.exe (and other >> .exe and .dll files) with the release version of libogg_static.lib. >> MSVS issues a "warning LNK4098: defaultlib 'libcmt.lib' conflicts with use >> of other libs; use /NODEFAULTLIB:library" > > Sounds like a bug. Debug targets should link to debug builds

Hugo Beauzée-Luyssen <hugo at beauzee.fr> wrote: > --- > src/share/win_utf8_io/win_utf8_io.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/src/share/win_utf8_io/win_utf8_io.c > b/src/share/win_utf8_io/win_utf8_io.c > index c61d27f3..1437b41e 100644 > --- a/src/share/win_utf8_io/win_utf8_io.c > +++ b/src/share/win_utf8_io/win_utf8_io.c >

By default, FLAC requires ogg library. Support of old versions of Visual Studio was removed from libogg code about 2 years ago: https://git.xiph.org/?p=ogg.git;a=commit;h=18c401c6bc8814d06f3ae53ebf5d4399f90871cc libogg 1.3.3 (released 2017-11-07) cannot be built with MSVS 2005/2008 anymore. Are there any developers that want to use libFLAC in their programs and still use Visual Studio 2005 or

src/libFLAC/memory.c cannot be compiled with MSVS 2005 (and probably VS2008 too) after this commit: http://git.xiph.org/?p=flac.git;a=commitdiff;h=7cbecbae9f70be770f7651d09531fec0de6f9cf5 because MSVS2005 doesn't provide stdint.h. According to MSDN, uintptr_t is defined in "STDDEF.H and other include files".

I frequently see mention of how upgrading is problematic, is there anyone here for whom upgrading msvc versions is problematic? It seems like we keep talking in hypotheticals, but I'd like to hear from someone for whom it is *actually* a problem, and why. Vs community is permissive enough now that licensing isn't an issue. And every time this comes up it seems like we're saying

As mentioned upthread, we're still on update 2 for various reasons. On Thu, Sep 1, 2016 at 1:07 PM, Robinson, Paul <paul.robinson at sony.com> wrote: > Hi Reid, first off thanks *very* much for all your help fixing > 2013-related problems. We really appreciate it. > > > > Let me propose a target date of September 15 for advancing the minimum MS > compiler to

I'd like to revisit this. As a person who spends a fair amount of time monitoring our VS 2013 buildbots, I would say that I am ready to throw in the towel on MSVC 2013. Since this discussion, I have committed five (!) workarounds for MSVC 2013: # in llvm $ git log --author=rnk --grep=2013 --after='Aug 4 2016' --oneline 21a8ade Fix the MSVC 2013 build by using Elf_Word instead of

On Fri, Oct 2, 2020 at 1:48 AM George Rimar <grimar at accesssoftek.com> wrote: > Thanks, David! > > > Few minor additions to the topic: > > > > I'm not sure which MSVC version on godbolt would be "MSVC 2017" that > the LLVM docs refer to > > > I've found that the minimal available version of MSVC on > godbolt is "WINE MSVC 2015:

On Thu, Oct 1, 2020 at 2:08 AM George Rimar <grimar at accesssoftek.com> wrote: > FWIW, I've performed an experiment with the code below at godbolt. > (used -O2, https://godbolt.org/z/nY95nh) > > ``` > #include <vector> > #include "llvm/Support/Error.h" > > llvm::Expected<std::vector<int>> foo() { > std::vector<int> V; >

More specifically, about this patch: http://git.xiph.org/?p=flac.git;a=commitdiff;h=70b078cfd5f9d4b0692c33f018cac3c652b14f90 I downloaded the latest code from git (flac-70b078c), disabled all SSE optimizations in the code and compiled it (GCC 4.8.2). This patch doesn't change FLAC output. Either gcc is too smart and optimizes this new code back to the old, or this fix is MSVS-specific. Or

When compiling lpc.c for x86-64 architecture MSVS issues warnings: warning C4028: formal parameter _N_ different from declaration because of flac_restrict modifier. This patch suppresses these warnings. -------------- next part -------------- A non-text attachment was scrubbed... Name: lpc-msvs-warnings.patch Type: application/octet-stream Size: 1025 bytes Desc: not available Url :

hi, Olly Betts, Thank you for you answer. My xapian version is 1.2.8. Need I upgrade it to 1.4 if I want to build it with MSVC2017 x64? lishu at fiberhome.com From: Olly Betts Date: 2018-03-29 11:10 To: 李澍; xapian-discuss Subject: Re: how to build 64bit xapian using MSVC2017? On Tue, Mar 20, 2018 at 08:28:24PM +0000, Olly Betts wrote: > Related to this, the appveyor build is