World: r3wp

REBOLight

Thermite ?

flash in a pan :)

isn't thermite explosive? :-)

yes, it creates flashes

so, we have a product that is capable of creating flash like graphics 
and better.

Or we can call it similar to Flash - Fresh, or reFresh

nah ... want something different and better

If GIDI is revolutionary, we want the ParadigmShift :-)

The tough thing to appreciate is that VID is a general-purpose entry/mid-level 
dialect.  R2/VID has been in the wild for 6yrs(?) now and we have 
certainly gone through periods of isolating key weaknesses, but we 
all have a tendency to have had starry-eyed visions for what VID 
should be.  The practical gets mixed in with the possibility when 
it's time for action.


I think the community would be better served with a strong VID alternative 
(not as a slight to RebGUI which does very well acheiving its stated 
aims) not bound by Carl's constraints for the entry level language, 
and open (as in open) source with very clear aims.  It has to be 
independent and perhaps needs to span R2 and R3, at least initially. 
 We have the capabilities, resources and talent to do it, but instead 
try to hammer these ideas into VID.


This isn't intended to be a rallying cry -- it's just my assessment 
based on observation and involvement.  Such an undertaking would 
have inevitable difficulty overcoming the differing visions of interested 
parties.  Conversely, it's within us to create an enduring, enviable 
framework...

Graham, you have an interesting way of working

However, many discussions about development methodologies are comparing 
apples to oranges

The iterative way of developing with lots of feedback, nowadays described 
in Extreme and Agile Programming, is very suitable for user applications 
and solves a lot of problems there

However, it's not suitable for systems programming, where you don't 
mold your design around user requirements, but around the requirements 
of hardware and underlying system software layers

REBOL is clearly systems software, a middleware layer that aims to 
bridge between lower level systems and frameworks for basing user 
applications on

Its design requires much more knowledge and experience of the system 
than most people, even REBOL programmers have, contrary to user applications, 
where the user is by definition the top expert

well the mear problemfor comunication is the monolitic way to think 
.... 1 guy working = stability of the way to work but fluctuant communication. 
And teh problem  can be there is not much to communicate about too 
. several guys working = code harder to stabilise but more easy to 
communicate each time you have a new thing done or a new idea popping

that remembers me how we started rebGUI with rebol community ashley 
and me. First ashley and me  were working on MakeDoc and MakeDoc 
Pro dialect to VID renderer we emulate each other alot and from this 
exange born the constatation that common VID face set was not adapated 
to usual GUI  or big amount of face handling. And from that constatation 
Ashley proposed to make rebGUI  wich we presented as a major enhancement 
to VID layer keeping the main idea alive "KEEP IT SIMPLE". Ashley 
proposed the community to share idea or suggestion and on every single 
widget the community proposed we got a discution and code proposition 
to achieve this goal.

sure the most of the work was lets say the assembly and diffusion 
part of rebgui was still done by 1 guy Ashley wich have the main 
vision of the project and was our guarant to get end edged library 
usable by any one but many were the  contributors and that leads 
to a really dynamic work i remember on the very beggining of the 
project a new version of rebgui was available every 2 weeks.

hum crhis the main problem is the interface betwin the common REBOL/VID 
and the side way external VID like dialect (but not using VID) developed 
by the community and promoted by the communnity. All the rebol communication 
is to say  you download only rebol VM  and you are done read for 
work.

REbGUI is working on top of VID not remplacing it and remplacing 
VID is yet another step of difficulties. As I said befor the only 
way to remplace VID would be to make a DLL and then a bridge to make 
the "user code" able to use it and that means a more complexe way 
to share your sofware

but that rebirth the ask i done about the "external modules" handling 
if we see rebol as a full opened virtual machine with an easy way 
to handle module then network, vid data etc are just modules and 
anyone can take them work on them enhance them or correct them share 
is news and rebol recentralise the works to make an official  release

this way rebol is hum thought more a module manager and a mean idea 
of was software programming is than a monolitic virtual machine wich 
I call the BIG black box able to do anything but with a big mistery 
regarding how the thing are internally done.

and maybe that would be more fun .... but most of the time we will 
be then discussion about C/C++ code than rebol code ... and maybe 
that's not the topic of our community

when I see the actual enthousiasm form google desktop applet and 
opera widgets developpement I really think rebol have his spot all 
ready in computing industry

if we look closer to this page  http://dev.opera.com/articles/view/creating-your-first-opera-widget/
 that clear VID dialect is really more powerfull

but on the redering result we can say VID2  compare tu opera widget 
is ugly and that not reflecting all the power of VID2  and that's 
truely pissing me

and yes i want to be able to use VID2 power to do sharp and beautyfull 
interface with rounded border window and this means being able to 
deal with tranparent windows background

