World: r4wp

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).

Infrared light + CCD cameras.

0.01mm precision in detecting position

impressive ...

It can also detect "tools" you're holding like pencils.

You can see a good demo here: http://youtu.be/ssZrkXGE8ZA

We have GOT to have access to that!  At this moment, there would 
be no better way to demo to people.

(Add a 3D API, and maybe Red could find a market in gaming)

Doc - would it work from behind the glass? I mean - in front of Windows, 
projecting image on the window (with some foils like Vikuiti from 
3M). Because the guy at the video has it laying on table. And you 
also said, that it does not work, if you point your fingers up or 
down, which might mean - towards the device?

Imagina navigalbe on-glass systems - signage - https://www.youtube.com/watch?v=3RYMR2LMVmQ

Adding support for cutting edge hardware, and things like VOIP and 
Videoconferencing - anything that tends to be hard to accomplish 
using other development tools, would really help to set Red ahead 
of others, make it look fantastic, and give new developers concrete 
reasons to WANT to use it.

(Same reasons many of us were initially attracted to using VID and 
other REBOL features that made it so practical).

No one will be impressed with normal GUI, email, database capabilities, 
even if it's 10x more productive, but anything multimedia, video, 
3D, etc. which demonstrates "modern" capabilities, and beats other 
solutions, works on mobile, etc., then they're much more likely to 
go "hmmm".

NickA: there are many domains where Red could shine, actually finding 
the right one, which fits the best, is the hard part. Supporting 
new and innovative hardware is surely a good thing to have anyway.

...if you point your fingers up or down, which might mean - towards 
the device?

 Yes, towards the device or away from it. It is supposed to be in 
 the device roadmap, but probably is not yet ready, like other early 
 announced features.

NickA - I share your point of view. Ppl mostly nowadays think, that 
the web rules it all. However - it is still complex. I don't care, 
if we generate HTML5 (whatever it is) in the end, as far as we can 
very easily build apps using VID like dialect. I remember those initial 
days, where we had really a small script (1.6KB) to show image from 
4 webcams ...

I think, after all those years, we could have what Carl envisioned 
with REBOL/Media :-), it will be just called - Red :-) Wrapping stuff 
like video playback, camera access, HW like accelerometers, gyroscopes, 
GPS, along with dialected simplicity, would be nice acomplischement 
...

Regarding OpenCV:   Thanks!!

I agree, the Leap device is amazing!  Who's ready for a 3D operating 
system?

Preliminary path! and set-path! support added to Red interpreter.

https://github.com/dockimbel/Red/commit/53f87ff81822e81c5ddf56245e68f8e6255c698b


Works only on series! so far, function calls with refinements are 
next on the todo-list.

Good stuff!

I'm happy to report that passing functions by reference works, and 
that they can take parameters if you invoke them with the interpreter:

Red []

f: func [
	a
][
	print a
]
g: func [
	h
][
	do [h "!"]
]
g :f

It would be possible to support it in the compiler too, but that 
would require that the `h` argument get declared with a type definition 
like: 

    g: func [h [function! [a]][...]

(not implemented yet though)

That would be very nice. Differences like this could otherwise prevent 
code written for the interpreter to be JIT-compiled later