r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3-OLD1]

Pekr
27-Jun-2008
[6106]
Narrow field? Why do you consider them being narrow? Is Action Scrip 
somehow limited? And look into most mp3 players, their UI, their 
games, etc. - everything Flash based. The market for such device 
starts being crowded. We will see what impact will there be on Android 
and Symbian in the future ...
Henrik
27-Jun-2008
[6107]
I would definitely not be using action script for 90% of the work 
I do with REBOL...
Chris
27-Jun-2008
[6108x2]
It may well be a missed opportunity for Rebol as a front end, but 
frankly I'd rather see R3 done right than speculatively rush it to 
market.  I see greater opportunities in the future for a feature 
complete, mature R3.


Even if R3 were the perfect combination of front and back end, RT 
does not have the leverage of Adobe or MS to establish R3 in the 
way you suggest.  The future of Rebol as I see it is in the grassroots, 
and for that, R3 must be all that it can be.
On the other hand, RT should be pushing for the spectrum of Rebol 
products - Base/Core/View to be included on every OS distribution. 
 Imagine if that had been pursued a few years back: .r would truly 
be write once, run anywhere...
Pekr
27-Jun-2008
[6110]
Nice analysis, Chris ...
Will
27-Jun-2008
[6111]
I said it already many times and now there is a new opportunity, 
quicktime browser plugin is today much more popular thanks to iTunes, 
it is installed in more than 80% of personal computers. quicktime 
once had a wired scripting language (qscript), Live stage Pro was 
the only editor for that. Now apple just announced they are working 
on Quicktime X, they will either drop scripting completely or they 
will put something new in. That new scripting in the quicktime plugin 
SHOULD BE REBOL !! it is a win-win solution. rebol would have access 
to  about 200 media formats, apple will offer the best language for 
scripting medias, and not limited to that. See, apple really has 
no interest in seeing flash ported to the iPhone, because the sell 
iPhones games on their iTunes store, and many other reason. Also 
in the last year apple has enhanced javascript ability to control 
quicktime movies in the browser. I have no idea about waht agreement 
apple and RT should come to, but I'm sure nobody can argument against 
this theory! Long life rebol! 8-)
[unknown: 5]
27-Jun-2008
[6112]
If you want to see REBOL expand then build APPS and distribute them 
with a BSD license.   If REBOL isn't "everywhere" then it isn't just 
Carl's fault - it is ours also.
Pekr
27-Jun-2008
[6113]
quicktime always sucked, sucks now, and will suck forever. It can 
take FF3 down. Besides that - who is Apple to define "standard"? 
Who caros of .mov container? That format is rudiculous and irrelevant 
:-)
Will
27-Jun-2008
[6114]
ok Pekr, it suck but it still is one of the most installed browser 
plugins, add rebol to it and you get rebol installed on all those 
computers on the next quicktime upgrade, or try and have people install 
rebol plugin.. ;-)
Pekr
27-Jun-2008
[6115]
I guarantee you, that .mov is pretty much ignored by Windows users, 
and very often found being obtrusive. It is recognised by those favoring 
Mac platform, but not otherwise. Yes, REBOL as a system language 
of anything would be benefical, but that will not easily happen imo 
...
Gabriele
28-Jun-2008
[6116]
Petr, Apple actually succeeded in making the MOV format a standard: 
the MP4 format is indeed MOV with some restrictions. Notice that 
MOV and AVI are both IFF clones (AVI just has the length in reverse 
order, indeed it's called RIFF, while MOV swaps chunck type and length). 
The way they are being used is another matter :)
Graham
28-Jun-2008
[6117x2]
Gabriele .. any updates on what is happening?
There is a dearth of visible activity
Gabriele
28-Jun-2008
[6119]
I don't really see more than what you see...
Graham
28-Jun-2008
[6120]
Oh .. I assumed that there were private groups
Pekr
28-Jun-2008
[6121]
Gabriele, I understand you. Mov might be technologically even superior. 
So I don't know if it is licencsing of Apple or ignorance of Windows 
probrammers, but - I just want to use one codeck pack - ffdshow for 
e.g. It is some 5 years I met some video, which was not able to work 
with it. Any player! But - quicktime is painfull exception! I don't 
want quicktime player! I want it to play with any player I choose. 
And it does not seem being so. So, I have also VNC, just to have 
such problems as getting sound, but not picture, etc. So - no mov 
for me.
Henrik
28-Jun-2008
[6122]
I agree that quicktime for windows does not at all show a fair picture 
of what quicktime is capable of.
Gabriele
30-Jun-2008
[6123x2]
Petr, I hated QT on windows too (or Itunes etc.). And, I hate the 
fact that MOV are often very hard to handle with open source software 
(eg. the DV videos produced by iMovie could not be processed on linux, 
but this was a couple years ago). But, I don't think it's the format 
at fault here. mplayer for eg. can easily play any MOV (as well as 
FLV, AVI, MKV, etc.), and VLC too, and they are both open source, 
so in principle there are no obstacles.
I'd rather see MKV or OGM being more used though, since they seem 
to be much more flexible (never looked inside though, so maybe they 
are crap ;)
Henrik
1-Jul-2008
[6125]
So it would seem that we're almost back in business after some time 
in the quiet. Carl has been talking about vast simplification of 
how people can do networking. A bit in the same way as when you send 
data with a webbrowser from a form, you don't mess around with ports, 
but simple HTML code to do that. There will be more information about 
this later.
james_nak
1-Jul-2008
[6126]
Cool.
shadwolf
7-Jul-2008
[6127x8]
Hello Carl and VID3 dev team i'm wondering something. I recently 
read alot on rebol3  lot of things are hsarper (VID3  is  really 
more performant with drawing statements for example). But as much 
i read so far I didn't found information about several topics.
What are the memory management enhancement proposed ? We all saw 
how it was difficulte to manage the mémory in previous rebol. For 
small data content that not a big issue but as soon you start to 
play with grafical content the mémory stack is amazing ( for example 
this code http://shadwolf.free.fr/berlinClock.ziptakes 10Mo  when 
running and in my opinion that from far 9M mega wasted ...). Can 
it be a way to make the recycle function more efficient to trap all 
non in use data
preset in the memory stack
next thing is the VID2 event system in same code we can see the rate 
face feel function don't allow the  event handling for the other 
face the Quit button for example.  (still in same code). Those things 
are trivial and i don't imagine to have to search hours and hours 
a way to solve them.
last thing is the "extension" modules  I would like to know how  
it's planned to handle them  when u add an external DLL to rebol 
VM your goal is not to have to rewrite a brigde code for each of 
your DLL you want to work with and you don't want too your rebol 
application code to be over complexified in regard to the regular 
rebol code wich use shaped  dialects. I know that's not easy thing 
to do ....
I want to be able to use any DLL in a rebolist way  to resume that's 
maybe an utopy but dreams allows
made the humanity advance  ^^
VLC is handling MPEG2  too and hum it's patented and hum lets say 
the authors hum .... how to say ..... hum .... well they just don't 
care
Graham
7-Jul-2008
[6135]
I believe efficient memory use is going to be a major focus.
BrianH
7-Jul-2008
[6136x3]
There's no reason that the authors of VLC should care about software 
patents, shadwolf: Where they live (France), software patents are 
illegal and can be ignored. Go France!
Memory management: R2 gets a bad rap for this because Windows doesn't 
report the working set seperately, so the numbers it reports are 
a little inflated with page file memory. Nonetheless, R3 should be 
better with memory.
The extension modules spec (as you call it) hasn't been specified, 
or even discussed at length yet. That's next.
Henrik
7-Jul-2008
[6139]
I think the graphics engine is much more memory efficient in R3. 
A single GOB takes up 64 bytes of memory where a FACE in R2 takes 
up much more memory.
BrianH
7-Jul-2008
[6140]
Making sure to minimize extra references to data will make them more 
collectable too. The change in function contexts helps with that.
Graham
7-Jul-2008
[6141]
but of course we don't know what is happening with Vid3.4 yet
Henrik
7-Jul-2008
[6142x2]
this gives greater performance scaling: R3 can easily handle thousands 
of GOBs, while R2 may suffer performance wise when handling hundreds.
of course a face and a GOB is not directly comparable, but just run 
the 1000cows.r demo to see the difference :-)
BrianH
7-Jul-2008
[6144]
VID is at a higher level than gobs, but Graham has a good point. 
All we know is that it will be good code, because Carl is doing it 
:)
Henrik
7-Jul-2008
[6145x2]
well, hopefully it will have actual features this time. :-)
although I'm not really that worried. if VID3.4 will be very different 
and inferior to VID3, it's important to have Gabriele finishing VID3 
to have a viable alternative as soon as possible for proper GUI development.
Graham
7-Jul-2008
[6147]
Why would Gabriele finish it for ?
Henrik
7-Jul-2008
[6148]
if VID3.4 does not live up to our requirements of completeness and 
scalability. basically all the things that are currently wrong with 
VID, then VID3 will be the way forward.
Graham
7-Jul-2008
[6149]
I just don't see that there are enough users to support two VIDs
Henrik
7-Jul-2008
[6150x2]
I agree, which makes it essential that VID3.4 is good enough. Perhaps 
it would help pushing Carl to make VID3.4 as complete as possible, 
so we won't need VID3.
there are usually only alternatives to something if the things already 
in place are inadequate.
Graham
7-Jul-2008
[6152x2]
Well, I don't see how Carl will have time to write all the widgets
So, I guess we all have to pitch in as soon as the prototype appears
Henrik
7-Jul-2008
[6154]
He doesn't have to write the widgets. He only has to build an engine 
that will let you write most widgets with ease.
Graham
7-Jul-2008
[6155]
Yes, that was what I was meaning.