World: r3wp

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.

Speed up the process: you'll be able to add easily new datatypes 
to Red. I won't code myself all the 50+ REBOL datatypes, only the 
basic and important ones. For example, I would very much appreciate 
if date! and time! could be contributed by someone. The basic types 
will be quick to add as soon as the underlying Red runtime (think 
MAKE, LOAD and a few basic natives) will be operational.

Is there going to be a central repository for code snippets like 
rebol.org ?

Certainly, maybe we could use a github repo for that as a start?

And use google to index

Right, or build a simple search service using github's public API.

After adding the float! support, the main thing is a series! datatyte. 
Should we wait for Red to implement it properly or do we want ti 
in red/system as well? (I know I can use pointer math to access values, 
but it's not so easy for ordinary scripting)

Red/System is not meant for scripting but low-level and system programming. 
Red is for scripting, so series! support as well as all others scripting 
facilites will be provided by Red.

So what one can do now to help you move Red to usable state? :)

Red/System: already anwsered by me, Kaj and others (also, there's 
a todo list on red-lang.org for contributors that are searching for 
tasks to handle).

Red: you need to wait a few weeks until the first alpha is out to 
start adding new datatypes.

todo list - you mean the roadmap?

No, the one from here: http://www.red-lang.org/p/contributions.html

(it's the "Community" menu, I guess I forgot to rename the page, 
will have to fix that)

@Oldes .. how about a black text on white background blogger theme! 
 That would help a lot.