[9fans] Pico (again)

[9fans] Pico (again)

[steve.simon]

Hi,

Pico was a JIT compiler for expressions mapping one image onto another.
The compiler was written only for the VAX.

There are several versions available in c.s.u starting with a cut down,
interpreted
version called popi released by Gerard Holzman later versions had JIT compilers
added  by Byron Rakitzis of Unix RC fame.

Some time ago I had grand ideas of producing something similar for
processing data streams of video but I'm afraid it fell at the hurdle of my lack
of
understanding of process networks generation.

The original interpreted popi should run fine on Plan9 under pcc.

Sorry if any of this is inaccurate, its from memory.

-Steve

Re: [9fans] Pico (again)

[Douglas A. Gwyn]

Dennis Ritchie wrote:
> http://www.cs.bell-labs.com/10thEdMan/v2pix.html

Any prizes for guessing what the transformation formulae were?

Re: [9fans] Pico (again)

[Douglas A. Gwyn]

anothy@cosym.net wrote:
> anyone got anything to deal with pico (v10 picfile(5)) images?

Somewhere in my archives I have 5620/630 code.
IIRC, it is a simple format similar to .BMP and so it
should be easy to reformat it into any frame-buffer device.

Re: [9fans] Pico (again)

[Byron Rakitzis]

>Hi,
>
>Pico was a JIT compiler for expressions mapping one image onto another.
>The compiler was written only for the VAX.
>
>There are several versions available in c.s.u starting with a cut down,
>interpreted
>version called popi released by Gerard Holzman later versions had JIT compilers
>added  by Byron Rakitzis of Unix RC fame.

Hm... I did code generators for SPARC and MIPS roughly 10 years ago.
Later on I added a code generator for Alpha which was adapted from
the MIPS code, but which became much more exciting ultimately because
I added floating point, polar coordinates, trig functions, etc.

I did make a quick Java JIT for x86 in 1995 which I bolted into the
then brand-new Sun interpreted runtime. I imagine it would be possible
to adapt those macros to make an x86 pico (for what else do people use
these days but x86s??), but I haven't spent time on pico in years
and years.

I hardly participate in 9fans and I don't know where to post the code
these days. If someone would like a bundle of my pico directory with
the three above-mentioned code generators (SPARC/MIPS/Alpha), let me know.

Byron.

Re: [9fans] Pico (again)

[ggm]

I always used to imagine Algorists gathering in a dusty college chamber,
glasses of Gluhwine warming in their hands (or alternately snifters of brandy)
as they discuss the relative merits of non-terminating iterative functions as
sources of near-random data.

> I retrieved some of the pico-processed images that
> were in the 10th edition manual:
> 
> http://www.cs.bell-labs.com/10thEdMan/v2pix.html
> 
> 
> 	Dennis

But now I've been reminded of these images I realise it was probably
more like a mix of an acid test, combined with a nitrous oxide jag. 

Of course that some of them are actually quite beautiful, and would not have
offended Rene Magritte or more plausibly Angus Bean or Man Ray (actually, I
think all of them would have pissed off Cecil Beaton or Karsh) only makes it
better.

Thanks for posting them. Didn't some of these also wind up on a tee-shirt
for a USENIX or AUUG?

-George

Re: [9fans] Pico (again)

[Micah Stetson]

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

> common to most unix command line programs on Plan 9. i've not
> checked to see that it does sensable things with images, though,
> mainly because i don't know what to do with popi's output. 

Here is a program that takes popi's output and makes a plan9
image from it.  It isn't anything amazing, but maybe it will
save you a few seconds.

Micah


