Re: [Bioc-devel] Resetting to previous commits

[Pages, Herve]

On 8/14/19 10:19, Kasper Daniel Hansen wrote:
...
> 
> Pro-tip: In general, you will be well served not to get too attached to
> version numbers. Bump it frequently even without new functionality or bug
> fixes and just live with the frequent bumping.

+1 for Best Advice Of The Week.


-- 
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: hpa...@fredhutch.org
Phone:  (206) 667-5791
Fax:(206) 667-1319
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Resetting to previous commits

[Kasper Daniel Hansen]

Yes, it will build the most recent version

If the previous build failed it will even build the most recent code, even
if the code is not bumped. The exception is the following
  you update package A to version X, build succeeds
  you commit code to package A, but does not bump the version
This will not trigger.a rebuild and your latest commits will not be
reflected in the tarballs available to the community. This is why you -- in
general -- need to bump versions when you commit code.

Pro-tip: In general, you will be well served not to get too attached to
version numbers. Bump it frequently even without new functionality or bug
fixes and just live with the frequent bumping.

On Wed, Aug 14, 2019 at 12:43 PM Mike Smith  wrote:

> Yes, the Bioconductor build system will only try to build the most recent
> version in the git repository.  If it never managed to successfully build a
> particular version then that version should not appear anywhere on the Bioc
> site.  For example biomaRt is now on release 2.40.3, but version 2.40.2
> never passed all the checks, and so is absent from the archive at
> https://bioconductor.org/packages/3.9/bioc/src/contrib/Archive/biomaRt/
> In
> theory someone could get hold of it via git, anyone doing so it probably
> experienced enough to look after themselves.
>
> Best,
> Mike
>
> On Wed, 14 Aug 2019 at 18:12, Erik Fasterius 
> wrote:
>
> > Thank you for the prompt response! I will just add more versions on top
> of
> > what I have already added. Would it be correct to assume that
> Bioconductor
> > will try to build the most recent version available, even though it
> failed
> > builds for previous versions?
> >
> > Regarding the change, it was indeed a breaking change, and I thus
> believed
> > that it would have been counted as a bug-fix for the release branch.
> >
> > All the best,
> > Erik
> >
> > On 14 Aug 2019, at 17:15, Kasper Daniel Hansen <
> > kasperdanielhan...@gmail.com>
> wrote:
> >
> > Also, it is not clear to me if this qualifies for a update to the release
> > branch. Updates to release should be restricted to critical bug fixes
> > (although if tidyr updates will break your package, that sounds like a
> > critical bug fix to me)
> >
> > Note to others: this (again) emphasizes that we may need to "copy" a
> > snapshot of CRAN into release.
> >
> > Best,
> > Kasper
> >
> > On Wed, Aug 14, 2019 at 11:13 AM Kasper Daniel Hansen <
> > kasperdanielhan...@gmail.com>
> wrote:
> > You cannot revert. By pushing those updates, you released a version into
> > the wild. It is true that as long as it doesn't build on the build
> servers,
> > it would have been hard to obtain for anyone, but it is still possible
> > through git. You need to update the version.
> >
> > Best,
> > Kasper
> >
> > On Wed, Aug 14, 2019 at 11:05 AM Erik Fasterius <
> > erik.faster...@outlook.com> wrote:
> > I made some changes to my seqCAT package the last few days in order to
> > prepare for version 1.0.0 of tidyr, which was apparently harder than I
> > initially thought. I was also a bit too quick with pushing to
> Bioconductor
> > (both the release and devel branches), and now I’ve got several updates
> and
> > versions that don’t work - very stupid of me, I know. I do seem to have a
> > working version now, though, and I finally learnt my lesson and have NOT
> > pushed this to Bioconductor yet. Now I want to reset to the previously
> > working versions of my package (1.6.0 for release and 1.7.2 for devel)
> >
> > I did try to make (temporary) hard resets and force push these to
> > Bioconductor (as per the “reset to a previous commit” in the “abandon
> > changes” developer section), but these did not work: all I got was errors
> > say I cannot move from a higher version (e.g. 1.6.2) back to a lower one
> > (1.6.0). Is there a way to bypass this? If not, I assume I’ll just have
> to
> > make a new version for each branch (1.6.3 and 1.7.5, as it were) and push
> > those, leaving several non-functional versions at Bioconductor? If at all
> > possible I’d like to avoid this.
> >
> > Again, I realise these problems are because of errors on my part, and
> > would like to know if I can solve them somehow or if I’ll just have to
> live
> > with them.
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >
> >
> > --
> > Best,
> > Kasper
> >
> >
> > --
> > Best,
> > Kasper
> >
> >
> > [[alternative HTML version deleted]]
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> 

