The NetBSD Project

CVS log for pkgsrc/devel/R-magrittr/distinfo

[BACK] Up to [] / pkgsrc / devel / R-magrittr

Request diff between arbitrary revisions

Default branch: MAIN

Revision 1.5 / (download) - annotate - [select for diffs], Thu Apr 28 15:46:57 2022 UTC (17 months ago) by mef
Branch: MAIN
CVS Tags: pkgsrc-2023Q3-base, pkgsrc-2023Q3, pkgsrc-2023Q2-base, pkgsrc-2023Q2, pkgsrc-2023Q1-base, pkgsrc-2023Q1, pkgsrc-2022Q4-base, pkgsrc-2022Q4, pkgsrc-2022Q3-base, pkgsrc-2022Q3, pkgsrc-2022Q2-base, pkgsrc-2022Q2, HEAD
Changes since 1.4: +4 -4 lines
Diff to previous 1.4 (colored)

(devel/R-magrittr)  Updated 2.0.1 to 2.0.3

# magrittr 2.0.3

* Fixed a C level protection issue in `%>%` (#256).

# magrittr 2.0.2

* New eager pipe `%!>%` for sequential evaluation (#247). Consider
  using `force()` in your functions instead to make them strict, if
  sequentiality is required. See the examples in `?"pipe-eager"`.

* Fixed an issue that could cause pipe invocations to fail in versions of
  R built with `--enable-strict-barrier`. (#239, @kevinushey)

Revision 1.4 / (download) - annotate - [select for diffs], Tue Oct 26 10:14:05 2021 UTC (23 months, 1 week ago) by nia
Branch: MAIN
CVS Tags: pkgsrc-2022Q1-base, pkgsrc-2022Q1, pkgsrc-2021Q4-base, pkgsrc-2021Q4
Changes since 1.3: +2 -2 lines
Diff to previous 1.3 (colored)

archivers: Replace RMD160 checksums with BLAKE2s checksums

All checksums have been double-checked against existing RMD160 and
SHA512 hashes

Could not be committed due to merge conflict:

The following distfiles were unfetchable (note: some may be only fetched

./devel/pvs/distinfo pvs-3.2-solaris.tgz

Revision 1.3 / (download) - annotate - [select for diffs], Thu Oct 7 13:39:00 2021 UTC (23 months, 3 weeks ago) by nia
Branch: MAIN
Changes since 1.2: +1 -2 lines
Diff to previous 1.2 (colored)

devel: Remove SHA1 hashes for distfiles

Revision 1.2 / (download) - annotate - [select for diffs], Sun Dec 13 23:51:10 2020 UTC (2 years, 9 months ago) by mef
Branch: MAIN
CVS Tags: pkgsrc-2021Q3-base, pkgsrc-2021Q3, pkgsrc-2021Q2-base, pkgsrc-2021Q2, pkgsrc-2021Q1-base, pkgsrc-2021Q1, pkgsrc-2020Q4-base, pkgsrc-2020Q4
Changes since 1.1: +5 -5 lines
Diff to previous 1.1 (colored)

(devel/R-magrittr) Updated 1.5 to 2.0.1  make test fails at PDF

# magrittr 2.0.1

* Fixed issue caused by objects with certain names being present in
  the calling environment (#233).

* Fixed regression in `freduce()` with long lists (kcf-jackson/sketch#5).

# magrittr 2.0.0

## Fast and lean implementation of the pipe

The pipe has been rewritten in C with the following goals in mind:

- Minimal performance cost.
- Minimal impact on backtraces.
- No impact on reference counts.

As part of this rewrite we have changed the behaviour of the pipe to
make it closer to the implementation that will likely be included in a
future version of R. The pipe now evaluates piped expressions lazily (#120).
The main consequence of this change is that warnings and errors can
now be handled by trailing pipe calls:

stop("foo") %>% try()
warning("bar") %>% suppressWarnings()

## Breaking changes

The pipe rewrite should generally not affect your code. We have
checked magrittr on 2800 CRAN packages and found only a dozen of
failures. The development version of magrittr has been advertised on
social media for a 3 months trial period, and no major issues were
reported. However, there are some corner cases that might require
updating your code. Below is a report of the backward
incompatibilities we found in real code to help you transition, should
you find an issue in your code.

### Behaviour of `return()` in a pipeline

In previous versions of magrittr, the behaviour of `return()` within
pipe expressions was undefined. Should it return from the current pipe
expression, from the whole pipeline, or from the enclosing function?
The behaviour that makes the most sense is to return from the
enclosing function. However, we can't make this work easily with the
new implementation, and so calling `return()` is now an error.

my_function <- function(x) {
  x %>% {
    if (.) return("true")

#> Error: no function to return from, jumping to top level

In magrittr 1.5, `return()` used to return from the current pipe
expression. You can rewrite this to the equivalent:

my_function <- function(x) {
  x %>% {
    if (.) {
    } else {

#> [1] "true"

For backward-compatibility we have special-cased trailing `return()`
calls as this is a common occurrence in packages:

1 %>% identity() %>% return()

Note however that this only returns from the pipeline, not the
enclosing function (which is the historical behaviour):

my_function <- function() {
  "value" %>% identity() %>% return()
  "wrong value"

#> [1] "wrong value"

It is generally best to avoid using `return()` in a pipeline, even if

### Failures caused by laziness

With the new lazy model for the evaluation of pipe expressions,
earlier parts of a pipeline are not yet evaluated when the last pipe
expression is called. They only get evaluated when the last function
actually uses the piped arguments:

ignore <- function(x) "return value"
stop("never called") %>% ignore()
#> [1] "return value"

This should generally not cause problems. However we found some
functions with special behaviour, written under the assumption that
earlier parts of the pipeline were already evaluated and had already
produced side effects. This is generally incorrect behaviour because
that means that these functions do not work properly when called
with the nested form, e.g. `f(g(1))` instead of `1 %>% g() %>% f()`.

The solution to fix this is to call `force()` on the inputs to force
evaluation, and only then check for side effects:

my_function <- function(data) {

Another issue caused by laziness is that if any function in a pipeline
returns invisibly, than the whole pipeline returns invisibly as well.

1 %>% identity() %>% invisible()
1 %>% invisible() %>% identity()
1 %>% identity() %>% invisible() %>% identity()

This is consistent with the equivalent nested code. This behaviour can
be worked around in two ways. You can force visibility by wrapping the
pipeline in parentheses:

my_function <- function(x) {
  (x %>% invisible() %>% identity())

Or by assigning the result to a variable and return it:

my_function <- function(x) {
  out <- x %>% invisible() %>% identity()

### Incorrect call stack introspection

The magrittr expressions are no longer evaluated in frames that can be
inspected by `sys.frames()` or `sys.parent()`. Using these functions
for implementing actual functionality (as opposed as debugging tools)
is likely to produce bugs. Instead, you should generally use
`parent.frame()` which works even when R code is called from
non-inspectable frames. This happens with e.g. `` and the new
C implementation of magrittr.

### Incorrect assumptions about magrittr internals

Some packages were depending on how magrittr was internally
structured. Robust code should only use the documented and exported
API of other packages.

## Bug fixes

* Can now use the placeholder `.` with the splicing operator `!!!`
  from rlang (#191).

* Piped arguments are now persistent. They can be evaluated after the
  pipeline has returned, which fixes subtle issues with function
  factories (#159, #195).

Revision 1.1 / (download) - annotate - [select for diffs], Fri Jan 1 13:19:40 2016 UTC (7 years, 9 months ago) by wen
Branch: MAIN
CVS Tags: pkgsrc-2020Q3-base, pkgsrc-2020Q3, pkgsrc-2020Q2-base, pkgsrc-2020Q2, pkgsrc-2020Q1-base, pkgsrc-2020Q1, pkgsrc-2019Q4-base, pkgsrc-2019Q4, pkgsrc-2019Q3-base, pkgsrc-2019Q3, pkgsrc-2019Q2-base, pkgsrc-2019Q2, pkgsrc-2019Q1-base, pkgsrc-2019Q1, pkgsrc-2018Q4-base, pkgsrc-2018Q4, pkgsrc-2018Q3-base, pkgsrc-2018Q3, pkgsrc-2018Q2-base, pkgsrc-2018Q2, pkgsrc-2018Q1-base, pkgsrc-2018Q1, pkgsrc-2017Q4-base, pkgsrc-2017Q4, pkgsrc-2017Q3-base, pkgsrc-2017Q3, pkgsrc-2017Q2-base, pkgsrc-2017Q2, pkgsrc-2017Q1-base, pkgsrc-2017Q1, pkgsrc-2016Q4-base, pkgsrc-2016Q4, pkgsrc-2016Q3-base, pkgsrc-2016Q3, pkgsrc-2016Q2-base, pkgsrc-2016Q2, pkgsrc-2016Q1-base, pkgsrc-2016Q1

Import magrittr-1.5 as devel/R-magrittr.

Provides a mechanism for chaining commands with a new forward-pipe
operator, %>%. This operator will forward a value, or the result of
an expression, into the next function call/expression.

This form allows you to request diff's between any two revisions of a file. You may select a symbolic revision name using the selection box or you may type in a numeric name using the type-in text box.

CVSweb <>