[-- Attachment #2.1: Type: text/plain, Size: 279 bytes --]

The following attachment had content that we can't
prove to be harmless.  To avoid possible automatic
execution, we changed the content headers.
The original header was:

	Content-Type: text/x-csrc; charset=us-ascii
	Content-Disposition: attachment; filename="popi2image.c"

[-- Attachment #2.2: popi2image.c.suspect --]
[-- Type: application/octet-stream, Size: 586 bytes --]

#include <u.h>
#include <libc.h>
#include <draw.h>
#include <memdraw.h>

#define DEF_X	248	/* image width  */
#define DEF_Y	248	/* image height */

void
main(void)
{
	int i;
	uchar *pix;
	Memimage *img;

	memimageinit();

	pix = (uchar*)malloc(DEF_X * DEF_Y);

	for (i = 0; i < DEF_Y; i++)
		if(readn(0, pix+i*DEF_X, DEF_X) != DEF_X) {
			fprint(2, "popi2image: read error\n", i);
			exits("read");
		}

	img = allocmemimage(Rect(0,0,DEF_X,DEF_Y), GREY8);
	loadmemimage(img, Rect(0,0,DEF_X,DEF_Y), pix, DEF_X*DEF_Y);
	writememimage(1, img);

	exits(0);
}

Re: [9fans] Pico (again)

[Dennis Ritchie]

I retrieved some of the pico-processed images that
were in the 10th edition manual:

http://www.cs.bell-labs.com/10thEdMan/v2pix.html


	Dennis

Re: [9fans] Pico (again)

[Fariborz (Skip) Tavakkolian]

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

I've attached my cheesy C version of display.bas that is in the package.
You can use it view the faces. It uses libXg that came with 9libs-1.0,
so the graphics model is understandable by a human being.

I've got popi running on Plan9 also. I guess I should have ask
the more direct question:

Why isn't a tool like pico available now? not chic anymore?

At 10:14 AM 7/18/2002 -0400, anothy@cosym.net wrote:
>just out of curiosity, i grabbed the popi stuff from holzmann's
>page and gave it a shot. popi, the portable pico, popi, compiles
>fine out of the box, although it runs into the buffered IO issue
>common to most unix command line programs on Plan 9. i've not
>checked to see that it does sensable things with images, though,
>mainly because i don't know what to do with popi's output. 
>
>the compiled version of pico available from holzmann's page
>doesn't compile. i put no effort into figuring out why. the notes
>on holzmann's page are not encouraging in this regard.
>
>i was not able to pull the version of pico described in Rakitzis'
>message, so it's untested.
>
>anyone got anything to deal with pico (v10 picfile(5)) images?
>ã‚¢

[-- Attachment #2: disp.c --]
[-- Type: text/plain, Size: 1014 bytes --]

#include	<u.h>
#include	<libc.h>
#include	<libg.h>

#define res 8

int threshold[res][res] = {
	{ 0,128,32,160,8,136,40,168}, 
	{ 192,64,224,96,200,72,232,104 },
	{ 48,176,16,144,56,184,24,152 },
	{ 240,112,208,80,248,120,216,88 },
	{ 12,140,44,172,4,132,36,164 },
	{ 204,76,236,108,196,68,228,100 },
	{ 60,188,28,156,52,180,20,148 },
	{ 252,124,220,92,244,116,212,84 }
};

main(int ac, char **av)
{
	FILE *infile;
	Point p;
	Event ev;
	register int x, y;

	if (ac < 2) {
		fprintf(stderr, "usage: %s filename\n", *av);
		exit(1);
	}
	if (! (infile = fopen(*(av+1), "r"))) {
		fprintf(stderr, "can't open %s\n", *(av+1));
		exit(1);
	}
	ac--;
	av++;

	xtbinit(0,0, &ac, av, 0);
	einit(Ekeyboard|Emouse);

	for (x = 0; x < 248; x++)
		for (y = 0; y < 248; y++) {
			int c;
			p = add(screen.r.min, Pt(y,x));
			if ((c = getc(infile)) == EOF)
				break;
			if (c <= threshold[x%res][y%res])
				point(&screen, p, ~0, S);
		}

	while(event(&ev) != Ekeyboard)
		continue;

	exit(0);
}

void
ereshaped(Rectangle r)
{
}

Re: [9fans] Pico (again)

[anothy]

just out of curiosity, i grabbed the popi stuff from holzmann's
page and gave it a shot. popi, the portable pico, popi, compiles
fine out of the box, although it runs into the buffered IO issue
common to most unix command line programs on Plan 9. i've not
checked to see that it does sensable things with images, though,
mainly because i don't know what to do with popi's output. 

the compiled version of pico available from holzmann's page
doesn't compile. i put no effort into figuring out why. the notes
on holzmann's page are not encouraging in this regard.

i was not able to pull the version of pico described in Rakitzis'
message, so it's untested.

anyone got anything to deal with pico (v10 picfile(5)) images?
ア

Re: [9fans] Pico (again)

[William Josephson]

In article, Fariborz Skip Tavakkolian wrote:
> wait.   I meant the other pico. I thought in this list at least the
> other one would be more famous.
> 
> http://cm.bell-labs.com/cm/cs/who/gerard/

I don't know if rsc did pico, but he did have a little
graphics compiler for the x86 at one point.  I doubt he
handed it out to anyone.

Re: [9fans] Pico (again)

[Fariborz (Skip) Tavakkolian]

You were talking about the dark ages, and I only meant the middle ages.

At 07:19 PM 7/17/2002 -0400, Sam wrote:
>There's my age showing again.

Re: [9fans] Pico (again)

[Fariborz (Skip) Tavakkolian]

wait.   I meant the other pico. I thought in this list at least the
other one would be more famous.

There is a link on this page to the original source; it is guaranteed not to compile
on any modern machines.
http://cm.bell-labs.com/cm/cs/who/gerard/

At 06:46 PM 7/17/2002 -0400, Sam wrote:
>Of course, now that I've thought about it if you're
>looking for an editor with the "simplicity" of
>pico you can always use the rio window buffer
>and snarf it into a file when you're done.
>
>Rob mentions this in his 8 1/2 paper (The editing,
>not the snarfing, iirc).
>
>Sam

Re: [9fans] Pico (again)

[Sam]

There's my age showing again.

Sorry about that.

Sam

On Wed, 17 Jul 2002, Fariborz (Skip)
Tavakkolian wrote:

> wait.   I meant the other pico. I thought in this list at least the
> other one would be more famous.
>
> There is a link on this page to the original source; it is guaranteed not to compile
> on any modern machines.
> http://cm.bell-labs.com/cm/cs/who/gerard/
>
> At 06:46 PM 7/17/2002 -0400, Sam wrote:
> >Of course, now that I've thought about it if you're
> >looking for an editor with the "simplicity" of
> >pico you can always use the rio window buffer
> >and snarf it into a file when you're done.
> >
> >Rob mentions this in his 8 1/2 paper (The editing,
> >not the snarfing, iirc).
> >
> >Sam
>

[9fans] Pico (again)

[Sam]

Of course, now that I've thought about it if you're
looking for an editor with the "simplicity" of
pico you can always use the rio window buffer
and snarf it into a file when you're done.

Rob mentions this in his 8 1/2 paper (The editing,
not the snarfing, iirc).

Sam