Re: [Bioc-devel] Resetting to previous commits

[Mike Smith]

Yes, the Bioconductor build system will only try to build the most recent
version in the git repository.  If it never managed to successfully build a
particular version then that version should not appear anywhere on the Bioc
site.  For example biomaRt is now on release 2.40.3, but version 2.40.2
never passed all the checks, and so is absent from the archive at
https://bioconductor.org/packages/3.9/bioc/src/contrib/Archive/biomaRt/  In
theory someone could get hold of it via git, anyone doing so it probably
experienced enough to look after themselves.

Best,
Mike

On Wed, 14 Aug 2019 at 18:12, Erik Fasterius 
wrote:

> Thank you for the prompt response! I will just add more versions on top of
> what I have already added. Would it be correct to assume that Bioconductor
> will try to build the most recent version available, even though it failed
> builds for previous versions?
>
> Regarding the change, it was indeed a breaking change, and I thus believed
> that it would have been counted as a bug-fix for the release branch.
>
> All the best,
> Erik
>
> On 14 Aug 2019, at 17:15, Kasper Daniel Hansen <
> kasperdanielhan...@gmail.com> wrote:
>
> Also, it is not clear to me if this qualifies for a update to the release
> branch. Updates to release should be restricted to critical bug fixes
> (although if tidyr updates will break your package, that sounds like a
> critical bug fix to me)
>
> Note to others: this (again) emphasizes that we may need to "copy" a
> snapshot of CRAN into release.
>
> Best,
> Kasper
>
> On Wed, Aug 14, 2019 at 11:13 AM Kasper Daniel Hansen <
> kasperdanielhan...@gmail.com> wrote:
> You cannot revert. By pushing those updates, you released a version into
> the wild. It is true that as long as it doesn't build on the build servers,
> it would have been hard to obtain for anyone, but it is still possible
> through git. You need to update the version.
>
> Best,
> Kasper
>
> On Wed, Aug 14, 2019 at 11:05 AM Erik Fasterius <
> erik.faster...@outlook.com> wrote:
> I made some changes to my seqCAT package the last few days in order to
> prepare for version 1.0.0 of tidyr, which was apparently harder than I
> initially thought. I was also a bit too quick with pushing to Bioconductor
> (both the release and devel branches), and now I’ve got several updates and
> versions that don’t work - very stupid of me, I know. I do seem to have a
> working version now, though, and I finally learnt my lesson and have NOT
> pushed this to Bioconductor yet. Now I want to reset to the previously
> working versions of my package (1.6.0 for release and 1.7.2 for devel)
>
> I did try to make (temporary) hard resets and force push these to
> Bioconductor (as per the “reset to a previous commit” in the “abandon
> changes” developer section), but these did not work: all I got was errors
> say I cannot move from a higher version (e.g. 1.6.2) back to a lower one
> (1.6.0). Is there a way to bypass this? If not, I assume I’ll just have to
> make a new version for each branch (1.6.3 and 1.7.5, as it were) and push
> those, leaving several non-functional versions at Bioconductor? If at all
> possible I’d like to avoid this.
>
> Again, I realise these problems are because of errors on my part, and
> would like to know if I can solve them somehow or if I’ll just have to live
> with them.
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
>
> --
> Best,
> Kasper
>
>
> --
> Best,
> Kasper
>
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Resetting to previous commits

