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

World: r3wp

[!REBOL3-OLD1]

Henrik
30-Jul-2007
[3842]
pekr, I'm just saying that the developers don't need to answer questions 
for things that are already planned. "what about this?" "what about 
that?" "why is X feature not there?", etc. Rather spend time finishing 
VID3 than talk about how to finish VID3. :-)
Pekr
30-Jul-2007
[3843x2]
also - one of motivations for R3 was that LNS needed better networking 
model. So not sure r3 LNS release could be so easily backported to 
r2?
Henrik - you know me and you know what I fear - pekr coming to final 
r3 VID, playing with it for few minutes, asking - how would I do 
that? And getting the answer, that it was not inteded to do such 
a thing and that it would require VID rewriting :-))
btiffin
30-Jul-2007
[3845]
Yeah, but a production release of R3 is what, 18 months away?
Pekr
30-Jul-2007
[3846x2]
so much away?
imo release could be regarded production level, if features added 
are stable. And that is imo also the plan. e.g. iirc unicode will 
not be there for 3.0 ... it will come later. But that does not mean 
3.0 could not be used for many usefull things already, and being 
called a production release, no?
Henrik
30-Jul-2007
[3848]
I don't think it's that far away. I think there will be a ton of 
additional work on extending R3, that could easily take 1-2 years 
after the first release of R3.
btiffin
30-Jul-2007
[3849]
That's what I was thinking.  R3 won't really be mainstream for quite 
a while no?
Henrik
30-Jul-2007
[3850]
everything takes its time :-) I'm just of the opinion that soon, 
an army of developers will be needed to take advantage of R3 to bring 
it to its full potential.
btiffin
30-Jul-2007
[3851]
But what about the "user" community during that phase.  They won't 
wait around will they?  Not to say I don't plan on trying my best 
to help out with R3, but I don't see taking it to a construction 
site boss for quite few more days/weeks/months.
Henrik
30-Jul-2007
[3852]
easily everyone in here could contribute to official parts of R3, 
given that the quality of work is good enough. :-)
Pekr
30-Jul-2007
[3853]
we need new C coders ... it will be a tough task, to attract new 
ppl being able to contribute good C code to extend REBOL ...
Henrik
30-Jul-2007
[3854x2]
brian, I'd start adapting simple scripts from R2 to R3. Do that by 
adding multithreading, adapting to async HTTP, etc.
pekr, driver developers will be essential.
btiffin
30-Jul-2007
[3856x2]
So I'm still back to planning for say an Invoicing application for 
a site boss.  That will be R2 code base for quite some time, no?
Cheyenne, RebGUI, Rugby et al...it's kind of where I live right now.
Henrik
30-Jul-2007
[3858x2]
brian, depends on the state of VID3, I suppose. Just right now, you 
can only build simple apps with it. I don't know the state of the 
networking. Actually I haven't work with networking at all in R3. 
:-)
well, if you are totally depending on those, you should probably 
stick to R2 for now and try out R3 for simpler scripts and wait for 
similar solutions to be ported to R3.
Pekr
30-Jul-2007
[3860]
Henrik - re VID - currently simple apps, because of incomplete style-set, 
no? But foundation is stronger than VID2, isn't it?
btiffin
30-Jul-2007
[3861]
Ok, so there has to be a plan to keep mainstream app building with 
forward momentum while building up R3.  imho.  So doesn't that mean 
wrapping at least a production release of 2.7.6?
Henrik
30-Jul-2007
[3862x2]
pekr, yep, incomplete style set. a few issues to be worked out with 
the layout model, bugs here and there and optimization.
brian, I think 2.7.6 is a good idea. It currently requires that someone 
clones Carl, so he can finish 2.7.6. :-)
btiffin
30-Jul-2007
[3864]
Part of my involvement over the last few months has been rebol.org, 
and I plan on being one of the grunts getting it R3 ready, but consulting 
work will still need to be a viable option for rebols until R3 can 
be taken to say an Insurance Company or small business, no?  Or is 
R3 going to hit the ground running so fast that it can be taken to 
an Executive sooner than later?
Geomol
30-Jul-2007
[3865]
driver developers will be essential.
Why? I thought, REBOL had a minimum interaction with host OS.
Henrik
30-Jul-2007
[3866]
Geomol, OpenGL, DirectX.... maybe? :-)
Geomol
30-Jul-2007
[3867]
Skip DirectX, use OpenGL and implement it using GLUT. It works the 
same on all platforms.
btiffin
30-Jul-2007
[3868]
No I think that RT will try and have a minimal interaction with host 
OS...that's what I took from the DevCon talks.
Pekr
30-Jul-2007
[3869]
btiffin - I would not depreciate r3. Remember - when r2 came, it 
was better than r1 even in beta state. It will not probably happen 
with r3, but otoh r3 provides you with many more capabilities, e.g. 
threading ....
Geomol
30-Jul-2007
[3870]
I can live without 2D hardware acceleration, I guess. But if there 
is a standard way of having it across platforms, it could be a good 
idea.
Henrik
30-Jul-2007
[3871]
Geomol, that's the beauty of R3: We don't have to skip DirectX, since 
a developer can make that interface if he/she wants to.
Pekr
30-Jul-2007
[3872]
Geomol - I jus hope rebcode is there, with refinements guys outlined 
... it should help too ...
Henrik
30-Jul-2007
[3873]
Geomol, but I agree for the first round, OpenGL is more important.
btiffin
30-Jul-2007
[3874x3]
I'm all for porting, but not if wating for key features means delaying 
work for "normal" folk.  I'm at a point where some of the bosses 
are actually getting pretty good at R2 data types.  :)
And I'm just starting to get people here involved with GNU/Linux...so 
I'm banking on that R3 release not being too far behind.  :)
Pekr;  Re r1 to r2.  I was a dropout from the computer biz from 1999 
till about January this year, so I was watching from a purely curiosity 
perspective, no vested interest.  Now the interest is much higher 
and far more vested.  :)  In that regard I'm still new.
Geomol
30-Jul-2007
[3877]
Henrik, it's good, that R3 is open in a way, that it's possible to 
interface all kinds of systems. But I wouldn't recommend interface 
too deep into anything, that is tied to a certain platform, like 
DirectX is. We should find good cross-platform standards and interface 
with those from REBOL, so all REBOL software can run on anything.
Pekr
30-Jul-2007
[3878]
Geomol - each coin has its two sides. Maybe there are some Windows 
only developers. From their POV, there is simply DirectX available 
on each PC, so no special need to install one. In the case of GLUT, 
they will have to either install it separately (I don't know anything 
about it, so maybe it is just few libraries), or simply pack with 
their app ...
Geomol
30-Jul-2007
[3879x3]
Afaik, OpenGL is on Windows. I'm not sure, if GLUT is or it is linked 
with app.
My point is, it's good that REBOL is open for interfaces. I just 
wouldn't recommend interfacing with DirectX. That's it.
Like I wouldn't recommend interfacing with e.g. the Velocity Engine 
on Macs, because it's tied to Mac OS and the Altivec technology found 
in G4 and G5 processors.
REBOL is about cross-platform also. Write-once-run-everywhere.
Pekr
30-Jul-2007
[3882]
OTOH - why not to optimise to what is native on all platforms? Under 
the hood, so that the programmer does not need to care? Well, app 
performance would probably vary between the platforms, but ....
Henrik
30-Jul-2007
[3883]
Geomol, I think you mean that _RT_ should not focus on DirectX. :-) 
I don't see anything wrong with a 3rd party developer doing work 
on interfacing DirectX.
Pekr
30-Jul-2007
[3884]
I would like to first see new View with rich-text, VID, ability to 
embed externall windows (e.g. video player, etc.), decent sound, 
really good VID, tools like screen painter, debugger, cross platform 
rebgui to give initial boost to apps, and then further fine-tuning 
using DirectX or View plug-ins (access to buffers etc.)
Geomol
30-Jul-2007
[3885]
Yeah, something like that. If you interface to something special 
found only on one certain platform, your software will only run there. 
If you support many such technologies on many different platforms, 
you end up having huge problems supporting new versions. Trick is 
to find the right things to interface with. Carefull selection! But 
of cource some specialized developer can interface with such things 
for some special software only to be run on that single platform.
Pekr
30-Jul-2007
[3886]
cross platform rebcode
 in my above text ...
Geomol
30-Jul-2007
[3887]
Yes, rebcode everywhere solve many performance issues! I agree!
Pekr
30-Jul-2007
[3888x3]
I think that we need few tweaks to it. BrianH and one other guy had 
some nice suggestions. Adding few instructions would allow emulation 
of some old machines :-) Porting some nice simple games could be 
easier :-)
Galaga already looked promissing :-)
And we are waiting for RPaint as well :-)
Geomol
30-Jul-2007
[3891]
Look a our situation with truetype fonts in DRAW. It's one single 
little issue in one corver of REBOL, yet we don't have it on all 
platforms, even if there is truetype fonts on all platforms. Imagine 
the situation, if we had many such things with all different areas 
of REBOL. So not only RT should choose carefully, also us developers 
who would like our software to run everywhere.