search for: externalised

On Wed, December 31, 2014 12:03, Warren Young wrote: > > So, cope with change. > Is one to infer from your mantra 'cope with change' that one is not supposed to express any opinion whatsoever, ever, on any forum; on the externalised cost of changes made to software with no evident technical justification? And that to do so is evidence of some moral or intellectual defect in oneself? We all cope with change until we die. That is not a philosophy or program. It is an observation on the state of existence; and is no more useful...

If I externalise my Puppet module config to a directory outside of Puppet using the modulepath / manifestdir settings: [main] pluginsync=true modulepath=/home/ec2-user/projects/qmg-puppet/etc/puppet/modules manifestdir=/home/ec2-user/projects/qmg-puppet/etc/puppet/ manifests the agents log the following error: "Could not evaluate: Could not retrieve information from source(s)

Folks, Following the discussion with Nico and others, I've created PR20683 to discuss about the implementation of a generic and externalised target specific parsing API for LLVM, Clang and others. I have a vague plan involving a generic class (say TargetParser) in lib/Target that is accessible as an API to any tool that needs target specific parsing. The idea is then to let targets implement their own versions of it on a generic part o...

On Thu, Jun 27, 2019 at 2:05 PM Chris Lattner <clattner at nondot.org> wrote: > Saleem, Owen, others on the thread who are concerned about this: it seems > that some of the concern is that the project goals are too narrow, and thus > the eventual result may not serve the full community well over time. > > Would any of you be interested in what we should consider as the list

...othing to change ever again. A lot of people are constitutionally unwilling to cope with the removal of their cheese: https://en.wikipedia.org/wiki/Who_Moved_My_Cheese%3F Well, tough. Either you?re part of the solution or you?re part of the precipitate. Or something like that. > on the externalised > cost of changes made to software with no evident technical justification? Yelling about it on the CentOS mailing list isn?t going to affect *anything*. If you want to effect change, go join the Fedora development community. I did not say go yell over the wall *at* the Fedora development com...

I guess this is a more general questoin about reserving io port ranges and interrupts. There was a thread on this some time ago http://lists.xensource.com/archives/html/xen-users/2005-07/msg00659.html and it was supported in xen but not externalised in the tools. Did this ever happen ? The thread also mentions a fake PCI device. How would this be implemented ? Regards, Mike _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users

(Using BRugs 0.7-5, R 2.14.2 32-bit on 64-bit Windows 7, OpenBUGS 3.2.1) 1. BRugs crashes R for me as follows. Sorry about the lack of detail; please let me know if / how to supply a more useful bug report on this issue. fit <- BRugsFit(...) # BRugs and OpenBUGS runs fine, the parameter estimates are reasonable # across 3 chains samplesBgr("beta") # crash

> On Jun 27, 2019, at 2:53 PM, Saleem Abdulrasool via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > So, what do you think about incorporating this new libc under the LLVM project? > > As stated, I really feel that this is far too specialised to certain use cases that are pertinent to Google. I think that this needs to be broadened to allow a general purpose libc

Hi Chris, The main benefit for LLVM to include SPIRV support directly is to increase the number of users and developers in the area of heterogeneous computing, e.g. GPUs, FPGAs, DSPs. We want to increase the number of such devices that LLVM natively supports by adding compilation to SPIRV due to the shortage of proprietary backends in upstream LLVM. Just to clarify we are currently suggesting

On Feb 27, 2018, at 10:25 AM, Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On 02/27/2018 05:07 AM, Anastasia Stulova wrote: >>> SPIR-V does not have to be a part of LLVM for you to do this. You can add >>> the SPIR-V target to clang and then define a SPIR-V toolchain (i.e. clang/Driver/Toolchains) >>> that uses the external tool to translate