search for: subbs

Hi, I just started using R a few weeks ago and have a problem with linking Fortran subroutines to R. For some reasons, I need to compile a Fortran program in R (or Splus) and the whole program consists a couple of subroutines, say, subA and subB. There is no difficulty in linking the subroutines individually, but two subroutines are nested, as shown below, SUBROUTINE subA(arg.) EXTERNAL

Hello all R-helpers, I've performed an experiment to test for differential effects of elevated temperatures on three different groups of corals. I'm currently performing a cox proportional hazards regression with censoring on the survivorship (days to mortality) of each individual in the experiment with two factors: Temperature Treatment (2 levels: ambient and elevated) and

Dear list, I am confused on how to explain the interaction term in the context of "treatment contrast". for example, I have an data frame as below: sub group val 1 a group1 3.685625 2 a group1 3.407445 3 a group1 4.040920 4 a group1 2.890875 5 b group1 3.853280 6 b group1 4.113585 7 b group1 3.043250 8 b group1 3.800920 9 c group1 5.394305 10 c

...d dovecot-sieve v 2.2.27 installed on a Debian 9.6. I'm trying to set a Sieve filter which will redirect all emails from `info` (i.e. .info) TLD to another email. This is the filter: require ["regex"]; # rule:[test] if header :regex "from" "info$" { redirect "subbs at domain.com"; } It's not being honored; all emails from .info TLD ends up in the inbox and none are redirected. Let me know what I'm doing wrong. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://dovecot.org/pipermail/dovecot/attach...

I have two vectors for values collected from a group of subjects, say a=c(100,200,150,120,140,180) b=c(200,300,420,130) I also have two vectors which indicate the corresponding subjects for a and b, say for a, the subjects are suba=c(1,2,3,4,5,6) for b, the subjects are subb=c(1,3,5,6) Then, I want to find out the paired values from a and b, such as (100, 200) (from subject 1), (150,300)

Hi all, I've been a tad busy in the last few weeks, but I don't think this issue is settled yet. > > the relations between each address space (equivalent, disjoint, subset/ > > superset). > > Any thoughts on that? Should they also belong in TargetData? > Only if absolutely required, see below. Is there any other place they would fit in better? What piece of below

On 5/16/2013 11:17 AM, Jakob Stoklund Olesen wrote: > > Would this TRI function solve your problem? >[...] > /// > /// Covering = getCoveringLanes(); > /// MaskA = getSubRegIndexLaneMask(SubA); > /// MaskB = getSubRegIndexLaneMask(SubB); > /// > /// If (MaskA & ~(MaskB & Covering)) == 0, then SubA is completely covered by > /// SubB.

On May 16, 2013, at 8:13 AM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: > The function TII::canCombineSubRegIndices has been gone for a while now, and I was wondering if there is a target-independent way of determining if a certain set of physical registers "adds up" to a larger register. For example, on X86, AL and AH together form AX. On Hexagon, R0 and R1 are

...ia dovecot wrote: > Hi! > > You forgot the wildcard '.*'?(=?Match zero or more instances of any > single character, except newline) > > require ["regex"]; > # rule:[test] > if header :regex "from" ".*info$" > { > ? redirect "subbs at domain.com"; > } > > With this rule, you are filtering emails from toplevel domain > '*.info' > or new domains that might occur in future (e.g '*.superinfo'). If you > want to restrict to classic tld '*.info' change the regex to > > ".*...

The function TII::canCombineSubRegIndices has been gone for a while now, and I was wondering if there is a target-independent way of determining if a certain set of physical registers "adds up" to a larger register. For example, on X86, AL and AH together form AX. On Hexagon, R0 and R1 are D0. The context here is an attempt to coalesce multiple loads/stores into fewer loads/stores

Hi Matthijs, > >>> Specifically, I would like instcombining to be able to use this >>> info to >>> remove useless bitcasts. Also, this information is useful for >>> clang to >>> know when inserting an implicit cast makes sense and when it >>> would be an >>> error. >> Clang should just reject implicit casts in *any*

On Jul 22, 2008, at 1:36 AM, Matthijs Kooijman wrote: >> Yep, I think it makes sense for TargetData to have info about the >> size/ >> alignment of a pointer in each addr space. That is also easy to >> encode. > Which is an added bonus, but the original subject under discussion > was the > relations between each address space (equivalent, disjoint, subset/

Hi Chris, > >> You probably want to somehow extend TargetData to encode the address > >> space descriptions, including pointer sizes and address space > >> relationships. > > Hmm, you have an excellent point there, pointer sizes could indeed easily > > have different sizes in different address spaces... That would make > > TargetData indeed a logical

Hi! You forgot the wildcard '.*'?(=?Match zero or more instances of any single character, except newline) require ["regex"]; # rule:[test] if header :regex "from" ".*info$" { ? redirect "subbs at domain.com"; } With this rule, you are filtering emails from toplevel domain '*.info' or new domains that might occur in future (e.g '*.superinfo'). If you want to restrict to classic tld '*.info' change the regex to ".*\.info$" The draft lists a table...

...and dovecot-sieve v 2.2.27 installed on a Debian 9.6. I'm trying to set a Sieve filter which will redirect all emails from `info` (i.e. .info) TLD to another email. This is the filter: require ["regex"]; # rule:[test]if header :regex "from" "info$"{ redirect "subbs at domain.com (mailto:subbs at domain.com)";} It's not being honored; all emails from .info TLD ends up in the inbox and none are redirected. Let me know what I'm doing wrong. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://dovecot.o...

--- mbr/Makefile | 6 +- mbr/mbr-diag.S | 372 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 377 insertions(+), 1 deletions(-) create mode 100644 mbr/mbr-diag.S diff --git a/mbr/Makefile b/mbr/Makefile index 0bdf7e3..b9d743d 100644 --- a/mbr/Makefile +++ b/mbr/Makefile @@ -17,7 +17,7 @@ topdir = .. include $(topdir)/MCONFIG.embedded -all: mbr.bin gptmbr.bin

--- mbr/Makefile | 6 +- mbr/mbr-diag.S | 371 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 376 insertions(+), 1 deletions(-) create mode 100644 mbr/mbr-diag.S diff --git a/mbr/Makefile b/mbr/Makefile index 0bdf7e3..b9d743d 100644 --- a/mbr/Makefile +++ b/mbr/Makefile @@ -17,7 +17,7 @@ topdir = .. include $(topdir)/MCONFIG.embedded -all: mbr.bin gptmbr.bin

Basic infrastructure for Xen S3 support with a common CPU context save/restore logic for both 32bit and 64bit. Wakeup code is split into two parts: - the first locates after trampoline code, to share all the tricks on the latter, like relocation base and identy mapping - the 2nd part locates in xen code segment, to do the actual CPU context restore Signed-off-by Ke Yu

--- mbr/Makefile | 6 +- mbr/mbr-diag.S | 377 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 382 insertions(+), 1 deletions(-) create mode 100644 mbr/mbr-diag.S diff --git a/mbr/Makefile b/mbr/Makefile index 0bdf7e3..b9d743d 100644 --- a/mbr/Makefile +++ b/mbr/Makefile @@ -17,7 +17,7 @@ topdir = .. include $(topdir)/MCONFIG.embedded -all: mbr.bin gptmbr.bin

From: Jeremy Fitzhardinge <jeremy.fitzhardinge at citrix.com> Hi all, This series does two major things: 1. It converts the bulk of the implementation to C, and makes the "small ticket" and "large ticket" code common. Only the actual size-dependent asm instructions are specific to the ticket size. The resulting generated asm is very similar to the current