AltME groups: search

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

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.

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.

I will correct my previous statement... AGG can do sub-pixel stuff 
too... but our use of integer pair! datatypes limit us to pixel coordinates 
within view.

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

as I said - you are free to do anything. What I want though, is at 
least one standard distro, even if being worse then external stuff. 
I don't want REBOL equivalent of KDE vs Gnome situation ...

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.

I can do se very easily, but I will revert - name me any candidate, 
which will attract millions, without the View/VID. Cheyenne? CureCode? 
Those are cool in itself, but how they will attract any new ppl to 
REBOL specifically?

I remember how we once tried to do similar stuff, just for the excercise 
purposes, wrapping SlashDot. There were 2-3 versions of GUI wrappers 
available.

Yes ... but we have some work to do here too. What about right mouse 
menu? Silverlight has there one item only - Silverligh. Flash has 
its own menu. Do we go similar route? E.g. JAVA install icon into 
Control Panel section. There has to be place, where you configure 
your plugin itself ...

Pekr, well, we have to figure out to extend the R3 console to javascript 
and basically do a console in a browser. It could be a big job.

Some requirements:


1. It would have to be a real console, so we can't simply send CGI 
jobs and close REBOL again.
2. There would have to be a way to spawn and kill consoles.

3. REBOL 3 will have to live up to its ability to limit itself memory 
wise. CPU hogging, we can't do much about. My Linode only has 384 
MB RAM right now.

4. The Ruby console can respond to various input and display help 
text related to what you are typing. This can be used to create tutorials.

5. I have a Cheyenne on my Linode. It either has to use it or not 
collide with it, if we don't use it. Can Cheyenne use a special R3 
process?

6. Managing the console output will obviously need to be done with 
AJAX.

7. Syntax highlighting seems a little superfluous right now, so the 
target right now would be a basic console.

The question is, if it should create sandbox for each user, I mean 
letting user to download something, save something, call something, 
parse it, etc. Or do you want to limit console to prevent file operations 
for e.g.?

Pekr, demo is a mezz. Another issue is graphics commands, lowlevel 
View and such. How do we handle that? I'm not sure we want to submit 
graphics via HTTP to the browser.

henrik, maybe you can create modules for each session and use do 
within each module... they will be shielded from each other, but 
you'll only need a single rebol process to run all users  :-)

no whatever calls your R3 decides which module to interact with and 
just calls something inside the module which returns the result of 
a 'DO executed from within the module.

console is going to be down for a bit while I do a rewrite of the 
console code.

I am trying to do simple CGI tests, using Cheyenne, and in reference 
to following blog: http://www.rebol.net/r3blogs/0182.html

For: http://localhost/show.cgi?test- I do get:

Content-type GE te 127.0 


Why always only 2 bytes? Is that actually two bytes? I would say 
- two "elements"

The code is:

#!c:\!rebol\altme\worlds\r3-gui\files\rebdev\view.exe -q

REBOL [
    Title:      "show"
    File:       %show.cgi
]

print "Content-type: text/html^/"
print get-env "REQUEST_METHOD"
print get-env "QUERY_STRING"
print get-env "REMOTE_ADDR"
print newline

Is that R3 problem, or Cheyenne problem?

hmm, strange. What can I do about it? IE displays chars correctly, 
the output in FF is weird, and I can't correct it by changing charset 
to any other setting ...

but if we need to output latin-1 afterwards (while dumping the html 
content, for example), the output encoding  should be selectable 
as a "current default", and all the --cgi would do is set that default 
to UTF-8 for example.

Max - your release 4 version plan sounds complicated to me. Can you 
see? Carl is not reacting to those things. IMO he thought he will 
put R3 into beta in few weeks, and as we know him, he might even 
do so, that is what I fear of. I agree, that unless some things are 
not stable enough, there is no point to go to beta.

btw Carl, it seems, is still open to renaming REBOL.  He seems to 
like "Zen" ... what do you guys think?

Heard a great line, don't remember from where: "Java has as much 
to do with JavaScript as Ham has to do with Hamster"

Of course it should have nothing to do with DirectX, but be the link 
between iPhone apps and Amiga ... or something.

