Re: [9fans] p9p sed vs linux sed

[Alexander Kapshuk]

On Wed, Aug 12, 2015 at 10:39 AM, Rudolf Sykora rudolf.syk...@gmail.com wrote:
 Hello,

 is this as expected?

 perseus=; echo -n aaa | 9 sed 's/^//'
 aaa
 perseus=; echo -n aaa | sed 's/^//'
 aaaperseus=;


 For me the linux sed does what I expect,
 but not the p9p one (it adds a newline). Why?

 Thanks!
 Ruda


In case you were still wondering about the 'why' of the behaviour of
sed you encountered. See below.

P9p sed
---
/usr/local/plan9/src/cmd/sed.c:1316,1324
void
putline(Biobuf *bp, Rune *buf, int n)
{
while (n--)
Bputrune(bp, *buf++);
Bputc(bp, '\n');
if(lflag)
Bflush(bp);
}

Plan9 sed
-
/sys/src/cmd/sed.c:1315,1321
void
putline(Biobuf *bp, Rune *buf, int n)
{
   while (n--)
   Bputrune(bp, *buf++);
   Bputc(bp, '\n');
 }

Modified local copy
--
/usr/$user/src/nsed.c:1315,1321
void
putline(Biobuf *bp, Rune *buf, int n)
{
while (n--)
Bputrune(bp, *buf++);
/* Bputc(bp, '\n'); */
}

term% echo -n aaa | sed 's/^//'
aaa
term% echo -n aaa | nsed 's/^//'
aaaterm%

Re: [9fans] Small Plan 9 Platforms

[Steve Simon]

I have tried to email BLS but fear I am being spam filtered... you there?

-Steve




 On 12 Aug 2015, at 23:27, Brian L. Stuart blstu...@bellsouth.net wrote:
 
 On Wed, 8/12/15, Skip Tavakkolian 9...@9netics.com wrote:
 the gpio pins don't seem accessible through a filesystem api
 like i see in plan9-bcm (unless i've missed something).
 
 I'm pretty sure it's not there.
 
   it would be great to merge that capability in.
 
 I've made a start on that this afternoon.  I took the devbcm from
 plan9-bcm and stripped it down to just the gpio parts and
 renamed it devgpio.  I've now got a B+ running with Richard's
 latest code that includes I2C and SPI and a first cut revision of
 devgpio.  I'm watching an LED I wired up to it blinking driven
 by a program in user space as I type this.
 
 BLS
 
 
 

Re: [9fans] p9p sed vs linux sed

[erik quanstrom]

i think the change doesn't work for any multi-line file:

; cp /sys/src/cmd/sed.c /tmp/notsed.c
; cd /tmp
; ed notsed.c
; ed notsed.c
27827
putline(Biobuf *bp, Rune *buf, int n)
+4
ebputc(bp, '\n');
d
w
27808
q
; tmk notsed.c
6c -FVTw notsed.c
6l -o 6.notsed notsed.6
; ; {echo a ; echo b} | 6.notsed 's/./.☺/g'
.☺.☺; 

- erik

Re: [9fans] Small Plan 9 Platforms

[Brian L. Stuart]

 I have tried to email BLS but fear I am being spam filtered... you there?

I did get one message from you, and replied earlier today.  Hopefully
it got through.

A little more update on recent pi playing.  I've been working on a
little toy the last few days, namely one of those small SPI driven
LCD panels:

http://www.adafruit.com/products/2441

As of this evening, I've gotten it sort of running alongside the
HDMI display showing the upper left corner.  Here are a few
pics of it in operation:

The Pi with the display connected to a keyboard and mouse:

http://cs.drexel.edu/~bls96/9pitft1-s.jpg

and a couple of pics of the display showing acme running:

http://cs.drexel.edu/~bls96/9pitft2-s.jpg
http://cs.drexel.edu/~bls96/9pitft3-s.jpg

It's a long way from being usable though.  The fundamental issue
is that there appears to be a very deeply embedded assumption
that a screen must be memory mapped.  I tried hooking into
the hwdraw() routine in screen.c, but it seems that not every
change to the screen memory space gets reflected in a call
to hwdraw().  For the pics, I've got a version that periodically
copies the whole of the appropriate area of the Memimage
to the LCD panel over the SPI port.  Obviously, that's too slow
and too resource-hungry to be practical.  Hopefully, I'm missing
something and there's an elegant way to graft a non-memory
mapped display into the devdraw/memdraw/screen infrastructure.

BLS