[9fans] drawterm bug

[9fans] drawterm bug

[erik quanstrom]

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

[9fans] drawterm bug

[erik quanstrom]

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

[9fans] drawterm bug

[erik quanstrom]

that was an ordeal.  here's the patch queue

https://bitbucket.org/quanstro/drawterm-fixes/changesets

- erik

[9fans] drawterm bug

[Skip Tavakkolian]

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
>
>

[9fans] drawterm bug

[erik quanstrom]

> 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

[9fans] drawterm bug

[Jeff Sickel]

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

[9fans] drawterm bug

[erik quanstrom]

> 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

[9fans] drawterm bug

[Jeff Sickel]

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

[9fans] drawterm bug

[Ethan Grammatikidis]

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.

[9fans] drawterm bug

[dexen deVries]

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.''

[9fans] drawterm bug

[Jeff Sickel]

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