Maxim - where do you come up with such info that Carl is open to 
renaming REBOL? I can't see anything like that floating around ... 
the REBOL rename is total nonsense and anyone claiming otherwise 
should take some marketing pills ...

Why do we come up with new names? Just search the blogs. Search R3-alpha 
altme group. Carl always teases community with similar topic, then 
I put some effort into collecting all possible names, post it several 
time to him ... just to see NO SIGLE response or decision ... this 
is really tiresome ...

yep... it would cost 1 billion, take twice as long as R3 to develop, 
do half of what R1does coded in javascript, and support for COBOL 
modules.


this is a direct reflection of what resulted in Bill implicating 
himself actively in vista's development process  :-)

I was just looking at the makedoc source, and when you count up section 
numbers, Carl spends about 15 lines of code doing that. You have 
to manually build the mechanics for counting section numbers. Now, 
this wasn't like the counter I was originally suggesting, because 
it was based on providing elaborate specs for the counter. Having 
to do that, might be why the proposition didn't live, as it's too 
complex to do natively.


But, still, what if you could count section numbers in a single line 
of code?

Your attention plz...

I noticed that between r3-a65 and r3-a76 (sorry i didn't test the 
interval).
we lost an hidden feature very useful (to my mind).

>>bin: #{000000}
>>bin/1: 513
>>bin
==#{010200}

Do you see what i mean ?

we could store integers into a binary stream in reversal order (little 
endian) without the need  to use a to-binary conversion (which consumes 
memory by reconstructing a binary and convert into big endian format 
instead).

But in the last alphas, we lost that.hidden feature:
** Script error: value out of range: 513

Any reason for that ?

BrianH: Carl asked me, that if I want some of following implemented/noticed, 
we should put them to the parse document. I gathered them in R3 chat. 
So - I would like to open short discussion about following proposals:
------------------

I would like to ask, what will happen to proposals, which are not 
part of the do

cument? I mean - I do remember following kind of proposals, which 
are discussed
in parent thread:


1) make /all option be the default parse mode. If I want to get really 
reliable
results, I always use /all, to be safe


2) there was some proposal to add /space, or /ignore, to allow easier 
parsing of

 CSV, etc., but other proposal was, that it might be better to let 
 it to the enc
oder/decoder level


3) there was a proposal to allow quoting of "", to make parsing easier.

Hmm, so good proposals are down the list ... e.g. of (I would call 
it any-of), do, reverse. Brian - what you think we get for the parse 
update for 3.0? Carl mentioned, that some proposals would require 
some big changes to underlying parse function. I was surprised,e 
.g. 'of being one of them ....

I worked out how to make it possible to use DO at all without it 
being a security disaster. Possible doesn't mean easy though.

do you think direct usage of PEG expressions? Well, I am waiting 
for "my" proposal - multiple to/thru :-)

No, words are still unbound by default. The miscellaneous loading 
mezzanine code binds the words to the appropriate contexts. PARSE 
won't do any binding, except probably to the keywords. The USE operation 
would be the only binding operation.

Do you get that the concept needs a name, and that obscure concepts 
also need names? The standard syntax for this concept won't work 
in REBOL, and the only other comparable parser is the one in Perl 
6, and we can't use that syntax either, or its semantics either (it's 
compiled). This *is* guru stuff - people get PHDs about parsing. 
Carl's proposal for +'s semantics is the way that this has to work 
given how REBOL parsing is implemented.

I don't mind the possibilities, I do care of naming and how long 
does it take for me to interpret it. If we go + route, we can change 
NOT to !, add &, II, >, -->, etc. :-)

Now I don't understand once again - if you are suggesting just changing 
the name of STAY to &, then please DON't do it!

Pekr, *you* want to change the | symbol. Or rather, you want to do 
something exactly equivalent, changing the corresponding & operation 
to STAY.

| is visually good ... it is like wall dividing slots ... it fits 
... the + is more complex. Guru stuff, which we will have difficulcy 
to explain. Maybe it can't be done the other way. So - user has to 
learn what does it do by examples, get used to it, and then maybe, 
he will understand it, once he sees it in the code. The only question 
is, if eventually naming it, or changing the syntax to achieve the 
same, could be done more elegantly, which I start to doubt.

