Test cases... for CORNER/CENTER rendering?

[Stuart Axon]

Hi,
I've been working on a toy implementation of shoebot, to try out a few things I've mentioned on the mailinglist.
It's semi from scratch (checking shoebot and nodebox code where possible).

******************************************************************************
My mac isn't working, if anybody can think of some test cases for CORNER/
CENTER and get some screenshots from nodebox on the mac, it'd be really good.
******************************************************************************

I think I can get both transform modes working, but I might be completely wrong :)
- Having asked the cairo list and looked at nodebox-javas source.


I've commited the sin of premature optimisation with this - everything is built in ways
I think *should* be faster, but I won't know until almost everything is working.


Fixes so far:
size(), background(). Can be called anywhere, only the last time actually matters
background() - is not affected by transforms (in shoebot try rotating then doing background)
size() can take variables
bot is always only run once per frame


Performance:
Drawing model:
Draw commands are returned as functions (closures), which are
added to a queue.

After the bot has run a frame, each command on the queue is called,
passed the context to act on.
I try and avoid if/elif blocks in favour of function references wherever possible
PathElements are only created when requested


Future performance:
Since running the bot and rendering is seperate, I'm wondering whether this could happen in different
threads (or even have more than one rendering thread).

PyPy - The next release will be able to run C Extensions, hopefully whichever version of shoebot will too.


API:
Where possible I'm trying to not add anything to the public API that isn't in nodebox, e.g. Bot.run is avoided



Will it work?
I hope so


Once I get everything working I'll try and merge back into a branch of shoebot
(right now everything is in a single file).

S++

[Sebastian Oliva]

Hi,
 I've been working on a toy implementation of shoebot, to try out a few things I've mentioned on the mailinglist.
It's semi from scratch (checking shoebot and nodebox code where possible).
******************************************************************************
My mac isn't working, if anybody can think of some test cases for CORNER/
CENTER and get some screenshots from nodebox on the mac, it'd be really good.
******************************************************************************
I think I can get both transform modes working, but I might be completely wrong :)
- Having asked the cairo list and looked at nodebox-javas source.
I've commited the sin of premature optimisation with this - everything is built in ways
I think *should* be faster, but I won't know until almost everything is working.
 size(), background().  Can be called anywhere, only the last time actually matters
 background()  - is not affected by transforms  (in shoebot try rotating then doing background)
 size()  can take variables
 bot is always only run once per frame
   Draw commands are returned as functions (closures), which are
added to a queue.
After the bot has run a frame, each command on the queue is called,
passed the context to act on.
 I try and avoid if/elif blocks in favour of function references wherever possible
 PathElements are only created when requested
 Since running the bot and rendering is seperate, I'm wondering whether this could happen in different
 threads (or even have more than one rendering thread).
 PyPy - The next release will be able to run C Extensions, hopefully whichever version of shoebot will too.
 Where possible I'm trying to not add anything to the public API that isn't in nodebox, e.g. Bot.run is avoided
Will it work?
  I hope so
Once I get everything working I'll try and merge back into a branch of shoebot
(right now everything is in a single file).
 S++
_______________________________________________
Shoebot-devel mailing list
http://lists.tinkerhouse.net/listinfo.cgi/shoebot-devel-tinkerhouse.net

Great, I have nodebox on my Mac, send me some files, and I'll test
them as soon as possible.
It would be real cool for you do merge the changes on to shoebot
Do you have a public repositore to look on the changes?

Regards
Seb

[Stuart Axon]

Post by Sebastian Oliva
I have nodebox on my Mac, send me some files, and I'll test

them as soon as

Post by Sebastian Oliva
possible.

It would be real cool for you do merge the changes on to

Post by Sebastian Oliva
shoebot

Do you have a public repositore to look on the

Post by Sebastian Oliva
changes?
Regards
Seb

I'll put it up tomorrow...

At the moment the code only outputs to SVGs, so I won't know if the
performance
makes any difference until everything is working.

The code is pretty experimental at the moment, I want to try and get it
right before
integrating it with the shoebot code (especially the APIs on how to call shoebot).

Once it's right I'll take it all apart again and put integrate it into the shoebot
structure.

S++

[ricardo lafuente]

Post by Stuart Axon
Hi,
I've been working on a toy implementation of shoebot, to try out a few things I've mentioned on the mailinglist.
It's semi from scratch (checking shoebot and nodebox code where possible).
******************************************************************************
My mac isn't working, if anybody can think of some test cases for CORNER/
CENTER and get some screenshots from nodebox on the mac, it'd be really good.
******************************************************************************

I can also help with Nodebox comparisons!

This reminds me, our examples/ dir is badly in need of restructuring.
Especially the nodebox/ directory, which seems to have become a
collection of scripts and tests which wouldn't fit elsewhere...

Post by Stuart Axon
I think I can get both transform modes working, but I might be completely wrong :)
- Having asked the cairo list and looked at nodebox-javas source.

