[9fans] pico

[9fans] pico

[Fariborz (Skip) Tavakkolian]

is there anything like it in Plan9?

Re: [9fans] pico

[Sam]

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

> is there anything like it in Plan9?
>
Does ed(1) count?

(no, there isn't)

Sam

Re: [9fans] How to read/write pixels from Memimage

[Pietro Gagliardi]

That transformation is in the book? It divides by zero for y == 0. I  
have to look.

I'm working on an update. It adds:
	r x y w h file (done)
		Reads a certain rectangle of a file. This makes crop(1)'s -r option  
three lines of rc or /bin/sh:
			echo 'r '$1' '$2' '$3' '$4' '$5'
			new = old
			w '$6 | pico
	Simple variables (started)
	Undo command u (done)
	Use of RGB24 instead of RGBA32 to make the examples work (done)
	Using Brdstr instead of Bgetc/Bungetc (this is not working)

On Jan 27, 2008, at 1:05 PM, Skip Tavakkolian wrote:

>> The code led me to confusion, so I just decided to use wordaddr. It
>> works properly now,  and my Pico is now up at /n/sources/contrib/
>> pietro/pico9.tgz (note the 9). Details are in README.Plan9, test
>> files are in /lib/face/.
>
> some book examples are failing:
>
> cpu% 8.out
> 1:	new[x,y] = x % y
> 8.out 181613: suicide: sys: trap: divide error pc=0x000023fd
>

[9fans] pico

[Steve Simon]

FYI

Byron Rakitzis (of posix rc fame) produced a version popi with the JIT
compiler, though sadly his where for cpus which are common cpus these days.

Also possibly of interest is the paper from the 10th edition manual
http://plan9.bell-labs.com/10thEdMan/pico.pdf

And a few fun pictures that where generated
http://plan9.bell-labs.com/10thEdMan/v2pix.html

-Steve

Re: [9fans] pico

[Russ Cox]

> Byron Rakitzis (of posix rc fame) produced a version popi with the JIT
> compiler, though sadly his where for cpus which are common cpus these days.

Computers and compilers are fast enough now
that you can get away with just feeding code
into a C compiler instead of writing a full JIT.
And there's no porting to do!

I just put a pico on sources that does this - 738 lines,
not many of which are the "JIT".

9fs sources
cd /n/sources/contrib/rsc/pico
mk demo

Russ

Re: [9fans] pico

[Pietro Gagliardi]

Wow, that's very impressive!

	open: /tmp/something does not exist (2x)
	no image lerp
	no image doug

But you have a preview, which I was going to add soon.

I am sticking with my code interpreter because I know how to use one  
(I toiled over hoc. and fossil ate my code up last December) and it  
doesn't require hooking to a C compiler. I do like the preprocessor  
idea though.

On Jan 28, 2008, at 6:36 PM, Russ Cox wrote:

>> Byron Rakitzis (of posix rc fame) produced a version popi with the  
>> JIT
>> compiler, though sadly his where for cpus which are common cpus  
>> these days.
>
> Computers and compilers are fast enough now
> that you can get away with just feeding code
> into a C compiler instead of writing a full JIT.
> And there's no porting to do!
>
> I just put a pico on sources that does this - 738 lines,
> not many of which are the "JIT".
>
> 9fs sources
> cd /n/sources/contrib/rsc/pico
> mk demo
>
> Russ
>

Re: [9fans] pico

[Bruce Ellis]

well i agree that russ did a good job but JITs are fun and often
make things 10 times faster.

brucee

On Jan 29, 2008 11:30 AM, Pietro Gagliardi <pietro10@mac.com> wrote:
> Wow, that's very impressive!
>
>        open: /tmp/something does not exist (2x)
>        no image lerp
>        no image doug
>
> But you have a preview, which I was going to add soon.
>
> I am sticking with my code interpreter because I know how to use one
> (I toiled over hoc. and fossil ate my code up last December) and it
> doesn't require hooking to a C compiler. I do like the preprocessor
> idea though.
>
>
> On Jan 28, 2008, at 6:36 PM, Russ Cox wrote:
>
> >> Byron Rakitzis (of posix rc fame) produced a version popi with the
> >> JIT
> >> compiler, though sadly his where for cpus which are common cpus
> >> these days.
> >
> > Computers and compilers are fast enough now
> > that you can get away with just feeding code
> > into a C compiler instead of writing a full JIT.
> > And there's no porting to do!
> >
> > I just put a pico on sources that does this - 738 lines,
> > not many of which are the "JIT".
> >
> > 9fs sources
> > cd /n/sources/contrib/rsc/pico
> > mk demo
> >
> > Russ
> >
>
>

Re: [9fans] pico

[Pietro Gagliardi]

In the latest update, I tried adding differentiating between color  
and b/w images. However, I can't test anything because every time I  
try a line like

	x new = dennis

I get something that ends in "(double-free?)" and then the program  
crashes, but something like

	x new
	x new =

do call the error() function. The lexer did not change since I  
started this update, but it did change when I improved symbol handling.

On Jan 29, 2008, at 12:30 AM, Bruce Ellis wrote:

> well i agree that russ did a good job but JITs are fun and often
> make things 10 times faster.
>
> brucee
>
> On Jan 29, 2008 11:30 AM, Pietro Gagliardi <pietro10@mac.com> wrote:
>> Wow, that's very impressive!
>>
>>        open: /tmp/something does not exist (2x)
>>        no image lerp
>>        no image doug
>>
>> But you have a preview, which I was going to add soon.
>>
>> I am sticking with my code interpreter because I know how to use one
>> (I toiled over hoc. and fossil ate my code up last December) and it
>> doesn't require hooking to a C compiler. I do like the preprocessor
>> idea though.
>>
>>
>> On Jan 28, 2008, at 6:36 PM, Russ Cox wrote:
>>
>>>> Byron Rakitzis (of posix rc fame) produced a version popi with the
>>>> JIT
>>>> compiler, though sadly his where for cpus which are common cpus
>>>> these days.
>>>
>>> Computers and compilers are fast enough now
>>> that you can get away with just feeding code
>>> into a C compiler instead of writing a full JIT.
>>> And there's no porting to do!
>>>
>>> I just put a pico on sources that does this - 738 lines,
>>> not many of which are the "JIT".
>>>
>>> 9fs sources
>>> cd /n/sources/contrib/rsc/pico
>>> mk demo
>>>
>>> Russ
>>>
>>
>>

Re: [9fans] pico

[Pietro Gagliardi]

This only happens with black/white images, I ran a color image (boyd)  
through and it worked fine. I think it's with the run function...

On Jan 29, 2008, at 3:33 PM, Pietro Gagliardi wrote:

> In the latest update, I tried adding differentiating between color  
> and b/w images. However, I can't test anything because every time I  
> try a line like
>
> 	x new = dennis
>
> I get something that ends in "(double-free?)" and then the program  
> crashes, but something like
>
> 	x new
> 	x new =
>
> do call the error() function. The lexer did not change since I  
> started this update, but it did change when I improved symbol  
> handling.
>
> On Jan 29, 2008, at 12:30 AM, Bruce Ellis wrote:
>
>> well i agree that russ did a good job but JITs are fun and often
>> make things 10 times faster.
>>
>> brucee
>>
>> On Jan 29, 2008 11:30 AM, Pietro Gagliardi <pietro10@mac.com> wrote:
>>> Wow, that's very impressive!
>>>
>>>        open: /tmp/something does not exist (2x)
>>>        no image lerp
>>>        no image doug
>>>
>>> But you have a preview, which I was going to add soon.
>>>
>>> I am sticking with my code interpreter because I know how to use one
>>> (I toiled over hoc. and fossil ate my code up last December) and it
>>> doesn't require hooking to a C compiler. I do like the preprocessor
>>> idea though.
>>>
>>>
>>> On Jan 28, 2008, at 6:36 PM, Russ Cox wrote:
>>>
>>>>> Byron Rakitzis (of posix rc fame) produced a version popi with the
>>>>> JIT
>>>>> compiler, though sadly his where for cpus which are common cpus
>>>>> these days.
>>>>
>>>> Computers and compilers are fast enough now
>>>> that you can get away with just feeding code
>>>> into a C compiler instead of writing a full JIT.
>>>> And there's no porting to do!
>>>>
>>>> I just put a pico on sources that does this - 738 lines,
>>>> not many of which are the "JIT".
>>>>
>>>> 9fs sources
>>>> cd /n/sources/contrib/rsc/pico
>>>> mk demo
>>>>
>>>> Russ
>>>>
>>>
>>>
>

Re: [9fans] pico

[Russ Cox]

> I get something that ends in "(double-free?)" and then the program  
> crashes, but something like

This usually means you have freed the same pointer twice
or you are passing a pointer to free that was not returned
by malloc.  If you run acid to get a stack trace to see the
context of the free, that is often enough to identify the
problem.

% acid pid
acid: stk()
...
^D
%

Russ

Re: [9fans] pico

[Pietro Gagliardi]

In this case, it only told me where the program crashed, which told  
me nothing on why (because a different line or a color image worked).

On Jan 29, 2008, at 5:46 PM, Russ Cox wrote:

>> I get something that ends in "(double-free?)" and then the program
>> crashes, but something like
>
> This usually means you have freed the same pointer twice
> or you are passing a pointer to free that was not returned
> by malloc.  If you run acid to get a stack trace to see the
> context of the free, that is often enough to identify the
> problem.
>
> % acid pid
> acid: stk()
> ...
> ^D
> %
>
> Russ
>

Re: [9fans] pico

[Bruce Ellis]

work it out.  it's called debugging.

brucee

On Jan 30, 2008 12:13 PM, Pietro Gagliardi <pietro10@mac.com> wrote:
> In this case, it only told me where the program crashed, which told
> me nothing on why (because a different line or a color image worked).
>
>
> On Jan 29, 2008, at 5:46 PM, Russ Cox wrote:
>
> >> I get something that ends in "(double-free?)" and then the program
> >> crashes, but something like
> >
> > This usually means you have freed the same pointer twice
> > or you are passing a pointer to free that was not returned
> > by malloc.  If you run acid to get a stack trace to see the
> > context of the free, that is often enough to identify the
> > problem.
> >
> > % acid pid
> > acid: stk()
> > ...
> > ^D
> > %
> >
> > Russ
> >
>
>

Re: [9fans] pico

[Pietro Gagliardi]

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

What do you think I've been doing? :-)

The problem seems to be in run(), because after run() returns,  
poolcheck fails. I'll go check it out.

On Jan 30, 2008, at 1:53 AM, Bruce Ellis wrote:

> work it out.  it's called debugging.
>
> brucee


[-- Attachment #2: Type: text/html, Size: 903 bytes --]

Re: [9fans] pico

[Pietro Gagliardi]

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

Well, I got the memory tampering bugs fixed, but a black and white  
image now does not show correctly. Gonna go back and check and fix.  
Will report when I put a new version up.

On Jan 30, 2008, at 6:42 PM, Pietro Gagliardi wrote:

> What do you think I've been doing? :-)
>
> The problem seems to be in run(), because after run() returns,  
> poolcheck fails. I'll go check it out.
>
> On Jan 30, 2008, at 1:53 AM, Bruce Ellis wrote:
>
>> work it out.  it's called debugging.
>>
>> brucee
>


[-- Attachment #2: Type: text/html, Size: 1410 bytes --]

Re: [9fans] pico

[Bruce Ellis]

more debugging, please tell us about it.  yawn.

On Jan 31, 2008 10:55 AM, Pietro Gagliardi <pietro10@mac.com> wrote:
>
> Well, I got the memory tampering bugs fixed, but a black and white image now
> does not show correctly. Gonna go back and check and fix. Will report when I
> put a new version up.
>
>
>
> On Jan 30, 2008, at 6:42 PM, Pietro Gagliardi wrote:
>
> What do you think I've been doing? :-)
>
> The problem seems to be in run(), because after run() returns, poolcheck
> fails. I'll go check it out.
>
> On Jan 30, 2008, at 1:53 AM, Bruce Ellis wrote:
>
> work it out.  it's called debugging.
>
> brucee
>
>

Re: [9fans] pico

[Pietro Gagliardi]

Okay, I got everything fixed a few days ago and added some more
features (simple arrays, r "long/file/name.1", etc.). The new pico is
in the usual place.

I'm redesigning my website, so I'm going to have my software
available from there too when that's done.

On Jan 31, 2008, at 2:41 AM, Bruce Ellis wrote:

> more debugging, please tell us about it.  yawn.
>
> On Jan 31, 2008 10:55 AM, Pietro Gagliardi <pietro10@mac.com> wrote:
>>
>> Well, I got the memory tampering bugs fixed, but a black and white
>> image now
>> does not show correctly. Gonna go back and check and fix. Will
>> report when I
>> put a new version up.
>>
>>
>>
>> On Jan 30, 2008, at 6:42 PM, Pietro Gagliardi wrote:
>>
>> What do you think I've been doing? :-)
>>
>> The problem seems to be in run(), because after run() returns,
>> poolcheck
>> fails. I'll go check it out.
>>
>> On Jan 30, 2008, at 1:53 AM, Bruce Ellis wrote:
>>
>> work it out.  it's called debugging.
>>
>> brucee
>>
>>