What I don't know is whether it is possible to do postfix anything 
- failure might cause backtracking before the ? is reached.

Once again - free yourself from REBOL, gee. Who said said EITHER 
should compare anything? Copy breaks normal copy rebol logic. VID 
'at command is completly different in semantic meaning to REBOL 'AT. 
So - how is that that for EITHER we do care about what it means in 
REBOL? The word EXACTLY expresses what you are doing ...

your rant towards EITHER not fitting anything breaks the initial 
purpse dialecting was brought to REBOL! And the meaning is - the 
same word, might mean different things in various contexts. We don't 
care for VID to use potentially the same keywords to REBOL functions, 
let we do care somehow mysteriously about PARSE to NOT use the same 
keyword naming as REBOL functions. Let's judge EITHER by its name, 
not by its REBOL level meaning.

but brian... ALL real parse rules are so complext that we need to 
properly define the groups of "|" between them... so the point is 
moot even if they do work better now.

i started the port of areatc to rebol 3 ... so far i hate the way 
to stilize gobs all those words to put every where yeeeeeeeeeeeeerk 
... my gob does already more than 10  lines and do nothing on screen 
!!!

I'm frustrated max ... i saw carl working on parse i wanted to take 
that opportinuty to start adapting area-tc to r3  and VID just is 
unfinished not even exploitable to do a starting of a begining of 
a test work ....  i though text instruction as been reformed last 
time carl working on GUI  and that we could use thing like text pos 
[ color1 "string1" color2 "string2" color3 '"string3" etc ...]

yeah ... i believed what people told me you can almost use Vid to 
do area-tc  thing is it's not the case at all ...

button "Close" [quit] that doesn't work neither ?

what i have to do then button "Close" with [actor: [ on-lick: [quit]] 
] ?

ok an just to unview the window  how can i do ?

The plan is now to do a /Core and /View, with /Core coming out first.

i tested even forcing rebol to use the tff file from windows XP  
and that produced the same sizing bug 

all the text motion turns around the idea you don't have much to 
care about each char size in pixel since it's always the same you 
do a size-text call on "MM" only when you change the font size (growing 
the text shrinking it) and that's all if we had to care about the 
rendering of each elements in the texts that woud be a real pain

Indeed VID3.4 is far from done. You can probably use it for a few 
things, like getting a name from a user in a text field or submit 
a very simple form, but not much more than that. To reiterate the 
state of the UI:

- No unicode yet in graphics (when Cyphre gets around to it).
- Resizing acts like a drunken sailor. (Carl)
- Skin is not published. (Me)
- Style tagging is not implemented. (Carl)
- Reasonable requesters are not yet implemented. (Carl or me)
- Layers are not yet implemented. (Carl)
- Guides are not yet implemented. (Carl)

- Better font rendering. We are not taking advantage of what AGG 
can do. (Cyphre again)
- Event system is from Gabriele's VID3. (Carl)
- Many features are untested, like drag&drop. (Me, I guess)
- Proper material management for skin. (Me).
- Many styles are not implemented, especially lists (Me).
- More elaborate animation engine (Carl or Me).
- Form dialect (Carl talked about this).
- More/better icon artwork (Me).


Plus, Maxim has some ideas for DRAW, to greatly speed up rendering, 
but I don't know if they can be implemented.


The overall design of the GUI engine is very good. Whenever a change 
or addition is made, you alter 3-5 lines of code in one place, and 
it works. I doubt the entire engine will be rewritten.


You won't see GUI bug reports in Curecode for a while. There could 
easily be 2-300 reports, once we get to that point.


My work regarding skins is rather big: I need to work out the basic 
styles first, so we have a reasonable way to build compound styles. 
These are being done using a very simple, but pixel accurate GUI 
using plain colored surfaces. This is easier for testing out, as 
draw blocks are small, but as Pekr likes to complain: They are not 
pretty to look at. Once the real skin goes into place, the draw blocks 
will grow a lot.


I would love to see a low-level GOB management dialect, like Gabriele's 
MakeGOB.

rich-text is read only spécific rendering  based on a specific markup 
language... since we are not talking about the same goal ( i want 
real time text edition (read and write) and the hability to create 
extend or change the rendering process to feet not only colorize 
text but any kind of tet rendering with high performances and simplicity 
of code writing. area-tc is just the first step in that process it's 
just  a proff to show that VID and most largely rebol concept can 
bring to that area. But there is still alot of work to do and that's 
normal initially VID and draw were not designed to handle such duties 
and the tricks we had to use to achieve that goal in R2 only showed 
us the limitation of the existing. So what we do do we evolve to 
chase that area or do we just try to redo again a limited R2  version)

you have your wysiwyg tool you write your documentation you push 
a button to generate the documents and store it then you do a view 
[ doc load %./data/doc.mdp ] and that's all

rich text is the internal specification, all your tool has to do 
is create the rich text block based on your desired looks.  rich 
text isn't meant as an output or an exported format.

R2 doesn't have any rich text you can direct.  which means you have 
to do all of the layout work manually.  as long as we have sizing 
examination of rich text atoms, then we can tell it to position things 
like we want and measure the result in order to properly convert 
the data to other formats.

maxim that's like if i was asking you to do 3D secenes in XML format 
because hey man i have thet vid xml-opengl rendering black box that 
will do the work for you but hey you don't have any control upon 
the rendering engine

the rich text has all of the format and explicit position info... 
if you want to slide text in order to add an image inline... just 
do so.  ;-)