[Erik Fasterius]

Thank you for the prompt response! I will just add more versions on top of what 
I have already added. Would it be correct to assume that Bioconductor will try 
to build the most recent version available, even though it failed builds for 
previous versions?

Regarding the change, it was indeed a breaking change, and I thus believed that 
it would have been counted as a bug-fix for the release branch.

All the best,
Erik

On 14 Aug 2019, at 17:15, Kasper Daniel Hansen 
mailto:kasperdanielhan...@gmail.com>> wrote:

Also, it is not clear to me if this qualifies for a update to the release 
branch. Updates to release should be restricted to critical bug fixes (although 
if tidyr updates will break your package, that sounds like a critical bug fix 
to me)

Note to others: this (again) emphasizes that we may need to "copy" a snapshot 
of CRAN into release.

Best,
Kasper

On Wed, Aug 14, 2019 at 11:13 AM Kasper Daniel Hansen 
mailto:kasperdanielhan...@gmail.com>> wrote:
You cannot revert. By pushing those updates, you released a version into the 
wild. It is true that as long as it doesn't build on the build servers, it 
would have been hard to obtain for anyone, but it is still possible through 
git. You need to update the version.

Best,
Kasper

On Wed, Aug 14, 2019 at 11:05 AM Erik Fasterius 
mailto:erik.faster...@outlook.com>> wrote:
I made some changes to my seqCAT package the last few days in order to prepare 
for version 1.0.0 of tidyr, which was apparently harder than I initially 
thought. I was also a bit too quick with pushing to Bioconductor (both the 
release and devel branches), and now I’ve got several updates and versions that 
don’t work - very stupid of me, I know. I do seem to have a working version 
now, though, and I finally learnt my lesson and have NOT pushed this to 
Bioconductor yet. Now I want to reset to the previously working versions of my 
package (1.6.0 for release and 1.7.2 for devel)

I did try to make (temporary) hard resets and force push these to Bioconductor 
(as per the “reset to a previous commit” in the “abandon changes” developer 
section), but these did not work: all I got was errors say I cannot move from a 
higher version (e.g. 1.6.2) back to a lower one (1.6.0). Is there a way to 
bypass this? If not, I assume I’ll just have to make a new version for each 
branch (1.6.3 and 1.7.5, as it were) and push those, leaving several 
non-functional versions at Bioconductor? If at all possible I’d like to avoid 
this.

Again, I realise these problems are because of errors on my part, and would 
like to know if I can solve them somehow or if I’ll just have to live with them.
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


--
Best,
Kasper


--
Best,
Kasper


