I demand that Lisandro Damián Nicanor Pérez Meyer may or may not have
written...
On Monday 05 August 2013 17:48:27 Paul Wise wrote:
On Mon, Aug 5, 2013 at 4:28 PM, Sune Vuorela wrote:
What about svg files that are converted into png's and then manually
adjusted?
I'd say the source is the
On Monday 05 August 2013 17:48:27 Paul Wise wrote:
On Mon, Aug 5, 2013 at 4:28 PM, Sune Vuorela wrote:
What about svg files that are converted into png's and then manually
adjusted?
I'd say the source is the combination of the SVG files plus the adjusted
PNGs.
I guess you are thinking
Ian Jackson ijackson at chiark.greenend.org.uk writes:
Jeremy Stanley writes (Re: We need a global decision about R data in
binary format, and stick to it.):
interpreted strongly. For example I have a program which relies on a
fairly large set of correlative data requiring hours of
On Mon, Aug 05, 2013 at 05:44:16PM -0700, Don Armstrong wrote:
My last question is, given the answers to the previous questions, what
do we do with the R packages that are already in the archive and also
contain data that is editable as is but do have an original source,
who will do it,
Paul Tagliamonte writes (Re: We need a global decision about R data in binary
format, and stick to it.):
On Mon, Aug 05, 2013 at 09:57:35AM +0900, Charles Plessy wrote:
it is the common practice in upstream R packages to store data in binary
objects. Those objects can be modified with R,
On Mon, Aug 05, 2013 at 02:13:15PM +0100, Ian Jackson wrote:
We need to separate these two issues.
Aye.
IMVHO, this is the same as how we should treat images (I mean, for any
data format, not just this one case of a pickled object) - if the image
was a photo, clearly the .jpg or .png or
Le 5 août 2013 15:42, Paul Tagliamonte paul...@debian.org a écrit :
On Mon, Aug 05, 2013 at 02:13:15PM +0100, Ian Jackson wrote:
We need to separate these two issues.
Aye.
IMVHO, this is the same as how we should treat images (I mean, for any
data format, not just this one case of a
Bastien ROUCARIES writes (Re: We need a global decision about R data in binary
format, and stick to it.):
Le 5 août 2013 15:42, Paul Tagliamonte paul...@debian.org a écrit :
IMVHO, this is the same as how we should treat images (I mean, for any
data format, not just this one case of a
On 2013-08-05, Paul Tagliamonte paul...@debian.org wrote:
IMVHO, this is the same as how we should treat images (I mean, for any
data format, not just this one case of a pickled object) - if the image
was a photo, clearly the .jpg or .png or whatever we get is the best way
to communicate this
On 2013-08-05 14:13:15 +0100 (+0100), Ian Jackson wrote:
[...]
The other is the assertion that this particular case involves a
generated data table. If this is the case then the source package
needs to contain the source code which generates the table - and,
really, it should regenerate the
Jeremy Stanley writes (Re: We need a global decision about R data in binary
format, and stick to it.):
No argument on the first, but the second sets a bad precedent if
interpreted strongly. For example I have a program which relies on a
fairly large set of correlative data requiring hours of
On Mon, Aug 5, 2013 at 4:28 PM, Sune Vuorela wrote:
What about svg files that are converted into png's and then manually
adjusted?
I'd say the source is the combination of the SVG files plus the adjusted PNGs.
I guess you are thinking of a particular case here? What is the reason
for manually
On 2013-08-05 16:41:13 +0100 (+0100), Ian Jackson wrote:
[...]
There should IMO be a standard way to request a source package to do
from-scratch rebuilds for this kind of thing, for QA purposes.
I absolutely agree. If there were a standard make target or envvar
for this purpose I would gladly
]] Ian Jackson
Bastien ROUCARIES writes (Re: We need a global decision about R data in
binary format, and stick to it.):
Le 5 août 2013 15:42, Paul Tagliamonte paul...@debian.org a écrit :
IMVHO, this is the same as how we should treat images (I mean, for any
data format, not just
On Mon, 05 Aug 2013, Ian Jackson wrote:
The other is the assertion that this particular case involves a
generated data table. If this is the case then the source package
needs to contain the source code which generates the table - and,
really, it should regenerate the table during the build.
Hi Joerg and Paul,
thank you for your prompt answers and thank for everybody's contribution.
I would like to focus my questions on R binary objects that represent data that
was not entirely computer-generated (that is, for which the source code can not
be summarised by a mathematical formula and
On Tue, 06 Aug 2013, Charles Plessy wrote:
My first question is: to what extent do we need to verify that the
object can be regenerated.
- The starting point is a source package with a R binary object.
- With this starting point only, it may be impossible to know if it
has a source or
Le Mon, Aug 05, 2013 at 12:37:17AM +, Paul Richards Tagliamonte a écrit :
Hi maintainer,
sysdata.rda appears to be in your source, which is a dataset compressed
into pickled R objects.
Can you assure me of one of two things:
1. that this data is *not* used anywhere in the binary
On Mon, Aug 05, 2013 at 09:57:35AM +0900, Charles Plessy wrote:
Dear Paul and everybody,
it is the common practice in upstream R packages to store data in binary
objects. Those objects can be modified with R, and exported into various
formats. The Debian archive if full of them.
This is
19 matches
Mail list logo