hum but  in general you do your best to select the best 3D file format 
 to go with your custom made 3D engine to get the best rendering 
real time speed and that best quality compromise.

maxim with an imposed close format and an imposed close black box 
called "doc"  what you gain in a hand you lost it on the other hand 
cause you still have to convert your raw data into the specifiq imposed 
markup language and if that markup language have limitations then 
you have find again new tricks to do what wasn't planned to be done... 
 that's not like choosing your own format and then your own rendering 
line. That's why i said in my example we impose to you the use oof 
XML  sheets to represent your 3D data (which is obviously far to 
be the most performant and the most suited to that use) and you are 
stuck to what the black box is able to do no way for you to directly 
have an impact on the rendering line.

I'm thinking that giving too much fun stuff for Carl to do is scary... 
he should go back to extensions...  or maybe not... he might popup 
a full ANSI C parse rule,  in an hour, just to prove its easier than 
before ;-)

I suggest anyone interested, to read example at: http://www.rebol.net/wiki/Parse_Project#Examples
, to see, how it "feels". AND keyword is like an alien from the outer 
space there, and if there would not be comment at the and of the 
line, stating (after fixig a typo): "Back in the same position as 
before the AND.", you would hardly know, what does have AND (most 
often perceived as logical operation) in common to keeping the position 
at original series index? Why not STAY, KEEP, HOLD?

Or do I understand AND meaning incorrectly?

As for EITHER/+, my favorite proposed name for that is now =>. We 
absolutely have to use '| for the second part, since => is *not* 
an infix operation, it just looks like one. Since we can't use 'else, 
'then looks a little silly, as do all alphabetic words when paired 
with a symbol like '|. We need another symbol, and => implies advancement 
without making it seem that the data position is being advanced like 
'next would.

I like => more and more (especially as I suggested it :-), but Henrik 
suggests, it has different meaning in Math. Is that true? I do remember 
that I often use ==> to express "then", so I just shortened it to 
=>

I have a proposal - I think that we all know, that View engine itself 
needs few enhancements, which would be nice to have for the official 
3.0 release. I would like to create wiki page similar to Parse proposal, 
to which we could contribute our requests. What do you think?

BrianH: how do you know => is going to be added? Any new info from 
Carl? Because I noticed his reply stating => is problematic, and 
no indication that ? might be changed to =>

Yes, I understand. That would need to be 3.1.  We do not want to 
delay 3.0.

I figured out how to do PARSE on seekable ports, so that might handle 
a lot of the problems.