Awesome :-) Did you run into what might be causing the oddness you
reported regarding transformations that wouldn't be applied?

Post by Stuart Axon
I've commited the sin of premature optimisation with this - everything is built in ways
I think *should* be faster, but I won't know until almost everything is working.

That's also my way of working, for better and worse :) In order to
minimise the risk of regressions, we do need a set of unit tests, as has
been mentioned multiple times on the list. More on that below.

Post by Stuart Axon
size(), background(). Can be called anywhere, only the last time actually matters
background() - is not affected by transforms (in shoebot try rotating then doing background)
size() can take variables
bot is always only run once per frame

This is GREAT stuff, awesome stuff indeed! I've been running into these
hurdles one too many times while showcasing Shoebot.

Post by Stuart Axon
Draw commands are returned as functions (closures), which are
added to a queue.

Wow, this is *very* clever. I'm really interested in seeing how this
works out code-wise.

Post by Stuart Axon
After the bot has run a frame, each command on the queue is called,
passed the context to act on.
I try and avoid if/elif blocks in favour of function references wherever possible
PathElements are only created when requested

Again, dying to see this.

Post by Stuart Axon
Since running the bot and rendering is seperate, I'm wondering whether this could happen in different
threads (or even have more than one rendering thread).

Maybe running the risk of sounding over-enthusiastic, but this is a very
very good idea. This reminds me of the constant complaints about threads
in Python, but you sound like you know what you're talking about ;-)

Post by Stuart Axon
PyPy - The next release will be able to run C Extensions, hopefully whichever version of shoebot will too.

I'm curious about how PyPy can benefit Shoebot.

Post by Stuart Axon
Where possible I'm trying to not add anything to the public API that isn't in nodebox, e.g. Bot.run is avoided

This is a good concern, and thanks for taking that into account.
However, feel free to test and expand the API whenever you think it's
appropriate. Nodebox is of course the main reference, but we can
definitely go further whenever that's warranted.

Post by Stuart Axon
Will it work?
I hope so

Fingers crossed :o)

Post by Stuart Axon
Once I get everything working I'll try and merge back into a branch of shoebot
(right now everything is in a single file).

Hey, if you need testing, point us to your working repository once you
have it!



After this, some thoughts of stuff we could think about working on:

* Unit tests: We should probably plan an IRC sprint of sorts to tackle
our lack of proper unit tests to check for eventual regressions. It
shouldn't be hard -- write/borrow the tests (Nodebox and Cairo have good
sources) and create images of expected results. Another enhancement
would be to have a 'dummy' back-end that would just spit out a report
(or even a Shoebot script) in order to check if stuff is coming out as
it should.

* Examples cleanup: Not sure about how we should organise our example
scripts, and there's also a lot of redundant cruft, e.g. the basic/
directory, which IIRC was written a long time ago by Paulo in a coding
style that is far away from PEP8 recommendations.

* Debian packaging: I've done 80% of the work here, i just need to sit
down for another couple of hours in order to wrap this longstanding
issue. The gem would be to have nightly builds available, which should
be relatively easy once we have the proper packages.

* Website structure: Stuff is shaky since the move to Wordpress and i
was planning to switch to yet another CMS, but Sebastian stepped forward
to fix the inconsistencies in the current website. Sebastian also kindly
offered to maintain our Trac, which IMHO turned out to be a bit too
complex to be of daily use...

I'd say that all this is doable before the LGM, which is a great excuse
to set the 0.3 milestone to mid-May. I'm planning on presenting a
Lightning talk on Shoebot with quick practical examples of its use --
for instance, i recently made a logo generator for this company who
wanted this generative identity; would be great to have your own
experiences of what you used Shoebot for!

Any other ideas out there for where we should go?

[Stuart Axon]

Sent: Wed, May 5, 2010 10:59:40 AM
Subject: Re: [shoebot-devel] Test cases... for CORNER/CENTER rendering?
Hi,
I've
been working on a toy implementation of shoebot, to try out a few things I've
mentioned on the mailinglist.
It's semi from scratch (checking shoebot
and nodebox code where possible).
******************************************************************************
My mac isn't working, if anybody can think of some test cases for CORNER/
CENTER and get some screenshots from nodebox on the mac, it'd be really good.
******************************************************************************

I

can also help with Nodebox comparisons!

Cool. I'll put up the initial repository a bit later (when I unbreak it).
For the moment all the code is just in one shoebot.py, so it'll
just be that and some test bots.

This reminds me, our examples/
dir is badly in need of restructuring. Especially the nodebox/ directory, which
seems to have become a collection of scripts and tests which wouldn't fit
elsewhere...

I should also put up some code I did as the start of a music vis and animation
system, however it's not really ready enough to include in shoebot.
- I tried the wiki, but it doesn't let you upload screenshots yet.
- Also we need an extension installed to display the code with syntax highlighting

