[9fans] USB - your contribution

[9fans] USB - your contribution

[Lucio De Re]

Boyd,

I have just acquired, perhaps by mistake, but that's an unrelated
story, a USB-to-IDE external enclosure and I was wondering if any
of the efforts you and rsc expended on getting a USB floppy to boot
Plan 9 would be relevant in deploying the device I have in some
Plan 9-like fashion.

Could you point me to your web site, once again, please, and also
add any comments you think may be appropriate?

Much appreciated.

++L

[9fans] Re: USB - your contribution

[Lucio De Re]

On Tue, Jan 13, 2004 at 11:09:26AM +0200, Lucio De Re wrote:
>
> Boyd,
>
Damn!  Caught by the Reply-to bug, once again!

++L

RE: [9fans] Re: USB - your contribution

[boyd, rounin]

    Damn!  Caught by the Reply-to bug, once again!

try this:

    http://www.insultant.net/repo/plan9/usbflop.html

it is 3rd ed, but works with 4th.

[9fans] always go for overkill, err vismon

[boyd, rounin]

http://www.insultant.net/images/vismon.jpg
--
MGRS 56H LJ 78915 53260

Re: [9fans] always go for overkill, err vismon

[Jeff Sickel]

I downloaded the file posted by boyd (http://www.insultant.net/images/vismon.jpg) only to get the following:

xxx 101: suicide: sys: trap: fault read addr=0xf000ff67 pc=0x0001e388
xxio 13: suicide: sys: trap: fault read addr=0xf000ff97 pc=0x0001c944
xx init: rc exit status: rio 13: sys: trap: fault read addr=0xf000ff97 pc=0x0001c944

init: starting /bin/rc
term%


sadly, or otherwise, I'm using a thinkpad and the reboot is a pain.  The error
occured with some kind of rio suicide (the xx marks come from screen blur
before my ability to capture the data for this message).

jas
---
ignore the spamisham.

Re: [9fans] always go for overkill, err vismon

[Fco.J.Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 150 bytes --]

It was better on my machine. It filled up the available memory and
the machine hanged. I don't know yet if that was what boyd wanted
to happen ;-)

[-- Attachment #2: Type: message/rfc822, Size: 2391 bytes --]

From: Jeff Sickel <jas@spamisham.corpus-callosum.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] always go for overkill, err vismon
Date: Wed, 14 Jan 2004 09:34:42 GMT
Message-ID: <1009klt9gkhffdf@corp.supernews.com>

I downloaded the file posted by boyd (http://www.insultant.net/images/vismon.jpg) only to get the following:

xxx 101: suicide: sys: trap: fault read addr=0xf000ff67 pc=0x0001e388
xxio 13: suicide: sys: trap: fault read addr=0xf000ff97 pc=0x0001c944
xx init: rc exit status: rio 13: sys: trap: fault read addr=0xf000ff97 pc=0x0001c944

init: starting /bin/rc
term%


sadly, or otherwise, I'm using a thinkpad and the reboot is a pain.  The error
occured with some kind of rio suicide (the xx marks come from screen blur
before my ability to capture the data for this message).

jas
---
ignore the spamisham.

Re: [9fans] always go for overkill, err vismon

[Anders Soendergaard]

On Wed, 2004-01-14 at 10:53, ext Fco.J.Ballesteros wrote:
> It was better on my machine. It filled up the available memory and
> the machine hanged. I don't know yet if that was what boyd wanted
> to happen ;-)
It did that on my Linux laptop also! Evil stuff! ;)

Re: [9fans] always go for overkill, err vismon

[boyd, rounin]

well; i wanted a 600 dpi 24 bit greyscale scan.  quality being job 1.

i only posted url.  i _could_ have posted it to the list ;)

Re: [9fans] always go for overkill, err vismon

[Jeff Sickel]

boyd, rounin <boyd@insultant.net> wrote:
> well; i wanted a 600 dpi 24 bit greyscale scan.  quality being job 1.

> i only posted url.  i _could_ have posted it to the list ;)

Well, maybe it's time to look at what is in the jpg library.

Re: [9fans] always go for overkill, err vismon

[mirtchov]