OK, to get back focused - so what is NEXT? :-) Do we rework the priority 
plan? Do we need to? Projects-plan needs imo few edits, no?

(I will attempt to do so today -- a busy day.)

Yes, ok. So, do we want to add any other columns to it?

BrianH: we can hear it once and once again - open-source mantra. 
Well, your question is absolutly correct - noone knows the licence, 
yet ppl are complaining. We now have much more important stuff to 
solve. I expect RT keeping to its initial promise = host code = open-source, 
interpreter = closed source. But even with closed source Core, we 
have daily ability to influence its design. Parse project (and not 
only that) is clear example. If the community would not define it, 
it would not happen. Now why do I need Core to be open-sourced too? 
Maybe because of resources. But then - I can imagine 10 incompatible 
versions of R3 flying around ....

Regarding the R3 web console: I'm bowing out as the back end seems 
much more complicated to do than I thought. There are also still 
security issues. I'll gladly hand the source to someone else, if 
they want to continue.

BrianH and I work together well, but the two of us alone are not 
enough!

.... It's about 10  years the rebol ommunity tells you can't do all 
alone and you need to open the source code... this doesn't means 
the final integration word is not yours... This doesn"t mean that 
you will have 100% ready to go additions. This doesn't  mean that 
rebol VM  will be stabilised to less than 1Mo ... More you have embeded 
feature hard written in the VM bigger it is that's why the "extension" 
approache is good.

Then the VM can be seen a minimal execution environement able to 
run any ind of things ... that the way most of the "regular" script 
languages works.

what i have real difficulties to figure out in parse is the index 
system... I have a problem to see where i'm  and what my actions 
is doing.  do i "store index match then action" or do i  "match store 
then action" ? And if you add to that the sub rules i'm like completly 
lost. Cause in some cases sub rules can trigger their own particular 
special only for them actions ...

There's barely a client. Web server support was originally intended 
to be built in, but we'll see whether the work gets done. Openning 
the source doesn't magically provide more people to do the work. 
We need help.

I think the point is being missed. I'm not looking for an error, 
when an empty block is scanned, when the parse expression is being 
built. I would of course want to modify my parse rules as I see fit. 
It is *right during parse time*, that I think there should be some 
kind of indicator that, we've hit a road block:

1. We're not moving
2. We're not processing any rules

3. I'll just do this 50 billion times, until my user gets tired of 
it.

Parsing, moreso than regular programming, is something you need at 
least a basic understanding of to do properly. That means learning 
stuff :(

BrianH R3 is open source but not open access.... hihihihihihi

My point is if you want dianamic particiapation on enhancements in 
rebol3 anyone should be able to access the  whole code as "reader" 
at least. I mean for example i want to bring a sql-protocol like 
enhancement but able to be used in the inner most layer of  rebol 
VM ...  if i can read the source code of the whole WM that allows 
me to get a better understanding on how the layers are made and how 
to do my intgration then I can come with my proposal and "offer it" 
to RT rt keeps the final word on new things integration based on 
community work . RT so remains the controler and the single diffusion 
source of retail R3 VM ...

BrianH: why do we need Device Extensions for DBs? To have it async? 
Because - DBs could be wrapped even now, no?

Do you need R3 GUI for any specific project, or just to play/learn? 
Because other folks might prefer more finished Core, e.g. Multitasking 
...

I am also not sure, GUI will support Unicode from the very beginning, 
altough many expressed it being a priority. There is a difference 
between GUI and VID. Carl worked on VID. Once he is back to it, I 
believe Cyphre is going to be contacted to do some work on View part 
...

After the parse enhancement, I really think the extensions improvements 
(other datatypes and devices/callbacks) should be done first... a 
lot of stuff can then start parallel to what carl works on.  not 
just by me... but many of us can work on improving R3 at the capacity 
level through extensions and have the need and will to do it.

Right, objects present a similar pain.  I know for the most part, 
you don't want to do this.  It's a very specific case - when 'parse 
into encounters a map, instead of returning false, it converts to 
a block and parses.  I don't see this as touching the way map! works 
at all, just parse - for those occasions where it'd be useful over 
an old-style workaround.

Well, the IF operation of PARSE was added exactly for that reason: 
to make alternating between PARSE and DO code easier :)