Post by Stuart Axon
I think I can get both transform modes working, but I
might be completely wrong :)
- Having asked the cairo list and looked at
nodebox-javas source.

Awesome :-) Did you run into what might be causing
the oddness you reported regarding transformations that wouldn't be
applied?

Sorry, couldn't remember if I emailed the list about this.
- I found out it's only happening in Windows, so switched my primary
development to Linux for now (which is faster even with software
opengl).
I haven't found out, but it might be easier to work out after this
as I'll have a better handle on how the bot draws stuff.

Post by Stuart Axon
I've commited the sin of premature optimisation with this -
everything is built in ways
I think *should* be faster, but I won't know
until almost everything is working.

That's also my way of working, for
better and worse :) In order to minimise the risk of regressions, we do need a
set of unit tests, as has been mentioned multiple times on the list. More on
that below.

Post by Stuart Axon
size(),
background(). Can be called anywhere, only the last time actually
matters
background() - is not affected by
transforms (in shoebot try rotating then doing background)
size() can take variables
bot is always only
run once per frame

This is GREAT stuff, awesome stuff indeed! I've been
running into these hurdles one too many times while showcasing
Shoebot.

Post by Stuart Axon
Drawing
Draw commands are returned as functions
(closures), which are
added to a queue.

Wow, this is *very*
clever. I'm really interested in seeing how this works out
code-wise.

Post by Stuart Axon
After the bot has run a frame, each command on the queue
is called,
passed the context to act on.
I try and
avoid if/elif blocks in favour of function references wherever
possible
PathElements are only created when
requested

Again, dying to see this.

Post by Stuart Axon
Future
Since running the bot and rendering is
seperate, I'm wondering whether this could happen in different
threads (or even have more than one rendering thread).

Maybe
running the risk of sounding over-enthusiastic, but this is a very very good
idea. This reminds me of the constant complaints about threads in Python, but
you sound like you know what you're talking about ;-)

True, I was thinking about the multiprocessing module, but I have no idea about
how easy this is, or how easy it is to pass variables to different processes
with this.

I am kind of hoping the other changes make a difference to the speed.

PyPy - The next release will be able to run C Extensions, hopefully whichever
version of shoebot will too.
I'm curious about how PyPy can benefit
Shoebot.

- And I forgot the next version of cairo with cairo-gl, I think this should probably
be ready by the end of the year too.

Where possible I'm trying to not
add anything to the public API that isn't in nodebox, e.g. Bot.run is
avoided
This is a good concern, and thanks for taking that into account.
However, feel free to test and expand the API whenever you think it's
appropriate. Nodebox is of course the main reference, but we can definitely go
further whenever that's warranted.

- I'm thinkingof maybe DrawBot, NodeBox and ShoeBot bots... however this
is a lot further ahead than I am right now.

Post by Stuart Axon
Will it work?
I hope so

Fingers crossed :o)

Post by Stuart Axon
Once I get everything
working I'll try and merge back into a branch of shoebot
(right now
everything is in a single file).

Hey, if you need testing, point us to
your working repository once you have it!
After this, some
* Unit tests: We
should probably plan an IRC sprint of sorts to tackle our lack of proper unit
tests to check for eventual regressions. It shouldn't be hard -- write/borrow
the tests (Nodebox and Cairo have good sources) and create images of expected
results. Another enhancement would be to have a 'dummy' back-end that
would just spit out a report (or even a Shoebot script) in order to check if
stuff is coming out as it should.

I guess there are two parts, tests in the form of Bots, and test coverage
of the shoebot code itself.

Cairo has a performance suite you can run any cairo based app through, to
find performance bottlenecks.

* Examples cleanup: Not sure about how
we should organise our example scripts, and there's also a lot of redundant
cruft, e.g. the basic/ directory, which IIRC was written a long time ago by
Paulo in a coding style that is far away from PEP8 recommendations.
*
Debian packaging: I've done 80% of the work here, i just need to sit down for
another couple of hours in order to wrap this longstanding issue. The gem would
be to have nightly builds available, which should be relatively easy once we
have the proper packages.
* Website structure: Stuff is shaky since the
move to Wordpress and i was planning to switch to yet another CMS, but Sebastian
stepped forward to fix the inconsistencies in the current website. Sebastian
also kindly offered to maintain our Trac, which IMHO turned out to be a bit too
complex to be of daily use...
I'd say that all this is doable before the
LGM, which is a great excuse to set the 0.3 milestone to mid-May. I'm planning
on presenting a Lightning talk on Shoebot with quick practical examples of its
use -- for instance, i recently made a logo generator for this company who
wanted this generative identity; would be great to have your own experiences of
what you used Shoebot for!
Any other ideas out there for where we should
go?

_______________________________________________
Shoebot-devel mailing

list

http://lists.tinkerhouse.net/listinfo.cgi/shoebot-devel-tinkerhouse.net