Displaying 7 results from an estimated 7 matches for "debuggiing".
Did you mean:
debugging
2019 Oct 05
5
should base R have a piping operator ?
Yes but this exageration precisely misses the point.
Concerning your examples:
* I love fread but I think it makes a lot of subjective choices that are
best associated with a package. I think it
changed a lot with time and can still change, and we have great developers
willing to maintain it and be reactive
regarding feature requests or bug reports
*.group_by() adds a class that works only (or
2019 Oct 06
1
should base R have a piping operator ?
...t; 5)
>
>
> were *parsed* as, for example, into
>
> local({
> . = group_by(iris, Species)
>
> ._tmp2 = summarize(., mean_sl = mean(Sepal.Length))
>
> filter(., mean_sl > 5)
> })
>
>
>
>
> Then debuggiing (once you knew that) would be much easier but behavaior
> would be the same as it is now. There could even be some sort of
> step-through-pipe debugger at that point added as well for additional
> convenience.
>
> There is some minor precedent for that type of transformative parsing...
2019 Oct 07
4
should base R have a piping operator ?
...an_sl > 5)
>
>
> were *parsed* as, for example, into
>
> local({
> . = group_by(iris, Species)
>
> ._tmp2 = summarize(., mean_sl = mean(Sepal.Length))
>
> filter(., mean_sl > 5)
> })
>
>
>
>
> Then debuggiing (once you knew that) would be much easier but behavaior
> would be the same as it is now. There could even be some sort of
> step-through-pipe debugger at that point added as well for additional
> convenience.
>
> There is some minor precedent for that type of transformative parsing...
2019 Oct 05
0
should base R have a piping operator ?
..._by(Species) %>% summarize(mean_sl = mean(Sepal.Length)) %>%
filter(mean_sl > 5)
were *parsed* as, for example, into
local({
. = group_by(iris, Species)
._tmp2 = summarize(., mean_sl = mean(Sepal.Length))
filter(., mean_sl > 5)
})
Then debuggiing (once you knew that) would be much easier but behavaior
would be the same as it is now. There could even be some sort of
step-through-pipe debugger at that point added as well for additional
convenience.
There is some minor precedent for that type of transformative parsing:
> expr = parse(text...
2019 Oct 07
0
should base R have a piping operator ?
...for example, into
>>
>> local({
>> . = group_by(iris, Species)
>>
>> ._tmp2 = summarize(., mean_sl = mean(Sepal.Length))
>>
>> filter(., mean_sl > 5)
>> })
>>
>>
>>
>>
>> Then debuggiing (once you knew that) would be much easier but behavaior
>> would be the same as it is now. There could even be some sort of
>> step-through-pipe debugger at that point added as well for additional
>> convenience.
>>
>> There is some minor precedent for that type of tra...
2019 Oct 06
1
should base R have a piping operator ?
...er(mean_sl > 5)
>
>
> were *parsed* as, for example, into
>
> local({
> . = group_by(iris, Species)
>
> ._tmp2 = summarize(., mean_sl = mean(Sepal.Length))
>
> filter(., mean_sl > 5)
> })
>
>
>
>
> Then debuggiing (once you knew that) would be much easier but behavaior
> would be the same as it is now. There could even be some sort of
> step-through-pipe debugger at that point added as well for additional
> convenience.
>
> There is some minor precedent for that type of transformative parsing:...
2019 Oct 07
0
[External] Re: should base R have a piping operator ?
...as, for example, into
>>
>> local({
>> . = group_by(iris, Species)
>>
>> ._tmp2 = summarize(., mean_sl = mean(Sepal.Length))
>>
>> filter(., mean_sl > 5)
>> })
>>
>>
>>
>>
>> Then debuggiing (once you knew that) would be much easier but behavaior
>> would be the same as it is now. There could even be some sort of
>> step-through-pipe debugger at that point added as well for additional
>> convenience.
>>
>> There is some minor precedent for that type of tra...