[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Canceled event: Biocondutor Developers Forum @ Thu Aug 15, 2019 12pm - 1pm (EDT) (bioc-devel@r-project.org)

[Sean Davis]

Sorry about any confusion I created. The forum is still on as far as I
know.

Sean


On Wed, Aug 14, 2019 at 11:21 AM Leonardo Collado Torres <
lcollado...@gmail.com> wrote:

> Hi everyone,
>
> I think this caused a bit of confusion. My understanding was that Sean
> created a google calendar event and cc'ed the bioc-dev mailing list.
> In any case, from what I can see at the BioC slack in the #general
> channel, the forum is still scheduled for tomorrow Thursday August
> 15th.
>
>
> Aaron Lun 1:38 AM
> So. Uh. This dev forum thing. Is it still on, or what?
> Today at 8:21 AM
> Martin Morgan 6:17 AM
> yep, Thursday 12 noon Eastern details at
> https://stat.ethz.ch/pipermail/bioc-devel/2019-August/015359.html
> there's also a #developers-forum
>
> Best,
> Leo
>
> On Thu, Aug 8, 2019 at 9:50 AM  wrote:
> >
> > This event has been canceled.
> >
> > Title: [Bioc-devel] Biocondutor Developers Forum
> > Dear all,
> >
> > I am excited to announce a new initiative within the Bioconductor
> project -
> > the Bioconductor Developers' Forum.  This monthly teleconference is
> > intended as a platform for Bioconductor developers to describe existing
> > software infrastructure to other members of the BioC community, to
> present
> > plans for future developments, and discuss changes that may impact other
> > developers or software tools within the Bioconductor.
> >
> > The intended audience is anyone interested in software development and
> > infrastructure, whether you're a member of the BioC core team with
> > responsibility for multiple packages, or you're just getting started with
> > creating a Bioconductor package.
> >
> > Our first meeting will take place on Thursday 15th August at 09:00 PDT/
> > 12:00 EDT / 18:00 CEST using BlueJeans and can be joined via:
> >
> > https://bluejeans.com/136043474?src=join_info (Meeting ID: 136 043 474)
> >
> > More details on the...
> > When: Thu Aug 15, 2019 12pm – 1pm Eastern Time - New York
> > Calendar: bioc-devel@r-project.org
> > Who:
> >  * seand...@gmail.com - organizer
> >  * peter.hic...@gmail.com
> >  * grimbo...@gmail.com
> >  * bioc-devel@r-project.org
> >
> >
> > Invitation from Google Calendar: https://www.google.com/calendar/
> >
> > You are receiving this courtesy email at the account
> > bioc-devel@r-project.org because you are an attendee of this event.
> >
> > To stop receiving future updates for this event, decline this event.
> > Alternatively you can sign up for a Google account at
> > https://www.google.com/calendar/ and control your notification settings
> for
> > your entire calendar.
> >
> > Forwarding this invitation could allow any recipient to send a response
> to
> > the organizer and be added to the guest list, or invite others regardless
> > of their own invitation status, or to modify your RSVP. Learn more at
> > https://support.google.com/calendar/answer/37135#forwarding
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>


-- 
Sean Davis, MD, PhD
Center for Cancer Research
National Cancer Institute
National Institutes of Health
Bethesda, MD 20892
https://seandavi.github.io/
https://twitter.com/seandavis12

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Canceled event: Biocondutor Developers Forum @ Thu Aug 15, 2019 12pm - 1pm (EDT) (bioc-devel@r-project.org)

[Leonardo Collado Torres]

Hi everyone,

I think this caused a bit of confusion. My understanding was that Sean
created a google calendar event and cc'ed the bioc-dev mailing list.
In any case, from what I can see at the BioC slack in the #general
channel, the forum is still scheduled for tomorrow Thursday August
15th.


Aaron Lun 1:38 AM
So. Uh. This dev forum thing. Is it still on, or what?
Today at 8:21 AM
Martin Morgan 6:17 AM
yep, Thursday 12 noon Eastern details at
https://stat.ethz.ch/pipermail/bioc-devel/2019-August/015359.html
there's also a #developers-forum

Best,
Leo

On Thu, Aug 8, 2019 at 9:50 AM  wrote:
>
> This event has been canceled.
>
> Title: [Bioc-devel] Biocondutor Developers Forum
> Dear all,
>
> I am excited to announce a new initiative within the Bioconductor project -
> the Bioconductor Developers' Forum.  This monthly teleconference is
> intended as a platform for Bioconductor developers to describe existing
> software infrastructure to other members of the BioC community, to present
> plans for future developments, and discuss changes that may impact other
> developers or software tools within the Bioconductor.
>
> The intended audience is anyone interested in software development and
> infrastructure, whether you're a member of the BioC core team with
> responsibility for multiple packages, or you're just getting started with
> creating a Bioconductor package.
>
> Our first meeting will take place on Thursday 15th August at 09:00 PDT/
> 12:00 EDT / 18:00 CEST using BlueJeans and can be joined via:
>
> https://bluejeans.com/136043474?src=join_info (Meeting ID: 136 043 474)
>
> More details on the...
> When: Thu Aug 15, 2019 12pm – 1pm Eastern Time - New York
> Calendar: bioc-devel@r-project.org
> Who:
>  * seand...@gmail.com - organizer
>  * peter.hic...@gmail.com
>  * grimbo...@gmail.com
>  * bioc-devel@r-project.org
>
>
> Invitation from Google Calendar: https://www.google.com/calendar/
>
> You are receiving this courtesy email at the account
> bioc-devel@r-project.org because you are an attendee of this event.
>
> To stop receiving future updates for this event, decline this event.
> Alternatively you can sign up for a Google account at
> https://www.google.com/calendar/ and control your notification settings for
> your entire calendar.
>
> Forwarding this invitation could allow any recipient to send a response to
> the organizer and be added to the guest list, or invite others regardless
> of their own invitation status, or to modify your RSVP. Learn more at
> https://support.google.com/calendar/answer/37135#forwarding
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Resetting to previous commits

[Kasper Daniel Hansen]

You cannot revert. By pushing those updates, you released a version into
the wild. It is true that as long as it doesn't build on the build servers,
it would have been hard to obtain for anyone, but it is still possible
through git. You need to update the version.

Best,
Kasper

On Wed, Aug 14, 2019 at 11:05 AM Erik Fasterius 
wrote:

> I made some changes to my seqCAT package the last few days in order to
> prepare for version 1.0.0 of tidyr, which was apparently harder than I
> initially thought. I was also a bit too quick with pushing to Bioconductor
> (both the release and devel branches), and now I’ve got several updates and
> versions that don’t work - very stupid of me, I know. I do seem to have a
> working version now, though, and I finally learnt my lesson and have NOT
> pushed this to Bioconductor yet. Now I want to reset to the previously
> working versions of my package (1.6.0 for release and 1.7.2 for devel)
>
> I did try to make (temporary) hard resets and force push these to
> Bioconductor (as per the “reset to a previous commit” in the “abandon
> changes” developer section), but these did not work: all I got was errors
> say I cannot move from a higher version (e.g. 1.6.2) back to a lower one
> (1.6.0). Is there a way to bypass this? If not, I assume I’ll just have to
> make a new version for each branch (1.6.3 and 1.7.5, as it were) and push
> those, leaving several non-functional versions at Bioconductor? If at all
> possible I’d like to avoid this.
>
> Again, I realise these problems are because of errors on my part, and
> would like to know if I can solve them somehow or if I’ll just have to live
> with them.
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>


-- 
Best,
Kasper

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Resetting to previous commits

[Kasper Daniel Hansen]

Also, it is not clear to me if this qualifies for a update to the release
branch. Updates to release should be restricted to critical bug fixes
(although if tidyr updates will break your package, that sounds like a
critical bug fix to me)

Note to others: this (again) emphasizes that we may need to "copy" a
snapshot of CRAN into release.

Best,
Kasper

On Wed, Aug 14, 2019 at 11:13 AM Kasper Daniel Hansen <
kasperdanielhan...@gmail.com> wrote:

> You cannot revert. By pushing those updates, you released a version into
> the wild. It is true that as long as it doesn't build on the build servers,
> it would have been hard to obtain for anyone, but it is still possible
> through git. You need to update the version.
>
> Best,
> Kasper
>
> On Wed, Aug 14, 2019 at 11:05 AM Erik Fasterius <
> erik.faster...@outlook.com> wrote:
>
>> I made some changes to my seqCAT package the last few days in order to
>> prepare for version 1.0.0 of tidyr, which was apparently harder than I
>> initially thought. I was also a bit too quick with pushing to Bioconductor
>> (both the release and devel branches), and now I’ve got several updates and
>> versions that don’t work - very stupid of me, I know. I do seem to have a
>> working version now, though, and I finally learnt my lesson and have NOT
>> pushed this to Bioconductor yet. Now I want to reset to the previously
>> working versions of my package (1.6.0 for release and 1.7.2 for devel)
>>
>> I did try to make (temporary) hard resets and force push these to
>> Bioconductor (as per the “reset to a previous commit” in the “abandon
>> changes” developer section), but these did not work: all I got was errors
>> say I cannot move from a higher version (e.g. 1.6.2) back to a lower one
>> (1.6.0). Is there a way to bypass this? If not, I assume I’ll just have to
>> make a new version for each branch (1.6.3 and 1.7.5, as it were) and push
>> those, leaving several non-functional versions at Bioconductor? If at all
>> possible I’d like to avoid this.
>>
>> Again, I realise these problems are because of errors on my part, and
>> would like to know if I can solve them somehow or if I’ll just have to live
>> with them.
>> ___
>> Bioc-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>
>
> --
> Best,
> Kasper
>


-- 
Best,
Kasper

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] Resetting to previous commits

