Re: [fossil-users] unclustered vs private vs phantom and not syncing content
Thus said Andy Bradford on 12 Jul 2014 13:36:58 -0600: 2) The artifact rid was in the unclustered table, but when create_cluster() ran it prematurely removed it from the table. I have been able to successfully reproduce/cause this. When a large number of artifacts are being transfered, they produce phantoms on the server side of the sync operation. Eventually, the unclustered table grows large enough that create_cluster() starts cleaning house and building a new cluster artifact to replace all the entries in the unclustered table. Then it deletes everything that it didn't just create as part of creating clusters, including phantoms for which content has not yet arrived (most importantly a checkin artifact in which the manifest references a lot of other files). If no other artifacts reference the artifacts that were phantoms on the unclustered table, now deleted, then the content seemingly disappears to other clients that are trying to sync. If the content eventually gets incorporated in other manifests then it will eventually sync because they will discover the artifacts in those manifests, mark them as phantoms and then request them with gimme cards. This is most easily reproduced by simply doing this in a clone of a repository: $ jot 1500 | while read x; do dd if=/dev/urandom bs=1k count=1 | hexdump file.$x; done $ fossil ci -m bigupdate --branch big $ fossil up trunk $ echo $RANDOM file.1 $ fossil ci -m back Now, never merge in the ``big'' branch and clients that have previously cloned the server repository will never see the checkin to the branch unless they use --verily. Otherwise, if the branch is merged into trunk (or the checkin is edited and the branch closed), then suddenly it will appear to those clients (assuming those changes don't get deleted from the unclustered table first). For repositories that are very active, and have smallish commits, this won't likely ever present itself. I have confirmed that the change in the cluster-changes branch actually does correct this, but I would like to solicit other alternatives if anyone has any suggestions. Basically, I made Fossil ignore phantoms when deleting from the unclustered table: http://www.fossil-scm.org/index.html/vdiff?from=619fa857c9330c10to=5c6891b2ab10c4d0sbs=1 Suggestions? Thanks, Andy -- TAI64 timestamp: 400053ce2090 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] commits not seen on 2nd local worktree unless forcing initial commit
Hello, while toying around with Andy Bradford's fix/analysis, found something else, which seems related to the no-initial-commit feature which is recent default in trunk. (FWIW, I know there have been flaws in this area before, and although I am not a dev having/willing to deal with them, I agree with Jan that 'bugs happen', and a feature uncovering bugs or even introducing new ones is not necessarily bad for that reason alone, if it eventually results in a cleaner design. I don't know how well initial-commit-less repos work with older fossil-versions, but I assume that has been discussed or considered in detail elsewhere. /EUR0.02) Here are 2 typescripts; the first witout empty initial commit, and the latter with forced initial commit. Everything is cleaned up in between the 2 sessions. In both cases, a repo is created, and it is opened as-is in 2 workdirs. A file is then added in workdir 'b', and an update is done is workdir 'a'. In the first example, the update is not seen; in the 2nd example, everything is OK: ---( without initial commit: )--- /tmp$ mkdir f /tmp$ cd f /tmp/f$ f new f.f project-id: bf874a5a154d7e572d99464d602a42bcb0dcf4bf server-id: c9f88d8904cedc4b7932c7c9832c3db8b6760d74 admin-user: michai (initial password is 7dfb91) /tmp/f$ mkdir a b /tmp/f$ cd a /tmp/f/a$ f open ../f.f project-name: unnamed repository: /tmp/f/a/../f.f local-root: /tmp/f/a/ config-db:/home/michai/.fossil project-code: bf874a5a154d7e572d99464d602a42bcb0dcf4bf checkins: 0 /tmp/f/a$ cd ../b /tmp/f/b$ f open ../f.f project-name: unnamed repository: /tmp/f/b/../f.f local-root: /tmp/f/b/ config-db:/home/michai/.fossil project-code: bf874a5a154d7e572d99464d602a42bcb0dcf4bf checkins: 0 /tmp/f/b$ f tim +++ no more data (0) +++ /tmp/f/b$ date thefile /tmp/f/b$ f add thefile ADDED thefile /tmp/f/b$ f ci -m test thefile New_Version: c3450bfdff913112f6121b145540aa669d99e8eb /tmp/f/b$ cd ../a /tmp/f/a$ f up /tmp/f/a$ f tim === 2014-07-22 === 09:20:06 [c3450bfdff] test (user: michai tags: trunk) +++ no more data (1) +++ /tmp/f/a$ ls /tmp/f/a$ ---( with forced initial commit: )--- /tmp$ mkdir f /tmp$ cd f /tmp/f$ date Tue Jul 22 11:22:04 CEST 2014 /tmp/f$ f new --date-override 2014-01-01 f.f project-id: 1f87142730004196e2388d27d2514fd06e8d9539 server-id: b2b51507887bf5e0e0f9b899298f8d2ecc67c258 admin-user: michai (initial password is a1757a) /tmp/f$ mkdir a b /tmp/f$ cd a /tmp/f/a$ f open ../f.f project-name: unnamed repository: /tmp/f/a/../f.f local-root: /tmp/f/a/ config-db:/home/michai/.fossil project-code: 1f87142730004196e2388d27d2514fd06e8d9539 checkout: b58cc4d9818973107a8acba469dda6edd4ba9683 2014-01-01 00:00:00 UTC leaf: open tags: trunk comment: initial empty check-in (user: michai) checkins: 1 /tmp/f/a$ cd ../b /tmp/f/b$ f open ../f.f project-name: unnamed repository: /tmp/f/b/../f.f local-root: /tmp/f/b/ config-db:/home/michai/.fossil project-code: 1f87142730004196e2388d27d2514fd06e8d9539 checkout: b58cc4d9818973107a8acba469dda6edd4ba9683 2014-01-01 00:00:00 UTC leaf: open tags: trunk comment: initial empty check-in (user: michai) checkins: 1 /tmp/f/b$ date thefile /tmp/f/b$ f add thefile ADDED thefile /tmp/f/b$ f ci -m test thefile New_Version: 4b720ef5510056c9ab365389e1bed9a6af78004b /tmp/f/b$ cd ../a /tmp/f/a$ f up ADD thefile --- updated-to: 4b720ef5510056c9ab365389e1bed9a6af78004b 2014-07-22 09:22:41 UTC leaf: open tags: trunk comment: test (user: michai) changes: 1 file modified. fossil undo is available to undo changes to the working checkout. /tmp/f/a$ f tim === 2014-07-22 === 09:22:41 [4b720ef551] *CURRENT* test (user: michai tags: trunk) === 2014-01-01 === 00:00:00 [b58cc4d981] initial empty check-in (user: michai tags: trunk) +++ no more data (2) +++ /tmp/f/a$ ls thefile /tmp/f/a$ --- The order of opening/committing are important; if the commit from workdir 'b' happens before the repo is opened in workdir 'a', everything seems to work OK. In the 1st session (without initial empty commit), more commits can be done from dir 'b', but these are not seen when updating in dir 'a' afterwards. The timeline in workdir 'a' does show the commits. hth, Michai ___ 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] unclustered vs private vs phantom and not syncing content
On Tue, Jul 22, 2014 at 10:27 AM, Andy Bradford amb-fos...@bradfords.org wrote: Suggestions? Only one: Keep it up! That was impressive investigatory work! It seems to me that you've discovered that fossil does indeed (unintentionally) support a form of branch-specific sync ;). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ 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] commits not seen on 2nd local worktree unless forcing initial commit
On 22 July 2014 11:35, Michai Ramakers m.ramak...@gmail.com wrote: while toying around with Andy Bradford's fix/analysis, found something else, which seems related to the no-initial-commit feature which is recent default in trunk. ... of course, forgot something: This is fossil version 1.30 [619fa857c9] 2014-07-19 19:20:25 UTC (i.e. trunk of this moment) Michai ___ 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] commits not seen on 2nd local worktree unless forcing initial commit
On Tue, Jul 22, 2014 at 11:35 AM, Michai Ramakers m.ramak...@gmail.com wrote: (FWIW, I know there have been flaws in this area before, and although I am not a dev having/willing to deal with them, I agree with Jan that AFAIR i reverted that to not be the default behaviour (IMO it should not be because it's a long-standing historical behaviour and we don't fully know the implications of removing it). results in a cleaner design. I don't know how well initial-commit-less repos work with older fossil-versions, but I assume that has been discussed or considered in detail elsewhere. /EUR0.02) LOL! Late last year Jan and i discussed it a bit (not at length) after i started experimenting with it in libfossil and was curious if fossil could support it. Jan was the only one brave/gutsy enough to try it out! i knew from having ported over so many algos from fossil that there were numerous corner cases, assumptions, and assertions that expected the initial RID to be in place, but those were just historical coding decisions - nothing in the architecture specifically (or implicitly) prohibits an empty repo. The bugs we've seen since introducing empty repos have been patching up former assumptions which are not true in the empty-repo case. ---( without initial commit: )--- ... /tmp/f/a$ f up /tmp/f/a$ f tim === 2014-07-22 === 09:20:06 [c3450bfdff] test (user: michai tags: trunk) +++ no more data (1) +++ /tmp/f/a$ ls /tmp/f/a$ ---( with forced initial commit: )--- Tue Jul 22 11:22:04 CEST 2014 Same time zone :) ... ... fossil undo is available to undo changes to the working checkout. /tmp/f/a$ f tim === 2014-07-22 === 09:22:41 [4b720ef551] *CURRENT* test (user: michai tags: trunk) === 2014-01-01 === 00:00:00 [b58cc4d981] initial empty check-in (user: michai tags: trunk) +++ no more data (2) +++ (That last line is a little confusing, IMO. Almost looks like an error.) The order of opening/committing are important; if the commit from workdir 'b' happens before the repo is opened in workdir 'a', everything seems to work OK. In the 1st session (without initial empty commit), more commits can be done from dir 'b', but these are not seen when updating in dir 'a' afterwards. The timeline in workdir 'a' does show the commits. i think i'm going to wait for Andy's response, rather than try to wrap my head around that ;). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ 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] commits not seen on 2nd local worktree unless forcing initial commit
On Tue, Jul 22, 2014 at 11:37 AM, Michai Ramakers m.ramak...@gmail.com wrote: of course, forgot something: This is fossil version 1.30 [619fa857c9] 2014-07-19 19:20:25 UTC (i.e. trunk of this moment) Good man :). FWIW, as a note to those who generally like to use officially released versions - the majority of us work directly from trunk (or our various branches) all of the time, and AFAIK none of us have ever lost any data nor otherwise seriously broken anything. If you have the option of working from the trunk, IMO that's a better idea that waiting on official releases, as we tend to only do those once the feature/bugfix list has grown to some appreciable length. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Curses! (foiled again?)
Hi, all, for some reason i cannot explain, i've always been fascinated by that absolutely horrible API known as curses (specifically, the every so slightly more modern ncurses). Curses is difficult to work with and has some of the worst API naming conventions one can imagine, but there's something entrancing about it, as if it was embedded in my DNA 1000 generations back. i can't help it. AFAIK, i was the first person to write JavaScript bindings for ncurses: http://spiderape.sourceforge.net/screenshots/ and now i'm struggling with the decision of how best to go about doing something similar for the libfossil script bindings. There is one big design decision which needs to be answered, and i'm looking for input from those familiar with curses APIs: a) port the low-level API 1-to-1 (some semantics differences are needed for script-space, but nothing too weird) b) supply only a higher-level API and hide the atrocious low-level API behind it? The advantage of (A) is that one can always open up their local man pages to see how a given API works (so (A) would keep the original (cryptic) API names). Likewise, that's the main disadvantage of (B): users familiar with curses would need to learn a new API and might find a higher-level API too limiting. OTOH, the curses API (a standard, btw) is pretty ugly and difficult to use properly, which almost begs for solution (B). i'm aware of the CDK (Curses Development Kit), and CDK is a Good Thing, but i'm hesitant to wrap it because then i'm stuck with that API (which i have never used). Opinions? -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ 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] unclustered vs private vs phantom and not syncing content
On 22 July 2014 10:27, Andy Bradford amb-fos...@bradfords.org wrote: Thus said Andy Bradford on 12 Jul 2014 13:36:58 -0600: 2) The artifact rid was in the unclustered table, but when create_cluster() ran it prematurely removed it from the table. I have been able to successfully reproduce/cause this. When a large number of artifacts are being transfered, they produce phantoms on the server side of the sync operation. Eventually, the unclustered table grows large enough that create_cluster() starts cleaning house and building a new cluster artifact to replace all the entries in the unclustered table. Then it deletes everything that it didn't just create as part of creating clusters, including phantoms for which content has not yet arrived (most importantly a checkin artifact in which the manifest references a lot of other files). If no other artifacts reference the artifacts that were phantoms on the unclustered table, now deleted, then the content seemingly disappears to other clients that are trying to sync. If the content eventually gets incorporated in other manifests then it will eventually sync because they will discover the artifacts in those manifests, mark them as phantoms and then request them with gimme cards. This is most easily reproduced by simply doing this in a clone of a repository: $ jot 1500 | while read x; do dd if=/dev/urandom bs=1k count=1 | hexdump file.$x; done $ fossil ci -m bigupdate --branch big $ fossil up trunk $ echo $RANDOM file.1 $ fossil ci -m back Now, never merge in the ``big'' branch and clients that have previously cloned the server repository will never see the checkin to the branch unless they use --verily. Otherwise, if the branch is merged into trunk (or the checkin is edited and the branch closed), then suddenly it will appear to those clients (assuming those changes don't get deleted from the unclustered table first). Thank you for the effort, this is or has been a long-standing issue indeed. I can't seem to reproduce what you describe - either that, or I'm missing the point (did you mean 'merge' as in 'fossil merge'?). I'm assuming you left out 'fossil add' (or 'addremove') twice in your example. I tried your example on a single host, hopefully to exclude complexity added by any physical network. (Do you think it's necessary to use 2 different hosts to reproduce the issue like you described?) I cloned using http:// before adding files, and then updated from within the cloned repo's workdir. (I can see the artifacts being received on the cloned repo's side, so I guess the attempt really ends there.) Longish typescript follows: --- michai@main:/fossils$ f ver This is fossil version 1.30 [619fa857c9] 2014-07-19 19:20:25 UTC michai@main:/fossils$ grep fossil /etc/inetd.conf http stream tcp nowait.1000 root /usr/local/bin/f /usr/local/bin/f http /fossils michai@main:/fossils$ f new --date-override 2014-01-01 ab.fossil project-id: e0b53c254d86b6445060df9c65a9017134b348db server-id: c72a02a0849d982ca8066b812521a1f7cde187af admin-user: michai (initial password is 794d90) michai@main:/fossils$ mkdir f michai@main:/fossils$ cd f michai@main:/fossils/f$ f open ../ab.fossil project-name: unnamed repository: /fossils/f/../ab.fossil local-root: /fossils/f/ config-db:/home/michai/.fossil project-code: e0b53c254d86b6445060df9c65a9017134b348db checkout: b58cc4d9818973107a8acba469dda6edd4ba9683 2014-01-01 00:00:00 UTC leaf: open tags: trunk comment: initial empty check-in (user: michai) checkins: 1 michai@main:/fossils/f$ pushd /tmp /tmp /fossils/f michai@main:/tmp$ mkdir f michai@main:/tmp$ cd f michai@main:/tmp/f$ f clone http://localhost/ab ab.fossil Round-trips: 1 Artifacts sent: 0 received: 0 Round-trips: 1 Artifacts sent: 0 received: 1 Round-trips: 2 Artifacts sent: 0 received: 1 Round-trips: 2 Artifacts sent: 0 received: 3 Clone finished with 461 bytes sent, 1155 bytes received Rebuilding repository meta-data... 0.0% complete... 100.0% complete... project-id: e0b53c254d86b6445060df9c65a9017134b348db server-id: 25482d35a0445e5710395d12423b421e90b9f4be admin-user: michai (password is e4a7ef) michai@main:/tmp/f$ mkdir f michai@main:/tmp/f$ cd f michai@main:/tmp/f/f$ f open ../ab.fossil project-name: unnamed repository: /tmp/f/f/../ab.fossil local-root: /tmp/f/f/ config-db:/home/michai/.fossil project-code: e0b53c254d86b6445060df9c65a9017134b348db checkout: b58cc4d9818973107a8acba469dda6edd4ba9683 2014-01-01 00:00:00 UTC leaf: open tags: trunk comment: initial empty check-in (user: michai) checkins: 1 michai@main:/tmp/f/f$ popd /fossils/f michai@main:/fossils/f$ cat /tmp/f.sh #!/bin/sh jot 1500 | while read x; do dd if=/dev/urandom bs=1k count=1 | hexdump file.$x; done f addr f ci -m bigupdate --branch big f up trunk echo $RANDOM file.1 f add file.1 f ci -m back
Re: [fossil-users] commits not seen on 2nd local worktree unless forcing initial commit
On 22 July 2014 11:48, Stephan Beal sgb...@googlemail.com wrote: On Tue, Jul 22, 2014 at 11:35 AM, Michai Ramakers m.ramak...@gmail.com wrote: (FWIW, I know there have been flaws in this area before, and although I am not a dev having/willing to deal with them, I agree with Jan that AFAIR i reverted that to not be the default behaviour (IMO it should not be because it's a long-standing historical behaviour and we don't fully know the implications of removing it). right, I remember, but I think for the purpose of weeding out bugs there, it became default again: http://fossil-scm.org/index.html/info/8364065c45ec839d01e0a0535ebd754f81e9cac4 ... fossil undo is available to undo changes to the working checkout. /tmp/f/a$ f tim === 2014-07-22 === 09:22:41 [4b720ef551] *CURRENT* test (user: michai tags: trunk) === 2014-01-01 === 00:00:00 [b58cc4d981] initial empty check-in (user: michai tags: trunk) +++ no more data (2) +++ (That last line is a little confusing, IMO. Almost looks like an error.) the '00:00:00'? That's because of the 'fossil new --date-override 2014-01-01' (e.g. fake initial commit well in the past). Michai ___ 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] commits not seen on 2nd local worktree unless forcing initial commit
On Tue, Jul 22, 2014 at 12:50 PM, Michai Ramakers m.ramak...@gmail.com wrote: there, it became default again: http://fossil-scm.org/index.html/info/8364065c45ec839d01e0a0535ebd754f81e9cac4 Ah, i missed that. 00:00:00 [b58cc4d981] initial empty check-in (user: michai tags: trunk) +++ no more data (2) +++ (That last line is a little confusing, IMO. Almost looks like an error.) the '00:00:00'? That's because of the 'fossil new --date-override 2014-01-01' (e.g. fake initial commit well in the past). Doh - didn't even notice that. i meant the no more data (2). After reading it 3 times i understand what it means, but it's not obvious. i have never noticed it because i've been using f-timeline (from libfossil) since last summer ;). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ 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] Curses! (foiled again?)
Stephan Beal sgb...@googlemail.com writes: Curses is difficult to work with and has some of the worst API naming conventions one can imagine, but there's something entrancing about it, as if it was embedded in my DNA 1000 generations back. i can't help it. Have you ever thought about termbox: https://code.google.com/p/termbox/ ? Sincerely, Gour -- The work of a man who is unattached to the modes of material nature and who is fully situated in transcendental knowledge merges entirely into transcendence. ___ 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] Curses! (foiled again?)
On Tue, Jul 22, 2014 at 12:54 PM, Gour g...@atmarama.net wrote: Have you ever thought about termbox: https://code.google.com/p/termbox/ ? Wasn't aware of it until now, but i am certainly looking at it now. Thanks! -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ 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] Curses! (foiled again?)
On Tue, Jul 22, 2014 at 12:58 PM, Stephan Beal sgb...@googlemail.com wrote: On Tue, Jul 22, 2014 at 12:54 PM, Gour g...@atmarama.net wrote: Have you ever thought about termbox: https://code.google.com/p/termbox/ ? Wasn't aware of it until now, but i am certainly looking at it now. Thanks! MUCH easier than curses, it would seem, and a wider range of display colors. Isn't as portable, but it only needs to be portable to Unix platforms. It doesn't appear to support anything but cell-level modifications (no higher level structs like curses PAD), but it seems to have enough that it would be easy to build such things on top of it. And only 12 functions in its API! Compare that with over 200 in curses! Even handles terminal resizing. Thanks again, Gour! -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ 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] Curses! (foiled again?)
Stephan Beal sgb...@googlemail.com writes: MUCH easier than curses, it would seem, and a wider range of display colors. Isn't as portable, but it only needs to be portable to Unix platforms. I plan to possibly use it with Go (language). And only 12 functions in its API! Compare that with over 200 in curses! Even handles terminal resizing. Thanks again, Gour! Well, Fossil spoils one with simplicity power. ;) Sincerely, Gour -- A person is said to be elevated in yoga when, having renounced all material desires, he neither acts for sense gratification nor engages in fruitive activities. ___ 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] Curses! (foiled again?)
On Tue, Jul 22, 2014 at 1:54 PM, Gour g...@atmarama.net wrote:
Well, Fossil spoils one with simplicity power. ;)
Indeed, it has been trivial so far:
[stephan@host:~/cvs/fossil/cwal/s2]$ cat tb.s2
const tb = s2.loadModule2('mod_termbox').termbox;
tb.init();
s2.time.sleep(3);
tb.shutdown();
[stephan@host:~/cvs/fossil/cwal/s2]$ ./s2sh tb.s2
[stephan@host:~/cvs/fossil/cwal/s2]$
That blanks the screen, sleeps 3 seconds, then returns the terminal to
normal. It took all of about 12 minutes to implement, 2 of which was
writing Makefile code and 3 of which was filing a termbox bug:
http://code.google.com/p/termbox/issues/detail?id=7
Still 10 functions left to bind.
My query regarding curses is officially closed. Termbox is much more
interesting :).
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do. -- Bigby Wolf
___
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] Curses! (foiled again?)
On Tue, 22 Jul 2014 13:54:25 +0200 Gour g...@atmarama.net wrote: MUCH easier than curses, it would seem, and a wider range of display colors. Isn't as portable, but it only needs to be portable to Unix platforms. I plan to possibly use it with Go (language). FWIW, there's a popular minimal support library for full-screen terminal applications for Go called termbox [1]. It's cross-platform (it means POSIX and Windows) and is pure Go. I mean, if you're about writing some full-screen terminal front-end for Fossil in Go it might be simpler to use termbox. 1. http://godoc.org/github.com/nsf/termbox-go ___ 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] Curses! (foiled again?)
On Tue, Jul 22, 2014 at 3:21 PM, Konstantin Khomoutov
flatw...@users.sourceforge.net wrote:
1. http://godoc.org/github.com/nsf/termbox-go
And we're halfway to one in s2 (which means, by extension, libfossil):
const tb = s2.loadModule2('mod_termbox').termbox,
sleep = s2.time.sleep;
tb.init();
var dims, currentInputMode, currentOutputMode;
var ex = catch {
currentInputMode = tb.inputMode(tb.inputMode.CURRENT);
currentOutputMode = tb.outputMode(tb.outputMode.CURRENT);
dims = {w: tb.width(), h:tb.height() };
tb.setCursor(0,0);
tb.present();
sleep(1);
tb.setCursor();
tb.present();
sleep(1);
};
tb.shutdown();
ex (throw ex) || unset ex;
print(dims);
print(Output mode:,currentOutputMode, modes:);
tb.outputMode.eachProperty(print);
print(Input modes:, currentInputMode, modes:);
tb.inputMode.eachProperty(print);
[stephan@host:~/cvs/fossil/cwal/s2]$ ./s2sh tb.s2
{h: 37, w: 145}
Output mode: 1 modes:
GRAYSCALE 4
216 3
256 2
NORMAL 1
CURRENT 0
Input modes: 1 modes:
ALT 2
ESC 1
CURRENT 0
:-D
Thanks again, Gour, for saving me the headache of doing yet another curses
binding!
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do. -- Bigby Wolf
___
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] Curses! (foiled again?)
Stephan Beal sgb...@googlemail.com writes: Thanks again, Gour, for saving me the headache of doing yet another curses binding! Well, ncurses are simply not human, so next time I'd gladly recommend against it with clear conscience. ;:) Sincerely, Gour -- One who restrains the senses of action but whose mind dwells on sense objects certainly deludes himself and is called a pretender. http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 ___ 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] Curses! (foiled again?)
Konstantin Khomoutov flatw...@users.sourceforge.net writes: I mean, if you're about writing some full-screen terminal front-end for Fossil in Go it might be simpler to use termbox. 1. http://godoc.org/github.com/nsf/termbox-go Yeah, I was thinking about that one. Not sure if I'd write full app with it 'cause I plan to write multi-platform GUI app, but termbox looks interesesting to be used while testing different libs to be written before main app. Sincerely, Gour -- Whenever and wherever there is a decline in religious practice, O descendant of Bharata, and a predominant rise of irreligion — at that time I descend Myself. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] 'open --nested', quick poll
Hello, I was wondering how many of you use 'open --nested' to have nested workdirs? A bit of background: A long time ago I asked here how/why/if people divided multiple-target project-trees into repos; some (like me) use one big repo for all, and some use many small repos. So this is not a real question let alone a fossil-specific one... Reason for asking is that I sometimes find myself going through changes between releases, and since I develop almost everything on trunk, the timeline-change overview between 'doc X version N' and 'doc X version N+1' so to say (each being tags) is naturally peppered with changes to other parts of the workdir, e.g. source, reference-material, pictures, whatnot. There was talk of giving the '/timeline' page something like a 'glob=' parameter a while ago, filtering out unwanted stuff. That would make going over diffs easier, but since the result would not be a consistent timeline anymore, I wonder if this would be a good idea, and whether my workflow is not fundamentally flawed. So... development of each target into its own branch (where branches could have contents in mutually exclusive dirs, e.g. 'docs', 'src', ...) is perhaps an option, or using different repos altogether, be it in nested workdirs or not? Ideas are welcome - assuming the above makes a bit sense, Michai ___ 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] 'open --nested', quick poll
On Tue, Jul 22, 2014 at 4:38 PM, Michai Ramakers m.ramak...@gmail.com wrote: I was wondering how many of you use 'open --nested' to have nested workdirs? nope A long time ago I asked here how/why/if people divided multiple-target project-trees into repos; some (like me) use one big repo for all, and some use many small repos. tend towards small ones, but most provide amalgamation-style builds which i then import into others as-is into other projects. So this is not a real question let alone a fossil-specific one... Reason for asking is that I sometimes find myself going through changes between releases, and since I develop almost everything on trunk, the timeline-change overview between 'doc X version N' and 'doc X version N+1' so to say (each being tags) is naturally peppered with changes to other parts of the workdir, e.g. source, reference-material, pictures, whatnot. One advantage of importing amalgamation builds (like sqlite's) is that each project is free to update or not, regardless of changes in the upstream (or embedded) repo. There was talk of giving the '/timeline' page something like a 'glob=' parameter a while ago, filtering out unwanted stuff. That would make going over diffs easier, but since the result would not be a consistent timeline anymore, I wonder if this would be a good idea, and whether my workflow is not fundamentally flawed. It's not flawed if it works for you, but you seem to place a lot of value on some of the more rarely used [by me!] features. e.g. file ages. So... development of each target into its own branch (where branches could have contents in mutually exclusive dirs, e.g. 'docs', 'src', ...) is perhaps an option, or using different repos altogether, be it in nested workdirs or not? i am ambivalent. Whatever works for your project. i can't say that i've ever liked using external repos, e.g. in subversion. i prefer to import external projects in amalgamation form or, if there is no amalgamation form, as-is (in some buildable form). The idea of having an upstream dependency which is automatically injected for me when it updates bugs me, but i'm probably in the minority on that. In Java development that's basically what 'mvn' does for the developer, and it seems to work well there. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ 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] unclustered vs private vs phantom and not syncing content
Thus said Michai Ramakers on Tue, 22 Jul 2014 12:35:03 +0200: I can't seem to reproduce what you describe - either that, or I'm missing the point (did you mean 'merge' as in 'fossil merge'?). I'm assuming you left out 'fossil add' (or 'addremove') twice in your example. Yes, I left out a few steps (sorry). It was assumed that the 1500 files already exist in the repository and the changes are just updates (but essentially a 100% rewrite of the file due to the randomness). Also, the entire lump of changes has to be large enough that max-download comes into play and there are multiple sync operations that occur as a result during the checkin. I don't think it matters whether these are new files or modified files (I just used edits because I was trying multiple variations), so after generating all the files, you could do ``fossil addremove'' to get the big change set. I tried your example on a single host, hopefully to exclude complexity added by any physical network. (Do you think it's necessary to use 2 different hosts to reproduce the issue like you described?) I cloned using http:// before adding files, and then updated from within the cloned repo's workdir. More steps I left out... No, I did this all on one host. I created the repo and started fossil server with the repo. Then I cloned it 2 times. In one clone I made the changes and then after the last checkin, I did an update in the second clone. It never received the artifact for the checkin (because it wasn't on the unclustered artifact and not mentioned in any other manifests). Also, as far as the Fossil version is concerned, though I think any should suffice, I was using [619fa857c933]. Thanks for attempting to confirm the problem. Andy -- TAI64 timestamp: 400053ce837e ___ 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] File contains invalid UTF-8, but is not UTF-8.
On Tue, Jul 8, 2014 at 9:37 PM, Stephan Beal sgb...@googlemail.com wrote: No characters between 128 and 255 are valid UTF-8, to avoid confusion with the many encodings which use that range. For the record, that's apparently wrong. My local man pages (and experimentation with the termbox API) say otherwise: Encoding The following byte sequences are used to represent a character. The sequence to be used depends on the UCS code number of the character: 0x - 0x007F: 0xxx 0x0080 - 0x07FF: 110x 10xx So the range is used, but it encodes to two UTF-8 characters. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ 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] unclustered vs private vs phantom and not syncing content
On 22 July 2014 17:29, Andy Bradford amb-fos...@bradfords.org wrote: Thus said Michai Ramakers on Tue, 22 Jul 2014 12:35:03 +0200: I can't seem to reproduce what you describe - either that, or I'm missing the point (did you mean 'merge' as in 'fossil merge'?). I'm assuming you left out 'fossil add' (or 'addremove') twice in your example. Yes, I left out a few steps (sorry). It was assumed that the 1500 files already exist in the repository and the changes are just updates (but essentially a 100% rewrite of the file due to the randomness). Also, the entire lump of changes has to be large enough that max-download comes into play and there are multiple sync operations that occur as a result during the checkin. I don't think it matters whether these are new files or modified files (I just used edits because I was trying multiple variations), so after generating all the files, you could do ``fossil addremove'' to get the big change set. I tried your example on a single host, hopefully to exclude complexity added by any physical network. (Do you think it's necessary to use 2 different hosts to reproduce the issue like you described?) I cloned using http:// before adding files, and then updated from within the cloned repo's workdir. More steps I left out... No, I did this all on one host. I created the repo and started fossil server with the repo. Then I cloned it 2 times. In one clone I made the changes and then after the last checkin, I did an update in the second clone. It never received the artifact for the checkin (because it wasn't on the unclustered artifact and not mentioned in any other manifests). Also, as far as the Fossil version is concerned, though I think any should suffice, I was using [619fa857c933]. ahh, right :-) Now everything works (breaks) perfectly. I tried to mimic the actual situation I had earlier (http://lists.fossil-scm.org:8080/pipermail/fossil-users/2013-August/013629.html), except on 1 host like you suggest, using 2 clones. I don't / didn't use branches other than trunk (which still breaks, using your example - good). Effectively committed the 1500 files onto trunk from within the 1st clone's workdir, and didn't follow it by an additional commit. Sync from within the 2nd clone's workdir received iirc 161 out of approx 1500 artifacts, after which the timeline didn't show the commit. Following that by a single added/committed file from within the 1st clone's workdir again, and a sync from within the 2nd clone's workdir, retrieved everything up to and including the last single-file commit. So... this seems exactly what I saw happen here at that time; thx again for the effort, I'm very happy this seems pinpointed! Michai ___ 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] unclustered vs private vs phantom and not syncing content
Thus said Michai Ramakers on Tue, 22 Jul 2014 17:58:24 +0200: I don't / didn't use branches other than trunk (which still breaks, using your example - good). Yes, this should work with trunk as long as there are no commits that follow the one which caused the exclusion of artifacts from clusters, as you mentioned. Following that by a single added/committed file from within the 1st clone's workdir again, and a sync from within the 2nd clone's workdir, retrieved everything up to and including the last single-file commit. In this case, the artifact is indirectly available through other manifests which get picked up and then pulled, but not through any cluster artifacts. Thanks, Andy -- TAI64 timestamp: 400053ce8e79 ___ 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] 'open --nested', quick poll
On Tue, Jul 22, 2014 at 10:38 AM, Michai Ramakers m.ramak...@gmail.com wrote: Hello, I was wondering how many of you use 'open --nested' to have nested workdirs? I have used it on MS Windows on a few occasions where I might otherwise have used symbolic links (Yes, I know that modern versions of Windows support symlinks, but I was getting eros from the command so I just did nested check outs instead.) Mostly I use one repo per project, but most of my utility programs and scripts are in 1 project I call Tools and so are in all in 1 repo. ___ 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] 'open --nested', quick poll
On 7/22/2014 10:22, Ron W wrote: Yes, I know that modern versions of Windows support symlinks, but I was getting eros from the command so I just did nested check outs instead. Native symlinks on Windows are a mess. First, the mklink command has its options in reverse order as compared to ln(1). And if your response to that is to shrug it off as just an unimportant cosmetic choice, observe that the ln(1) option order is the same as the cp(1) option order, which is the order copied by DOS's copy command. So yeah, mklink is objectively *backwards*. The second annoying mklink restriction -- and the one that probably bit you -- is that you not only have to be in the Administrators group to run it, you have to do so from an elevated command shell. If you're using Cygwin on Windows, it's a whole lot easier to just use its emulated symlink mechanism. As for the poll, I've never used --nested, but I'm a Fossil newbie, so let that count for a quarter vote at most. ___ 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] 'open --nested', quick poll
On 7/22/2014 10:43, Warren Young wrote: the mklink command has its options in reverse order I shouldn't say option here. I mean the two path names you have to give to both mklink and ln: $ ln source symlink-target C:\ mklink symlink-target source ___ 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] File contains invalid UTF-8, but is not UTF-8.
On Tue, Jul 22, 2014 at 11:48 AM, Stephan Beal sgb...@googlemail.com wrote: On Tue, Jul 8, 2014 at 9:37 PM, Stephan Beal sgb...@googlemail.com wrote: No characters between 128 and 255 are valid UTF-8, to avoid confusion with the many encodings which use that range. For the record, that's apparently wrong. My local man pages (and experimentation with the termbox API) say otherwise: So the range is used, but it encodes to two UTF-8 characters. Actually, 1 Unicode character encoded in to 2 UTF-8 bytes. FWIW, FYI, UTF-8 has an optional Byte Order Mark, 0xEF 0xBB 0xBF,that can appear at the beginning of a file. This just the UTF-8 encoding of code point U-00FEFF, which is the actual Unicode Byte Order Mark. For UTF-8, this mark is really only useful as a suggestion that the following text might be UFT-8 encoded Unicode. For UFT-16 and UTF-32 encodings, this mark is used to inform the receiver of the text the order of bytes within the 16 or 32 bit encoding units (presuming that the file is actually UTF-16 or 32 encoded text). ___ 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] Curses! (foiled again?)
On Tue, Jul 22, 2014 at 3:29 PM, Stephan Beal sgb...@googlemail.com wrote:
On Tue, Jul 22, 2014 at 3:21 PM, Konstantin Khomoutov
flatw...@users.sourceforge.net wrote:
1. http://godoc.org/github.com/nsf/termbox-go
And we're halfway to one in s2 (which means, by extension, libfossil):
For completeness:
Done! Example script:
http://fossil.wanderinghorse.net/repos/cwal/index.cgi/finfo?name=s2/mod_termbox.s2
[stephan@host:~/cvs/fossil/cwal/s2]$ ./s2sh mod_termbox.s2
interactive session snipped
tb.attr = {bold: 256, default: 0, reverse: 1024, underline: 512}
tb.colors = {black: 1, blue: 5, cyan: 7, default: 0, green: 3,
magenta: 6, red: 2, white: 8, yellow: 4}
Output mode: 1 modes:
GRAYSCALE 4
216 3
256 2
NORMAL 1
CURRENT 0
Input mode: 2 modes:
ALT 2
ESC 1
CURRENT 0
Summary of termbox: fairly low-level, but infinitely simpler than. However,
to be really useful it needs:
a) some higher-level APIs like box/panel management. It only recognizes one
window/screen element, and provides no APIs to store the current screen
state, so creating panels and whatnot requires getting their z-ordering
correct and (potentially) rendering everything from the bottom up. i.e. a
lot of the optimizations curses already does.
b) a key mapping/dispatching mechanism. This is easier to do from script
space than C, though.
c) higher-level widgets like string input. That gets complex quickly if you
want to support any basic line editing.
So there's still lots of higher-level work to do before it can be really
useful, but it provides most of the low-level bits UIs need.
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do. -- Bigby Wolf
___
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] Curses! (foiled again?)
Stephan Beal sgb...@googlemail.com writes: c) higher-level widgets like string input. That gets complex quickly if you want to support any basic line editing. Have you seen https://github.com/nsf/godit - text editor? Sincerely, Gour -- Even the intelligent are bewildered in determining what is action and what is inaction. Now I shall explain to you what action is, knowing which you shall be liberated from all misfortune. ___ 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] Curses! (foiled again?)
On Tue, Jul 22, 2014 at 7:33 PM, Gour g...@atmarama.net wrote: Have you seen https://github.com/nsf/godit - text editor? i hadn't until now. It seems he implemented all of those features in script code. i was hoping someone had written them in C already. Maybe the time i saved wrapping termbox (only heard about it 6 hours ago) over curses (would have taken several days) can be invested in some widgets. But first i need a windowing/paneling system, so that's my first step... -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ 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] Curses! (foiled again?)
On Tue, Jul 22, 2014 at 10:56 AM, Stephan Beal sgb...@googlemail.com wrote: On Tue, Jul 22, 2014 at 7:33 PM, Gour g...@atmarama.net wrote: Have you seen https://github.com/nsf/godit - text editor? i hadn't until now. It seems he implemented all of those features in script code. i was hoping someone had written them in C already. Maybe the time i saved wrapping termbox (only heard about it 6 hours ago) over curses (would have taken several days) can be invested in some widgets. But first i need a windowing/paneling system, so that's my first step... Having heard about termbox only through this thread I just had a quick look over the API ... The blit() function seems to be the core for windowing, copying a cell-rectangle into the main termbox buffer. Have a display-list of windows = rectangles, and blit() them into the main buffer, from back to front before presenting the result. Missing features to help with this - Can't blit() rect's out of the main buffer (to save state, before blitting in a modal window, for example) - Can't redirect the put()/change() APIs to work on rect's outside of the main buffer. Still, something to keep track off. Might be interesting to see how it meshes with linenoise. -- Andreas Kupries Senior Tcl Developer Code to Cloud: Smarter, Safer, Faster™ F: 778.786.1133 andre...@activestate.com http://www.activestate.com Learn about Stackato for Private PaaS: http://www.activestate.com/stackato EuroTcl'2014, July 12-13, Munich, GER -- http://www.eurotcl.tcl3d.org/ 21'st Tcl/Tk Conference: Nov 10-14, Portland, OR, USA -- http://www.tcl.tk/community/tcl2014/ Send mail to tclconfere...@googlegroups.com, by Sep 8 Registration is open. ___ 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] Curses! (foiled again?)
On Tue, Jul 22, 2014 at 8:21 PM, Andreas Kupries andre...@activestate.com wrote: Having heard about termbox only through this thread I just had a quick look over the API ... The blit() function seems to be the core for windowing, copying a cell-rectangle into the main termbox buffer. Have a display-list of windows = rectangles, and blit() them into the main buffer, from back to front before presenting the result. It currently looks like that's the approach i'll need to take. i'll first need a Window class where i can store the necessary bits for each window and keep track of child windows for GC purposes, but that won't be hard to do. Missing features to help with this - Can't blit() rect's out of the main buffer (to save state, before blitting in a modal window, for example) i (coincidentally) emails the author asking about the ability to save/restore blocks. No answer yet, but it was only an hour or so ago. Looking at the godit link from Gour, it seems it is indeed possible to implement multi-windowing, popup window support, etc., using only the available APIs. See the screenshots - it looks a lot like emacs and is implemented in go: https://github.com/nsf/godit - Can't redirect the put()/change() APIs to work on rect's outside of the main buffer. That's where the Window class (fairly analog to a curses Window) would come in. It would need its own variants which translate the coordinates into the global (stdscr) space. The fact that there's only one output routine (tb_change_cell(); tb_put_cell() is just a convenience wrapper around that one) should mean that higher-level code has to wrap less stuff. In curses there are many routines which have to be specialized for windows vs pads vs panel. BTW: termbox got the coordinates right: (x,y) instead of (y,x). Curses is dead. Long live curses. Still, something to keep track off. Might be interesting to see how it meshes with linenoise. termbox provides all the low-level bits you'd need to implement linenoise-like editing, but it would be a bit of work to do, at least in C - might be easier in script code. Speaking of: it took me all of a couple hours to bind the 12-or-so functions to script space, and i'm quite certain you could implement a TCL module for it faster than that. My point is only - in the off chance that you want to experiment with it, doing so would not require a huge time sink. Will post screenshots if/when i've got something interesting to show. The core API binding is finished (plus a few extras, e.g. clearing the screen using given fg/bg attributes), but i'm not yet sure if i'm in the mood to hack on it further tonight. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ 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] Curses! (foiled again?)
On Tue, Jul 22, 2014 at 11:45 AM, Stephan Beal sgb...@googlemail.com wrote: On Tue, Jul 22, 2014 at 8:21 PM, Andreas Kupries andre...@activestate.com wrote: i (coincidentally) emails the author asking about the ability to save/restore blocks. No answer yet, but it was only an hour or so ago. Heh. Looking at the godit link from Gour godit seems to be from the same person as termbox, and termbox-go. , it seems it is indeed possible to implement multi-windowing, popup window support, etc., using only the available APIs. See the screenshots - it looks a lot like emacs and is implemented in go: https://github.com/nsf/godit - Can't redirect the put()/change() APIs to work on rect's outside of the main buffer. That's where the Window class (fairly analog to a curses Window) would come in. It would need its own variants which translate the coordinates into the global (stdscr) space. Not necessarily. If the operations are done on the window buffer itself no transform is required. It happens implicitly when the window buffer is blitted into the main for presentation. The fact that there's only one output routine (tb_change_cell(); tb_put_cell() is just a convenience wrapper around that one) should mean that higher-level code has to wrap less stuff. In curses there are many routines which have to be specialized for windows vs pads vs panel. BTW: termbox got the coordinates right: (x,y) instead of (y,x). Curses is dead. Long live curses. Still, something to keep track off. Might be interesting to see how it meshes with linenoise. termbox provides all the low-level bits you'd need to implement linenoise-like editing, but it would be a bit of work to do, at least in C - might be easier in script code. Speaking of: it took me all of a couple hours to bind the 12-or-so functions to script space, and i'm quite certain you could implement a TCL module for it faster than that. Heh. Yes, after looking at termbox my first thought was that it should be easy to make a low-level binding for it with critcl. My point is only - in the off chance that you want to experiment with it, doing so would not require a huge time sink. True. Will post screenshots if/when i've got something interesting to show. The core API binding is finished (plus a few extras, e.g. clearing the screen using given fg/bg attributes), but i'm not yet sure if i'm in the mood to hack on it further tonight. Have fun. (The world is currently not so funny right now :( ) -- Andreas Kupries Senior Tcl Developer Code to Cloud: Smarter, Safer, Faster™ F: 778.786.1133 andre...@activestate.com http://www.activestate.com Learn about Stackato for Private PaaS: http://www.activestate.com/stackato EuroTcl'2014, July 12-13, Munich, GER -- http://www.eurotcl.tcl3d.org/ 21'st Tcl/Tk Conference: Nov 10-14, Portland, OR, USA -- http://www.tcl.tk/community/tcl2014/ Send mail to tclconfere...@googlegroups.com, by Sep 8 Registration is open. ___ 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] 'open --nested', quick poll
NOTE: In Unix there is the handy shortcut that you can leave off the target location: ln -s foo/bar will create the link: bar - foo/bar Quite handy and yet another reason for the parameter ordering used on Linux/Unix. On Tue, Jul 22, 2014 at 9:46 AM, Warren Young war...@etr-usa.com wrote: On 7/22/2014 10:43, Warren Young wrote: the mklink command has its options in reverse order I shouldn't say option here. I mean the two path names you have to give to both mklink and ln: $ ln source symlink-target C:\ mklink symlink-target source ___ 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] Curses! (foiled again?)
On Tue, Jul 22, 2014 at 9:04 PM, Andreas Kupries andre...@activestate.com wrote: Not necessarily. If the operations are done on the window buffer itself no transform is required. It happens implicitly when the window buffer is blitted into the main for presentation. i'm currently building Window as (basically) a set of coordinates/size, plus an array of tb_cell (screen cell state). The window ops will of course operate on that buffer, and then i'll blit that. Oh, need to add z-order :/. And sort my child list on that. And support resizing, and, and, and. Will post screenshots if/when i've got something interesting to show. The core API binding is finished (plus a few extras, e.g. clearing the screen using given fg/bg attributes), but i'm not yet sure if i'm in the mood to hack on it further tonight. Have fun. (The world is currently not so funny right now :( ) i'm off of work this week and fairly well shielded from current events ;). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ 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] 'open --nested', quick poll
We are using -nested very successfully to break a large area of related but mostly independent sub-areas into multiple fossils. I'm very happy with it. BTW, the whole reason why the modern SCM approach used by fossil, git etc. is so powerful is because the number of degrees of freedom were reduced by eliminating working on subsets of the file tree. If you add back in the ability to subdivide the file tree then you will have to add complexity to deal with branching and merging. Just my $0.02. On Tue, Jul 22, 2014 at 7:38 AM, Michai Ramakers m.ramak...@gmail.com wrote: Hello, I was wondering how many of you use 'open --nested' to have nested workdirs? A bit of background: A long time ago I asked here how/why/if people divided multiple-target project-trees into repos; some (like me) use one big repo for all, and some use many small repos. So this is not a real question let alone a fossil-specific one... Reason for asking is that I sometimes find myself going through changes between releases, and since I develop almost everything on trunk, the timeline-change overview between 'doc X version N' and 'doc X version N+1' so to say (each being tags) is naturally peppered with changes to other parts of the workdir, e.g. source, reference-material, pictures, whatnot. There was talk of giving the '/timeline' page something like a 'glob=' parameter a while ago, filtering out unwanted stuff. That would make going over diffs easier, but since the result would not be a consistent timeline anymore, I wonder if this would be a good idea, and whether my workflow is not fundamentally flawed. So... development of each target into its own branch (where branches could have contents in mutually exclusive dirs, e.g. 'docs', 'src', ...) is perhaps an option, or using different repos altogether, be it in nested workdirs or not? Ideas are welcome - assuming the above makes a bit sense, Michai ___ 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] 'open --nested', quick poll
On 22 July 2014 21:18, Matt Welland estifo...@gmail.com wrote: We are using -nested very successfully to break a large area of related but mostly independent sub-areas into multiple fossils. I'm very happy with it. BTW, the whole reason why the modern SCM approach used by fossil, git etc. is so powerful is because the number of degrees of freedom were reduced by eliminating working on subsets of the file tree. If you add back in the ability to subdivide the file tree then you will have to add complexity to deal with branching and merging. Just my $0.02. Alright. I saw your post (http://lists.fossil-scm.org:8080/pipermail/fossil-users/2014-January/015012.html) before I asked this question, btw. Did you start using --nested after that moment in time? I guess this sort of thing is personal, with added downside that it's quite costly to try it a bit (I mean change from one big repo to finer grained repos). We'll see; when frustration with one big repo rises above some limit here, perhaps I try with small repos (and perhaps back again :-) Michai ___ 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] 'open --nested', quick poll
On 7/22/2014 9:38 AM, Michai Ramakers wrote: I was wondering how many of you use 'open --nested' to have nested workdirs? Tcl nests whatever repositories you want checked out into subdirectories of pkgs. Each nested repository is expected to further nest the Tclconfig repository (itcl and thread do this), though they can instead have their own tclconfig directory (I think sqlite does this, though I see it in its autoconf/tea subdirectory). -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ 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] Curses! (foiled again?)
On Tue, Jul 22, 2014 at 8:45 PM, Stephan Beal sgb...@googlemail.com wrote: Will post screenshots if/when i've got something interesting to show. A very basic hierarchical window class demonstrated in the white box here: http://wanderinghorse.net/wh/tmp/termbox-poc-window1.png The inner black box with text is a sub-window. Tapping a key closes the sub-win here: http://wanderinghorse.net/wh/tmp/termbox-poc-window2.png demonstrating that the parent window's bg attributes are retained. Still lots of experimentation to do, but so far it's been pretty painless, in strong contrast to curses development. The script code: http://fossil.wanderinghorse.net/repos/cwal/index.cgi/finfo?name=s2/mod_termbox-Window.s2 -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ 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] File contains invalid UTF-8, but is not UTF-8.
Thus said Stephan Beal on Tue, 22 Jul 2014 19:01:27 +0200: One would think i'd be more conscious of how i throw around byte vs character :/. i'm still not clear on the whole char-vs-code point bit, though. The whole char-vs-codepoint has always been unclear for me, no matter how many times I read technical descriptions of it. :-) Andy -- TAI64 timestamp: 400053cf4d1f ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
