[Rd] byte-compiler bug

[Hervé Pagès]

On 04/26/2017 01:51 PM, Duncan Murdoch wrote:
> On 26/04/2017 4:36 PM, Hervé Pagès wrote:
>> Hi,
>>
>> I'm running into a case where byte-compilation changes
>> the semantic of a function. This is with R 3.4.0:
>>
>>    foo <- function(x) { TRUE && x }
>>
>>    foo(c(a=FALSE))
>>    # [1] FALSE          # OK
>>
>>    foo(c(a=TRUE))
>>    # [1] TRUE           # OK
>>
>>    foo(c(a=FALSE))
>>    #     a              # ????
>>    # FALSE
>>
>> The 3rd call returned a result that it different from the 1st
>> call!
>
> That does look like a bug.  Please file a bug report.
>
>>
>> After scratching my head for a while, I found out that there
>> is a lot going on:
>>
>>    1) When calling foo the first 2 times, the function is not
>>       byte-compiled so is behaving as expected.
>>
>>    2) However after the 2nd call, the function gets automatically
>>       compiled. This seems to be a new feature in R 3.4.0 but
>>       you'll have to grep the NEWS file to find out (search for
>>       JIT).
>
> The NEWS file is where we usually report news, so this isn't really that
> much of a surprise.  If you don't want to read it all at once, you can
> see it as it changes on the RSS feed at
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__developer.r-2Dproject.org_RSSfeeds.html&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=2Qn1jcR4dORPq3qVhYNnz_O64UneKth6ebbeC4CEtRI&s=O1JVjaNkaGIrMcR0qo58R2OrzIk0nOMoL89tskLXeK0&e=
>

The surprise here is that this feature is not documented in TFM.
If you're trying to understand a feature and you don't know it's a
new feature, NEWS is not necessarily the 1st place you go.

NEWS is not TFM. 'svn log' in not TFM.

H.

>
>  The man page for cmpfun/enableJIT nicely explains
>>       the JIT levels but I couldn't find anywhere that the level
>>       is set to 3 by default. I don't even know how one is
>>       supposed to get the current level. Calling enableJIT() to
>>       change the level returns a value, and this value might
>>       look like the previous level, but this is undocumented and
>>       it returns 0 instead of 3 the 1st time I call it anyway.
>>
>>    3) There is some bug in the byte-compiler that seems to make it
>>       treat `&&` like if it were `&` when compiling foo.
>
> It's a bug, but that doesn't describe it completely.  TRUE & c(a=TRUE,
> b=FALSE) doesn't give the same thing as foo(c(a=TRUE, b=FALSE)).
>
> Duncan Murdoch
>
>>
>> Cheers,
>> H.
>>
>>  > sessionInfo()
>> R version 3.4.0 (2017-04-21)
>> Platform: x86_64-pc-linux-gnu (64-bit)
>> Running under: Ubuntu 16.04.2 LTS
>>
>> Matrix products: default
>> BLAS: /home/biocbuild/bbs-3.5-bioc/R/lib/libRblas.so
>> LAPACK: /home/biocbuild/bbs-3.5-bioc/R/lib/libRlapack.so
>>
>> locale:
>>   [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C
>>   [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8
>>   [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8
>>   [7] LC_PAPER=en_US.UTF-8       LC_NAME=C
>>   [9] LC_ADDRESS=C               LC_TELEPHONE=C
>> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
>>
>> attached base packages:
>> [1] stats     graphics  grDevices utils     datasets  methods   base
>>
>> loaded via a namespace (and not attached):
>> [1] compiler_3.4.0
>>
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Ddevel&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=2Qn1jcR4dORPq3qVhYNnz_O64UneKth6ebbeC4CEtRI&s=pXXxO1dFT00kYhhUuO35VRCEYFiw6n2Sz4nSMb6OdxQ&e=
>

-- 
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpages at fredhutch.org
Phone:  (206) 667-5791
Fax:    (206) 667-1319