World: r3wp

I'm using the timers to have much better resolution in controling/measuring 
frame rates.

its not perfect, because the time events aren't very reliable, but 
at least I can measure some of mouse events and throttle them.

does chrono-time work for you?

I get:
** Script Error: vin has no value
** Where: chrono-time
** Near: vin ["chrono-time()"] 
vout 
GLOBAL_CHRONO-TIMED +

ohhh.... forgot to remove the call to 'VIN part of another library 
(also on rebol.org)

btw, how come you didn't want to use 'dt for 'time-lapse as in R3?

this could be part of 22-forward, I would think - at least for windows

i don't like acronyms like that.  I could have used time-delay   
but  time lapse is actually more precise meaning, especially when 
speaking about chronometers.

yes, maybe brianh could include this into R2/forwards... its MIT 
 so go ahead if it suits you.

dt is close to delta, or delta-time - it's used in math all the time

yeah... I think I also actually didn't want to overwrite the 'proper' 
word space from R3 with my own.


if brianH feels this is effective enough, then he can always put 
this into /forward and rename the function.

R2/Forward is all mezzanine code, no library calls, all cross-platform. 
But it is also MIT licensed, so do with it what you will.

'VIN fixed

As far as I can make out, Google Charts API works in R3 as well. 
 Project page:
http://www.ross-gill.com/page/Google_Charts_and_REBOL


Other marker types: line, arrow, cross, diamond, rectangle, diamond, 
square, horizontal lines, x.


They all follow the same basic structure: name, opt color, index, 
opt points, size, z-index.  See the page on Compound Charts for more 
info:


http://code.google.com/apis/chart/docs/gallery/compound_charts.html

(only one diamond)

I'm a little confused by that last statement.  Why would Google Charts 
API "not" work from any program that can call something to HTTP?

The api doesn't actually call HTTP, just generates the URL.

The API -- this script...

It does a lot of little conversions to drill it down to the URL, 
so I was pleased that it worked unmodified on R3 (doesn't always 
happen)

Did you try the link?

Also, 'chart takes an object as an argument too, so you can reuse 
data:

	sample: context [type: 'line data: [10 95 60 95 10] bars: none]
	browse chart sample
	sample/type: 'bar
	sample/bars: [55 8]
	browse chart sample

Go Chris go!

Yes, very cool stuff Chris. You are putting out nice web integration 
things, this, and twitter stuff. Very nice!

(does anyone have anything related to openId with rebol?)

Kaj, is it possible to wrap the result to fit the page?

if I say read %., it responds with not enough memory. curious error.

No, it means you tried to use more memory than I'm willing to let 
you on our server :-)

That's explained in the introduction text on the start page

Oh wait, this one is different. That would have happened if there 
are already very many REBOL expression files in the folder. But for 
some reason, R3 now yields this result if you don't add a /

So it may be doing something weird that is caught by the set resource 
limits

I chose not to wrap the expression result to provide the purest evaluation 
result

Very cool Max!

I'm working on using radial fill-pens, but as expected... its VERY 
heavy.

Very nice...for a days work....


Radial Fill-pens....that's what I was working with. did not get too 
far

I've got fire done... tweaking it... but its easily 2 to 3 times 
heavier cpu-wise.

Is there much improvement to it visually?

for fire not much, a part that its a bit softer... though I am now 
trying to change the shape of the fill and cirlce so its a vertical 
ellipsis.. this should hel make the flames more or less lines..

bah, its just too much cpu... with the smoke... it end ups eating 
7-10 more cpu, and I can't crank up the rate past 70 so its really 
bad.


with normal circles, I can up the rate to 500 and just make things 
less opaque and the end result is much prettier.

Great work.

I'm about to upload a new version... flame quality is really better 
and the default setup is really neet.

Great stuff Max. It saves the setup, but doesn't seem to reapply 
it on startup. Is that correct? I had a good looking smoke and flame 
I wanted to share, but then closed the app again. Setting the smoke 
life to a smaller value greatly reduces the "bubble" effect and makes 
it look *really* nice.


The Smoke Darkness slider doesn't seem to initialize to the correct 
value. e.g. move it slightly and the smoke color changes dramatically 
the first time.

the latest version saves all the birth points and their life span, 
but doesn't save out the "looks" properties yet.


about the smoke color slider... yes... I forgot to change it to light 
color.

Thanks for updating INCLUDE Ladislav! I use it a lot, and this will 
give me more reason to try some things under R3.

I'll just copy my email here, as I don't know everybody's on the 
ML:


This is great! First real R3 extension. Just few suggestions overall:


- we should not really forget about using schemes/ports - aproach 
you used is really an old-school, non rebolish. Surely useable, but 
maybe I am just too much used to nice other-rebol-db-driver interfaces. 
As for ports and blocking argument - wasn't R2 ODBC eventually blocking 
too?


- embedded extension is nice, but as well as for SQLite Robert did, 
I suggest to use DLL aproach, with tiny wrapper - you save novices 
from the need to set-up the compiler.


Other than that, I am very surprised that somene actually finally 
produced something VERY usefull, along with nice docs. Just - wow, 
and thanks :-)

Thanks, Petr, you're feedback is appreciated! Just some comments: 
Yes, I was thinking *ports*, too, but with R3, the not yet available 
*devices* will be an even better way to go. The API with open-* and 
close-* isn't really nice but it's not yet set in stone, no way. 
Definitely I'll compile to a DLL, too, that's just a matter of time.

Christian... compiling to a db, requires two lines of text to change 
in you C code, and a change in compiler so that it compiles as a 
dll instead of an exe.   really. it takes 15 minutes to change (I 
did so as a test with one extension I was using to try out the new 
interface)

on top of it, you won't have to play around with updating your host 
itself each time a new release is done.   The host itself which is 
subject to change very often right now.

These two lines, Max, should be somet #define REB_EXT and a RXI_LIB 
RL  declaration, but that doesn't get me too far. This "15 minute 
 change" is going to cost me hours ;-) And the funny thing is that 
I had it working as a DLL first with A102/A103 and then changed to 
embedded extension. Now I don't find my way back ...

looking at it now... there are a few changes... but look at this 
code by Andreas, and it should get you up and running within minutes... 
basically copy/paste all the appropriate stuff and change what is 
specific to your code.

https://gist.github.com/0677266b8511d83ce76a

That's what I was doing, the comiler still is complaining about missing 
stuff. Will have a look into this tomorrow.