AltME groups: search

That means that you already had versions of those files in your work 
dir, and that get * didn't overwrite them. If you haven't made local 
changes to any files in that directory, do a purge-dir, then get 
*.

Nicolas, please check whether the return value from ON-CLICK can 
be a face. After clicking, it's possible to return a drag object 
and if a face object is returned, it might fail.

Not just for the os shell which has launched rebol, but rebol scripts 
that do other rebol scripts - the DO could be considered like a function 
call, and the DO'ed script could RETURN just as if it was a function.

The attractiveness of the idea is that there is just one function 
(return) to learn which handles the same concept (returning) in different 
contexts.

What do you mean by completness? IMO R3 is more advanced than R2 
already, and we are nearing beta stage =  system architecture is 
in-there, all slots in the right place. Now we need to finish few 
things, for user to be usable as R2 is:


- better console (not necessarily needed, but Windows one is total 
crap and makes experience 40% worse for me)
- fixed call
- network protocols (ftp, pop, smtp, proxy )
- ported DB drivers (done by community hopefully)

- improved parse (needed probably if we want to have DB drivers and 
network drivers done new way, but not necessarily)
- missing CGI mode
- GUI far from beta

thanks Petr thats what I was looking for.  I'm in the process of 
putting together a small proposal for my company, and I hadn't seen 
much recently on the release scheduling on the R3 blog.

I would wait 6-12 months at least with using R3 in production apps, 
particularly if you are betting on advanced high level things like 
GUI. Development could start now, but R3 is not near feature freeze 
yet. Many moving targets and bugs remain. Cyphre is supposed to give 
the graphics engine another overhaul. We are also missing many docs 
for painless porting of R3 to other OS'es.


BTW: Carl has mentioned before that some things are needed for beta. 
I'm not sure the recent blog post is a good indication that R3 is 
anywhere near beta. I read it more like "this is a necessary 3.0 
feature".

If so, it could be, because he wants to remove the GUI from 3.0. 
I know he is going a bit back and forth on that.

I doubt it ... do you think that module can have easily binary code? 
:-) You can remove VID, but what about View kernel? I doubt it. But 
we still have to see Core and Host isolation interface. Extensions 
are something different. We are still waiting for Host code release 
...

Henrik - a bit OT here, but maybe not. Have you looked into UIs of 
iPhone, HTC Sense (TouchFlo 3D)? I wonder if those glossy nice icons 
and other UI elements can be done using AGG and gradients, or are 
those things precisely rendered using 3D tools? Or are they just 
non-scallable bitmaps?

they are usually made with 3D tools and Photoshop and the like.

So, I am still curious, how Core and Host parts are being abstracted/separated. 
And even then such separation does not mean, that View can be easily 
extracted outside as a module. Extracting only VID is imo nonsense.

to me REBOL the language and REBOL the platform are two different 
things.   forcing view as a requisite to rebol does not allow the 
language to live on its own.


if RT release the equivalent of core and makes that stable, we can 
already build a lot of apps, Back-ends, services, clients, etc.  
I'd rather have networking protocols, a stable set of mezz, continued 
improvements on extensions, than a lot of time waisted on view, delaying 
yet again all we can do with core already.

the OpenGL GUI will not need view, and if someone wants to make a 
cocoa extension or a windows native gui extension... they should 
not be forced to include view in their binaries.

a platform like view is a good thing, not saying it isn't, but its 
a different thing... to me, R3 is about the maturing of the language 
and of its interpreter.

Then good luck to RT, as they should find another mechanism, of how 
to physically isolate various components. With View, there si event 
queue involved, so I wonder, how the eventual split so that you "import 
View can be done. While I like REBOL.dll idea and its isolation, 
I don't like one homogenic Host portion code. It will lead to tonnes 
of various releases. Any ideas here? Could extension isolation interface 
be used for Host code and its componentes? Or are there different 
requirements? I will probably post to R3 Chat, to provoke some ideas 
from Carl. So just stop me, if you think that what I am asking is 
eventually very obvious :-)

At least we need 2 releases: Core and View

