World: r4wp

cycle: func ["Cycle a series through its index."
	'series [word!]
	/local s
][
	either tail? s: get series [
		set series  next head s
		first head s
	][
		set series  next s
		s/1
	]
]

Nice one!

Branch `lex-scope` merged in master.

It seems that the optional attributes and function description are 
swapped in Red/System compared to REBOL. Is that intentional?

http://www.rebol.com/r3/docs/concepts/funcs-defining.html#section-1

Yes, it makes it easier and faster to find optional attributes this 
way.

We could change it though, it's no significant impact on the compiler.

I believe REBOL allows either order, so it's just the docs that say 
it has to be that way.

I like the REBOL order better in the formatting of the program

I can see arguments both ways. Attrs are short, and having them first 
makes them easier to see, because they will be used far less than 
doc strings. OTOH, being used less makes them feel "more optional" 
than doc strings, hence could come after the doc string.

This would be a great question for Carl, as to why he did it the 
way he did it in REBOL. That is, allowing either order.

I like to put the function description on the same line as the function 
name, so it's easy to scan through a program text for them. Having 
the attributes in front of it makes the line too long and hides the 
atrributes in the text

So when there are attributes, I have to move the description in line 
with the arguments, where it becomes hidden because it's not lined 
up with the other function descriptions

Kaj: I've pushed a change in attributes handling for Red/System functions, 
you can now specify attributes or function's description doc-string 
in any order. I've replaced direct spec block access for attributes 
by a function call in deep compiler's code parts, so watch out for 
regressions especially in callbacks!

Fast response, thanks!

Pekr mentioned on 7-Jun-2012 in this group that an OpenCV binding 
was coming, but I can't find it anywhere.  Does anyone know if it 
exists?

Good question. I have no idea where Petr pulled that from

OpenCV binding is done by François Jouen, it's a work in progress. 
There's a Red/System version that you could find from this page (in 
french):


http://www.digicamsoft.com/cgi-bin/rebelBB.cgi?thread=%3C25May2012200150764026200%3E


There's a Red version that François sent me privately a few days 
ago for testing, but I haven't had the time yet to review it.

François showed me a few nice demos done with that binding a couple 
of weeks ago when I visited him in Paris. He had some camera-controlling 
and image recognition demos done from Red(/System).

Any chance he'd be willing to share his Red/System code?  I want 
to do something similar, and it would be great if I could see working 
examples!

Oh, I see he has a samples.zip file in that link you posted above.

Right.

I will ask him for the latest version tomorrow.

Very cool

This would be a good thing to add to the Contributions page on red-lang.org. 
:-)  (I looked there first for the OpenCV binding)

I wish I could work with Red instead of at my regular job. :-/

I see it's another library that dug itself into a C++ hole

Compilation time seems to be reported modulo one minute or so, at 
least in the Red/System compilation phase

Dyn-lib-emitter branch upgraded to match master.

Cool!

Now we need to make those Red functions callable from outside. ;-)

No problem, I can just make a Red/System callback with a Red callback 
:-)

I would like to add an #export option directly at Red level, with 
automatic argument marshalling...will be handier. ;-)

No argument here :-)

Branch `fix-385` merged in master.

Added OpenCV to contributions page, François sent me the link for 
the latest version and says that it can be now used in production.

http://www.wuala.com/fjouen/Code/OpenCV/Red/

Cool to see!

Btw - I noticed you tweeted about the LeapMotion - what's your first 
impression?

François also did a binding for the DAQmxBase v3.6 lib that can be 
found here:
http://www.wuala.com/fjouen/Code/NI/Red/


This lib allows to drive data acquisition devices from NI: http://www.ni.com/data-acquisition/

Ah, so cool, now I feel like Red is getting into embedded sphere 
:-)

Leap device: huge potential, C++ drivers (!), only simple demos and 
basic testing tools available currently.

C++ drivers - bad to wrap for us, no?

What would be also cool would be to bind to one of media frameworks 
- libVLC, ffmpeg, Libav, mplayer, Gstreamer, etc. - dunno which one 
is the best ....

Yeah, significant extra work to interface with it. But there's a 
shortcut, a API is also available through a builtin websocket server, 
so you can access the device from your browser directly.

I'll write a websocket client for Red when we'll have networking, 
so I will be able to test it deeply.

My first impression was: we're half-way of the right interface, it 
lacks a force-feeback system. One of the demo allows you to manipulate 
a virtual cube with your fingers, but without force-feedback it feels 
incomplete.

So Leap device + feedback gloves would do real wonders!

Also, from the first tests, the device has some limitations, like 
loosing track of your fingers if you point them up or down. Not sure 
if it's a soft or hardware limitation.

I wonder, what is inside. What exactly measures your fingers in the 
space? It is not camera based, is it? So what kind of sensor does 
it have, and how is that they are so precise? I do own Kinect, but 
it is far from being so precise ...

IIRC, it's sensible to ambient light, so it's probably camera-based 
(but probably not only).