[Erik Fasterius]

I made some changes to my seqCAT package the last few days in order to prepare 
for version 1.0.0 of tidyr, which was apparently harder than I initially 
thought. I was also a bit too quick with pushing to Bioconductor (both the 
release and devel branches), and now I’ve got several updates and versions that 
don’t work - very stupid of me, I know. I do seem to have a working version 
now, though, and I finally learnt my lesson and have NOT pushed this to 
Bioconductor yet. Now I want to reset to the previously working versions of my 
package (1.6.0 for release and 1.7.2 for devel)

I did try to make (temporary) hard resets and force push these to Bioconductor 
(as per the “reset to a previous commit” in the “abandon changes” developer 
section), but these did not work: all I got was errors say I cannot move from a 
higher version (e.g. 1.6.2) back to a lower one (1.6.0). Is there a way to 
bypass this? If not, I assume I’ll just have to make a new version for each 
branch (1.6.3 and 1.7.5, as it were) and push those, leaving several 
non-functional versions at Bioconductor? If at all possible I’d like to avoid 
this.

Again, I realise these problems are because of errors on my part, and would 
like to know if I can solve them somehow or if I’ll just have to live with them.
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] Underscores in package names

[Martin Maechler]

> Duncan Murdoch 
> on Fri, 9 Aug 2019 20:23:28 -0400 writes:

