World: r3wp

Kaj, I've been able to reproduce a similar behavior (having 12 in 
list/value instead of an address) using a small program, I'm analyzing 
it right now.

I have fixed the bug (issue with variadic function's return value), 
but it is still crashing. It seems the real issue is that callbacks 
are not stable on ARM...I haven't found the time to properly test 
them, so I'll need to do it now. Fortunately, Andreas has joined 
the bug hunting party. :-)

Good progress

What's your experience with Red/System wrapping interface? Is it 
suitable to wrap (relatively saying) "any" C defines? I am recently 
scripting VLC a bit, to see if I can use that player instead of LED 
Studio (which is really bad chinese standard LED accompanying sw) 
for our LED screen.


So far, I am fine talking to VLC via TCP - 10 lines of Rebol code. 
But their RC (remote control interface) missess advanced playlist 
handling. I was looking into vlccore library API, and I found various 
wrappers, and e.g. Python one, is auto-generated, by going thru includes.


IIRC, Max worked on something similar for R3, but never released 
the code. Now I wonder, how difficult would it be to achieve using 
Red/System?

btw - VLC natively supports LUA, so I will also look, if it can't 
do more, than what is being exposed via RC interface ...

Red/System's way to write bindings is the best I've seen. Barring 
C features it doesn't have yet, it should be able to bind any C function. 
Mostly only 64 bits integers and importing data values are still 
missing by now

I've been considering a VLC binding, but it isn't a priority for 
me right now

One issue with it is that VLC is GPL, even the library, so your code 
on top of it must be open source. If you don't want that, the remote 
programming is the way to go

It would be a problem for an R3 binding, because the GPL doesn't 
allow VLC and REBOL to run in the same process

VLC library is going to be LGPL since 1.2, or I have read something 
like that. Anyway - I have basic remote thing working. That damned 
thing can't do so simple stuff as viewing jpg images, nor I can have 
transition effects, so I am considering another alternatives ...

I missed the LGPL relicensing. That's really cool

That makes a Red binding much more interesting

VLC is weak in my book - sorry that it belongs to vent most probably, 
but that player can't replay something as simple, as jpg or png files. 
How can they expect ppl using their solution to build player upon 
it? Every old LCD TV can replay images, VLC can't. Nor it has transition 
effects ...

It's a video stream player, not an image viewer

Kaj - that is just an excuse imo. My 3 years old TV played just audio 
plus images. New versions can play namely anything. Ommiting ability 
to display images is a big design flaw imo. Because you can do it, 
or you can't do it. And VLC can't do it. You are also not right, 
that it is only a stream player - it is also a normal player, so 
it should try to display us much content as possible. Imagine you 
want to build small hw media player - will you ommit ability to display 
photos? And if not, it is clear you have to use another kludges to 
combine VLC with something else ...

An excuse? Should every program be able to do anything?

No, not anything, but what normal consument expects. There is plenty 
of bare bones DVD players, DVB-T tuners, and apart from video, all 
handle even photos, as I think, that in the age of digital cameras, 
it is pretty normal to request such a feature. But - whatever ...

Your multi-purpose TV contains an operating system. VLC is not an 
operating system

If you want a program that simulates a TV, you should use MythTV 
or something like that

My conclusion is, that VLC does not fit my requirements needs, and 
that's all. No wonder, that if you look into their website, trying 
to find projects which build their solutions upon it, you find only 
few projects actually. mplayer is much better in that regards. Dunno 
why though, as both build upon ffmpeg, so I expect their core having 
similar features, and API wise VLC seems to be ven better (LUA interface), 
but mplayer seems being more popular indeed.

Of course wrapping mplayer would mean releasing the source of the 
project, I think it is GPL, not LGPL.

VLC is doing just fine with "normal consumers". They downloaded it 
a billion times, a good deal less than competitors such as MPlayer

But you're right: this belongs in ~Vent

a good deal more, I meant

Is there anything others can do to speed up the development of Red?

A lot, I'd say. Enhance Red, write bindings, write example programs, 
write documentation. etc.

Doc says he is starting soon on Red ?

He has started months ago with the memory allocator and the tokeniser, 
but Red/System keeps postponing the rest

On the other hand, implementing things such as the allocator yields 
experience for further developing Red/System

If you don't think you can create a contribution with time, you could 
make a donation in money

Kaj - donation is not a problem imo. I donated and will donate again 
in March. At least a bit, but the question is, if it can speed anything, 
apart from the fact, that Doc will be able to work on the Red fulltime 
eventually. I think that Graham might be in a position of need to 
work on new stuff, and is deciding what tool should he use. In such 
a case, it is a bit preliminary to consider Red imo. But who knows, 
how quickly the RED itself can be written.

We will have to wait for Doc's estimate. It is also a question, if, 
when implementing e.g. Red "natives", he will accept the work of 
other developers, or will want to write it himself.

I am also not sure, that in the case of Red, eventual R3 source release 
would help to speed things up, as Red "natives" are going to be written 
in Red/System, not C, or so is my understanding of the platform.

I don't think any R3 development could speed up Red, but R2/Forward 
may

I had something other in mind - RT releasing sources for R3, it might 
be easier for Doc to rewrite R3 C code into Red/System, than implementing 
all functions "from scratch".

Perhaps with some functions, but in general probably not. REBOL C 
code will be very R3 specific. Interfacing with external systems 
is still sparse, and those examples can be looked up in many other 
projects

Also, the plan is to implement as few functions as possible in Red/System. 
Red will be preferred instead, to work at a higher level

And I take it we are not waiting for Red/System to be rewritten in 
Red/system before work on red starts?

So a few natives get written in R/S, and then use those to write 
the core of Red.  And those that need to be rewritten in R/s can 
be done as a later optimization.

I think that's the plan. World has similar goals I believe.

And in a few years we'll be able to write apps :)

An incentive to live a little longer. :-)

I don't think any R3 development could speed up Red

 - perhaps only already taken design decisions, as design can take 
 time and mistakes can be made.

A few points releting to recent posts:

Nenad is already working fulltime on Red.


He has already accepted contributions to the Red/System compiler 
from both Andreas and Oldes.


Finding bugs by using Red/System will help speed the process of Red 
especially as Nenad's current design is to generate Red/System code 
from Red.

Yes, design decisions are important, but we were talking about potential 
new R3 development

Graham, programs can be written in Red/System right now

You were asking what anyone can do to help, and the most obvious 
way is writing programs

Ok, though I can't think of anything I need to write in R/S at present. 
 I need GUI based apps though

if one wants to test Red/System: port some simple C stuff?

FYI, I'm on trip until Saturday, so I won't be able to work much 
on Red until there. I will try anyway to release the version 0.2.4 
that includes floats support this week.