GNU bug report logs - #40764
New package: r-restrserve

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 40764 in the body.
You can then email your comments to 40764 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eric Brown <ecbrown <at> ericcbrown.com>
To: guix-patches <at> gnu.org
Cc: rekado <at> elephly.net
Subject: New package: r-restrserve
Date: Wed, 22 Apr 2020 06:12:13 -0500

[Message part 1 (text/plain, inline)]

Dear Guix,

Please see attached diff for r-restrserve.  Please note that it depends
on a patch r-rserve which I submitted just a moment ago.

Cheers,
Eric

[0001-gnu-Add-r-restrserve.patch (text/x-patch, inline)]

From 77b08891ad2ffba228858dc0d06b0000b544597a Mon Sep 17 00:00:00 2001
From: Eric Brown <ecbrown <at> ericcbrown.com>
Date: Wed, 22 Apr 2020 06:07:14 -0500
Subject: [PATCH] gnu: Add r-restrserve.

* gnu/packages/cran.scm (r-restrserve): New variable.
---
 gnu/packages/cran.scm | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/gnu/packages/cran.scm b/gnu/packages/cran.scm
index 70cb7cc700..8b27279f2b 100644
--- a/gnu/packages/cran.scm
+++ b/gnu/packages/cran.scm
@@ -21162,3 +21162,25 @@ evaluated interactively.")
 Bayes factors, posterior model probabilities, and normalizing constants in
 general, via different versions of bridge sampling.")
     (license license:gpl2+)))