> boyd, rounin <boyd@insultant.net> wrote:
>> well; i wanted a 600 dpi 24 bit greyscale scan.  quality being job 1.
>
>> i only posted url.  i _could_ have posted it to the list ;)
>
> Well, maybe it's time to look at what is in the jpg library.

the Links sources come with a copy of the jpeg library.  compiling it
will create two add-on programs -- cjpeg and djpeg -- which convert
between jpg and pnm files and could be used to verify whether the
problem lies with Plan 9's jpg, Plan 9's rio or something else:

	hget http://boyd's jpg image | djpeg | page

Re: [9fans] always go for overkill, err vismon

[Christopher Nielsen]

to add another data point, it locked up my windows xp box
solid. i was using mozilla firebird. i couldn't even pull up
the task manager; had to power cycle the box.

On Thu, Jan 15, 2004 at 08:29:24AM -0700, mirtchov@cpsc.ucalgary.ca wrote:
> > boyd, rounin <boyd@insultant.net> wrote:
> >> well; i wanted a 600 dpi 24 bit greyscale scan.  quality being job 1.
> >
> >> i only posted url.  i _could_ have posted it to the list ;)
> >
> > Well, maybe it's time to look at what is in the jpg library.
>
> the Links sources come with a copy of the jpeg library.  compiling it
> will create two add-on programs -- cjpeg and djpeg -- which convert
> between jpg and pnm files and could be used to verify whether the
> problem lies with Plan 9's jpg, Plan 9's rio or something else:
>
> 	hget http://boyd's jpg image | djpeg | page

--
Christopher Nielsen
"They who can give up essential liberty for temporary
safety, deserve neither liberty nor safety." --Benjamin Franklin

Re: [9fans] always go for overkill, err vismon

[rog]

> to add another data point, it locked up my windows xp box
> solid. i was using mozilla firebird. i couldn't even pull up
> the task manager; had to power cycle the box.

on the other hand, i was able to view it fine on my plan 9 box (with
128MB of memory).

viewing large images on plan9 is difficult due to the restriction that
image memory is kernel memory, and thus can't be paged.

before he left, chris locke did quite a nice image viewer under
inferno that allowed viewing of arbitrarily large images (a 22MB jpg
aerial view of baghdad was one example); unfortunately it was never
completely finished.

Re: [9fans] always go for overkill, err vismon

[mirtchov]

> on the other hand, i was able to view it fine on my plan 9 box (with
> 128MB of memory).

I wonder if there's anything wrong with my box then:

	jpg: loadimage v.jpg failed: loadimage: image too wide for buffer

resample on the other hand copes with it quite nicely, resizing at 50%
makes it readable in page...

Re: [9fans] always go for overkill, err vismon

[Chris Hollis-Locke]

----- Original Message -----
From: <rog@vitanuova.com>
To: <9fans@cse.psu.edu>
Sent: Thursday, January 15, 2004 8:42 PM
Subject: Re: [9fans] always go for overkill, err vismon


> before he left, chris locke did quite a nice image viewer under
> inferno that allowed viewing of arbitrarily large images (a 22MB jpg
> aerial view of baghdad was one example); unfortunately it was never
> completely finished.
>

Story of my life!

The problem was that I was trying to standardise the interface for all the
Inferno image conversion modules.  I wasn't happy with how the interface was
looking and didn't want it to become part of the main Inferno system.

It may be possible to make it tidier with John Firth's limbo changes.  At
the time I was leaning towards not having a generic interface but instead a
'pattern' so each converter had its own specific interface but the code to
use it would be very similar.

If people are interested it could be released as a separate app.  The JPEG
converter fixed several bugs that both the p9 and inferno converters
suffered, did progressive mode properly etc.  VN were paying me at the time
so I wouldn't release it without their permission.  Rog has access to the
code (over to you my friend!).

Chris.

Re: [9fans] always go for overkill, err vismon

[boyd, rounin]

