Opened 5 years ago

Closed 5 years ago

Last modified 3 years ago

#16711 closed enhancement (fixed)

Upgrade R to version 3.1.1

Reported by: charpent Owned by:
Priority: minor Milestone: sage-6.3
Component: packages: standard Keywords: r-project
Cc: Merged in:
Authors: Emmanuel Charpentier, Nathann Cohen Reviewers: Nathann Cohen
Report Upstream: N/A Work issues:
Branch: 752190c (Commits) Commit:
Dependencies: Stopgaps:

Description (last modified by vbraun)

Same reasons as usual.

Link to renamed upstream source :

http://boxen.math.washington.edu/home/vbraun/upstream/r-3.1.1.tar.gz

Change History (12)

comment:1 Changed 5 years ago by charpent

  • Branch set to u/charpent/upgrade_r_to_version_3_1_1

comment:2 Changed 5 years ago by charpent

  • Commit set to 9259e536e801aaa3544aa1466e624ce3aa327f34
  • Status changed from new to needs_review

Candidate for review. Uneventful drop-in.


New commits:

9259e53New R version, uneventful drop-in, passes ptestlong.

comment:3 follow-up: Changed 5 years ago by ncohen

  • Reviewers set to Nathann Cohen

Hellooooooooooo !

I added a commit to your branch on public/16711. It adds a couple of line to spkg-src so that it is (even) easier to update this spkg. If you agree with it you can set this ticket to positive_review :-)

Nathann

comment:4 in reply to: ↑ 3 ; follow-up: Changed 5 years ago by charpent

  • Authors changed from Emmanuel Chatpentier to Emmanuel Charpentier, Nathan Cohen

Replying to ncohen:

Dear Nathann,

Hellooooooooooo !

I added a commit to your branch on public/16711. It adds a couple of line to spkg-src so that it is (even) easier to update this spkg. If you agree with it

I can't : this has deep interferences with the Sage build system, which I do not undetstand yet. See Trac#16629 for a related problem : the length of exchanges with Volker Braun (who does understand the build system) proves that I do not understand the problem (except possibly on a set of null measure...:-).

Furthermore, this fixes a problem different of the original one. This kind of ticket hijacking is likely to delay the solution of both hijacker and hijacked issues. Would you cate to take a look at #16629 and give us ypur advice ? BTW, this ticket still awaits review...

you can set this ticket to positive_review :-)

I can't either : I am the author, and the whole point of a systematic peer review is to avoid too-hasty incorporation of incomplete/foolhardy/misguided patches. Saved my ass a couple of times already...

On the other hand, you can give it positive review if you think that the branch fixes the specific problem the ticket was aimed at ;-) Ditto for #16629, BTW...

HTH,

Emmanuel Charpentier

Last edited 5 years ago by charpent (previous) (diff)

comment:5 in reply to: ↑ 4 ; follow-up: Changed 5 years ago by ncohen

Helloooooooooo !!

I can't : this has deep interferences with the Sage build system, which I do not undetstand yet.

Nonono it does not. Those spkg-src script are not used automatically in any way, they are just there to help us update packages. I also used it to do a "proper reviewing job", because I can't just accept a binary files of 20mb+ trusting that you just copied the original files. Technically you could have modified anything in there without me noticing, and the code will run on everybody's machine.

So I checked that I could produce the spkg myself and that the hash were the same. I did so with the lines I added to the file.

Furthermore, this fixes a problem different of the original one. This kind of ticket hijacking is likely to delay the solution of both hijacker and hijacked issues.

O_o

Hey, the commit only adds 3 lines to a file to make what you just did easier, and your ticket has been created 21 hours ago. There is no hijacking going on, and 21 hours is not what can be called a "long delay" either.

Would you cate to take a look at #16629 and give us ypur advice ? BTW, this ticket still awaits review...

I don't understand much about the management of spkg in Sage. And I had to query a dictionary for the definition of "munch".

I can't either : I am the author, and the whole point of a systematic peer review is to avoid too-hasty incorporation of incomplete/foolhardy/misguided patches. Saved my ass a couple of times already...

It is my commit. I wrote the code and your review it. And I review your code. If you can review a 3-lines commit on another ticket it can probably be done here too. Sage's rules are not sacred, they are here to avoid mistake. The point of reviewing each other's code definitely makes sense, so if every code is reviewed by somebody who is not the author there is no problem.

I can swear that I saw it happen quite a lot of times already. Some patches even have the same two names in the "reviewer" and the "authors" field. Everybody checks the other's code, that's all.

On the other hand, you can give it positive review if you think that the branch fixes the specific problem the ticket was aimed at ;-) Ditto for #16629, BTW...

