* [9fans] drawterm bug @ 2011-03-21 15:36 erik quanstrom 2011-03-22 14:40 ` erik quanstrom 0 siblings, 1 reply; 11+ messages in thread From: erik quanstrom @ 2011-03-21 15:36 UTC (permalink / raw) this is drawterm on osx 10.6 to plan 9. i don't have time to investigate right now, but here's the bug looks like sign extension. minooka; cp /mnt/term/tmp/file.gz . cp: error reading /mnt/term/tmp/file.gz: negative i/o offset minooka; ls -l --rw-r--r-- M 1638 xxx xxx 2147483648 Mar 21 11:05 file.gz - erik ^ permalink raw reply [flat|nested] 11+ messages in thread
* [9fans] drawterm bug 2011-03-21 15:36 [9fans] drawterm bug erik quanstrom @ 2011-03-22 14:40 ` erik quanstrom 2011-03-22 17:40 ` erik quanstrom 2011-03-22 17:45 ` Jeff Sickel 0 siblings, 2 replies; 11+ messages in thread From: erik quanstrom @ 2011-03-22 14:40 UTC (permalink / raw) On Mon Mar 21 11:38:22 EDT 2011, quanstro at quanstro.net wrote: > this is drawterm on osx 10.6 to plan 9. > > i don't have time to investigate right now, but here's the bug > looks like sign extension. > > minooka; cp /mnt/term/tmp/file.gz . > cp: error reading /mnt/term/tmp/file.gz: negative i/o offset > minooka; ls -l > --rw-r--r-- M 1638 xxx xxx 2147483648 Mar 21 11:05 file.gz it wasn't hard to get a reproducer: ; dd -iseek 2147483640 -count 10 -if /mnt/term/dev/zero -of fubar -bs 1 read: negative i/o offset 8+0 records in 8+0 records out this smelled like a sign extension bug, and sure enough, it was in the first place i looked hg diff include/fcall.h diff -r 005885bfe3f2 include/fcall.h --- a/include/fcall.h Tue Dec 28 16:40:27 2010 -0500 +++ b/include/fcall.h Tue Mar 22 10:28:00 2011 -0400 @@ -37,7 +37,7 @@ #define GBIT8(p) ((p)[0]) #define GBIT16(p) ((p)[0]|((p)[1]<<8)) #define GBIT32(p) ((p)[0]|((p)[1]<<8)|((p)[2]<<16)|((p)[3]<<24)) -#define GBIT64(p) ((vlong)((p)[0]|((p)[1]<<8)|((p)[2]<<16)|((p)[3]<<24)) |\ +#define GBIT64(p) ((u32int)((p)[0]|((p)[1]<<8)|((p)[2]<<16)|((p)[3]<<24)) |\ ((vlong)((p)[4]|((p)[5]<<8)|((p)[6]<<16)|((p)[7]<<24)) << 32)) #define PBIT8(p,v) (p)[0]=(v) hg is a pain, so the drawterm-fixes patch queue broke as soon as russ pulled in some changes. i'll try to work out how to get this up while causing minimal chaos. - erik ^ permalink raw reply [flat|nested] 11+ messages in thread
* [9fans] drawterm bug 2011-03-22 14:40 ` erik quanstrom @ 2011-03-22 17:40 ` erik quanstrom 2011-03-22 17:59 ` Skip Tavakkolian 2011-03-22 17:45 ` Jeff Sickel 1 sibling, 1 reply; 11+ messages in thread From: erik quanstrom @ 2011-03-22 17:40 UTC (permalink / raw) that was an ordeal. here's the patch queue https://bitbucket.org/quanstro/drawterm-fixes/changesets - erik ^ permalink raw reply [flat|nested] 11+ messages in thread
* [9fans] drawterm bug 2011-03-22 17:40 ` erik quanstrom @ 2011-03-22 17:59 ` Skip Tavakkolian 2011-03-22 18:57 ` erik quanstrom 0 siblings, 1 reply; 11+ messages in thread From: Skip Tavakkolian @ 2011-03-22 17:59 UTC (permalink / raw) i feel your pain. i went through the process for a patch queue to support ARM. FYI, when i mentioned this to Russ, he said I could email him the patch. I think if it's small enough it's probably the best way. On Tue, Mar 22, 2011 at 10:40 AM, erik quanstrom <quanstro at quanstro.net> wrote: > that was an ordeal. ?here's the patch queue > > https://bitbucket.org/quanstro/drawterm-fixes/changesets > > - erik > > ^ permalink raw reply [flat|nested] 11+ messages in thread
* [9fans] drawterm bug 2011-03-22 17:59 ` Skip Tavakkolian @ 2011-03-22 18:57 ` erik quanstrom 0 siblings, 0 replies; 11+ messages in thread From: erik quanstrom @ 2011-03-22 18:57 UTC (permalink / raw) > i feel your pain. i went through the process for a patch queue to support ARM. > > FYI, when i mentioned this to Russ, he said I could email him the > patch. I think if it's small enough it's probably the best way. unfortunately, i need this patch asap. it's causing real problems on machines i can't compile for. it's interesting that all these problems could be viewed as self-inflicted. a plan 9 program would be automaticly updated for everybody on the fs. and i could trivally compile for other machines. - erik ^ permalink raw reply [flat|nested] 11+ messages in thread
* [9fans] drawterm bug 2011-03-22 14:40 ` erik quanstrom 2011-03-22 17:40 ` erik quanstrom @ 2011-03-22 17:45 ` Jeff Sickel 2011-03-22 17:51 ` erik quanstrom 1 sibling, 1 reply; 11+ messages in thread From: Jeff Sickel @ 2011-03-22 17:45 UTC (permalink / raw) On Mar 22, 2011, at 9:40 AM, erik quanstrom wrote: > hg is a pain, so the drawterm-fixes patch queue broke as > soon as russ pulled in some changes. i'll try to work out > how to get this up while causing minimal chaos. I've found that using hg mq stacks of patches are a pain. But that's just my experience with the tool. It's all too easy to think that a patch is applied out of some mq managed stack just to find that it clearly is not once attempting to submit it upstream. Pull, try to update just to realize that you've got to hg qpop -a first, then remember to stuff things back in the right order. Needs work, well, time, it takes time. -jas ^ permalink raw reply [flat|nested] 11+ messages in thread
* [9fans] drawterm bug 2011-03-22 17:45 ` Jeff Sickel @ 2011-03-22 17:51 ` erik quanstrom 2011-03-22 18:02 ` Jeff Sickel 0 siblings, 1 reply; 11+ messages in thread From: erik quanstrom @ 2011-03-22 17:51 UTC (permalink / raw) > back in the right order. Needs work, well, time, it takes time. hey, wait a second ... i thought that was the whole point of hg, to save time. :-) there were some definate gotchas - hg diff doesn't do the right thing with a patch queue. - hg qpush is terribly misnamed; and hg push --mq is just a poke in the eye. - bitbucket tracks qupdate not qcommit. i don't understand this. - erik ^ permalink raw reply [flat|nested] 11+ messages in thread
* [9fans] drawterm bug 2011-03-22 17:51 ` erik quanstrom @ 2011-03-22 18:02 ` Jeff Sickel 2011-03-25 19:48 ` Ethan Grammatikidis 0 siblings, 1 reply; 11+ messages in thread From: Jeff Sickel @ 2011-03-22 18:02 UTC (permalink / raw) On Mar 22, 2011, at 12:51 PM, erik quanstrom wrote: >> back in the right order. Needs work, well, time, it takes time. > > hey, wait a second ... i thought that was the whole point of hg, > to save time. :-) It does, as long as you don't use certain extensions. > there were some definate gotchas > - hg diff doesn't do the right thing with a patch queue. > - hg qpush is terribly misnamed; and hg push --mq is just a poke in the eye. > - bitbucket tracks qupdate not qcommit. i don't understand this. Cloning and not using quilted patch queues does man you can work along in your branch of code as needed. Flush out a change, diff it w/ someone other revision/tip/repository and go to town. Export the changes upstream and it is a bit easier, even push them. I've just not taken the time to fully grok the way Bitbucket and a few others use mq. Too much complexity triggers the trap. -jas ^ permalink raw reply [flat|nested] 11+ messages in thread
* [9fans] drawterm bug 2011-03-22 18:02 ` Jeff Sickel @ 2011-03-25 19:48 ` Ethan Grammatikidis 2011-03-25 20:09 ` dexen deVries 0 siblings, 1 reply; 11+ messages in thread From: Ethan Grammatikidis @ 2011-03-25 19:48 UTC (permalink / raw) On Tue, 22 Mar 2011 13:02 -0500, "Jeff Sickel" <jas at corpus-callosum.com> wrote: > > On Mar 22, 2011, at 12:51 PM, erik quanstrom wrote: > > >> back in the right order. Needs work, well, time, it takes time. > > > > hey, wait a second ... i thought that was the whole point of hg, > > to save time. :-) > > It does, as long as you don't use certain extensions. > > > there were some definate gotchas > > - hg diff doesn't do the right thing with a patch queue. > > - hg qpush is terribly misnamed; and hg push --mq is just a poke in the eye. > > - bitbucket tracks qupdate not qcommit. i don't understand this. > > Cloning and not using quilted patch queues does man you can work along in > your branch of code as needed. Flush out a change, diff it w/ someone > other revision/tip/repository and go to town. Export the changes > upstream and it is a bit easier, even push them. I've just not taken the > time to fully grok the way Bitbucket and a few others use mq. > > Too much complexity triggers the trap. What on Earth is a quilted patch queue? I always thought the whole point of using a drcs was that you could work in your own branch. I've only used a drcs once, but everyone had their own branch there & it went pretty smoothly. ^ permalink raw reply [flat|nested] 11+ messages in thread
* [9fans] drawterm bug 2011-03-25 19:48 ` Ethan Grammatikidis @ 2011-03-25 20:09 ` dexen deVries 2011-03-25 21:00 ` Jeff Sickel 0 siblings, 1 reply; 11+ messages in thread From: dexen deVries @ 2011-03-25 20:09 UTC (permalink / raw) On Friday 25 of March 2011 20:48:50 Ethan Grammatikidis wrote: > What on Earth is a quilted patch queue? I always thought the whole point > of using a drcs was that you could work in your own branch. I've only > used a drcs once, but everyone had their own branch there & it went > pretty smoothly. I believe branches in hg are somewhat permanent. Your branches have direct, one-to-one, relationship with remote ones. Also, you can't exactly remove a branch in it, AFAIK. But there is `Local Branch Extension' available. after using hg for some time, i went for git where branches are more ephemeral. no idea why this group shuns git, but i'm in no position to proselytise. perhaps porting fossil (the dvcs) [1] to plan 9 would be a good option? [1] an unfortunate name conflict -- aside of the fossil archival filesystem there is fossil DVCS (by the sqlite guys), implemented in C (probably c99 flavor) http://en.wikipedia.org/wiki/Fossil_(software) -- dexen deVries ``One can't proceed from the informal to the formal by formal means.'' ^ permalink raw reply [flat|nested] 11+ messages in thread
* [9fans] drawterm bug 2011-03-25 20:09 ` dexen deVries @ 2011-03-25 21:00 ` Jeff Sickel 0 siblings, 0 replies; 11+ messages in thread From: Jeff Sickel @ 2011-03-25 21:00 UTC (permalink / raw) On Mar 25, 2011, at 3:09 PM, dexen deVries wrote: > On Friday 25 of March 2011 20:48:50 Ethan Grammatikidis wrote: >> What on Earth is a quilted patch queue? I always thought the whole point >> of using a drcs was that you could work in your own branch. I've only >> used a drcs once, but everyone had their own branch there & it went >> pretty smoothly. It's a made up reference to the mq extension (search for 'quilt'): http://mercurial.selenic.com/wiki/MqExtension > I believe branches in hg are somewhat permanent. Your branches have direct, > one-to-one, relationship with remote ones. Also, you can't exactly remove a > branch in it, AFAIK. But there is `Local Branch Extension' available. Hg branching is very different than the use of the queues extension. I've had decent success using hg branches in the past, much safer and easier to manage than queues. > after using hg for some time, i went for git where branches are more > ephemeral. no idea why this group shuns git, but i'm in no position to > proselytise. > > perhaps porting fossil (the dvcs) [1] to plan 9 would be a good option? Personally I went the hg route instead of git for a few reasons: - it was easier to build Python and install Hg on the targets I needed than to build/install most of the other options at the time. - at the time getting git to run on anything but a few distros of gnu/linux was more effort for less bang, if not ending up in a fizzle. It's easier now that the coding monkeys have taken on the task of releasing git into the wild. - the alignment with tools I'd used in the past fit well. Hg branching and merging work a lot like devman (another tool killed by sun(tm), and some other tools I've used. It's not the only dvcs out there, but it's got good backing and runs everywhere python is available (which is more than the current git targets). Though I'd like to rely on venti, it's not really a source control system. Metadata about a change can be important if managed well, especially in large groups. There has been discussion on this list about trying to come up with a more Plan 9-influenced source revision system. -jas ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2011-03-25 21:00 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-03-21 15:36 [9fans] drawterm bug erik quanstrom 2011-03-22 14:40 ` erik quanstrom 2011-03-22 17:40 ` erik quanstrom 2011-03-22 17:59 ` Skip Tavakkolian 2011-03-22 18:57 ` erik quanstrom 2011-03-22 17:45 ` Jeff Sickel 2011-03-22 17:51 ` erik quanstrom 2011-03-22 18:02 ` Jeff Sickel 2011-03-25 19:48 ` Ethan Grammatikidis 2011-03-25 20:09 ` dexen deVries 2011-03-25 21:00 ` Jeff Sickel
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).