> > clearly you did not run this script. this doesn't
> > work for the same reason that here docs in functions
> > don't work.
>
> I actually did, but accidentally ran the old unix port. sorry for the noise.
ah, yes byron did make here documents work, and i think paul
goaded him into adding her
On Wed, May 8, 2013 at 12:08 AM, erik quanstrom wrote:
>> I guess I must be missing something, but this seems equivalent to your
>> bash script:
>>
>> for(i in 1 2 3) {
>> cat <> $i
>> !
>> }
>
> clearly you did not run this script. this doesn't
> work for the same reason that here docs i
> I guess I must be missing something, but this seems equivalent to your
> bash script:
>
> for(i in 1 2 3) {
> cat < $i
> !
> }
clearly you did not run this script. this doesn't
work for the same reason that here docs in functions
don't work.
- erik
On Mon, May 6, 2013 at 9:27 AM, Rudolf Sykora wrote:
> Can the rc example be modified --- still using a here document --- so
> that it works?
I guess I must be missing something, but this seems equivalent to your
bash script:
for(i in 1 2 3) {
cat <
> i think the assertion that memload "loads directly to the screen" is not
> correct.
> at least to my walking through memload.
i read wrong. i think this may fix the issue in a systemic, but not
entirely satisfying way. it does seem rather optimistic that we can
just scribble on the screen.
On Tue May 7 14:51:13 EDT 2013, yari...@gmail.com wrote:
>
> > the issue, and this fact this fix works must mean that
> > devdraw(3)'s 'd' command usually doesn't cause (much)
> > cursor flicker, but the 'y' command does.
> >
> > so either there is a timing or locking problem on the pi,
> > or s
> the issue, and this fact this fix works must mean that
> devdraw(3)'s 'd' command usually doesn't cause (much)
> cursor flicker, but the 'y' command does.
>
> so either there is a timing or locking problem on the pi,
> or swcursoravoid(r) is not called for the 'y' command.
Correct: swcursoravo
> I use 9atom on the pi daily and vncv often a d have never observed this
> behavior.
does 9atom uses a higher HZ setting which could make swcursor be drawn sooner?
> i am using the memdraw from p9p which fixes a number of
> bad drawing cases. (no more blue pngs.) and i don't use
> vnc, so it's hard for me to replicate.
I use 9atom on the pi daily and vncv often a d have never observed this
behavior.
> This problem happens in 386 too (I mean the original
> problem this patch is addressing or tries to address).
the problem is still in the kernel. hacking around it in
vnc won't fix the problem for other programs. hwdraw
should behave the same for either, so something in
the kernel should be c
On Tue, May 7, 2013 at 4:10 PM, erik quanstrom wrote:
> On Tue May 7 05:03:57 EDT 2013, yari...@gmail.com wrote:
> > When using vncv on a terminal with software cursor (vesa, rpi) the
> > mouse cursor leaves a trail. This seem to be caused by the fact that
> > vncv loads picture updates with loa
On Tue May 7 05:03:57 EDT 2013, yari...@gmail.com wrote:
> When using vncv on a terminal with software cursor (vesa, rpi) the
> mouse cursor leaves a trail. This seem to be caused by the fact that
> vncv loads picture updates with loadimage(2) directly to screen.
> Loading to an offscreen image f
> Submitted as /n/sources/patch/vncv-curtrail
It's been long overdue! Thank you.
++L
When using vncv on a terminal with software cursor (vesa, rpi) the
mouse cursor leaves a trail. This seem to be caused by the fact that
vncv loads picture updates with loadimage(2) directly to screen.
Loading to an offscreen image followed by a draw(2) to screen removes
the artifact:
/n/dump/2013
14 matches
Mail list logo