I did my review, and my review included a commit. If you don't agree with it for religious reasons another reviewer will come.

Nathann

comment:6 Changed 5 years ago by git

  • Commit changed from 9259e536e801aaa3544aa1466e624ce3aa327f34 to 752190c8b5dcd7964ddbae59a4f7899100d787be

Branch pushed to git repo; I updated commit sha1. New commits:

752190ctrac #16711: Automatically download the tarball and fix checksums

comment:7 in reply to: ↑ 5 ; follow-up: Changed 5 years ago by charpent

  • Status changed from needs_review to positive_review

Replying to ncohen:

Helloooooooooo !!

I can't : this has deep interferences with the Sage build system, which I do not undetstand yet.

Nonono it does not. Those spkg-src script are not used automatically in any way, they are just there to help us update packages. I also used it to do a "proper reviewing job", because I can't just accept a binary files of 20mb+ trusting that you just copied the original files. Technically you could have modified anything in there without me noticing, and the code will run on everybody's machine.

After re-reading the docs, I agree with you. I forgot this one (thus demonstrating the interest of cross-review...:-).

So I checked that I could produce the spkg myself and that the hash were the same. I did so with the lines I added to the file.

Furthermore, this fixes a problem different of the original one. This kind of ticket hijacking is likely to delay the solution of both hijacker and hijacked issues.

O_o

Hey, the commit only adds 3 lines to a file to make what you just did easier, and your ticket has been created 21 hours ago. There is no hijacking going on, and 21 hours is not what can be called a "long delay" either.

Hmmm... My previous drop-in of R 3.0 was delayed for months by an attempt to make it compile on Cygwin without a previously known bug...

Would you cate to take a look at #16629 and give us ypur advice ? BTW, this ticket still awaits review...

I don't understand much about the management of spkg in Sage. And I had to query a dictionary for the definition of "munch".

I can't either : I am the author, and the whole point of a systematic peer review is to avoid too-hasty incorporation of incomplete/foolhardy/misguided patches. Saved my ass a couple of times already...

It is my commit. I wrote the code and your review it. And I review your code. If you can review a 3-lines commit on another ticket it can probably be done here too. Sage's rules are not sacred, they are here to avoid mistake. The point of reviewing each other's code definitely makes sense, so if every code is reviewed by somebody who is not the author there is no problem.

I can swear that I saw it happen quite a lot of times already. Some patches even have the same two names in the "reviewer" and the "authors" field. Everybody checks the other's code, that's all.

I didn't know that.

On the other hand, you can give it positive review if you think that the branch fixes the specific problem the ticket was aimed at ;-) Ditto for #16629, BTW...

I did my review, and my review included a commit. If you don't agree with it for religious reasons another reviewer will come.

No religious feelings here. You convinced me.

Nathann

comment:8 follow-up: Changed 5 years ago by vbraun

  • Description modified (diff)

Wget-able URLs please...

comment:9 in reply to: ↑ 7 Changed 5 years ago by ncohen

Yoooooooooooooooo !!!!

Hmmm... My previous drop-in of R 3.0 was delayed for months by an attempt to make it compile on Cygwin without a previously known bug...

Hmmmmm... Sorry for that :-/

My worst memory is "This code does not work on OpenSolaris 64bits". It was unpleasant too :-P

Thank you for this update ! :-)

Nathann

Last edited 5 years ago by ncohen (previous) (diff)

comment:10 Changed 5 years ago by vbraun

  • Branch changed from u/charpent/upgrade_r_to_version_3_1_1 to 752190c8b5dcd7964ddbae59a4f7899100d787be
  • Resolution set to fixed
  • Status changed from positive_review to closed

comment:11 in reply to: ↑ 8 Changed 5 years ago by charpent

  • Commit 752190c8b5dcd7964ddbae59a4f7899100d787be deleted

Replying to vbraun:

Wget-able URLs please...

Pray tell me where I could have uploaded this ? spkg-uploads, hosted on googlecode, no longer accepts uploads (at least the inteface has disappeared, and I saw http://google-opensource.blogspot.fr/2013/05/a-change-to-google-code-download-service.html, which leaves little doubts.) I have no account on publicly accessible machines.

A suggestion ?

And, oh, since you got the renamed tarball, placed it in a publicly accessible place and presumably will use that fpr the next release, I suppose I can delete the Googledrive copy ?

Sincerely yours,

-- Emmanuel Charpentier

comment:12 Changed 3 years ago by chapoton

  • Authors changed from Emmanuel Charpentier, Nathan Cohen to Emmanuel Charpentier, Nathann Cohen
Note: See TracTickets for help on using tickets.