Shadwolf, all of my contributions to R3 and R2 have been in the open 
source portions, which is already a significant fraction of REBOL. 
This source has been open for a year at least, effectively. In that 
time, having the source open has brought the code contributions of 
a couple people. This is what I mean when I say that opening the 
source isn't some magic trick that will get you help.


In that same time period, the introduction of CureCode, R3 chat and 
DocBase have led to huge amounts of contributed help, more testers 
finding more bugs than we ever would have found without them. Those 
contributions have been extremely valuable. However, none of them 
were related to opening the source.


Now, I am all in favor of opening the source, but I am in favor of 
it for social, business and convenience reasons. I have no illusions 
that it will get more than a few people to contribute though. And 
read-only licenses are the worst of all, because anybody who wants 
to actually do anything with what they might learn from reading the 
code is usually legally prohibited from reading the code, to prevent 
accidental copyright infringement.

[post removed by library team. (sunanda)]

how do you want people to be more implicated in rebol VM  enhancement 
if  they can't learn from what already exists in it ... and once 
again i'm sorry but it's a mater of fact compared to public accessible 
open source VM  REbol is clandestine...  and what is the purpose 
to do a revolution that is kept in a bottle ...

The trouble is, that you constantly repeat your point of view on 
all possible places, whereas we have more important things to do 
right now. REBOL should be open-sourced long time ago, or we should 
wait a bit for open-sourcing it in future. And open-sourcing host 
code is good for starters. Yes, we are slow, but we are getting there. 
Carl needs to finish Parse, then he is back to Extensions, which 
apparently are going to be used for Host code isolation. Once that 
is done, the code can be released.

Gabriele - if you find yourself in a tunnel (which is our situation), 
you first have to escape it ... which is what we try to do ...

ofcourse it is a priority to polish parse ... but the thing is only 
car can try new feature...  having opensource accessible to all mean 
alot of tries can be done and shown and that's better than the 1 
to  X  relation we have. Mainly and i'm not the only one to say it 
we propose alot of things but since we can't show them they are. 
what do i want is a rebol that evolve faster ... it's been 2 years 
since rebol 3  enhancement started we lost alot of time in futil 
consideration like how do we name that and how about changing the 
name of this ... and we skipped during a loooooooooong time the main 
topic ....

Shadwolf - we do wish, and we do hope for those ppl to return. We 
also hope to attract many new ppl.

or maybe that's so easy to do that doesn"t interrest anyone to do 
them ...

A two-pronged attack killed REBOL. First, the fact that the end user 
had to single-handedly install an interpreter and do a good amount 
of legwork to get it and the application in sync ensured that the 
language wasn't going to be adopted by the masses" - the person clearly 
does not know, what he is ranting about ...

henrik or the 3rd thing ... that's don't have a beggining of a clue 
on what and how to do protocols....

just read the output from left to right. it shows that PARSE called 
MAKE-TEXT-STYLE, that FONTIZE called PARSE, that DO called FONTIZE, 
etc.


R2 would only point to the source location of MAKE-TEXT-STYLE, and 
then you would just have to hope that the place was unique enough 
to find it with a text editor's search function. That would be hard 
if MAKE-TEXT-STYLE existed in 20 different places in the code, and 
so you would have to proceed with several minutes of probing. No 
need for that anymore.

Here, I can immediately tell the path to the problem.

ok, I'm under the impression that closures are supposed to do the 
opposite thing.

What a closure seems to do (sort of):
func [][
	compose context [
	 (copy/deep body)
	]
]


It's not a correct simulation of R2 functions, which should be something 
like:

context [
	func spec body
]


You see, the context created should be outside, so that it would 
be build only one time and not each time the function is called.

Actually, it's what i do to create local persistant variable in a 
function. I wrap the function in a context and declare the persistant 
variable in the object instead.

More i think about that, more i think the closure! type is useles, 
at least less than the above case.

Geomol, closures need to do a bind/copy at each call. maybe that 
should not copy strings, though, however, this way it is more consistent 
i guess.