From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: From: Dave MacFarlane Date: Sat, 28 May 2016 13:49:59 -0400 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=94eb2c05be56b0c5540533eaa845 Subject: Re: [9fans] More about /dev/draw Topicbox-Message-UUID: 94f6f268-ead9-11e9-9d60-3106f5b1d025 --94eb2c05be56b0c5540533eaa845 Content-Type: text/plain; charset=UTF-8 That's exactly what I'm doing. I don't have a monitor with HDMI within network-cable and power-cable reach to hook it up to, and the last time I hooked it up to my TV my toddler tore the usb/power cable of the Pi in two, so I can only try debugging it when he's not around.. (And Go 1.6 or later for Plan9, but 1.7 or later for ARM, for the record..) On Sat, May 28, 2016 at 1:34 PM, Skip Tavakkolian < skip.tavakkolian@gmail.com> wrote: > a quick and easy way to get a local Plan 9 terminal is to use 9Pi (Plan 9 > on Raspberry Pi). with Go 1.6 and later you can cross compile for plan9/arm. > > > On Sat, May 28, 2016 at 10:24 AM Dave MacFarlane > wrote: > >> Either I'm going insane, the default Plan 9 /dev/draw in-memory >> implementation >> doesn't implement draw(3), or possibly both. >> >> When I do the following, it works as expected under both drawterm and a >> locally mounted instance: >> 1. Allocate a screen with an 'A' message >> 2. Allocate an image on the screen of the same size as /dev/wctl with a >> 'b' message >> 3. Draw the image over the window with a 'd' message >> 4. Flush the buffer with 'v' >> >> When I do the following, it works under drawterm, but not with a local >> /dev/draw implementation: >> Steps 1-2 above >> 3. Allocate another image of some arbitrary fill colour with 'b' (with or >> without the repl bit) >> 4a. (Optional, doesn't seem to make a difference) set the compositing >> operator with 'O' >> 4b. Draw the new image over a portion of the window image from step 2 >> with 'd' >> 5. Go to step 3-4 from the first variation. >> >> (I don't have a 9front instance to test on.) >> >> On the other hand, replacing a portion of the image from step 2 with 'y' >> works under either. (I haven't gotten around to using 'Y' when appropriate >> yet.) >> >> Basically, I can only get any variation of this code: >> https://github.com/driusan/exp/blob/18a78a1549541d46d26cb6088a904585c386d812/shiny/driver/devdrawdriver/uploadimpl.go#L50 >> >> to work under drawterm. >> >> The end result is that under a local Plan 9 instance the basic sample >> shiny test looks like this: >> >> http://driusan.github.io/plan9/basicmem.png >> >> Instead of this: >> >> http://driusan.github.io/plan9/basicdrawterm.png >> >> Does anyone have any pointers? I don't have much access to a physical >> Plan 9 machine, so I'm having trouble debugging this since it works under >> drawterm (or perhaps is buggy under drawterm in a way that makes it seem >> like it's working..) >> >> It would also potentially be helpful if someone who uses Go under 9front >> could let me know how x/exp/shiny/examples/basic looks with the shiny >> driver in that branch, but I'm not sure that it matters since it'll most >> likely be the same as one of the above.. >> >> - Dave >> > -- - Dave --94eb2c05be56b0c5540533eaa845 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That's exactly what I'm doing. I don't have a = monitor with HDMI within network-cable and power-cable reach to hook it up = to, and the last time I hooked it up to my TV my toddler tore the usb/power= cable of the Pi in two, so I can only try debugging it when he's not a= round..

(And Go 1.6 or later for Plan9, = but 1.7 or later for ARM, for the record..)

On Sat, May 28, 2016 at 1:34 PM, Skip Tavak= kolian <skip.tavakkolian@gmail.com> wrote:
a quick and easy way to get a lo= cal Plan 9 terminal is to use 9Pi (Plan 9 on Raspberry Pi). with Go 1.6 and= later you can cross compile for plan9/arm.


On Sat, May 28, 2016 at 10:24 AM Dave MacFarlane <driusan@gmail.com> wrote:
Either I'm going ins= ane, the default Plan 9 /dev/draw in-memory implementation
doesn't = implement draw(3), or possibly both.

When I do the= following, it works as expected under both drawterm and a locally mounted = instance:
1. Allocate a screen with an 'A' message
<= div>2. Allocate an image on the screen of the same size as /dev/wctl =C2=A0= with a 'b' message
3. Draw the image over the window with= a 'd' message
4. Flush the buffer with 'v'
=

When I do the following, it works under drawterm, but n= ot with a local /dev/draw implementation:
Steps 1-2 above
3. Allocate another image of some arbitrary fill colour with 'b'= (with or without the repl bit)
4a. (Optional, doesn't seem t= o make a difference) set the compositing operator with 'O'
4b. Draw the new image over a portion of the window image from step 2 wit= h 'd'
5. Go to step 3-4 from the first variation.

(I don't have a 9front instance to test on.)

On the other hand, replacing a portion of the image f= rom step 2 with 'y' works under either. (I haven't gotten aroun= d to using 'Y' when appropriate yet.)


to work under dra= wterm.

The end result is that under a local Plan 9= instance the basic sample shiny test looks like this:

=

Instead of this:


Does anyone have any = pointers? I don't have much access to a physical Plan 9 machine, so I&#= 39;m having trouble debugging this since it works under drawterm (or perhap= s is buggy under drawterm in a way that makes it seem like it's working= ..)

It would also potentially be helpful if someon= e who uses Go under 9front could let me know how x/exp/shiny/examples/basic= looks with the shiny driver in that branch, but I'm not sure that it m= atters since it'll most likely be the same as one of the above..
<= /div>

- Dave



--
=
- Dave
--94eb2c05be56b0c5540533eaa845--