> On 09/08/2019 4:37 p.m., Gabriel Becker wrote:
>> Duncan,
>> 
>> 
>> On Fri, Aug 9, 2019 at 1:17 PM Duncan Murdoch > > wrote:
>> 
>> On 09/08/2019 2:41 p.m., Gabriel Becker wrote:
>> > Note that this proposal would make mypackage_2.3.1 a valid
>> *package name*,
>> > whose corresponding tarball name might be mypackage_2.3.1_2.3.2
>> after a
>> > patch. Yes its a silly example, but why allow that kind of ambiguity?
>> >
>> CRAN already has a package named "FuzzyNumbers.Ext.2", whose tarball is
>> FuzzyNumbers.Ext.2_3.2.tar.gz, so I think we've already lost that game.
>> 
>> 
>> I suppose technically 2 is a valid version number for a package (?) so I 
>> suppose you have me there. But as Ben pointed out while I was writing 
>> this, all I can really say is that in practice they read to me (as 
>> someone who has administered R on a large cluster and written 
>> build-system software for it) as substantially different levels of 
>> ambiguity. I do acknowledge, as Ben does, that yes a more complex 
>> regular expression/splitting algorithm can be written that would handle 
>> the more general package names. I just don't personally see a motivation 
>> that justifies changing something this fundamental (even if it is both 
>> narrow and was initially more or less arbitrarily chosen) about R at 
>> this late date.
>> 
>> I guess at the end of the day, I guess what I'm saying is that breaking 
>> and changing things is sometimes good, but if we're going to rock the 
>> boat personally I'd want to do so going after bigger wins than this one. 
>> Thats just my opinion though.