ok, posted Chat questions and suggestion for blog article describing 
"REBOL packaging methods"

Just mulling it over, and I think I like it.

Re. new datatypes. Would all of set-paren!, get-paren! and lit-paren! 
make sense? Working like this:

>> a: 4
>> :(a)
== (4)		; type paren!
>> '(a)
== (a)		; type paren!
>> blk: [a b c]
>> (blk/2): 42
>> b
== 42

I suggested, a get-block! should work, so
:[a b c]
was the same as
reduce [a b c]
Maybe it's better, if it was:
reduce [:a :b :c]
?

I came to think of symmertry between parens and blocks. It make sense 
to me to have a lit-paren! datatype. What about a lit-block! datatype? 
The thing is, parens are evaluated by default, blocks are not. So 
a block acts like a lit-block! would, I guess. Is it a good idea, 
that blocks are not evaluated by default? A lot of functions take 
blocks as arguments. Some functions reduce their block argument, 
some don't. This can be confusing. If blocks were always evaluated, 
functions didn't have to reduce them. And then a lit-block! datatype 
would make sense.

Comments?

Example of functions, that treat they block argument differently:

>> first [a]
== a
>> print [a]
** Script Error: a has no value


If blocks were always evaluated, and we had lit-block!, it would 
look like this:

>> first [a]
** Script Error: a has no value
>> first '[a]
== a
>> print '[a]
a

John; I've become quite a fan of REBOL unreduced block data.  Super 
handy and learning the wisdom of it is a right of passage.

Sorry John ... I had ^s turned off ... drop that last snarky bit 
about   insert.   Stupid question that could very well have some 
intelligent and reasonable responses.

John, actually previous version of rebol had "aggressive" evaluations 
on some blocks in some circumstances and it was quite annoying in 
fact.  it got removed in 2.3 IIRC forcing us to reduce a little more, 
but now we have control.

it definitely is possible language-wise, we are already doing it 
with string parsing and using load/next.  The defining moment here 
is the decision by Carl to "let go" of  the total expressive control 
of the language, and that will not happen soon IIRC.  its already 
cool that he has decided to open source all but the deep core of 
the language.

maybe with R4, after all of the goodies this opening will have brought, 
he will be able to contemplate opening up a bit more.  There is always 
a risk that letting go of *total* control can warp your creation 
to something you don't like.  But my experience in a decade of REBOL 
shows that stuff which isn't "sanctified" by RT have a lot of difficulty 
picking-up speed.


When you (i.e. Carl) spend 10 years on a project and it doesn't take 
off in-part because the responsability of keeping control stymies 
its growth, to a slower pace than that of the industry, IMHO you 
realize that the possible upside to *total* control definitely is 
dwarfed by having a mass of like-minded peers who move along with 
you.  


obviously no one sings exactly the same tune, but you need to try 
out stuff in order to know if its really a good or a bad idea... 
I'd rather have 100 people doing this, and then selecting the obvious 
clear winners than trying to muse about it, try a single idea and 
finally realize it wasn't a good idea.


Plus, what is good philosophy for RT isn't good for everyone... the 
proof is that the PITS model isn't enough for everyone.  Even RT 
had to acknoledge this.

REBOL "The language" is IMHO the best on the surface of Earth, but 
the platform (the actual executable, the desktop, view, IOS, et all) 
all show signs of tearing at the seams when you really want to "DO 
REAL WORK". 


You can get by, but its often painfull, or result to dubious work-arounds. 
  I have a lot of experience in big REBOL apps, so its not just word 
of mouth... I'm one of the few who has been succesffull at PITL work 
in R2 (hobby and commercial) for years.  But not everyone likes to 
say that problem-solving the platform itself is part of the work. 
 Most people want to work, they don't have time to try and fix view, 
or some tcp scheme, or charging their clients 30 hours to find a 
way to make 'CALL  work properly (or implement a MS COMLIB hack).

Every single broad decisision in R3 has been an enabling one for 
REBOL at large (both platform and language).   


