World: r4wp

(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

The interpreter is able to detect if a function has been compiled 
to native code and run the native code version, so in the above case, 
the interpreter overhead is very small, and a JIT-ed version wouldn't 
run noticeable faster. The real place where the JIT-compiler will 
make a big difference is for functions created at runtime, that would 
otherwise need to be interpreted.

I wasn't concerned about performance here, just compatibility

If you write a script for the interpreter, and it contains function 
references with arguments, it would run in the interpreter, but not 
in the compiler

If you write it for the interpreter, that's probably because it can't 
be executed by the compiler, but in the future, you would probably 
want to have it JIT compiled

Actually, we could just make the compiler recognize such case and 
generate a call to the interpreter without you having to specify 
DO. The drawback would be that all subsequent values in that block 
level, would be passed to the interpreter too, as the compiler can't 
determine the expression boundaries. I'm not very fond of such option, 
but it is a possibility.

That's interesting, too. The compiler could issue an optimisation 
warning

Actually, this is supposed to be the compiler fallback strategy for 
cases that are not statically solvable. I haven't needed it so far, 
and I'll try to push the compiler as far as possible before implementing 
it.

Just in case Red followers haven't noticed, we now have REDUCE and 
COMPOSE fully implemented in Red (both in compiler and interpreter).

Thanks for the reminder Doc!

Refinements evaluation is now supported by the Red interpreter.

Timely

Has anyone successfully read in a jpg into Red or Red/System yet?

I'm talking about converting it to a bitmap, like R2 does.

Bo, have you looked into ImageMagick binding for Red/System yet? 

https://github.com/dockimbel/Red/blob/master/red-system/library/lib-iMagick.reds

Yes.  But I was hoping for something that would simply return a flat 
binary representation.

You could write a Red/System wrapper over http://libjpeg.sourceforge.net/

you mean, something like R2's image! datatype?

@Pekr: Yes.

If your wrapper is good enough, there's a great chance that your 
code would be included in Red at some point.

@Doc: I may have to consider that.

Doc - that's interesting questions indeed. What attracted ppl to 
Rebol, was, that it was a complete package. So no problem with tonnes 
of libraries out there, plus wrappers, but curious to know, if you 
still think, that some common standard would be nice to have ... 
well, it would be even better to have ports for many things, plus 
schemes, plus codecs below :-)

common standard
 for what precisely?

What attracted ppl to Rebol, was, that it was a complete package
 Who said that Red will not be a complete package too??

@Pekr: That's one of the things that attracted me to Rebol.  I didn't 
like to have to specify every library file that I wanted to link 
to and have all these dependencies...just one package with everything 
in it.

for many things we are used to ... so that Red is able to read bmp.jpg 
png, play basic sound, do compression/decompression ....

well, Bo, explained it better. I am not saying that you are not planning 
it, I was just asking, if it is planned, because other point of view 
might be, that we will get some very core funcionality, plus millions 
of nice wrappers, but that would make a different feeling ...

Or at least like the Rebol SDK where you can easily include the major 
components you want, and the granularity to remove ones you don't 
want, like the View subset.

For Red, it will rather work as R2 SDK where you just import the 
modules you need to build your binary. We would also provide a console 
binary with all or most of modules included by default (like the 
fat binaries from the SDK).

I like the way the R2 SDK worked.  You could include a whole subgroup 
of functionality or just component-by-component.

As we discussed before, you can get JPEG data from the GDK binding, 
but you have to finish the struct definition

Any framework that supports more than one image format will have 
its own internal format. That goes for R2, SDL, GDK, ImageMagick 
and any other framework you could bind to

If you bind to LibJPEG directly, you'll have to devise your own internal 
format once you add support for another image type

@Kaj: I'm trying to get the JPG data without having X11 installed. 
 If I were to do something with LibJPEG directly, I would try to 
make it look like the R3 image! datatype.

Are you sure GDK has a dependency on X?

Looks like it

I was pretty sure GDK required X.