similar to: Can lit be upgraded to assume Python 2.7?

This sounds like a good idea to me! I can’t think of any common platform where you can’t get 2.7. Lets get rid of that legacy cruft! > On Feb 23, 2016, at 1:32 PM, Eric Christopher <echristo at gmail.com> wrote: > > Seems reasonable to me. Chris? > > On Mon, Feb 22, 2016, 8:40 PM Sean Silva via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at

Great! I'll circle around to this at some point. Despite the "obvious" nature of it I still am wary of underestimating the cruftiness of the buildbots, so I'll probably do it some time at night when the bots are mostly green so that I can easily see if any bots *are* broken by this. -- Sean Silva On Tue, Feb 23, 2016 at 6:55 PM, Chris Matthews <chris.matthews at

OK, I give up and come grovelling, "Fork" was suggested at 18:23, it's now 22:20 and I have been through 4 different methods, all block with a 2 second delay before returning to dialplan. Here are just some of the examples I have tried, as as per the suggestions, I am closing all possible outputs in the forked process. https://docs.python.org/3.5/library/multiprocessing.html

Hi All, The landed patch https://reviews.llvm.org/D38481 introduced the usage of CPU_COUNT defined in glibc sched.h header. I failed to find this symbol in sched.h of glibc version 2.5-24, so compilation just fails. /home/dolphin/merge-from-upstream-area/ws/pristine/lib/Support/Threading.cpp: In function 'unsigned int llvm::hardware_concurrency()':

Hi, I have installed Calibre using wine 1.3.22 . The program is not usable since adding/converting ebooks is not working. Running wine calibre-debug -g I get the following error: Exception in thread Thread-4: Traceback (most recent call last): File "threading.py", line 530, in __bootstrap_inner File "site-packages\calibre\utils\ipc\server.py", line 221, in run File

Reverted: https://reviews.llvm.org/rL314922 On Oct 4, 2017, at 1:17 PM, Philip Reames via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: + Rui, the patch author Do we know what the oldest glibc which works with this patch is? For context, the most recent REHL 5 ships with glibc 2.5. REHL 6 ships with 2.12 and REHL ships with 2.17. I have evidence

Our build system is setup to deliberately use a very old environment.  We've found that's one of the most reliable easy ways to ensure we don't accidentally introduce a dependency on a newer system library than intended.  This lets us ship prebuilt binaries which run on a wide spectrum of systems.  We're going to chat internally and check to see if we can roll this forward a

Dear Devs, (I hope this question is not that much OT for this list..) My question is about fast OpenGL context switching, i.e. when there are several processes using the same nvidia card, each one with their own OpenGL context. In my specific case, I am trying to dump 720p video simultaneously to multiple windows using OpenGL textures. So, to begin with, I have a process that spans child

On Oct 4, 2017 2:31 PM, "Rui Ueyama via llvm-dev" <llvm-dev at lists.llvm.org> wrote: On Wed, Oct 4, 2017 at 2:19 PM, Philip Reames <listmail at philipreames.com> wrote: > Our build system is setup to deliberately use a very old environment. > We've found that's one of the most reliable easy ways to ensure we don't > accidentally introduce a dependency

Okay, joining hosts to a pool, cant seem to be completed due to different cpu types, research i should be able to mask one can anyone confirm this is doable with these two boxes, and if so which should be masked to which ?? xe host-cpu-info cpu_count : 8 vendor: GenuineIntel speed: 2493.790 modelname: Intel(R) Xeon(R) CPU

On 2012-12-01 21:57, Gregory Szorc wrote: > I'd like to continue the discussion about minimum Python versions from the "Use multiprocessing instead of threading" thread in its own thread because I feel it warrants additional discussion. ... > For these reasons, I urge LLVM to drop support for Python older than 2.6. I would encourage requiring 2.7 (preferably the latest

Happy new year to all; A few days ago, I posted similar problem. At that time, I found out that our R program had been 32-bit compiled, not 64-bit compiled. So the R program has been re-installed in 64-bit and run the same job, reading in 150 Affymetrix U133A v2 CEL files and perform dChip processing. However, the memory problem happened again. Since the amount of physical memory is 64GB, I think

> > Replicating ExternalProject would be a lot of work... > One approach commonly used with CMake modules that change frequently upstream is for the project to keep a local copy and have a check in place to use CMake's version if new enough. For instance, in llvm's source tree: cmake/modules/ExternalProject.cmake: if(CMAKE_VERSION VERSION_LESS "3.5.1")

I'd like to continue the discussion about minimum Python versions from the "Use multiprocessing instead of threading" thread in its own thread because I feel it warrants additional discussion. In that thread, we were discussing maintaining support for Python 2.4 and 2.5. The latest response is: On Fri, Nov 30, 2012 at 1:40 PM, Daniel Dunbar <daniel at zuster.org> wrote: >

Hans, I have posted a complete patch for solving the linkage issues with LLVM_LINK_LLVM_DYLIB on Phabricator at http://reviews.llvm.org/D16945. The bulk of the fix the simple changes of... Index: cmake/modules/AddLLVM.cmake =================================================================== --- cmake/modules/AddLLVM.cmake (revision 259743) +++ cmake/modules/AddLLVM.cmake (working copy) @@

On Sat, Dec 1, 2012 at 2:08 PM, Dimitry Andric <dimitry at andric.com> wrote: > On 2012-12-01 21:57, Gregory Szorc wrote: >> >> I'd like to continue the discussion about minimum Python versions from the >> "Use multiprocessing instead of threading" thread in its own thread because >> I feel it warrants additional discussion. > > ... >

I have been building R-devel daily for years. In the last week or so, R-devel has failed make check with the error in tests/Examples/parallel-Ex.R The specific error is > pkgname <- "parallel" > source(file.path(R.home("share"), "R", "examples-header.R")) > options(warn = 1) > library('parallel') Error in dyn.load(file, DLLpath =

I use a python AGI which pulls some info from a web service, which should take half a second. Sometimes, it takes 5-10 seconds which blocks the dialplan execution, but the dialplan should continue immediately as it's not dependent on the AGI/web service data. What's the simplest, easiest quickest least-code way of firing off an AGI with some variable, and then returning to the dialplan?

My name is Michael Frerichs and I am a part of a research team led by Dr. Krishna Kavi at the University of North Texas. Our current work focuses on optimizing dynamic memory for multiprocessor systems. We are interested in the LLVM infrastructure and the Automatic Pool Allocation technique. We believe this tool could be useful to our research and wondered if we could utilize your implementations

Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> writes: > On 24 February 2016 at 19:49, Sean Silva via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Great! I'll circle around to this at some point. Despite the "obvious" >> nature of it I still am wary of underestimating the cruftiness of the >> buildbots, so I'll probably do it some