Unfortunately, some things still require the core to be improved 
a bit, but we are nearing a point where REBOL will be able to fly 
on its own wings.   Just look at my attempt to get OpenGL to work 
with R3... it took me  10 hours of work from downloading the extension-enabled 
R3 version, downloading MS compiler, scrubbing the net for OpenGL 
reference material, libs, examples... and integrating all of this. 
 I've never coded OpenGL directly before... 


now imagine 100 of us doing this... that is what I see in REBOL's 
future within 2 years.  You will have things like trolltech QT bindings 
appearing, REBOL libs for any precise API out there... finally REBOL 
will be able to evolve with the rest of the world, and hopefully, 
impact its philosophy on the Computer Science more obviously...

JSON is a proof that it already has... now let's get that into the 
spotlight and start letting REBOL do what its really good at.... 
high-level application development...


 let it be the MCP for all the cool APIs, libs, network services, 
 game engines, web sites, smart appliances, etc... out there.


 (Refer to the movie Tron, for those who don't know what MCP stands 
 for... ;-)

There were still talks in REBOL community about the model of concurency, 
and some other systems studied.

Maxim, the reason that custom datatypes can't extend the syntax is 
technical, not a control issue. When TRANSCODE/on-error was proposed, 
Carl revealed that TRANSCODE can't call out to external code on syntax 
exceptions without making it drastically slower, too slow for use. 
This is why the /error option was implemented instead: it doesn't 
use hooks or callbacks.


We do have custom datatype hooks for the serialized syntax constructors, 
but those are passed the preparsed REBOL data inside the #[ ]. Custom 
syntax hooks for ordinary literals would require a complete redesign 
of the parser, and that redesigned parser would be much worse, in 
terms of resource usage (speed, memory).

TRANSCODE/error *is* the junk! type, except it is (properly) an error! 
instead, just not thrown. You can process the info in that error 
and continue as you like.

re "symmetry between parens and blocks": "it make sense to me to 
have a lit-paren! datatype" no need, use:

On the other hand, I'm not a fan of letting user/age also search 
for set-words, lit-words and get-words.

Ladislav, I seem to remember, you once argued against get-words (or 
was it lit-words) as arguments to functions?

 - actually, that is a different matter. What I argued against was 
 "non-transparent" argument passing. The func [:argument] is not "just 
 a get-word", it is a specification of  "as-is argument passing". 
 As far as this one is concerned, it is much better than in R2; cf. 
 the QUOTE function, which cannot be implemented using any kind of 
 argument passing available in R2, while it is trivial in R3. The 
 "unevaluated words argument passing" specified by func ['some-word] 
 is still a different matter and I think that it is much less useful 
 than many users think. (e.g. the GET or SET function don't use it 
 for a good reason).

There are a few years gone since I wrote my last c program under 
windows.
Just today I tried the extensions.
I was successful with Win-Lcc, but not with tcc.

Can someone tell me, if its possible to compile the extensions with 
tcc and how it should be done?

Thinking aloud for a bit in relation to the new Copy Semantics:
http://www.rebol.net/wiki/Copy_Semantics


What about the idea of protecting values. This way they won't be 
copied, when creatng a new object. Today we can protect words, but 
not values. So if a word is used for an indirect value, we can kinda 
change the word anyway (I say 'kinda', because we change the value, 
the word points to):

>> a: "a string"
>> b: a
>> protect 'a
>> change b "hmm"
>> a
== "hmmtring"


My idea is, that if we were able to protect values producing constants, 
this idea could be used to guide the creating of objects. And Copy 
Semantics could maybe be a lot simpler.

Will images within objects be handled the same way in R2 and R3 then? 
;-)

Would this seem like a REBOL way to create a constant?

define s "a string"

Used e.g. in an object this way:

o: context [
	define s "a string"
]


s can then be used as any other word, except it can't be modified 
(both the word and the value), and it won't  be cloned, when creating 
new objects from o.

To me, the best way is, if the rules are so simple, you're never 
in doubt when programming. I compare these rules to operator rules. 
In REBOL, operators are evaluated left to right. It's a lot easier 
to remember, than having to look at page 53 in "The C Programming 
Language" every now and then, when I program in C, because I can't 
remember all those rules.


I guess, it would be dead simple, if all values were cloned by default, 
when creating new objects. And then use constants for those, that 
you don't wanna have cloned.

Honestly i don't see the interest to protect things.

All the Rebol scripts are plain texts so that they are readable and 
modifiable by any skilled programmer.

If we could compile some scripts or modules to prevent them from 
being inspected, i would say yes, i will protect some things.
but not currently.

From the docs:


COPY/types - specify as a typeset the values to be copied. Note that 
you can use /types without /deep, in which case the copy is applied 
only to the top level of values.


COPY/deep - perform the copy recursively on each value. If you use 
/deep without /types, it is assumed that you want to copy all series 
values (any-string!, binary!, and any-block!) but not bitsets, images, 
vectors, maps, functions, or objects.


I'm pretty sure, I won't be able to remember these rules, so I have 
to look it up, every time I use it. Result: I will probably not use 
it, if I don't really really have to.

Steeve, I sometime manage to accidently redefine words as TO. The 
result is, my script produce strange results, and it's a hard bug 
to find. I could consider protecting all the system words (there's 
a function to do that). But maybe better, if REBOL could give me 
a warning, when I redefine a system word (or maybe changing type 
of one of my own words).

First of all, i use local contexts everywhere, so that if i redefine 
a global words, the bad effect is limited.

Second: I mostly don't use mezzanines because i want my code as fast 
 as possible. So, I only have to remember the name of natives.

Third: I love REBOL and practices it every weeks, so it's not a pain 
to remember all the words.

fourthly: Because of that, i never do such bugs (except in old times)

Right, sometime I forgot those inside layout blocks, and that can 
be hard to debug.

Yup, I think, it might be a good idea to use that to guide copying 
of content within objects, so we don't have to have this complex 
copy semantics. A rule could be: protected values are like constants, 
and they don't get cloned, when creating new objects. All other values 
get cloned.
Makes sense to me.

A problem is though, if I wanna change such a protected value anyway. 
Then I have to first unprotect, change and (maybe) protect again. 
Alternatively, REBOL would need a new flag on values, that mark them 
as "changable constants" or "not-being-copied values" or whatever. 
A rule could be, that such values doesn't get cloned, but they can 
be changed effecting all objects having them.

Yeah, and only two words were wrong in the released version :)

My bad, not Carl's. The errors caused by the two wrong words are 
minor.

I would prefer that the next version work on the new object spec 
block and the rest of the copy semantics. The version after that 
can focus on splitting off the system context. After that, I would 
love it if the rest of the PROTECT bugs were fixed.

I've thought a great deal more about shared content within objects. 
One problem is, they're called objects, because we then think of 
objects, as we understand them in other languages. If we think of 
them as contexts instead, then the goal to achieve is to share something 
between contexts.

Do we want to share words or values?


If we share values, then we could have one word in one context point 
to the same value as another words in another context. We can do 
this today with indirect values (like strings, blocks, contexts, 
etc.), but not immediate values like integers.


I think, it's better to share words between contexts. With this, 
I mean, that some word in one context should give the same value 
as the same word in another context, if I so choose.

>> same? context1/my-word context2/my-word
== true


And if I change the value for my-word in one context, then the value 
for the same word in the other context should change too (if I've 
specified this word to be a shared word). We can't do this with words 
representing immediate values in REBOL. So I see too simple solution 
(simple as in not complex):


1) Either a new type of word, the shared word, is implemented in 
the language, and this can handle both immediate and indirect values.

2) Or the simple R2 rule is enough. In R2, contexts within contexts 
are not cloned, but everything else is. We as programmers then have 
to put our shared words (representing all types of values, both immediate 
and indirect) inside contexts in our contexts (or using the REBOL 
terminology: inside objects within objects).

(Ah, good to get all this off my chest.) ;-)

Geomol, regarding 1: Sounds good to me. And maybe we can make a big 
step forward to lazy evaluation including immediate values.

Robert - do you need such lazy evaluation? I mean - even 'alias seems 
being removed from R3. Don't we have enough of reflectivity? Anyway 
- anyone who imo wants to propose something, should definitely do 
so in terms of CureCode or R3 Chat, or Carl WILL NOT know about the 
request at all, and your only chance here will be BrianH :-)

Geomol, the main problem with sharing is doing it in a manageable 
way. The advantage of using explicitly shared contexts is that you 
can know where your values are and distingish them from non-shared 
values.


Your idea about a different word type for shared values won't work 
because words don't actually contain anything. All values are stored 
in contexts, blocks or type-specific containers. All values "assigned 
to words" are contained in contexts, no exceptions. Even function 
words are associated with contexts. The question is which one.

R3 has two context types already:

- object!: Similar to system/words in R2, though for some internal 
instances (like error!) expansion is blocked. Direct reference.

- function!: Not expandable, stack-relative reference. Task and recursion 
safe.


Closures have object-style contexts, with a new instance created 
with every call (with bind/copy overhead on the code block, sort-of).

Robert, you can do lazy evaluation using functions that replace themselves 
with their results. Anything more requires a full language semantics 
overhaul, and might not be possible in an interpreted language. What 
do you hope to accomplish?

Sorry, i was seeking the post related to laziness from Robert and 
didn't found it....

Brian wrote "Your idea about a different word type for shared values 
won't work because words don't actually contain anything."


Don't say, it won't work. It can be made to work, if the will is 
there. I can think of many different possible implementations of 
REBOL with the current behaviour, we see. As I don't know, how exactly 
REBOL is implemented (I guess, only Carl does), I won't go in detail 
how to do, what I propose. Anyway, I personal feel, it might NOT 
be worth the efford to implement, what a programmer would observe 
as shared words. The C code will be more complex, and it will probably 
hit performance to some degree. Shared contexts within contexts as 
in R2 is probably just fine. Only problem (as I see it) in R2, is 
that it's difficult to not share contexts within contexts. But the 
R3 possibility to copy contexts can solve that. I think, the current 
R3 implementation of contexts (objects) and the copy semantics is 
far too complex.

But the /deep refinement for make would only be used with objects, 
and it's maybe not ok to add a refinement to a function, if it's 
only to be used with one certain type of argument?

From time to time I ask myself, why I write so much about all this. 
It's because I care for the language, and I see many stange implementation 
decisions, and that's not good.

Geomol, I'm not saying that what you want can't be done, I'm saying 
that you would be creating a new context type, not a new word type. 
The type of a word doesn't in any way affect the behavior of value 
slots that the word might refer to, but the context type does.


However, I don't think that a new context type would be needed here, 
because the object! context is shared by default. The only thing 
you are affecting is whether prototype fields would be shared amongst 
derived objects, or copied. You could easily implement this kind 
of sharing using a mezzanine like FUNCT (not FUNCT, but another mezzanine 
with a similar implementation). There would be no performance degradation 
on use of the shared words, and only minimal at creation time. The 
reslting code would be semantically equivalent to the R2-style shared 
inner object model, but the code wold be simpler.

For the most part, you don't access unexported module variables, 
and don't use path notation. Minimal programmer overhead.

Well, I probably think about them way too much as about objects. 
OTOH - I might have some module, but I want to hide my internals 
... kind of DLL aproach - you only provide docs with the accessible 
API and the rest should be hidden and even maybe signed ...

In general, R3 assumes that the developer who is creating the script 
is not an idiot, and knows what they want to do. If they want to 
lock things down then there are ways to enable that safely. Otherwise, 
it's as open as you want it to be. PITL doesn''t require that the 
system hide everything, just thaat it be possible to organize large 
systems. Protect what you need to.

OK, so what is the possibility for developer to provide users with 
some secure = signed module, with protected internals and only providing 
users with exported API? Do I have to use extensions for that, and 
mangle my code somehow? Calling proted/hide in user app does not 
help module author, if he/she does not wish to release his code. 
My questions are theoretical - I will probably never write any such 
stuff, but I would like to imagine, how some business entinty could 
aproach this ...