> Sorry, I wasn't clear.  I agree with you.  I was just saying that the 
> particular argument based on ugly tarball names isn't the reason.

> Duncan Murdoch

Thank you (and Gabe).

We have had some R core internal "talk" about Jim Hester's
suggestion (of adding underscores to the allow characters in
package names).
Duncan had already given a good reason why such a change would be problematic
(the underscore being used as unique separator of package name
 and version in source and binary package archives),
and with Jim's offer to find and provide patches for all places
this is used in the R sources, we've convinced ourselves that
there is much more code "out there", notably 'devops' code in
scripts, which currently relies on the current package naming
rules and which could break, often only rarely and hence
possibly unnoticed for too long.

Also, we've not seen compelling arguments why the current scheme
would be too limited (people mentioned that if you must use a
separator, "." was available).

Consequence:  We stay with the stability principle and the
package naming scheme is _not_ going to be changed for now.

Martin Maechler
ETH Zurich and R Core Team

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] behaviour and documentation of qr.solve

[Michael Meyer via R-devel]

Greetings,

In my opinion the documentation or behaviour of qr.solve, qr.coef, qr.resid, 
and qr.fitted is not easily comprehensible and unfortunate.
We all know that a linear system Ax=b can have 0, one or infinitely many 
solutions. To treat all these cases uniformly we can rephrase the problem
as 
x = argmin_u||Au-b||,   


where ||.|| denotes the Euclidean norm. There is then exactly one natural and 
distinguished solution x, the minimizer x which is itself of minimal
Euclidean Norm. So if we want to return only one solution, I think we can agree 
that this should be it.

In fact this very solution can be computed from the QR-decomposition of either 
A (overdetermined system) or t(A) (underdetermined system).
I tried qr.solve on the underdetermined system Ax=b with  

b <- c(3,5,7)   
and
A <- rbind(
c(1,1,1,1,1),
c(1,2,2,2,2),
c(1,2,3,3,3)
)
The system has infinitely many solutions. The minimal norm solution is 
x=c(1,0,2/3,2/3,2/3).
But qr.solve(A,b) yielded the solution x=(1,0,2,0,0) which is destinguished 
only by being sparse and I do not think qr.solve
tries to compute the sparsest solution. So what does qr.solve do in case of an 
underdetermined system? 
It is not documented.

Then I tried to figure out what qr.coef, qr.resid, and qr.fitted do. I had to 
do actual experiments to figure out that it seems to solve the
problem x=argmin_u||Au-y|| with
   qr.coef(A,y) = x but which x 
when there are infinitely many?
   qr.fitted(A,y) = Ax
   qr.resid(A,y) = y-Ax 
but this is certainly not evident from the language in the documentation which 
conflates qr(x,...) with solving the system Ax=b then states:

"The functions qr.coef, qr.resid, and qr.fitted return the coefficients, 
residuals and fitted values obtained 
  when fitting y to the matrix with QR decomposition qr."

Since when do we call solving a system of equations "fitting the right hand 
side to the matrix ..." or call the solution x "the coefficients"
(which more usually are the elements of A) or introduce the "fitted values" 
with no definition?
Moreover the language does not fit the underdetermined case Ax=y, where we need 
the QR-decomposition of t(A) and not of A  to compute the
minimizer x = argmin_u||Au-y|| which is itself of minimal norm.

Or, maybe this is not at all what these functions are doing.
But then, what is it and should this not be evident from the documentation?

Sincerely,

Michael Meyer

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [R-pkg-devel] Error ... could not find function ...

[Dirk Eddelbuettel]

On 14 August 2019 at 17:44, Rolf Turner wrote:
| > Error in cpp_object_initializer(.self, .refClassDef, ...) : 
| >   could not find function "cpp_object_initializer"

This can happen when a package using Rcpp Modules is not fully loaded. While
I am not familiar with eiher package here, try `import(brms)` and / or
`importFrom(...)` for a particular routine.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel