AltME groups: search

I know, but Gabriele communicates better than Carl does. I think 
he is quite skilled at leading a project as long as he can get his 
fingers in the code as well.

Paul, yes, VID should fit there, but Carl was of a different opinion. 
I think it's a matter of priority and with his new ideas on how to 
combine VID with extremely simple networking, might be top-priority 
to him.

henrik hum maybe because gabriele is a member of our overbored community 
and knows how is frustrating to be pending on informations

ICarii yes but that always been the case hihihihihi .... I remember 
rebo 1.3 .... Mwuhahahaha  full amator dev .... oups sorry. So it 
first start as 1.3 is only solving the loooooooooooooot of bugs posted 
on rambo by the community then it turns to Ho and how about adding 
AGG  to ViD ? and then it was Hey I  have a big new thing REbSERVICE 
!!!! and ASync  .... Bhuuuuuuuuuuuuuuuuu

at the end it took  1  year of dev when originally we where expecting 
a 2 month dev ....

R2 isn't even half saturated in what can be developed for it. If 
we wanted to, we could produce a whole lot more for rebol.org than 
the few scripts that are put there. R3 will be far harder to saturate.

Things i would like to see completed in R3:
1. AGG/Draw and richtext fixed.
2. Ports/async working 100% reliably.
3. Object system global/local completed.

unfortunately all these areas are currently a black box scenario.

It would be nice to get a 20 - 50x speedup from OpenGL :)

when you compare the size of OpenGL to win32 GDI.. you wont find 
a lot of size difference - only feature difference

I saw I project of a VM  based on OPENGL  for 3D interface it's name 
was IO  or something like that I stopped it as soon i downloaded 
it the helloworld was bigger in memory than in rebol

It just makes sense to have your compositing done on a video card 
rather than in CPU - and you will notice Vista / OSX both take this 
approach

its like having a toolbox ful of tools but refusing to use anything 
except the hammer in case of compatibility problems or bloat :P

but were getting a little OT from R3 here ;)

It will be even more fun to work within the R3 framework. Did you 
know that user defined datatypes are planned to include support for 
user defined function types? You could write your own rebcode as 
a plugin.

having a rebol clone strong project can give us more skills and maybe 
lead carl to trust us more and open too alternative things like for 
example working on a new way to hook DLL  to extend rebol

we shouldnt need to hook dll :P Rebol is a messaging language - it 
should have interface handling built in :)

why not? if each component is a black box and only data is passed 
between the you have more flexibility.

but then the problem is you move the hook to a server in C code and 
most  of your work is to write the hooking server in C ...

in python when I want to use a DLL  I write a bridge wich is more 
easy to wirte because C and python data types and hum the same  (same 
with java ...) so the bridging part is not so headach tahn writing 
a bridge in rebol

From Carl's posts on the subject (not necessarily in the blog), it 
seems that he is using the new VID design as a mental framework that 
he is hanging a bunch of core changes on. This seems like a significant 
project that Carl is uniquely suited for. I would even recommend 
that prospective cloners wait until he is through this project - 
the results are likely to be worth it :)

rebol as a (windows/whatever) service would be nice - if it was stable 
enough.

Ho that remember i noticed in VID2  a surprising bug ....

Mental framework is a system design term. Synapses are in the implementation 
phase :)

ICarii - as for DLLs - maybe DLL interface will not be present in 
R3 as we know it. Well, most wrappers will not probably work out 
of the box. IIRC Carl was thinking making DLL interface just a plug-in. 
Plug-in interfaces API is done from some 80%, just not exposed yet 
...

that should renderize 1 image then the second on the lower then block 
of 4 images in sqaure  the below an image then a secon column same 
way

Brian: sure, user defined types are interesting features, but do 
you seriously think that such low-level feature would be implemented 
(and finished) before 2010 if high-level features like VID take precedence 
? What would be the next priority, View's Desktop ? Looking at how 
R3 has evolved since the first alpha in june 2007, I see that only 
very few core vital features have been finished, like ports, and 
the rest of the time has been spent on less important things like 
unicode support (which is a *very* valuable addition, but not vital, 
because anyone can implement it at mezz level if required). Features 
that nobody, except Carl, can add to the language (because it's closed) 
like modules, threading, rebcode, user-types,... are still pending.

that what i love with rebol  an sample is while discusing to pop 
out a bug is so easy to do  ^^

Doc, a lot of the module code is there already, mostly mezzanine 
and a few core changes that have already been done. Rebcode we can 
add ourselves after UDTs are there. Unicode was a lot more important 
than you think, because it required language design changes and had 
deep implications - it had to be done first. I agree that there are 
definitely some low-level things that I would like Carl to focus 
on next, like threading and the changes to the object! semantics 
(this affects modules and nearly everything else). Only then can 
the plugin interface be done, and with plugins come UDTs.

hum well if it was only a little hum spacing problem I wouldn't  
point at it but why the first column is rendering OK and the column 
with exactly same instructions is not

and where the bug arrive to the top of the mountain is when you add 
a 3rd colum you have the 2 first column rendered OK  and the bug 
show on the 3rd column ...

Doc, I'm not assuming that Carl is chasing windmills at this point; 
unfortunately I don't have enough info to make that judgement. All 
I can tell is that the Unicode stuff was deep and far reaching, and 
required many core changes, so much so that it had to be done first. 
That was definitely not chasing windmills, that was bare minimum 
functionality for a modern programming language, something that all 
of the other language rewrites going on right now have had to do.

That's not a bug though :)

The discussions happened a year ago, mostly on Carl's blog and the 
R3 development world, but were put on hold until enough of the R3 
infrastructure was in place to do them properly (including binding 
changes and Unicode). The discussions will be resuming after Carl 
resurfaces.

Don't worry, it was just a year ago. I can still remember all of 
the major arguments on every side.

and i have heart beat and 1000 cows with 70 fps on my computer that's 
great would be even greater If gob could get a transparent background 
^^

Perk because organising a widget content in a CSS way is yes more 
readable but get more line of codes than VID2  way wich is not seen 
anywhere else

in opera widgets applet you have a CSS whay to setup the widget and 
in destop google applet you have a XML  way to setup the widget

well that's my personal taste the only way to get me spend hours 
on a GUI  is when I write a brand new widget  ^^

but anyway that's another way to organise the code maybe the most 
of ppl will like it and I still can do a  bridge dialect VID2-> VID3 
 to keep my habits  in GUI  coding  hihihihi

like a makedoc but for VID2 -> VID3

I did notice that you have to create new widgets in VID2 a lot more 
than seemed necessary to me. I hope that most people can get away 
with just using widgets in their code, and leave the widget creation 
to the GUI designers (which I am not).

yeah but hum with VID2 If you wanted something hum looking a little 
bit pro (before rebGUI) you was obligated to build your own widgets 
or customize the existing ones ...

Yup, that is definitely the case with VID2. With VID3, you are supposed 
to just be able to download a professional looking skin made by someone 
like Henrik and get back to the work of doing your aplication :)

if i can use my makeVID2 we get a deal lol

Orca is a REBOL-like interpreter which can be used under the terms 
of either the GPL or LGPL.


The interpreter is a C library so that C/C++ applications can use 
Orca as an embedded scripting system.

Hum integrated in a C library that reminds me something ....

I'm looking of what can be done and how it can be done with orca 
hum compare to rebol that's a short version.

on language structure i realy don't see why it revendicates to be 
a rebol like VM ....

it's more like a shell ... than rebol

hum i make a mistake the code samle igived is thune

http://trac.geekisp.com/orca/wiki/OrcaProject<- seems like a better 
start point...

So Carl is back for a bit. We're having a little chat. Will post 
a summary when we're done.

Henrik thanks for posting.  That sounds a bit like how I currently 
dev my gui apps.  They behave like webpages for the most part.

