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

World: r3wp

[!REBOL3-OLD1]

Henrik
22-Jul-2008
[6629]
a stronger link betwin 

networking" and "visual" modules ??? hum that's like if Carl was 
preteneding we can't already do that !!??"


I haven't mentioned this, because I was afraid I would get it wrong 
and Carl would bash me for it. :-) What I'm writing here below is 
one of the reasons to switch to a webbrowser mentality. It was also 
one of the the reasons for dumping VID3.


Webbrowser mentality helps building infrastructure, very quickly. 
There is allegedly a stronger link now between VID and networking 
in the same way as there is a link between HTML and HTTP. When you 
create a link in a webpage, it takes only a few tags in one line 
of code (even inline) to do that. You don't do anything else but 
provide the link. The browser takes care of the rest, and you can 
build an entire infrastructure with hyperlinks. You don't have to 
worry about TCP ports or wait for acknowledge from the server. The 
basic philosophy that goes behind hyperlinking is its extreme simplicity, 
which is why it's so widespread. It's easy to grasp and easy to code.

When you for example write in a forum, you are often capable of providing 
hyperlinks. As a result, hyperlinking is available to any users, 
who have just the basic knowledge of coding, which to them is "typing 
funny chars to make a link".

Carl wants the same thing in VID3.4, where you must currently work 
with ports, store things in words and do something with the words 
in order to get where you need to go. You need to do some programming 
and make complex decisions. That level of detail must not go away 
of course, but there is a simplifying element that's missing, and 
that is to use buttons directly as hyperlinks. If successful, anyone 
could code simple VID GUIs.


