World: r3wp

does it work for you?

not quite - the correct path is still prefixed with the directory 
of the rebol exe

** Access Error: Cannot open /C/dev/r2/C:\Windows/system32/Kernel32.dll
** Near: k32-lib: load/library join to-file get-env

need a leading "/" to make it an absolute path, no?

oops... to-file should be  'TO-REBOL-FILE

OK, now

ok, will update rebol.org file.

I get:

>> do http://www.rebol.org/download-a-script.r?script-name=windows-chrono.r
connecting to: www.rebol.org
Script: "Chrono - High-precision time measurement" (24-Aug-2010)
** Script Error: Feature not available in this REBOL
** Near: i64-struct: make struct! [
    low [integer!]
    hi [integer!]
] [0 0]
>>

you are not using the latest rebol which has library support for 
free.

2.7.7 or higher?

2.7.7

core or view?   AFAIK only the view version has the library support.

Library support requires /View for now, not /Core.

that was core - with view, it works

what was the reason for limiting it to /View?

It was limited to /View before. That limitation was just not removed 
yet. 2.7.7 was put out quickly.

I get significantly varying results from consecutive executions of 
 print ".". Is this typical?

>> probe time-lapse [print "."]
.
0:00:00.000521096
== 0:00:00.000521096
>> probe time-lapse [print "."]
.
0:00:00.001658861
== 0:00:00.001658861
>> probe time-lapse [print "."]
.
0:00:00.001802788
== 0:00:00.001802788
>> probe time-lapse [print "."]
.
0:00:00.00178686
== 0:00:00.00178686
>> probe time-lapse [print "."]
.
0:00:00.001694701
== 0:00:00.001694701
>> probe time-lapse [print "."]
.
0:00:00.001815304
== 0:00:00.001815304
>> probe time-lapse [print "."]
.
0:00:00.001718594
== 0:00:00.001718594
>> probe time-lapse [print "."]
.
0:00:00.0017971
== 0:00:00.0017971
>> probe time-lapse [print "."]
.
0:00:00.001743625
== 0:00:00.001743625
>> probe time-lapse [print "."]
.
0:00:00.002421733
== 0:00:00.002421733
>> probe time-lapse [print "."]
.
0:00:00.002234001
== 0:00:00.002234001
>> probe time-lapse [print "."]
.
0:00:00.001800513
== 0:00:00.001800513
>> probe time-lapse [print "."]
.
0:00:00.001718594
== 0:00:00.001718594
>>

On Windows, yes. You will get varying results on anything. It's a 
non-real-time multitasking thing.

sure, I would expect some variation, but this seems a bit large

anyhow, this should be averaged over thousands of executions to get 
a more accurate value

Anything that requires traditional I/O (not OpenGL or DirectX) will 
have a lot of variation on Windows. Video games use timers and delays 
to get consistent behavior.

adrian, its up to you to put a loop in the block.

but, you can get a feel for relative speeds.... sine, on my system 
takes a little over 0.000015 seconds on average.  when I run the 
timer with a loop of 100000 It takes about 1.5 seconds... so the 
resolution of the timer is factual.

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