search for: harmonising

...cal on CPU? > How one can even guarantee e.g. that a calling > convention for NVIDIA GPUs is appropriate for ATI GPUs? We have full control over the target code generators. There's nothing stopping us defining a specific constant representing the 'kernel' calling convention and harmonising the GPU targets to use that calling convention. Thanks, -- Peter

Hello, With the introduction of SSH_ASKPASS_REQUIRE in version 8.4, I've set up a script for SSH_ASKPASS to query my local passwordstore (https://www.passwordstore.org/) vault to retrieve the password for a given key. This works for ssh-add as well as ssh (configured with AddKeysToAgent set to 'yes'). My workflow effectively transforms into entering the password for the GPG key used

On 22:17, Thu 25 Sep 14, Charles Lepple wrote: > > I think the OMNIVS800 protocol 2012 entry came from Tripp Lite test results. (There have definitely been naming collisions in the past; hence, the messages in the drivers if you accidentally choose the wrong one.) > > Confusingly, if the USB ProductID is 0001, the Tripp Lite specific "Protocol" number (shown in

> On that note, has anyone written a tool that "harmonises" users mail > directories' permissions - ideally reading the dovecot configuration to assess > where *THE* mail directories are actually used by dovecot? doveadm user $user which will supply the second half: it will spit out the UID, GID, home and mail directories of a user as specified by dovecot's

David "Show Me The Vintage!" McGuire wrote: > I for one am finding this thread extremely entertaining. I have to > wonder how you'd sound if you came across a machine that was actually > OLD. ;) Well, I am fond of "old" hardware, which may still be on the wrong side of the New/Old divide for some of you: DECSYSTEM-20s and VAX 11/780s were the first

Greetings: As I am not a windows user, I cannot try this: is it possible to install rgdal on windows without having to compile it from source ? Compilation on MacOS is within my abilities, however each time i try and install the rgdal package it dies complaining that it cannot find gdal-config --- which was recently installed with GRASS. I have updated my PATH environment variable, logged

> From: Peter Collingbourne [mailto:peter at pcc.me.uk] > Sent: 20 December 2010 20:11 > As with __local variables, it may be that "kernelness" cannot be > represented in a standard form in LLVM. For example on a CPU a > kernel function may have an additional parameter which is a pointer to > __local memory space, which would not be necessary on GPUs. Then in >

On Sep 26, 2014, at 3:48 AM, Dave Williams <dave at opensourcesolutions.co.uk> wrote: > On 22:17, Thu 25 Sep 14, Charles Lepple wrote: >> >> I think the OMNIVS800 protocol 2012 entry came from Tripp Lite test results. (There have definitely been naming collisions in the past; hence, the messages in the drivers if you accidentally choose the wrong one.) >> >>

On 06/09/2017 05:13 PM, M. Balridge wrote: > I do know that this little box of horrors has 200-300MB mbox INBOXes on an > ext3 filesystem formatted in 2005. I am very nervous about converting them to > Maildir at this point. If I could get someone (or something) to the site and > replace it with something much more suitable, I could have these people join > the 21st Century. I

On Sep 25, 2014, at 5:51 PM, Dave Williams <dave at opensourcesolutions.co.uk> wrote: > Using this UPS in the UK on 240V mains. > > Connected via USB: > Bus 001 Device 002: ID 09ae:0001 Tripp Lite > > Requires tripplite_usb driver as it is (Product ID: 0001). There is an > entry in the compatibity list for OMNIVS800 USB (protocol 2012) using > usbhid-ups which is

...can even guarantee e.g. that a calling > > convention for NVIDIA GPUs is appropriate for ATI GPUs? > > We have full control over the target code generators. There's nothing > stopping us defining a specific constant representing the 'kernel' > calling convention and harmonising the GPU targets to use that > calling convention. > > Thanks, > -- > Peter > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

With 2.0.18 I was using a quota warning script like this: plugin { ... # Quota quota = maildir quota_rule = INBOX.Trash:storage=+2048M quota_warning = storage=99%% quota-warning 99 %u quota_warning2 = storage=95%% quota-warning 95 %u quota_warning3 = storage=90%% quota-warning 90 %u quota_warning4 = storage=85%% quota-warning 85 %u } # der schickt die Quota warnmails service

I'm announcing today a new testsuite application for Markdown called MDTest. I've been using it as a replacement for John's Markdown Test for some time now I think it's ready for release. First, I want to say Markdown Test has been very useful in developing PHP Markdown. The testsuite covers many cases, however I still found the need to add other tests for PHP Markdown, to

Using this UPS in the UK on 240V mains. Connected via USB: Bus 001 Device 002: ID 09ae:0001 Tripp Lite Requires tripplite_usb driver as it is (Product ID: 0001). There is an entry in the compatibity list for OMNIVS800 USB (protocol 2012) using usbhid-ups which is little misleading (although I guess maybe correct for some instances of the UPS). OMNIVS1000 USB (older; product ID: 0001) is

> I do know that this little box of horrors has 200-300MB mbox INBOXes on an > ext3 filesystem formatted in 2005. I am very nervous about converting them to > Maildir at this point. Fortunately, it just involves reformatting the data and a little reconmfiguration of dovcot. If you can find the tool and disk space, it's well worth doing. Of course, when running a proverbial

Hello list. I have a perfectly working PV host, with this configuration: kernel = "/boot/vmlinuz-2.6.18.8-xen-3.3.0-7mdv" ramdisk = "/boot/initrd-2.6.18.8-xen-3.3.0-7mdv.img" root = "/dev/sda1 ro" extra = "(hd0)/boot/grub/menu.lst" memory = 256 maxmem = 512 name = "sexonthebeach" uuid = "f36962f5-0dec-4708-84a0-f5b4dea48d34" disk = [

On Fri, Dec 17, 2010 at 04:21:18PM -0500, David Neto wrote: > However we record the fact that a function is a kernel, the mechanism > should handle the case of a kernel calling another kernel. > Recall that a kernel called by another kernel behaves more like a > regular function. For example it doesn't have workspace iteration > automatically applied to it; rather it just