Signing a module only gives a user someone to blame if things go 
wrong - it isn't real protection. But I agree, code signing would 
be nice, especially for extensions since you can't just read the 
code very easily. The checksum support works for verifying the code 
matches what you expect though.


The module system is designed with security in mind, not closing 
the source. If you want closed source make an extension, or encrypt 
your REBOL source (like R2 encapping), or build your own host program 
(the R3 version of encapping), or download the source from a secure 
server and protect the words that refer to it so you can't get at 
it through reflection at runtime. REBOL still isn't compiled, sorry.

An extension's mezz code is itself a module, and its source is as 
closed as you can make any source that is embedded in native code.

so since we export some words and extension mezz are essentially 
unnamed modules... their content really is hidden and can't be extracted 
  :-)

although I guess scanning the extension with a hex editor will reveal 
the code inside!?

Just read a R3 blog post about the future of the alias cmd in R3. 
Someone commented that we should see the state of the art : http://www.extjs.com/products/gxt/
 not too foolish but can we do something similar with R2 or R3 ? 
That's where I would like  to go with R2 and R3 ...

The extension mezz are not just unnamed modules, they are real modules 
that follow the same rules as regular modules, including naming and 
isolation. IMPORT doesn't know the difference between a module and 
an extension.

Gerard - I think that in regards to View, we might see some interesting 
things. VID3 is going to be much more flexible, than VID2. It should 
(and hopefully will) provoke skin and widget authors to come-up with 
some more professional looks. We can try to mimick ExtJS for e.g. 
Another possibility is VID3 "compiler", so that your VID3 source 
gets "compiled" to ExtJS or some other widgets, running in your browser 
.... it is very preliminary to say, where the future leads us ...

I think you are underestimating how badly REPLACE sucks. I wrote 
it, so I know it is as good as you are going to get in mezzanine. 
And it's a widely used and reviled function.

If it didn't suck, it would be used a *lot*. This would be almost 
as much of a speedup as REDUCE/into and COMPOSE/into.

I more care about the completness level, hence I am a bit surprised 
that e.g. CGI mode is not on the list and networking protocols are 
low priority. As for those, maybe Carl plans that community should 
do it. But as for CGI - why are not CGI related mezzanines in R3?

I have no idea what mezzanines you would want for CGI support. And 
can't really test them except in simulation, due to Windows CGI not 
working yet. What do you want?

Making a module, even a community library, is the best way to get 
the more complex stuff in. Post it to DevBase, start the discussion, 
get it refined, and then it may be incorporated, or may not be. Don't 
waste all of the work I did to get the module system working.

The new REPLACE would be native, and noone has made any proposed 
source or even spec yet. Still under discussion.

CGI mode is only missing on Windows (and might be on OSX - noone 
has checked yet). CGI works just fine on Linux.

As for where the right place to put the CGI environment variables, 
R3 currently leaves them in the environment, and uses GET-ENV to 
get at them. When system/options/cgi was first created, REBOL didn't 
have a user-accessible GET-ENV function. You could easily write a 
REBOL function that could construct an object containing all of the 
information passed to a CGI process, but that function and that object 
would be web-server-specific.

However, you are missing the whole point of the module system: R3 
won't be as monolithic as R2, and will have fewer mezzanines, not 
more, on purpose. We are trying to make R3 cleaner than R2, and easier 
to customize for your specific use. That means less built in, and 
more added on, in some cases from a common library of modules that 
the community maintains. Non-CGI apps don't need CGI mezzanines.

Re user types, Its just that I've realised a common theme in the 
last weeks, and they all can be handled via a simple user type datatype. 
 They wouldn't need any C coding and can start very simple and be 
augmented as usage gives us valuable feedback.


Coupled with extensions, they could be a VERY interesting way to 
add toolsets to REBOL. (just like people do it in python  ;-)  


I could very easily wrap liquid, as an example, and allow completely 
invisible dataflow to some extent!  It would take me less than an 
hour to do with what I propose (once liquid works in R3).

I don't really know - I'd have to look up the CGI specs and write 
a script. I don't have Linux working here locally, so I can't experiment.

