World: r3wp

You are right about a hex editor seeing the REBOL source though, 
unless you do something weird to generate the source instead of referencing 
a literal string. However, remember that the code in memory is the 
result of executing the code in the module source, generating the 
in-memory data. That generation can be really elaborate if you like.

last two - three weeks are really slow in regards to R3 development 
... unless Carl is doing something in the background ...

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

Seems links to demos on that page are dead.

September plan posted - http://www.rebol.com/article/0426.html

hmm, actually does not sound like a plan ...

yeah, what about the sound port ?? ;-)

look at detailed beta plan - it is just list of things to do. It 
seems Carl is not sure about adding sound device (for the beta)

i wasn't serious...

But rebolek might be serious :-)

the list is sometimes strange - why 'replace has high priority, but 
other imo more important stuff has medium or low?

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.

I expected such a comment on your part :-)

well, everything is important. But how much speed-up do we get via 
new replace? How often is that used in our code? :-)

I made it as best I could. It needs to be native.

I agree about the need for replace being a native. I would prefer 
emphasis on other areas though, e.g. on parse enhancements :-)

But - according to the list, it is hopefully being adressed too ...

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.

Parse enhancements are hard - have you seen that list?

yes, I had ... and? :-) Carl reserved 5 days for that. I am for implementation 
of all stuff from  the list. If you count the time needed, it is 
not more that 1-2 months to beta. After 3 years 1 or 2 months is 
OK with me ...

:)

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?

Because there has not been any discussion or proposals for what those 
mezzanines should be yet. There isn't even any CuureCode requests 
for such - only a request to get CGI working on Windows (it already 
does on Linux).

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?

help cgi ;-)

It won't work the same way in R3 - no system/options/cgi object.

system/options/cgi

hmm - so where is the right place for such stuff?

Do we want to put it into external module? Then we are stripping 
out important stuff from R3, making it less compact than R2

hmm, Max lobbing for user dtypes :-)

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.

is there any new work version of REPLACE ?

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

BrianH: it is not about wasting. I just want we don't do fatal mistake 
- pretending we order users how they should use R3. R3 would be already 
used by many ppl, but is not, due of following reasons:

- missing network protocols, proxy
- call incompletness in comparison to R2
- weird console
- missing CGI mode
- missing DB protocols


No matter how your module system is usefull, if we don't provide 
users with R2 level completness, we are doing fatal mistake ...

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.

This is also why the extension model was so important - not everyone 
needs SQLite either, but the people who do *really* need it.

Max just proposed interesting way to implement utypes on R3 chat.

probably, we should use APPLY :find in REPLACE to allow more options, 
no ?

REPLACE has as many options as it can handle. The overhead of managing 
all of the REPLACE refinements is reaching the point of diminishing 
returns. The main problem of REPLACE isn't flexibility, it's performance.

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

BrianH, what's a quick check for CGI?

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.

pekr is a tool??