I'm still sure I'm getting it a bit wrong, so there's not much point 
discussing it right now. He emphasized very strongly about building 
infrastructure through very simple methods that most people can understand 
and use. He talked about this more than about VID itself.
shadwolf
22-Jul-2008
[6630x6]
VID was already simple  in comparasion to what are the other libraries 
I don't know if you ever tryed to deal with transparencies with raw 
X llibrary that pain in the head number 1  ^^.   Well i'm not against 
simplifying the system but first how does the industry shape their 
GUI 99.9 percent of the time the GUI  is build using a GUI designer 
and the only thing you have to do is set thru the GUI designer interface 
the settings for the widgets you graphically picked and organised 
then you have to write the call back code... Then to take your example 
back with the hyperlink people then don't code they only format text 
en even then most of now in days forum like PHP BB  use javascripted/pugined 
rich text area  to format their  text you push a button it insert 
the text the way you want. and some of them on the php engine level 
are able to recognize http:// footage to build on the fly the hyperlink 
without requiering any tag adding by the user .... I'm not sure separating 
the way you organise the widget to the way you configure them will 
lead us to more easy way
but that take us back to the main ask do we want a rebolvm that we 
can extend and make code over or do we want a monolitic VM  where 
you can't do any extend.  I like VID becaus it was enough flexible 
to allow rebGUI  and other VID based library to be done.
buton the other hand none of those libraries could go further than 
what was VID engine capable of the events where still the same and 
still handle the same way for example. If you wanted to do a rich 
text area you will have to deal with that
you could do transparent buttons (hum that's partly false  you can 
do that if you draw your button using AGG  then you use mouse position 
when  left clic is done to simulate the reaction of your button) 
or windows
We need more information on what Carl is cooking ...
hum so lets imagine due to the few information how a VID "page" will 
be page [ <button text="my text on the button" action: [  some-callback] 
 bgcolor: red fgcolor: pink size:100x50  position: 0x0 >
[unknown: 5]
24-Jul-2008
[6636]
A few questions I have about R3:


Will R3 be open source in some fashion?  For example if Carl were 
to retire or expire, would the language remain viable or would the 
evolution of operating systems make it obsolete.


Will R3 be capable to access low level hardware?  For example, will 
I be able to read sections of a hard drive directly?

Will R3 enable me to send ICMP packets over the network?


What is the primary revenue source for RT expected to be from the 
production of R3?  Is is the software alone or some other licensing 
models?


I'm sure I'll have other questions but curious of these for now as 
I contemplate the future of my programming skills.
Henrik
24-Jul-2008
[6637]
1. There is a clause that makes sure the code will be opened or transfered 
to a different instance in case of RT's demise, but I'm not exactly 
sure on which circumstances it counts.


2. You should be able to access drivers directly, anything that fits 
with R3's device model. See http://www.rebol.net/r3blogs/0087.html

3. See 2.


4. Products built on top of R3. R3 itself will be free as in beer.
[unknown: 5]
24-Jul-2008
[6638]
Then how is RT to make any money $$$?
Henrik
24-Jul-2008
[6639]
See 4. :-)
[unknown: 5]
24-Jul-2008
[6640]
So Carl doesn't need to make money from R3?
Henrik
24-Jul-2008
[6641]
I don't think he can make money from R3. R2 has specific barriers 
that prevent you from implementing specific things in the free version. 
Those barriers are gone in R3.
[unknown: 5]
24-Jul-2008
[6642]
I'll guess I'll hang on for a bit longer.
Henrik
24-Jul-2008
[6643x2]
My take on it is that REBOL/IOS made more money than R2 did. It's 
just well-known that a lot of people didn't like paying for essential 
features like better security algorithms, ODBC or DLL access (DLL 
is now free in R2 though). When that is the case, it's easier to 
just flip over to an open source language like Python which do these 
things for free. I also know that RT is wanting to build apps based 
on REBOL, and not just sell REBOL itself.
forgot the SDK... that must have made a few $ as well. I don't think 
that will be free for R3.
[unknown: 5]
24-Jul-2008
[6645]
What would be included in the R3 SDK?
Henrik
24-Jul-2008
[6646]
I don't know yet. Other than encappers, hopefully an IDE or advanced 
debugger. It's stated on the rebol.com site that an IDE would have 
to be done in cooperation with a third party (us!). :-)
[unknown: 5]
24-Jul-2008
[6647]
I see.  I know I currently have the R2 SDK.
Henrik
24-Jul-2008
[6648]
I have it too.
shadwolf
24-Jul-2008
[6649x11]
Will R3 be open source in some fashion?  For example if Carl were 
to retire or expire, would the language remain viable or would the 
evolution of operating systems make it obsolete.
Paul tjat's  an ask I do to myself often rebol have to stay for the 
futur generations ...
paul all the other asks you do i'm doing them since 4 years now ^^ 
...
I don't think he can make money from R3. R2 has specific barriers 
that prevent you from implementing specific things in the free version. 
Those barriers are gone in R3. ---> Was true on the earlier version 
but as more ppl using it more way to bypass the limitations on free 
version have been found (using a C server to implements callback 
to a library overide all those limitations 4 years ago I told Carl 
those limitations where just futile they can slowing down the developpement 
nothing more...)  examples: calling a .Exe file was  bypassed first 
by the browse/ set-browser command wich lead me to co write the first 
free rebol WM packager a clone to a SDK (not as sharp) but  witch 
was able to package in a .exe file a VM script and related datas 
(dependencies (iimages etc...). That project was grebox. and then 
It was obvious to allow free version to use call function.
sql:// have been opened by  mysql-protocol so the limitation to access 
odbc:// was not working neither
for DLL we openned it by  doing C  servers and make rebol scripts 
sending commands to those servers wich is what rebol is all about 
 (messaging system)
so as all limitations can be bypassed why keeping them ?  I prefere 
franckly the way blender claim mommey they have a preoject they do 
the bill then they publish on their web sites "OK guys we want to 
intruce this new feature it will cost us that monney we open donation 
if you donate alot you will get prizes (t-shirtt, cd with advanced 
tutorials, mugs  etc...) and that system works well plus contributors 
feel they really are guest and participating activly on the blender 
project advancement that's in my opinion lot more dynami
c
for IDE that's too an old dream of us pending to the lack of often 
release ....
I don't want to start programming an IDE if at the end of the year 
I have to redo all the work because rebol3 is realeased and I have 
to change the whole IDE
but the IDE is an IDE in rebol to do rebol software.... But why an 
IDE  in rebol ??? Well for a  lot of reason 1) promotion purpose 
.... Rebol don't need anything else than rebol to do his dev tools 
... and if we can do dev tools as sharp as you can see it with rebol 
that means rebol can do alot for your company too. 2) cause rebol 
 is what we are doing here  ^^... Other language are other languages 