hum for multimedia extension we should choose things partable and 
on public domaine i think ...

it's easy to make a VID front end to pilot a oggvorbis player for 
example it's more difficult to mix VID and opengl.

actually it isn't hard to mix VID and OpenGL  :-)  all we need is 
a way to do a quick memcopy of the OpenGL pixel buffer into an image! 
datatype... that's it.  really simple.


now I dont want to be forced into using View though.  I want to be 
able to use extensions to control the windowing too.  I need to be 
able to use other window managers if I want to integrate into better 
engine which are already ported to all major platforms.  Things like 
open scene graph or other game-oriented 3D engine, DirectX, whatever.

even use precise timers and trigger rebol code... for high-end audio 
and video editing, and working with specialized media hardware too... 
this is essential.

extensions are the key to liberating REBOL from its platform limits. 
 just like python can focus on its core, all the rest is modular 
and is maintained by other people, not Guido.


once I get the OpenGL extension working to some basic level, RT will 
never need to support it, I am pretty sure, John, Cyphre, Henrik, 
Anton, I and others will be able to give it a life of its own, all 
that RT will have to do is provide a link to it on its own site and 
say that R3 supports OpenGL natively.


same for sqlite and pekr, and many other tools many of us use daily 
and wish we could manage with rebol instead.

Device interfacing was officialy added to project-plan. It is a good 
sign it will come, along with image and vector datatype support. 
No callbacks yet though ....

Carl`s reaction on the R3 chat wrt callbacks sort of seems to imply 
that he likes my callback idea and it might make the cut for extensions. 
 crossing my fingers.

3D allows us to use sub-pixel rendering which is actually more precise 
than AGG.  and if you don't use fancy shaders and effects, the rendering 
will be sooo similar as to not even be measurably different.

Max - unless my GUI looks precisely the same on all systems, I don't 
want to use it, easy as that. So - give a call to gfx card and driver 
makers, and try to standardise that :-)

Anyone is free to do anything. What I don't like is early split. 
I think that R3 without View has little sense. Who thinks that Core 
will make it, is imo mistaken. What would be browser plugin good 
for, if it would be Core only - there is no point in making such 
a plugin. And what GUI will we get? Multimegabyte SDL linked one? 
No VID?

I use REBOL to solve problems, please clients and get work done. 
 I also want to start doing some gaming and I really want to use 
OGL and REBOL so it can be cross platform and very fast with the 
minimal fuss.

and many clients DONT want custom guis... they want OS look and features 
which are OS native, like D&D, spotlight menu integration on OSX, 
system tray on windows, etc etc.

I prefer one well supported engine instead of 10 less supported. 
Everybody is free to do anything. What I don't like is, that sometimes 
new stuff distracts the crowd and splits the effort. In the same 
way I think that VID Ext Kit, in current days, is contraproductive 
product, but this is just my opinion.

We have to have our own face. The custom GUI is not the problem. 
The problem always was in its behavioral area - we need system compatible 
behaviour and deployment.

you forget that many of us actually use REBOL to feed our families 
 ;-)


R3 won't allow that for me until at least 6 months... and that's 
if the extension get extended enough.  otherwise, I have *Absolutely* 
no incentive to move to R3 right now.

Maxim - I might not care. This is just one measure, what client want. 
I provided clients with many solutions, from DOS apps via Windows 
native apps, some web apps, and VID/RebGUI small apps. They don't 
care.

Python does very well and it has no native GUI.

I'm saying that I need to be able to get shit done.  :-)


as much as I like the community and would love to be paid to work 
on improving R3 and making the world a better place, REBOL is and 
will always be a tool.  my needs are not the same than yours, or 
Graham's or Carl's.

If R3 has VID3 working, I'll probably use it for some projects... 
but when GLass will start to work (using OpenGL) then I'll probably 
never need VID anymore.  simply cause it'll do 5000 frames a second 
for my interfaces, including very advanced looks and next gen functionality 
like run-time interface manipulation by end-users.

Just let Henrik build a GUI for both R2 and R3 ...