Thus said Warren Young on Wed, 05 Oct 2016 09:04:57 -0600:
> That's a nice bit of detective work, Andy! I can't imagine what
> possessed you to keep pursuing it for 8 months, but thank you. :)
Haha, well, it was a bit less glamorous than 8 months of investigations.
:-) I was trying to get
On Oct 5, 2016, at 12:59 AM, Andy Bradford wrote:
>
> I propose that blob_delta_create should use blob_materialize instead of
> blob_buffer here:
>
> http://www.fossil-scm.org/index.html/info/75ddc3687acbdb32
That’s a nice bit of detective work, Andy! I can’t imagine what possessed you
to ke
Thus said Richard Hipp on Tue, 09 Feb 2016 07:39:57 -0500:
> The input to checksum() should normally be a pointer to a buffer
> obtained from malloc(). And such buffers should always be 8-byte
> aligned (or 4-byte aligned on Windows). So I'm not sure how this is
> happening. There
On Feb 19, 2016, at 9:04 PM, Andy Bradford wrote:
>
> Notice here that my stack has much smaller numbers pTarget=0xcf7c6300 vs
> pTarget=0x7fffaf5dccd0:
I’m on a 64-bit machine. If yours OS or executable is 32-bit, that explains it.
Also, different OSes use different defaults in how they prese
Thus said Stephan Beal on Sat, 20 Feb 2016 04:46:51 +0100:
> i see lots of 0x7ffs in there, and i happen to know that
> se=... is indeed a stack-allocated object. i'm a bit surprised that
> argv is, but not overly so.
Yeah, I guess it's more common than I thought and I'm not us
On Sat, Feb 20, 2016 at 4:42 AM, Andy Bradford
wrote:
> Thus said Martin Gagnon on Fri, 19 Feb 2016 20:56:47 -0500:
>
> > This is not usually stack addresses?
>
> Yes, for allocated memory, but how big is the stack that supports an
> address that big?
>
Dunno. Just kinda randomly taking a b
Thus said Martin Gagnon on Fri, 19 Feb 2016 20:56:47 -0500:
> This is not usually stack addresses?
Yes, for allocated memory, but how big is the stack that supports an
address that big?
Andy
--
TAI64 timestamp: 400056c7e0c0
___
fossil-users
On Sat, Feb 20, 2016 at 2:53 AM, Andy Bradford
wrote:
> Thus said Warren Young on Fri, 12 Feb 2016 09:45:34 -0700:
>
> > #5 0x004237f6 in blob_delta_create (pOriginal= out>, pTarget=0x7fffe330, pDelta=0x7fffe370) at ./src/deltacmd.c:40
>
> I could be wrong, but those seem like ex
> Le 19 févr. 2016 à 20:53, Andy Bradford a écrit :
>
> Thus said Warren Young on Fri, 12 Feb 2016 09:45:34 -0700:
>
>> #5 0x004237f6 in blob_delta_create (pOriginal=> out>, pTarget=0x7fffe330, pDelta=0x7fffe370) at ./src/deltacmd.c:40
>
> I could be wrong, but those seem like
Thus said Warren Young on Fri, 12 Feb 2016 09:45:34 -0700:
> #5 0x004237f6 in blob_delta_create (pOriginal=,
> pTarget=0x7fffe330, pDelta=0x7fffe370) at ./src/deltacmd.c:40
I could be wrong, but those seem like extreme memory addresses...
Anyone?
Andy
--
TAI64 timestamp: 4
On Feb 11, 2016, at 6:05 AM, Richard Hipp wrote:
>
> On 2/10/16, Warren Young wrote:
>> On Feb 9, 2016, at 5:50 AM, Stephan Beal wrote:
>>>
>>> Can you post the configure/build options you used?
>>
>> Well, you kind of nailed it. I’ve reproduced the problem thusly:
>>
>>f set mv-rm-file
On 2/11/2016 10:06 AM, Ross Berteig wrote:
What does fossil revert do in this circumstance?
It says:
REVERT f1
DELETE f1new
"fossil undo" is available to undo changes to the working checkout.
and has now forgotten the pending rename.
I think that fossil stash save *should* do the sam
On 2/10/2016 10:41 PM, Andy Bradford wrote:
Thus said Ross Berteig on Wed, 10 Feb 2016 15:48:40 -0800:
which as expected renamed the file in the repository but not on the
disk. It then says
fossil stash -m "B 2016-02-09"
Did you mean:
fossil stash save -m "B 2016-02-09"
Yes,
On 2/10/16, Warren Young wrote:
> On Feb 9, 2016, at 5:50 AM, Stephan Beal wrote:
>>
>> Can you post the configure/build options you used?
>
> Well, you kind of nailed it. I’ve reproduced the problem thusly:
>
> f set mv-rm-files 1
> f mv foo.c bar.c
> f stash
>
I cannot seem to rep
Thus said Ross Berteig on Wed, 10 Feb 2016 15:48:40 -0800:
> which as expected renamed the file in the repository but not on the
> disk. It then says
>
> fossil stash -m "B 2016-02-09"
Did you mean:
fossil stash save -m "B 2016-02-09"
> ERROR: no such file: c:/Users/Ross/Documen
On Feb 10, 2016, at 4:48 PM, Ross Berteig wrote:
>
> What was fossil stash supposed to do in this circumstance?
OP expects the stash to be as capable as bundles, differing only in where the
archived data are stored and how each archive is named. (Stash IDs vs bundle
file names.) If bundles c
On 2/10/2016 7:35 AM, Warren Young wrote:
However, this nonstandard option is not at fault per se. This also triggers it
with a default build:
mv foo.c bar.c
f mv --soft foo.c bar.c
f stash
So, the problem is trying to stash a renamed file.
Given this nice, concise, and
On Feb 9, 2016, at 5:50 AM, Stephan Beal wrote:
>
> Can you post the configure/build options you used?
Well, you kind of nailed it. I’ve reproduced the problem thusly:
f set mv-rm-files 1
f mv foo.c bar.c
f stash
I always enable --with-legacy-mv-rm in my Fossil builds, and always
On Tue, Feb 9, 2016 at 1:43 PM, Stephan Beal wrote:
> On Tue, Feb 9, 2016 at 1:39 PM, Richard Hipp wrote:
>
>> work regardless on Intel, but other platforms (ARM, Sparc) have
>> stricter alignment requirements.
>>
>
> i'm powering up the ARM now to try to reproduce it.
>
Unfortunately no such l
On Tue, Feb 9, 2016 at 9:22 AM, Warren Young wrote:
>
> This was with version [b8c7af5bd9], plus the patch I recently sent to the
> list, running on CentOS 5.
>
Can you post the configure/build options you used?
The trunk tests are currently running on my ARM (no idea how long that will
take),
On 2/9/16, Stephan Beal wrote:
>
> But how does the (unsigned char *) cast on the NULL pointer affect the
> result of (z-0)?
That was my effort to convert a pointer into an integer in a way that
is portable across a variety of compilers.
--
D. Richard Hipp
d...@sqlite.org
_
On Tue, Feb 9, 2016 at 1:43 PM, Stephan Beal wrote:
> On Tue, Feb 9, 2016 at 1:39 PM, Richard Hipp wrote:
>
>> work regardless on Intel, but other platforms (ARM, Sparc) have
>> stricter alignment requirements.
>>
>
> i'm powering up the ARM now to try to reproduce it.
>
> But how does the (unsi
On Tue, Feb 9, 2016 at 1:39 PM, Richard Hipp wrote:
> work regardless on Intel, but other platforms (ARM, Sparc) have
> stricter alignment requirements.
>
i'm powering up the ARM now to try to reproduce it.
But how does the (unsigned char *) cast on the NULL pointer affect the
result of (z-0)?
On 2/9/16, Stephan Beal wrote:
> On Tue, Feb 9, 2016 at 12:51 PM, Richard Hipp wrote:
>
>> On 2/9/16, Warren Young wrote:
>> > I was getting this from “fossil stash” for no obvious reason:
>> >
>> > fossil: ./src/delta.c:231: checksum: Assertion `(z - (const unsigned
>> > char*)0)%4==0' failed
On Tue, Feb 9, 2016 at 12:51 PM, Richard Hipp wrote:
> On 2/9/16, Warren Young wrote:
> > I was getting this from “fossil stash” for no obvious reason:
> >
> > fossil: ./src/delta.c:231: checksum: Assertion `(z - (const unsigned
> > char*)0)%4==0' failed.
>
> I wish you could reproduce this, b
On 2/9/16, Warren Young wrote:
> I was getting this from “fossil stash” for no obvious reason:
>
> fossil: ./src/delta.c:231: checksum: Assertion `(z - (const unsigned
> char*)0)%4==0' failed.
I wish you could reproduce this, because that is an important
assertion and I would really like to cha
I was getting this from “fossil stash” for no obvious reason:
fossil: ./src/delta.c:231: checksum: Assertion `(z - (const unsigned
char*)0)%4==0' failed.
Rebuilding both the local repo and the master repo didn’t help. Closing the
current checkout and re-opening it did.
The number of uncommi
27 matches
Mail list logo