there is 2 ways to see a window and it's content the first 1 is the 
all made container the window is a set of default widget a tittle 
a status bar etc.... or you see it as a transparent rectangular area 
where you put other common widget . Maybe the true power of VID2 
 and by extention the true power of the rebol dialecting would be 
to think the window as a transparent rectangular area and then have 
2 kind of super widget able to get user input and deal with event 
able  to render draw AGG instruction and this widget will be the 
base for a design of all the widget

and VID should be able to use all common interface like systray or 
always on top

What is all the power of REBOL good for, if the whole project is 
pretty much missmanaged?

well rebol power is to not have to manage the project ^^

I have done alone in less than a day serveral things that in other 
language would have took me weeks  with several other guys

I am speaking about R3, not REBOL projects ...

yeah .... Pekr you are right .... and that's not a new issue I remember 
it took like 1 year to get rebol 1.3  VM  but  if we look closely 
rebol is not only built for windows and that's pretty complexifying 
the rebol developement process ...  since all REBOL VMs have to produce 
the same on all platerform from 1 single code you have to lower the 
specifications and possibility  the ground ones wich will feet to 
some less designed OS .....

for google desktop and opera widget that's clear they limited their 
OS to windows  MOSX  and linux those 3  OS having the same kind of 
inferfaces

they are different but what can get in result is close

I think the rebol developing process would first be enhanced if once 
for all we say we are in 21 st century therefore we focus on OS of 
this century  ^^

then we say rebol and it's main dialects should be able to use 100 
% of functionalities of those OS

and third we say ok we can put all in rebol therefor we design or 
think a way to easy extend it keeping for the extentions the rebol 
coding way

and third we say ok we can not  put all in rebol therefor we design 
or think a way to easy extend it keeping for the extentions the rebol 
coding way

Shadwolf:


- development has to be vital. There is IMO noone contracted right 
now. Gabriele, Cyphre, simply noone. Cyphre has not fixed deep View 
bugs for some 4 months or something like that

- there is nothing complicated about cross-platform nature of R3, 
as right now, kernel is imo not under development

- according to available info, VID should be the focus now. And maybe 
it is the focus. But it is not communicated. I hate those periods 
and they do happen once in something like 2 years, last one was probably 
during the rebservices period, which were not finished btw anyway. 
So - the blogging about Vista being broken or California fires is 
good, but look at frequency of R3 blogs. If it will not change, I 
recommend to remove personal blog from REBOL.NET, as it gives overal 
impression of RT breeding wine, instead of coding. Not that I have 
anything against personal life or wine :-), but can you imagine some 
system integrator, potential investor or tech.company willing to 
use R3 in their cell phone would look at REBOL.NET blogs? It seems 
to scream for - "... but where's the development happening"? And 
once again - all is about communication imo. If VID3 is in some stage, 
one blog per week would not hurt - whatever - principle explanation, 
simple glimpse of code, a screenshot, whatever ....

there used to be a running joke in my workplace that whatever startup 
company i got excited about was doomed to failure.  Be Inc. with 
BeOS (focus shift), Constellation 3D with their Flourescent Multilayer 
Disks (FMD) (factory bombed in start of Palestinian intifada), and 
now Rebol?


Each of the technologies was/is paradigm shifting in their field 
but through mismanagement, mishaps and miscommunication something 
along the way seems to get lost and the excitement they originally 
engendered fades from the public eye. 


If, in the case of Rebol3, it simply is too much work for one person 
- then perhaps now would be the time to open such areas as View development 
(the underlying system) and advertise to the 'World' "Come, see what 
you can do!".


Personally, I'd love to see Cyphre's work with View taken that one 
step further and translated into OpenGL and all that entails.  Not 
everyone today is looking to use Rebol only on their embedded devices 
;)

You know how it goes. In order for View to be opened, the DevBase 
needs to be finished. In order to finish DevBase, rebservices redesign 
is planned, etc., etc.

The biggest block to finishing DevBase was that my time to work on 
it went away for a few months. That should be changing soon.

The rebservices portion of DevBase works just fine, and once rebservices 
are finalized (changed? rewritten?) DevBase will be able to adjust 
with little difficulty. The main block we ran into in DevBase development 
was disagreement on the UI, and other factors we don't need to get 
into here.

The main block to View being opened is not DevBase, it is that the 
core design of View isn't done yet. REBOL has a lead designer - we 
don't do design by committee. The rest of us refine the design and 
make really cool stuff based on the foundations, but the lead architect 
is still Carl.

but why, when the core design for View isnt done yet is Carl even 
thinking on working on VID?  Surely we need a View before VID is 
even feasible?

He is making adjustments to View to make VID feasible. Shortcomings 
in the core were causing shortcomings in VID.

VID is the goal. View is the means.