a stronger link betwin "networking" and "visual" modules ??? hum 
that's like if Carl was preteneding we can't already do that !!?? 
What VID (or what ever called (turtle, springler, widlets reblets, 
reboing, rebelistic-view-system,widbol)  needs is a better Interface 
Human machin a better set of functionnalities  to reflect the most 
of the visual capabilities of now in days computers and a better 
set of widgets.... (call it cosmetic (code and rendering) and performancies 
to be short )

the remaining questions are  futil  and worthless .... I prefere 
a no mane thing working than a named thing not working ....

interresting questions: what is the new road map (with deadlines) 
whowill participate?  actual gabrile code remains or is it trashed 
?  in the futur how can we organise the community to apport more 
and in amore productivly way?  what is the real main vision he have 
on view? does it's going to be an easy to  build  fexible and easy 
to update visual  IHM  or does it going to be nothing more than a 
webrowser (and bro if that's your vision you are a decade too late 
there is plenty of web browser and most of thempropose way to extend 
them with minimal coding .... )

He says he's building a new gui system ... don't really know what 
that means.

I read that too graham  but that's too fuzzy man ... That's like 
the NASA tell us they are going to lend a shuttle on mars planet 
....

wellwhat amazed me is the community message was (as far my poor idiot 
brain understood it ) "We need VID  with more widgets closer in the 
look and capabilities of what can be done with other widgets libraries, 
better performancies and a bette way to handle user/machine interface 
. And Carl reply by okay VID2  is a trash lets change all .... I'm 
not sure the reply feets with the ask. But maybe our   ask was too 
much short ended vision and Carlplans on a bigger plan but that can 
only telled by him

I'm not sure having CArl and gabriele working on there own on differents 
things is a good thing because at the end the one who  will realese 
the official  content is carl

most of people to tell you the truth plan a little with rebol see 
some of it capabilities then face a lack ( not able to do something 
they want to do ) and abandon rebol ....

unless you have a way to use existng things

Rebol and VID were a S shaped learning curve.

in my opinion that depends what you means by visual interface ? Is 
it some buttons some text and some pictures or is it 3D  content 
menubars and lot of flicking a bouncing widgets ?

plus if anytime the community ask for extention carl reply by I change 
it all that will not make rebol be better known and accepted as a 
trusted solution for buisness area...

even financial software needs a decent gui

doing vid a webbrowser like librarie hum ... but webbrowser now in 
day are dependant on  flash plug in so in a way things are not done 
 in anymore on the webrowser layer

Maybe Carl is writing a web browser??

Carl 'In other words, when you download R3 and run it, it will look 
like a web browser."

Getting rid of the desktop metaphor which is confusing because it 
doesn't behave like a desktop

but  achieving a web browser is more than only connect to a http 
server retrive and renders HTTP once again that way to think was 
OK in years 90  but not in years 2008 ...  Yes most of what do a 
webbrowser is to rederised HTML  page but what about the video streaming 
or animated interfaces (what flash is ablem to bring to a  webbrowser 
and make the 2008 web sites so hum dynamic)

I take it you're venting some frustrations ... but we aren't in a 
position to deal with them lacking the information.

for example opera webbrowser functionnalities: It render HTML content 
(some times with some strange bug), you have voice speech sinthesis 
to read the content of a page for blind people for example  you have 
voice command system  to operate it, you have widgets (external kind 
of mini GUI  sofware pieces to show you web information on an extend 
way) you have a plugin system with lot of plugings you can use P2P 
bitorrent to download you can connect to IRC read your mails ... 
 So yes now in day web browser are not only web browser and that's 
a matter of  fact  this evolution took 10  years of constent apports 
I don't see rebol going this way in only a couple of month ...

well after a deep reflection VID2 widgets set was already to reflect 
the kind of widget  you can renderize in HTML

I get the feeling that Carl wants VID3.4 to be just right, so it 
takes a little time to do.


The point in the webbrowser form factor is to provide a more recognizable 
launcher. I don't think the idea is to compete with existing webbrowsers 
at all. We don't even know if it will be capable of displaying HTML 
webpages.

well with vID2 we done a MDP Makedoc  renderer so doing HTML  one 
is not so hard with actual VID but the fact is MD GUI  and MDP GUI 
 gots a big lack of widgets for the none document rendering part 
wich I will call the IHM (menu bars, tab-panels, ability to resize 
easyly the whole content  or part of it   and that what lead us to 
do rebGUI ... to enhance that aspect.)

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.

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

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 >

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.

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.

I'll guess I'll hang on for a bit longer.

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.

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!). :-)

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.

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

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  ^^)

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.

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...

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.

Collaboration and community development is a goal of DevBase.

unicode has changed many things on a basic level. this affects some 
mezzanines which need to be fixed.

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.

So to answer Louis' question: Not yet, as far as we know. The data 
structures for Unicode strings are there, as are UTF-8 word! values, 
but binary encoding and decoding is not yet there, and there are 
some limts to Unicode input and output (mostly due to the Windows 
console). The encoding/decoding work seems likely to get done as 
a part of Carl's GUI work, as that will probably include text display. 
The console IO limits are likely to remain until the written-in-REBOL 
GUI console is adopted.

Carl "A PANEL is a group of FACES, each of which are of a STYLE" 
= Vid3.4

Carl "Yes, this week I'll begin writing a lot more about the concepts, 
and provide examples, screenshots, and a diagram or two."