[fossil-users] Ticket [967cedbf20]: fossil extra - Report for subtree
Hello all, I would like to see this feature request granted. Is there any objection to merging branch [ticket-967cedbf20] to trunk? It will allow the fossil extra and fossil clean to be given extra arguments, specifying a subset (directories or files) of the directory structure where the extra/clean should be operated on. Without arguments, the operation stays the same as it is now; it's fully upwards compatible. Regards, Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Latest SQLite3 broken on Android?
Just a quick heads up for http://fossil-scm.org/index.html/tktview?name=752aa31a6d since I don't have access to the sqlite3 mailing list/repo. It seems that the latest version of SQLite3 fails to build for Android (the Android Bionic libc doesn't have posix_fallocate). Considering the widespread use of sqlite on Android this seems like it could be an issue. Fix is at http://mpcjanssen.nl/cgi-bin/fossil/vpatch?from=ea018d154657ddd9to=f0df1fe2d8f001e3 Mark ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] cloning / opening fails on WinXP SP3
On Wed, Jun 19, 2013 at 10:28:29AM +0200, Michai Ramakers wrote: On 19 June 2013 10:25, Edward Berner e...@bernerfam.com wrote: I'm surprised, but yeah, its looking that way. I just ran the test again using the same fossil binary on XP and Windows 7. The clone failed on XP but succeeded on (64 bit) Windows 7. It also succeeds on 32 bit Vista but fails on Windows 2000 (I had to use a different binary on Windows 2000). As a sanity check I served up a copy of Fossil's own repository in the same way as my test repository. All systems were able to successfully clone it. That's a big help, thank you. Did you happen to also try cloning from WinXP to the same WinXP box, using either file:// or http:// with 'fossil clone' ? I get same problem on my Windows XP SP3 virtual machine using normal http:// protocol. But using file:// and ssh:// protocol, the clone was successfull. Also, I was able to open the resulting clone (when using http://), but checkout was empty, and when I try to do a: fossil pull, I got the following error: Error: bad command: pull big sha1 number I didn't see that error during the clone, and I grep for bad command in the source code and I found nothing.. Does it give some any hints to someone ? -- Martin G. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Divide and Mod by 0 in th1
On Thu, Jun 20, 2013 at 9:40 AM, Eduardo Morras emorr...@yahoo.es wrote: set a = [expr 231%0 ] If Run TH1 is pressed, fossil crash. Stephen, check your th1 fork too. LOL! Thanks for the head's up - just last night, coincidentally, i fixed this same problem in my conceptual fork of th1. i'll get this patched in fossil and my fork. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Divide and Mod by 0 in th1
On Thu, Jun 20, 2013 at 9:40 AM, Eduardo Morras emorr...@yahoo.es wrote: case OP_DIVIDE: iRes = iLeft/iRight; break; case OP_MODULUS: iRes = iLeft%iRight; break; The error message isn't the best, but it's fixed now: set a = [expr 231/0 ] Divide by 0: 231 set a = [expr 231%0 ] Modulo by 0: 231 th1 doesn't have enough info to report the error location, so i just took the left-hand-side as the error message, with the hope that it will at least be marginally helpful in locating the location. http://fossil-scm.org/index.html/info/fded1d055f Thanks again for the report! -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] 64-bit integers in JSON on Win32/64
Hi Stephan, Just noted that JSON (CSON) on win32/64 cannot use 64-bit integers. My attempt to fix this is in: http://fossil-scm.org/index.html/info/50e8847df7 But becasue CSON is an amalgamation, I'm sure the real fix should be somewhere else. Regards, Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] cloning / opening fails on WinXP SP3
On Thu, Jun 20, 2013 at 09:05:50AM -0400, Martin Gagnon wrote:
On Wed, Jun 19, 2013 at 10:28:29AM +0200, Michai Ramakers wrote:
On 19 June 2013 10:25, Edward Berner e...@bernerfam.com wrote:
I'm surprised, but yeah, its looking that way. I just ran the test again
using the same fossil binary on XP and Windows 7. The clone failed on XP
but succeeded on (64 bit) Windows 7. It also succeeds on 32 bit Vista but
fails on Windows 2000 (I had to use a different binary on Windows 2000).
As a sanity check I served up a copy of Fossil's own repository in the
same
way as my test repository. All systems were able to successfully clone
it.
That's a big help, thank you. Did you happen to also try cloning from
WinXP to the same WinXP box, using either file:// or http:// with
'fossil clone' ?
I get same problem on my Windows XP SP3 virtual machine using normal
http:// protocol. But using file:// and ssh:// protocol, the clone was
successfull.
Also, I was able to open the resulting clone (when using http://), but
checkout was empty, and when I try to do a: fossil pull, I got the
following error:
Error: bad command: pull big sha1 number
I didn't see that error during the clone, and I grep for bad command
in the source code and I found nothing..
Does it give some any hints to someone ?
After doing the clone under GDB (under mingw), I got a segmentation
fault during the clone.
here's a part of my gdb session output:
--%
(gdb)
172 fossil_print(Rebuilding repository meta-data...\n);
(gdb)
Rebuilding repository meta-data...
173 rebuild_db(0, 1, 0);
(gdb)
50.0% complete...
Program received signal SIGSEGV, Segmentation fault.
0x00404d42 in blobReallocStatic (pBlob=0x22fe7c, newSize=76281) at
src/blob.c:176
176 memcpy(pNew, pBlob-aData, pBlob-nUsed);
(gdb) p pNew
$26 = 0x805568
\356■\356■\356■\356■\356■\356■\356■\356■\r¡║\r¡║\r¡║\r¡║\r¡║\r¡║\r¡║\r¡║\r¡
║\r¡║\r¡║\r¡║\r¡║\r¡║\r¡║\r¡║\r¡║\r¡║\r¡║\r¡║\r¡║\r¡║\r¡║\r¡║\r¡║\r¡║\r¡║\r¡║\r¡
║\r¡║\r¡║\r¡║\r¡║\r¡║\r¡║\r¡║\r¡║\r¡║\r¡║\r¡║\r¡║\r¡║\r¡║\r¡║\r¡║\r¡║...
(gdb) p bBlob-aData
No symbol bBlob in current context.
(gdb) p pBlob
$27 = (Blob *) 0x22fe7c
(gdb) bt
#0 0x00404d42 in blobReallocStatic (pBlob=0x22fe7c, newSize=76281) at
src/blob.c:176
#1 0x00405394 in blob_resize (pBlob=0x22fe7c, newSize=76280) at src/blob.c:377
#2 0x00405436 in blob_materialize (pBlob=0x22fe7c) at src/blob.c:387
#3 0x004302cd in manifest_parse (pContent=0x22fe7c, rid=2, pErr=0x0) at
src/manifest.c:375
#4 0x00432382 in manifest_crosslink (rid=2, pContent=0x22fe7c) at
src/manifest.c:1650
#5 0x0043d3bf in rebuild_step (rid=2, size=262223975, pBase=0x22fe7c) at
src/rebuild.c:255
#6 0x0043d7da in rebuild_db (randomize=0, doOut=1, doClustering=0) at
src/rebuild.c:393
#7 0x0040dcd5 in clone_cmd () at src/clone.c:173
#8 0x0042efc5 in main (argc=4, argv=0x3e41d8) at src/main.c:629
(gdb) l
171 if( newSize==0 ){
172 *pBlob = empty_blob;
173 }else{
174 char *pNew = fossil_malloc( newSize );
175 if( pBlob-nUsednewSize ) pBlob-nUsed = newSize;
176 memcpy(pNew, pBlob-aData, pBlob-nUsed);
177 pBlob-aData = pNew;
178 pBlob-xRealloc = blobReallocMalloc;
179 pBlob-nAlloc = newSize;
180 }
--%
--
Martn G.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Ticket [967cedbf20]: fossil extra - Report for subtree
On Thu, Jun 20, 2013 at 9:26 AM, Jan Nijtmans jan.nijtm...@gmail.comwrote: I would like to see this feature request granted. Is there any objection to merging branch [ticket-967cedbf20] to trunk? :) Any chance of adding the same to ls as well? Side-note: the graph view in the www ui never ceases to impress me: http://fossil-scm.org/index.html/timeline?r=ticket-967cedbf20 -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] 64-bit integers in JSON on Win32/64
On Thu, Jun 20, 2013 at 3:30 PM, Stephan Beal sgb...@googlemail.com wrote: That's the fix i would have suggested. i'll get it added to the upstream build. Feel free to merge that one to the trunk - it'll just get overwritten the next time i pull in upstream (which is undergoing yet another round of malloc-reduction optimization, and isn't ready for merging yet). FYI: upstream includes your patch now, so it won't get lost during the next merge. Thanks again! -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] 64 bit rowid bug?
2013/6/15 Richard Hipp d...@sqlite.org: On Fri, Jun 14, 2013 at 8:15 PM, Edward Berner e...@bernerfam.com wrote: Hello, db_last_insert_rowid() is defined in db.c to return an i64, but every use of the function stores the result in an int. I guess it might cause problems - if you created a repository with over 2 billion artifacts. A typical busy project (ex: Tcl, SQLite) accumulates between 1K and 10K artifacts per year. So this probably won't be a problem any time soon. I think the assumption of of less than 2 billion artifacts probably permeates the code, so this might be a really big patch, though. Are you sure it is worth it? Hm, I would suggest to change the return-type from i64 to size_t. On 32-bit systems that would double the maximum number of artifacts, with hardly any impact. See: http://fossil-scm.org/index.html/info/e1cb483a9b Of course, some more internal variables have to change type, but it's a harmless change, and it will mean that on 64-bit systems there simply will be no limit any more. The only hassle that needed to be solved first was 64-bit support for JSON on win64, but that's done now. Richard, Stephan, how do you feel about this? Regards, Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] 64 bit rowid bug?
On Thu, Jun 20, 2013 at 4:01 PM, Jan Nijtmans jan.nijtm...@gmail.comwrote: Hm, I would suggest to change the return-type from i64 to size_t. On 32-bit systems that would double the maximum number of artifacts, *shiver* i've had nothing but problems when trying to rely on size_t across 32/64-bit portable apps. i recommend going one further and relying on C99's inttypes.h and stdint.h, which define fixed-size integers and their portable printf/scanf modifiers (as you saw when you patched cson). i use them in almost all of my code, even projects which are otherwise 100% C89. There is also a free (BSD) drop-in impl for MS C platforms (since MS doesn't do C99): http://code.google.com/p/msinttypes/ The only hassle that needed to be solved first was 64-bit support for JSON on win64, but that's done now. Careful - JSON itself does NOT specify integer precision, which means that just because fossil can now generate e.g. the value 140, doesn't mean that any given consumer on the other end can read it properly (or even fail predictably). The IETF is (right now) discussing (at length) a formal JSON standard and this topic has come up (i've been following the list chatter), but AFAIK there has been no consensus reached because it is impossible to enforce any given limits on any and all platforms. They can, at best, define how a JSON consumer has to deal with values which fall outside of its limits. Richard, Stephan, how do you feel about this? Personally i'm for inttypes.h and stdint.h, using fixed-size integers, and i've always been well-served by them, but if 100% portability to c89 is of a concern then it's not an option. (i tend to aim for c89 but am relatively ambivalent on the topic.) That said, sqlite3 also uses (long long) in one of its typedefs, though that type is not strict C89 (but is a common extension). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] 64 bit rowid bug?
2013/6/20 Stephan Beal sgb...@googlemail.com: On Thu, Jun 20, 2013 at 4:40 PM, Stephan Beal sgb...@googlemail.com wrote: *shiver* i've had nothing but problems when trying to rely on size_t across 32/64-bit portable apps. Sorry, i should have qualified that a bit better: problems not meaning segfaults and whatnot, but the fact that i can't get a printf() or scanf() to DTRT without explicit casts on one platform or the other. Fixed-size ints and standard format strings patch that all up (with one caveat being that there is no portable 64-bit format string for C_89_). Fossil does it's own printf-like formatting, so whatever solution chosen can be implemented consistantly. size_t is the simplest, with least impact on 32-bit systems. Making everything i64 is possible too, but Richard already remarked on that: Are you sure it is worth it? Careful - JSON itself does NOT specify integer precision, which means that just because fossil can now generate e.g. the value 140, doesn't mean that any given consumer on the other end can read it properly (or even fail I thought that javascript uses 64-bit floating-point for numbers internally, which means that integers up to 153 should be no problem for any compliant implementation. That's a lot more than 132. ! Regards, Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] 64 bit rowid bug?
2013/6/20 Richard Hipp d...@sqlite.org: Making this change will only introduce new, real bugs that impact everyday users. Thanks! That's OK with me. But then the question remains why the return-type of db_last_insert_rowid() is not int then? Regards, Jan Nijtmans. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Ticket [967cedbf20]: fossil extra - Report for subtree
+1 On Thu, Jun 20, 2013 at 6:26 AM, Stephan Beal sgb...@googlemail.com wrote: On Thu, Jun 20, 2013 at 9:26 AM, Jan Nijtmans jan.nijtm...@gmail.comwrote: I would like to see this feature request granted. Is there any objection to merging branch [ticket-967cedbf20] to trunk? :) Any chance of adding the same to ls as well? Side-note: the graph view in the www ui never ceases to impress me: http://fossil-scm.org/index.html/timeline?r=ticket-967cedbf20 -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Matt -=- 90% of the nations wealth is held by 2% of the people. Bummer to be in the majority... ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] 64 bit rowid bug?
On Thu, Jun 20, 2013 at 11:12 AM, Jan Nijtmans jan.nijtm...@gmail.comwrote: 2013/6/20 Richard Hipp d...@sqlite.org: Making this change will only introduce new, real bugs that impact everyday users. Thanks! That's OK with me. But then the question remains why the return-type of db_last_insert_rowid() is not int then? It now returns an int, and throws a fatal error if the last rowid() is negative or will not fit into an int. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