More rebol to save the people  ^^.... 3) because who knows better 
what we need and what we want than us  maybe the strongest and the 
first to believe in rebol  4) because IDE in rebol can make us share 
the code and work together on a base project where anyone will apport 
his ideas tries and that's what is a community all about doing there 
own project on their sides sharing informations and experiencies 
and gathering around hudge project or mendatory projects  ( like 
rebgui  ^^)
[unknown: 5]
24-Jul-2008
[6660]
Thanks for the info Shadwolf.  I see your frustration and noticed 
some of those projects over the years.
Henrik
24-Jul-2008
[6661]
I would not start working on an R3 IDE until R3 is feature stable 
(sometime around beta release). R3 contains in its current version 
more debugging and profiling functions than the public alpha and 
there might be more to come. It could be that Carl sees a good direction 
for an IDE at some point.
[unknown: 5]
24-Jul-2008
[6662]
I have no intention at this time, thats for sure.
Chris
24-Jul-2008
[6663x2]
Sw: I guess you see an IDE as having some built-in collaboration 
tools (as per #4)?  #3 -- Rebollers, for some reason, have a very 
hard time using someone else's code -- that's part of why it's difficult 
to establish a repository.  Perhaps an IDE would bridge this as it 
would allow developers to bring in 'modules' seemlessly?  #1 -- look 
at Ruby and Rails for a language/framework that is successful in 
spite of IDE availability.  They use that language as a strength 
and rely on the quality of 3rd party editors (TextMate?) to make 
it accessible.  Not to mention immediate availability within all 
but Windows OS (sigh)
My goal with QM is to deliver a high-level entry point for developing 
web applications (and a fledgling sister project in app development) 
that gets you started quickly, reduces the quirk quotient, structures 
the environment, and is above all expressive.  I see this as the 
hook.  Depth comes with initial success...
[unknown: 5]
24-Jul-2008
[6665]
Chris, I think the thing we lack in REBOL is that we don't have any 
collaborations really.  What I mean is the partnering of each others 
products and putting them out as a solution.  Think of QM and TRETBASE 
or some other product and then maybe that powering Henriks forum 
just to give you an idea.
BrianH
24-Jul-2008
[6666]
Collaboration and community development is a goal of DevBase.
Louis
25-Jul-2008
[6667]
What is the status of REBOL3 right now?
ICarii
25-Jul-2008
[6668]
usable but not complete
Henrik
25-Jul-2008
[6669]
Louis:

http://www.hmkdesign.dk/rebol/files/90e3407319954c2fb00e1665fdbd0e22-128.html

http://www.hmkdesign.dk/rebol/files/2d1fc42665bf4b0db081b79d236a3b38-129.html
Louis
25-Jul-2008
[6670x2]
Henrik, many thanks for the blog links. Very interesting.
Is unicode support finished?
Henrik
25-Jul-2008
[6672x2]
it's implemented, although there are still compatibility bugs left 
some places.
unicode has changed many things on a basic level. this affects some 
mezzanines which need to be fixed.
Louis
25-Jul-2008
[6674]
I figured unicode support would be very complex, but I think now 
that it was even more complex than I thought. It will be very helpful 
to me. Thanks for the info, Henrik!
BrianH
25-Jul-2008
[6675x2]
I am not aware of any bugs in the mezzanines relative to Unicode, 
but there are a few in the natives. Overall the code could use a 
conceptual audit for Unicode compatibility, though a great deal of 
this has been done already.
If anyone else knows of specific bugs in the mezzanines that relate 
to Unicode, please bring them up here or in the applicable forums.
Henrik
25-Jul-2008
[6677]
BrianH, well I guess I counted indirect changes in. If you look at 
the latest bugs, some mezzanines still expect non-binary input for 
WRITE and non-binary output for READ.
BrianH
25-Jul-2008
[6678]
I'll check. Thanks for the heads-up.