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 "sour
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 ar
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 wil
Ian Jackson 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
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 sour
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 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
]] 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" a écrit :
> > > IMVHO, this is the same as how we should treat images (I mean,
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
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 manua
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 d
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
On 2013-08-05, Paul Tagliamonte 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 data, but if th
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" a écrit :
> > IMVHO, this is the same as how we should treat images (I mean, for any
> > data format, not jus
Le 5 août 2013 15:42, "Paul Tagliamonte" 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 pickled objec
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 whateve
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. Thos
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
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 b
19 matches
Mail list logo
