On Thu, Jan 17, 2013 at 09:04:55PM +0100, Thomas Neidhart wrote:
> On 01/17/2013 08:24 PM, Gilles Sadowski wrote:
> >>> [...]
> >>>
> >>> If we do not have the resources to dig further into the real problem, we
> >>> can
> >>> circumscribe it by indicating which interval of epsilon values are
> >>
On 01/17/2013 08:24 PM, Gilles Sadowski wrote:
>>> [...]
>>>
>>> If we do not have the resources to dig further into the real problem, we can
>>> circumscribe it by indicating which interval of epsilon values are
>>> considered trustworthy (and declining all resposibility if user try pushing
>>> th
> > [...]
> >
> > If we do not have the resources to dig further into the real problem, we can
> > circumscribe it by indicating which interval of epsilon values are
> > considered trustworthy (and declining all resposibility if user try pushing
> > the implementation too far).
>
> Well, I do dis
On 01/17/2013 04:21 PM, Gilles Sadowski wrote:
> Hi Thomas.
>
> On Thu, Jan 17, 2013 at 03:59:20PM +0100, Thomas Neidhart wrote:
>> On Thu, Jan 17, 2013 at 3:52 PM, Gilles Sadowski <
>> gil...@harfang.homelinux.org> wrote:
>>
>>> On Thu, Jan 17, 2013 at 02:28:56PM +0100, Thomas Neidhart wrote:
>>>
I think a number of applications use a concatenation of a standard archive
format and custom data. The most well known probably is .rpm which is/was a
cpio stream immediately followed by additional information (iirc - it might
go the other way). In any case a developer might expect to have the inpu
Hi Thomas.
On Thu, Jan 17, 2013 at 03:59:20PM +0100, Thomas Neidhart wrote:
> On Thu, Jan 17, 2013 at 3:52 PM, Gilles Sadowski <
> gil...@harfang.homelinux.org> wrote:
>
> > On Thu, Jan 17, 2013 at 02:28:56PM +0100, Thomas Neidhart wrote:
> > > Hi,
> > >
> > > by investigating a recent issue (MAT
On Thu, Jan 17, 2013 at 3:52 PM, Gilles Sadowski <
gil...@harfang.homelinux.org> wrote:
> On Thu, Jan 17, 2013 at 02:28:56PM +0100, Thomas Neidhart wrote:
> > Hi,
> >
> > by investigating a recent issue (MATH-930), I discovered that the newly
> > introduced LinearConstraintSet stores the constrain
On Thu, Jan 17, 2013 at 02:28:56PM +0100, Thomas Neidhart wrote:
> Hi,
>
> by investigating a recent issue (MATH-930), I discovered that the newly
> introduced LinearConstraintSet stores the constraints internally in a
> HashSet.
> This leads to undeterministic behavior as the iteration order of
>
> For tar it would be one block (usualy 512 bytes), for zip the full
> central directory has to be read which could be quite a bit.
>
Urgh. Because that's at the end for zips? That's not so good then.
>
> I currently plan to implement it inside getNextEntry as it is cleaner.
> In the tar case I
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-scxml-test has an issue affecting its community integration.
This
On 2013-01-17, Torsten Curdt wrote:
> If we see `getNextEntry` return null we should position the stream at
> the end of the archive. I think that's your (1). Sounds simpler and
> more straight forward from an API POV. IIUC that reading should only
> be a few bytes. A second EOF marker for TAR f
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-vfs2-test has an issue affecting its community integration.
This i
Hi,
by investigating a recent issue (MATH-930), I discovered that the newly
introduced LinearConstraintSet stores the constraints internally in a
HashSet.
This leads to undeterministic behavior as the iteration order of
constraints is not fixed (especially between different JRE versions).
TBH, I
Late reply but anyway.
If we see `getNextEntry` return null we should position the stream at the
end of the archive.
I think that's your (1). Sounds simpler and more straight forward from an
API POV.
IIUC that reading should only be a few bytes. A second EOF marker for TAR
for example.
Did I get
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-proxy-test has an issue affecting its community integration.
This
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-dbutils has an issue affecting its community integration.
This iss
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-chain2 has an issue affecting its community integration.
This issu
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-digester3 has an issue affecting its community integration.
This i
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-functor has an issue affecting its community integration.
This iss
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-dbcp has an issue affecting its community integration.
This issue
20 matches
Mail list logo
