Re: [9fans] Chords, ^, _, ^B and scroll with mouse wheel in p9p sam
What would you think about moving the named pipe from samterm into sam? It doesn't make much sense if you think of the named pipe as an alternative to the plumber. If you're using it for scripting a long-running sam process then maybe it's useful? It should also allow samterm to connect (or reconnect) to an already running sam process, possibly on a remote machine, wihich would be great for long running sessions, and/or unstable/intermittent connections. It could even simplify some of the logic and further decouple sam from samterm etc. I still need to look in to that a bit more. Just a thought :). I'll probably end up implementing that in my local version of sam anyway. All the best, Mark On Fri, 27 May 2016 at 20:06 wrote: > I did that before, and I don't know why but It didn't work. > Then after reading your mail I gave it a try again, and its working! > > >
Re: [9fans] Chords, ^, _, ^B and scroll with mouse wheel in p9p sam
On Fri, May 27, 2016, at 11:37 PM, stanley lieber wrote: > The intended convention is for the scrollwheel to behave similar to clicking > inside the scrollbar. > > It is unclear how to fix mousing for users who don't want to keep track of > where the mouse pointer is. > > sl > > I suppose some kind of standard for user settings is unavoidable. $home/lib/input perhaps. Looking at what you actually wrote, (because I know you too well to think your meaning can be assumed from the topic of conversation, :) ) "mousing" in general isn't much of a problem for me. To click or select, I move the mouse, the movement of the pointer catches my eye, and then I can position it as needed. When scrolling, I want to keep my eyes on the text, not be distracted by a pointer. -- I'm too old to use vi.
[9fans] More about /dev/draw
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
Re: [9fans] More about /dev/draw
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 >
Re: [9fans] More about /dev/draw
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.tavakkol...@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
Re: [9fans] More about /dev/draw
it's easier to just get a thinkpad that's listed on http://fqa.9front.org/fqa3.html On 5/28/16, Dave MacFarlane wrote: > 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.tavakkol...@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 >
Re: [9fans] More about /dev/draw
worth remembering that hdmi and DVI are equivalent in terms of what is needed for a computer monitor. hence hdmi to DVI adopters are very cheap. -Steve > On 28 May 2016, at 18:49, Dave MacFarlane wrote: > > 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 >> 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
[9fans] Plan 9 article in hacker magazine!
2600 is a hacker's quarterly magazine that specializes in sharing subtle tips and tricks related to computer hacking. Volume 33, issue 1, however, featured something that was pleasent to read: an article on Plan 9. It describes what it is, how it came to be, how it differs from other OS's, and how to get it. It's a basic introduction to 9 that most of us already know about, but nonetheless I wanted to share it with you all to show that there's still a very strong interest in the OS. And with this article, perhaps it'll gain a little more! Thanks for reading. Definitely pick up a copy of 2600 if you have the chance!
Re: [9fans] More about /dev/draw
I see an image at bell labs for the raspberry pi. http://plan9.bell-labs.com/sources/contrib/miller/9pi.img.gz I see that there are Raspberry Pi 2 Model Bs and Raspberry Pi 3 Model Bs for sale. Will either one work with that image? I have a Samsung SyncMaster E1920 I could use, it's got an 'HDMI' connection, I believe. Am I good to go? On 2016-05-29 00:34, Skip Tavakkolian 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
Re: [9fans] More about /dev/draw
I use the Pi 2 version daily at work with an hdmi monitor. there seem to be a couple of lurking bugs in the sub driver which generate spurious grumbles and seem to prevent sub serial adapters from working, which is a minor annoyance. Other than that it works like a charm. audio out is still broken too which is a continuous source of guilt to me - I will fix that one day. -Steve > On 29 May 2016, at 06:40, jfmxl wrote: > > I see an image at bell labs for the raspberry pi. > http://plan9.bell-labs.com/sources/contrib/miller/9pi.img.gz > > I see that there are Raspberry Pi 2 Model Bs and Raspberry Pi 3 Model Bs for > sale. Will either one work with that image? > > I have a Samsung SyncMaster E1920 I could use, it's got an 'HDMI' connection, > I believe. Am I good to go? > > > >> On 2016-05-29 00:34, Skip Tavakkolian 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 >
Re: [9fans] More about /dev/draw
Thanks for the answer, Steve. Do you suppose Pi 3 may have fixed the 'sub driver' bugs? What's a 'sub driver'? not 'usb driver', or is it? The audio out is broken, but it's your fault? How is that? On 2016-05-29 12:50, Steve Simon wrote: I use the Pi 2 version daily at work with an hdmi monitor. there seem to be a couple of lurking bugs in the sub driver which generate spurious grumbles and seem to prevent sub serial adapters from working, which is a minor annoyance. Other than that it works like a charm. audio out is still broken too which is a continuous source of guilt to me - I will fix that one day. -Steve On 29 May 2016, at 06:40, jfmxl wrote: I see an image at bell labs for the raspberry pi. http://plan9.bell-labs.com/sources/contrib/miller/9pi.img.gz I see that there are Raspberry Pi 2 Model Bs and Raspberry Pi 3 Model Bs for sale. Will either one work with that image? I have a Samsung SyncMaster E1920 I could use, it's got an 'HDMI' connection, I believe. Am I good to go? On 2016-05-29 00:34, Skip Tavakkolian 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
Re: [9fans] More about /dev/draw
Actually, looking at the back of the monitor, it has an analog vga plug-in and a similar sized digital plug-in, but no HDMI. Can I still use it with Raspberry Pi Plan 9? On 2016-05-29 12:59, jfmxl wrote: Thanks for the answer, Steve. Do you suppose Pi 3 may have fixed the 'sub driver' bugs? What's a 'sub driver'? not 'usb driver', or is it? The audio out is broken, but it's your fault? How is that? On 2016-05-29 12:50, Steve Simon wrote: I use the Pi 2 version daily at work with an hdmi monitor. there seem to be a couple of lurking bugs in the sub driver which generate spurious grumbles and seem to prevent sub serial adapters from working, which is a minor annoyance. Other than that it works like a charm. audio out is still broken too which is a continuous source of guilt to me - I will fix that one day. -Steve On 29 May 2016, at 06:40, jfmxl wrote: I see an image at bell labs for the raspberry pi. http://plan9.bell-labs.com/sources/contrib/miller/9pi.img.gz I see that there are Raspberry Pi 2 Model Bs and Raspberry Pi 3 Model Bs for sale. Will either one work with that image? I have a Samsung SyncMaster E1920 I could use, it's got an 'HDMI' connection, I believe. Am I good to go? On 2016-05-29 00:34, Skip Tavakkolian 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
[9fans] rio on plan 9 from user space
On another tack ... I have installed plan 9 from user space on my debian machine, and sam and acme seem to open and work ok. But when I type rio, I get ... $ rio rio: it looks like there's already a window manager running; rio not started So, rio under plan 9 from user space (p9port?) wants the the whole display? I cannot run xfce and have rio in a window? I am trying to communicate with a plan 9 cpu, but drawterm seems slow and awkward. Are there any plan 9 installations open to people like myself to 'try out'?