my old man's XP box scanned it, ftp'd it and displayed it all at 19200 baud
(don't ask).

Re: [9fans] always go for overkill, err vismon

[andrey mirtchovski]

My setup includes the following machines (listed with available ram):

    1.7GB ram cpu server
    512MB ram cpu server
    160MB ram terminal running in vmware

on all those machines, either sitting behind the terminal, connecting via
drawterm or running in a vnc session I get exactly the same behaviour when
reading Boyd's jpg scan -- namely "page file.jpg" fails with:

    warning: couldn't read image: readimage: image too wide for buffer

on the other hand jpg -c file.jpg | page works! turns out that page uses

    jpg -t9 file.jpg

to convert the image to Plan 9 format. looking at the man page for jpg:

          -c   Convert the image to a Plan 9 representation, as
               defined by image(6), and write it to standard output.

          -9   Like -c, but produce an uncompressed image.  This saves
               processing time, particularly when the output is being
               piped to another program such as page(1), since it
               avoids compression and decompression.

          -t   Convert the image, if it is in color, to a true color
               RGB image.

the files that result from the conversion of Boyd's image have the
following sizes:

    --rw-rw-r-- M 1178 andrey andrey  1676944 Jan 16 10:09 c.bit
    --rw-rw-r-- M 1178 andrey andrey 22857190 Jan 16 11:17 9.bit
    --rw-rw-r-- M 1178 andrey andrey 68571450 Jan 16 11:13 t.bit

(ordered by option used -- -c -9 and -t9 respectively). readimage() can
handle the first two even on my puny 160mb vmware terminal but chokes on
the third one...

a possible solution is to use Memimage instead of Image -- readmemimage()
can apparently handle even the biggest of the three. I have hacked page to
use memimages, displaying only a part that is clipped by the screen
coordinates. there are ways to be smart about how much of the image is
loaded at any time, but it'll require more than a late afternoon of thinking and
a morning of tinkering. the conversion between Memimage and Image is non trivial
and it'll be great if we had a couple of library routines we could use to
draw from one onto the other (or maybe i fail to see them in the man
pages). the way it's done in the hacked page is to writememimage() to
one end of a pipe and readimage() from the other.

all of this impacts performance negatively, of course :)

andrey

Re: [9fans] always go for overkill, err vismon

[mirtchov]

ugh, forgot to ask: what is that lml(1) the jpg(1) man page speaks of?

Re: [9fans] always go for overkill, err vismon

[Sape Mullender]

> ugh, forgot to ask: what is that lml(1) the jpg(1) man page speaks of?

lml is the linuxmedia video capture card I once wrote a driver for.
It features in jpg(1) because we gave that program an option to
combine the even and odd fields (independently jpg compressed by
the lml card) of interlaced video into a single image.

Re: [9fans] always go for overkill, err vismon

[boyd, rounin]

> I downloaded the file posted by boyd
(http://www.insultant.net/images/vismon.jpg) only to get the following:
>
> xxx 101: suicide: sys: trap: fault read addr=0xf000ff67 pc=0x0001e388
> xxio 13: suicide: sys: trap: fault read addr=0xf000ff97 pc=0x0001c944
> xx init: rc exit status: rio 13: sys: trap: fault read addr=0xf000ff97
pc=0x0001c944

think of it as rigorous testing.

RE: [9fans] always go for overkill, err vismon

[Tiit Lankots]

> It was better on my machine. It filled up the available memory and
> the machine hanged. I don't know yet if that was what boyd wanted
> to happen ;-)

That's something new - DoS by pictures. Guerilla terrorists of computer
industry, take notes.

Tiit

Re: [9fans] always go for overkill, err vismon

[Skip Tavakkolian]

> It was better on my machine. It filled up the available memory and
> the machine hanged. I don't know yet if that was what boyd wanted
> to happen ;-)

Same here on one term I tried it on; it said something like "rio: out
of swap" and then went into a coma.

 From what I know of boyd (mainly through this list), I'd say he was
making a point.

Re: [9fans] always go for overkill, err vismon

[boyd, rounin]

> From what I know of boyd (mainly through this list), I'd say he was
> making a point.

yes someone was slagging off faces so i scanned vismon(9.1) [~1984]
and ftp'd it, but you chose to look at the url -- caveat emptor.

i hope got the latin right, 'cos i'm hideously jetlaged.

theory is (although i havn't checked) is that i have my 9th Ed manual
in the northern hemisphere .

--
MGRS 31U DQ 52572 12604