+
+(define-public r-restrserve
+  (package
+    (name "r-restrserve")
+    (version "0.2.2")
+    (source
+     (origin
+       (method url-fetch)
+       (uri (cran-uri "RestRserve" version))
+       (sha256
+        (base32 "1b8wbar98qhhl46s4i7qks5nm2wy5bvfi9029gpd4gmqsq4bmbm7"))))
+    (build-system r-build-system)
+    (propagated-inputs
+     `(("r-rserve" ,r-rserve)))
+    (home-page "https://restrserve.org")
+    (synopsis "R web API framework")
+    (description
+     "RestRserve is an R web API framework for building high-performance AND
+robust microservices and app backends. With Rserve backend on UNIX-like systems
+it is parallel by design. It will handle incoming requests in parallel - each
+request in a separate fork.")
+    (license license:gpl2+)))
-- 
2.26.2

Message #8 received at 40764 <at> debbugs.gnu.org (full text, mbox):

From: Marius Bakke <mbakke <at> fastmail.com>
To: Eric Brown <ecbrown <at> ericcbrown.com>, 40764 <at> debbugs.gnu.org
Cc: rekado <at> elephly.net
Subject: Re: [bug#40764] New package: r-restrserve
Date: Sat, 30 May 2020 19:56:37 +0200

[Message part 1 (text/plain, inline)]

Eric Brown <ecbrown <at> ericcbrown.com> writes:

> Dear Guix,
>
> Please see attached diff for r-restrserve.  Please note that it depends
> on a patch r-rserve which I submitted just a moment ago.

This patch no longer applies.  Can you rebase it on 'master'?  Thanks in
advance, and sorry for the delay.

Also, make sure 'guix lint r-restrserve' passes.  :-)

[signature.asc (application/pgp-signature, inline)]

Message #13 received at 40764-done <at> debbugs.gnu.org (full text, mbox):

From: Christopher Baines <mail <at> cbaines.net>
To: Eric Brown <ecbrown <at> ericcbrown.com>
Cc: 40764-done <at> debbugs.gnu.org
Subject: Re: [bug#40764] New package: r-restrserve
Date: Wed, 09 Dec 2020 19:36:17 +0000

[Message part 1 (text/plain, inline)]

Eric Brown <ecbrown <at> ericcbrown.com> writes:

> Dear Guix,
>
> Please see attached diff for r-restrserve.  Please note that it depends
> on a patch r-rserve which I submitted just a moment ago.

Hi Eric,

I've gone ahead and pushed this as
e36291ef52a30b1c667b78ef76c1980363f8c138.

Due to the delay in merging this, I updated the package to 0.4.0 and
added some more inputs.

In the future, I'd strongly recommend not adding packages to the bottom
of modules, unless you really want the package definition to be
there. If every new definition gets added at the bottom, merge conflicts
become very likely. Related to this, I also moved the package definition
up off the bottom of the module.

Thanks,

Chris

[signature.asc (application/pgp-signature, inline)]

Message #16 received at 40764-done <at> debbugs.gnu.org (full text, mbox):

From: zimoun <zimon.toutoune <at> gmail.com>
To: Christopher Baines <mail <at> cbaines.net>, Eric Brown <ecbrown <at> ericcbrown.com>
Cc: Ricardo Wurmus <rekado <at> elephly.net>, 40764-done <at> debbugs.gnu.org
Subject: Re: bug#40764: New package: r-restrserve
Date: Thu, 10 Dec 2020 13:36:34 +0100

Hi Chris,

On Wed, 09 Dec 2020 at 19:36, Christopher Baines <mail <at> cbaines.net> wrote:

> In the future, I'd strongly recommend not adding packages to the bottom
> of modules, unless you really want the package definition to be
> there. If every new definition gets added at the bottom, merge conflicts
> become very likely. Related to this, I also moved the package definition
> up off the bottom of the module.

What do you mean?  From my understanding, we always add new R packages
at the botton of the files cran.scm or bioconductor.scm; mainly.

Instead, what do you suggest?  Again, from my understanding, merge
conflicts could happen wherever the package is added.  If the package is
added at one location in the file and this location does not make sense
anymore because other packages had been added before this location, then
conflict.  For sure, adding bottom increases the probability it
happens. ;-) But adding elsewhere does not prevent neither.

The only fix to avoid boring conflicts is to reduce the time between the
submission and the merge, IMHO.

Do I miss something?

All the best,
simon

Message #19 received at 40764-done <at> debbugs.gnu.org (full text, mbox):

From: Ricardo Wurmus <rekado <at> elephly.net>
To: zimoun <zimon.toutoune <at> gmail.com>
Cc: Eric Brown <ecbrown <at> ericcbrown.com>, Christopher Baines <mail <at> cbaines.net>,
 40764-done <at> debbugs.gnu.org
Subject: Re: bug#40764: New package: r-restrserve
Date: Thu, 10 Dec 2020 14:18:27 +0100

zimoun <zimon.toutoune <at> gmail.com> writes:

> Hi Chris,
>
> On Wed, 09 Dec 2020 at 19:36, Christopher Baines <mail <at> cbaines.net> wrote:
>
>> In the future, I'd strongly recommend not adding packages to the bottom
>> of modules, unless you really want the package definition to be
>> there. If every new definition gets added at the bottom, merge conflicts
>> become very likely. Related to this, I also moved the package definition
>> up off the bottom of the module.
>
> What do you mean?  From my understanding, we always add new R packages
> at the botton of the files cran.scm or bioconductor.scm; mainly.

The problem is 100% with tooling.  Git needs some context to apply
patches.  When you add package definitions to the bottom and that bottom
context keeps changing you will always need to tell Git how to apply that
patch.

By picking an arbitrary location somewhere in the file you avoid this
problem because it’s unlikely that other people will pick that very same
location.

> The only fix to avoid boring conflicts is to reduce the time between the
> submission and the merge, IMHO.

Not even that would be a fix, because you can have two different people
submitting patches for modifications at the bottom of the file at the
same time.  Applying them one after the other will result in the same
problem, no matter how fast we are.

Of course it’s always better to reduce time between submission and
application.

It would be *great* if we could find another way to appease git and do
the right thing for the most common case of simply adding a package
definition to the bottom of the file, no matter what context there might
be right above.

-- 
Ricardo

Message #22 received at 40764-done <at> debbugs.gnu.org (full text, mbox):

From: Efraim Flashner <efraim <at> flashner.co.il>
To: Ricardo Wurmus <rekado <at> elephly.net>
Cc: Eric Brown <ecbrown <at> ericcbrown.com>, 40764-done <at> debbugs.gnu.org,
 zimoun <zimon.toutoune <at> gmail.com>
Subject: Re: [bug#40764] New package: r-restrserve
Date: Thu, 10 Dec 2020 16:22:03 +0200

[Message part 1 (text/plain, inline)]

On Thu, Dec 10, 2020 at 02:18:27PM +0100, Ricardo Wurmus wrote:
> 
> zimoun <zimon.toutoune <at> gmail.com> writes:
> 
> > Hi Chris,
> >
> > On Wed, 09 Dec 2020 at 19:36, Christopher Baines <mail <at> cbaines.net> wrote:
> >
> >> In the future, I'd strongly recommend not adding packages to the bottom
> >> of modules, unless you really want the package definition to be
> >> there. If every new definition gets added at the bottom, merge conflicts
> >> become very likely. Related to this, I also moved the package definition
> >> up off the bottom of the module.
> >
> > What do you mean?  From my understanding, we always add new R packages
> > at the botton of the files cran.scm or bioconductor.scm; mainly.
> 
> The problem is 100% with tooling.  Git needs some context to apply
> patches.  When you add package definitions to the bottom and that bottom
> context keeps changing you will always need to tell Git how to apply that
> patch.
> 
> By picking an arbitrary location somewhere in the file you avoid this
> problem because it’s unlikely that other people will pick that very same
> location.
> 
> > The only fix to avoid boring conflicts is to reduce the time between the
> > submission and the merge, IMHO.
> 
> Not even that would be a fix, because you can have two different people
> submitting patches for modifications at the bottom of the file at the
> same time.  Applying them one after the other will result in the same
> problem, no matter how fast we are.
> 
> Of course it’s always better to reduce time between submission and
> application.
> 
> It would be *great* if we could find another way to appease git and do
> the right thing for the most common case of simply adding a package
> definition to the bottom of the file, no matter what context there might
> be right above.
> 

This is why I like sorting them alphabetically :)

-- 
Efraim Flashner   <efraim <at> flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[signature.asc (application/pgp-signature, inline)]

Message #25 received at 40764-done <at> debbugs.gnu.org (full text, mbox):

From: zimoun <zimon.toutoune <at> gmail.com>
To: Ricardo Wurmus <rekado <at> elephly.net>
Cc: Eric Brown <ecbrown <at> ericcbrown.com>, Christopher Baines <mail <at> cbaines.net>,
 40764-done <at> debbugs.gnu.org
Subject: Re: bug#40764: New package: r-restrserve
Date: Thu, 10 Dec 2020 15:25:30 +0100

Hi Ricardo,

On Thu, 10 Dec 2020 at 14:18, Ricardo Wurmus <rekado <at> elephly.net> wrote:
>> On Wed, 09 Dec 2020 at 19:36, Christopher Baines <mail <at> cbaines.net> wrote:
>>
>>> In the future, I'd strongly recommend not adding packages to the bottom
>>> of modules, unless you really want the package definition to be
>>> there. If every new definition gets added at the bottom, merge conflicts
>>> become very likely. Related to this, I also moved the package definition
>>> up off the bottom of the module.
>>
>> What do you mean?  From my understanding, we always add new R packages
>> at the botton of the files cran.scm or bioconductor.scm; mainly.
>
> The problem is 100% with tooling.  Git needs some context to apply
> patches.  When you add package definitions to the bottom and that bottom
> context keeps changing you will always need to tell Git how to apply that
> patch.

[...]

> It would be *great* if we could find another way to appease git and do
> the right thing for the most common case of simply adding a package
> definition to the bottom of the file, no matter what context there might
> be right above.

The option “format-patch --base” reduces the burden and I proposed this
patch:

   <http://issues.guix.gnu.org/issue/43946>

Adding directly in the patch the (base) commit where the patch is known
to apply fixes most of the issues.  IMO.


All the best,
simon

Message #28 received at 40764-done <at> debbugs.gnu.org (full text, mbox):

From: Oleg Pykhalov <go.wigust <at> gmail.com>
To: zimoun <zimon.toutoune <at> gmail.com>
Cc: Ricardo Wurmus <rekado <at> elephly.net>, Eric Brown <ecbrown <at> ericcbrown.com>,
 40764-done <at> debbugs.gnu.org
Subject: Re: [bug#40764] New package: r-restrserve
Date: Mon, 14 Dec 2020 12:54:57 +0300

[Message part 1 (text/plain, inline)]

Hello,

zimoun <zimon.toutoune <at> gmail.com> writes:

[…]

> The option “format-patch --base” reduces the burden and I proposed this
> patch:
>
>    <http://issues.guix.gnu.org/issue/43946>
>
> Adding directly in the patch the (base) commit where the patch is known
> to apply fixes most of the issues.  IMO.

It adds ‘base-commit’ and optionally ‘prerequisite-patch-id’ (see [1]), which will
help you to checkout base-commit and apply a patch, but still you will
need to rebase on origin/master with solving conflicts AFAIK.

Also, on git version 2.29.2 --base requires an argument.  If we apply
the patch on 43946 issue, we should mention this in example.  

And, IMHO, the --base flag should be mention inside the first paragraph
of [2], where format-patch is recommended for patch submission.
Otherwise people will send with and without --base, which probably
will not hurt, but still.

[1]: --base=HEAD~~ output example
--8<---------------cut here---------------start------------->8---
oleg <at> guixsd ~/src/guix-master$ git format-patch --base=HEAD~~ --stdout HEAD~..HEAD
From ea50795d7f54582d5c439f60e836ff2ee5d8aed2 Mon Sep 17 00:00:00 2001
From: Leo Famulari <leo <at> famulari.name>
Date: Sat, 12 Dec 2020 00:39:26 -0500
Subject: [PATCH] gnu: linux-libre 4.4: Update to 4.4.248.

* gnu/packages/linux.scm (linux-libre-4.4-version): Update to 4.4.248.
(linux-libre-4.4-pristine-source): Update hash.
---
 gnu/packages/linux.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index 4c5917bc59..73dec7d1b7 100644
[…]


base-commit: 4c327e025277dd59b864200d5ecf671b5656e7c9
prerequisite-patch-id: 2f8bef97c220d126e922b526c4fccc847592311d
-- 
2.29.2

--8<---------------cut here---------------end--------------->8---

[2] https://guix.gnu.org/manual/en/html_node/Submitting-Patches.html

[signature.asc (application/pgp-signature, inline)]

Message #31 received at 40764-done <at> debbugs.gnu.org (full text, mbox):

From: zimoun <zimon.toutoune <at> gmail.com>
To: Oleg Pykhalov <go.wigust <at> gmail.com>
Cc: Ricardo Wurmus <rekado <at> elephly.net>, Eric Brown <ecbrown <at> ericcbrown.com>,
 40764-done <at> debbugs.gnu.org
Subject: Re: [bug#40764] New package: r-restrserve
Date: Tue, 15 Dec 2020 15:35:45 +0100

Hi,

On Mon, 14 Dec 2020 at 12:54, Oleg Pykhalov <go.wigust <at> gmail.com> wrote:

> It adds ‘base-commit’ and optionally ‘prerequisite-patch-id’ (see [1]), which will
> help you to checkout base-commit and apply a patch, but still you will
> need to rebase on origin/master with solving conflicts AFAIK.

“with **hypothetically** solving conflicts”.  Well, it is by-design
because of Git.

It is still better than the current situation IMHO where it is boring to
apply old patches.


> Also, on git version 2.29.2 --base requires an argument.  If we apply
> the patch on 43946 issue, we should mention this in example.

Agree.

> And, IMHO, the --base flag should be mention inside the first paragraph
> of [2], where format-patch is recommended for patch submission.
> Otherwise people will send with and without --base, which probably
> will not hurt, but still.

Yes, the first paragraph seems better.

More people will send with base-commit and easier automation will be.
For example, we could imagine that the testing build-farm builds the
patch applied at the base-commit, so the reviewer can use the substitute
instead of burning CPU (sometimes the test suite is really resource
hungry).  The reviewer checks the compliance and rebase if needed.


All the best,
simon

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.