AltME groups: search

Maarten: yes, but they are two show-stoppers for that, firstly you 
need to be based in USA, secondly you need to get a big enough user 
base.

My virtual XP machine is running I think Belgian localistation (turned 
off, but the base system is localised). W7 host is Czech localisation. 
I should try this with original US version.

It might also be caused by real conflicts from DLLs loaded by REBOL...only 
WinDbg could tell us by looking at the base address of all loaded 
DLLs.

Well who is issuing them, with what authority and what fundamental 
value? I cannot see this, whereas the state has the authority of 
the land where we live and foods are produced to base money value. 
(Second life 'money' was a hype.)  But that is a discussion for outside 
this Red message group.

I will push the current Red compiler & runtime code base tomorrow, 
still some more code cleaning to do. It will contain the Red boot 
script with all base definitions (currently actions, ops, a few natives 
and a few char! values) and a compiler front-end (similar to %rsc.r).


Don't expect too much, only MAKE has been fully implemented and FORM 
on integer! values only. PRINT is the only native currently.


This is not the first Red alpha, but it's a working base we can implement 
the alpha on (basically implementing actions and natives).

Pekr: I had fun too working on low-level with Red/System, but it 
takes a lot of energy while working at Red level is a lot more relaxing. 
;-)


But this is short holidays, once Red gets mature enough (I bet on 
a couple of months), we'll start working on Red/System v2 (rewritten 
in Red, with a new compiler & linker architecture). This will give 
up the opportunity to reboot Red/System, fix a few design decisions 
if required, extend it, and get a clean and lean new code base in 
Red. I plan to write some architectural specs about the target compiler 
before starting, so all contributors will be able provide me with 
feedback before we implement it. Trust me, you _will_ like the final 
compiler! ;-)

I've dropped the C library dependency from all bindings that don't 
strictly need it, to minimise the code base. However, the only binding 
I could get to work somewhat inlined in Red is SQLite, because it's 
little more than the imports

They base themselves on Squeak, the traditional Smalltalk educational 
track, with Scratch on top, and Python thrown in to appease the rest 
of the world

Ladislav: I think it is relevant to this topic as findind out if 
the index 0 gap is a real practical issue or not, could help decide 
about the indexing base.

I am still sure that once we have negative numbers, we cannot do 
without zero (to maintain compatibility with the continuity of the 
underlying series). Then, actually, the SKIP behaviour is the only 
one easy to describe and use as the base of the "nomenclature".

I must have missed the proposal of BASIS?, but the fact that it would 
be a function or variable implies that it would be used to detect 
a global setting, like system/options/binary-base. Global settings 
like that have proven to be a universally bad idea in practice. Local 
settings are better.

Sorry, I didn't mean off in the sense of false, I meant short for 
an offset. Any place where you have computed indexes can have a computation 
that turns out to be less than 1, especially if your base position 
is offset.

Error out and add PICKZ, POKEZ while at it. That would at least give 
us a base to work with.

I use computed indexes for computed lookup lists, such as for precomputed 
intermediate results of computations, translation tables, etc. If 
the computation uses signed numbers, you have to do an offset base 
position to get the results from the positions less than 1. Having 
a hole slows down the computation because it has to be handled in 
mezzanine code. PICKZ/POKEZ would actually be better for most of 
these situations because the computations work better with 0-based 
numbers (modulus, for instance). It's pretty common in code that 
actually *needs* to use PICK/POKE on series.

Anyone who does computed indices from offset base positions would 
run into that issue. However, given that this only tends to happen 
in heavy-math code, I wouldn't be surprised if Ladislav and I would 
be caught by it more often than anyone else in the REBOL community, 
even Carl.

You can stay at the beginning of the series if you add the base offset 
to every calculated index reference. Bad idea in REBOL, too slow, 
but maybe Red's optimizer will be smart enough to undo that calculation. 
How many algebraic transformations will the optimizer be able to 
handle?

One occasion where you use computed indexes is when you do C-style 
fake multidimensional array access. As with C, however, the math 
tends to be 0-based because of the modulus, so a 0 hole really hurts 
here. You can do these calculations much more easily if your base 
series position is 2 (or plus 1 * (dimension - 1) for each dimension) 
because the 0's go back one.

Ladislav, we don't need analysis on negative indices being back from 
the tail of the series. The concept only makes sense if you are only 
able to refer to a series from its head, thus negative indexes don't 
really have a meaning if you see the series as linear, so you decide 
to give negative indexes a meaning by looking at the series as a 
loop where the end wraps around to the beginning and vice-versa. 
If you are able to refer to a series frome a base position of somewhere 
other than at its head then you already have a meaning for negative 
indexes, and don't need to make up another.

Completely agreed 0 does not exist, even not for computers. A computer 
with 0 memory does not have memory at address 0 either :)

Counting starting at 0 is nonsense. No matter who and how many times 
it is explained. In human/fysic world we only put letter 1 in envelope 
1, letter 2 in envelope 2 etcetera, there is no letter 0 to put into 
envelope 0. It is only a confusing trick to start at 0. (I know you 
can look at memory like a binary tree) In these days of plenty of 
memory, I say let location 0 unused. Besides for who was REBOL meant 
initially? People. Scientists not computerscientists. Let those struggle 
with C and the likes. 1-base is one of the big plusses REBOL has 
over the majority of other languages. (enough bikeshedding from me 
today)

Default base index in programming languages: 

http://en.wikipedia.org/wiki/Comparison_of_programming_languages_%28array%29#Array%5Fsystem%5Fcross-reference%5Flist


Notable languages with 1-based indexing: FORTRAN, Lua, Mathematica, 
MATLAB, Smalltalk.

Whilst Pascal allows arrays to have a user specified base for array 
indeces, the default is 1 based. It also allows a zero element:

Code
program Arrays;
uses SysUtils;
var
  i : Integer;
  myArray : Array[-1..1] of Integer = (1,2,3); 
begin
  for i := -1 to 1 do

    writeln('Element ' + IntToStr(i) + ' Value ' + IntToStr(myArray[i]));
end.

Result
Element -1 Value 1
Element 0 Value 2
Element 1 Value 3

Kaj: nice! Actually, such kind of function (highly recursive, very 
small body) should perform 5-10 times faster than R3 in the target 
compiler. Functions with bigger bodies shoud be in the 10-15 range. 
Functions with pure math expressions should be in a 20-100 range.


Though, these are very rough early estimates I did on the base of 
a few micro-benchmarks.

Pekr: your proposition is not as bad as it could be at first look. 
;-) 


REBOL allows to prefix binary values with a base integer, with base 
16 as default::

    #{F0}
    16#{F0}
    2#{1111111100000000}
    64#{8A==}


We could use a similar convention, but as a suffix, for specifying 
the base for an integer! value:

    123
     7B# 	(default base would be 16 too)
     7B#16
     01111011#2
     173#8


Such literal forms with base explicitly specified would be converted 
to integer! decimal form at LOADing stage. This is just me thinking 
loud, but how does that look like to you?

Specify literal integer values in base: 2, 8 or 16.

I like having the numbers in binary! values, but not as much for 
this. My brain says "this is a binary in base 16 notation", but for 
hex or binary literals, I want to think of the words 'hex and 'binary, 
rather than "this is a base-16 number, which means it's in hex format". 
I think I looked for alternate notations a long time ago. Have to 
see if I can find my notes.

Hex: your proposition is acceptable, but it makes hex literals writing 
still a bit more verbose than needed. We should be able to come up 
with a better solution that leads to just one additional character 
in order to write and identify hex literals (hence my # suffix proposition, 
with a base-16 default value).

Actually, I still haven't found time to read the whole R3 sources 
base. I was too busy this week designing some new parts of Red.

Yes, go Doc! I wish I was better at low-level programming so I could 
help a little. If there would be any examples of simple bindings 
or base of TCP that we could extend to different protocols I would 
try to participate a little.

Kaj: I have a problem with #381. I have reconstructed a similar directory 
structure relative to Red/System root folder (on Linux). My issue 
is that #include directives specified from Red or specified from 
embedded Red/System should have the same base folder from the user 
perspective, but that's not the case currently. So, my question is: 
do you see any drawback in fixing this inconsistency? (Also from 
the implementation perspective, it is a nightmare to handle otherwise)

https://github.com/dockimbel/Red/issues/381

Think of it in the context of Red being encapped and used a single 
binary, having a reference to a Red/System base folder would make 
no sense.

Well, it's not the largest code base. Most active, I don't know

Features like that need to be provided, not created by the user base. 
 There's no motivation for anyone to get involved if the feature 
set isn't complete.

Dialects implementations do not need PARSE, they can be implemented 
with base functions, as shown by Kaj with its VID-like dialect for 
GTK+.

François says that the Red/System binding has been tested successfully 
with OpenCV 2.0. Base OpenCV features are 98% complete, now François 
is working on wrapping image processing functions.

I see there are specialised platform specific print functions only 
for printing the internal format. They look like a base for the general 
purpose conversions, though

I've written a quick function that will take a Red char (UCS4) and 
output the equivalent UTF-8 as bytes stored in a struct!.


It can be used for the base of converting a Red sting to UTF-8. What 
is needed is to extract Red Char! s from the Red String, call the 
function and then appedn the UTF-8 to a c-string!

What I meant when you asked for I/O are the red, red-core and red-base 
interpreter binaries. They're in the Red-test repository, the first 
I gave you

That base should be enough for a start, the hard part now is to generate 
the resources tree with all the right entries ...far from easy.

So far adding the rswr section modifies these values:   [ entry-point-addr 
code-base data-base ] which should be same as without rsrc in my 
tests, and not increasing init-data-size.

Ok.. moving [ build-rsrc job ] after [ build-import job ] leads to 
expected result with the  [entry-point-addr code-base data-base] 
values

So Red/System is like a base for Red?

Like C is the base for World, yes

Yeah, I was just thinking, if it makes sense at all to include a 
language like Verilog in the way, Red/System is made today. I haven't 
looked deeper into it. Maybe it makes more sense to create a cross-compiler 
from Red/System to Verilog and such, totally independent of the code 
backend found in Red/System?


Maybe Red/System could be the base for all different kind of hardware.

Actually, your work on porting that algorithm has many values, like 
showing us the trade-offs of 1-base vs 0-base indexing at Red/System 
level.

About odd, this solution managed to get all odd number from the even 
ones. Your solution is way more elegant, better fitting the language.

Base-1 Base-0, my personal view on this, it is the programmers choice 
on the level of the source code. What happens beneath the surface 
is compiler/linker sh*t. As a programmer and a human being I start 
to count at 1. 0 is not the new number 1 nor is 1 the new number 
2 etc. It is only an addressing issue, compare to the post. Houses 
in the street are numbered from 1 up to N. The first address a computer 
has in an array is the all 0 address, which is the first "pidgeon-hole" 
to be used. The computer doesn't know 0 as we understand it. Well 
you know all about it.

CPU are optimized for 0-based accesses. Using 1-base indexing will 
make Red/System a bit slower than it needs to be.

OTOH, you can always use pointer arithmetics to get a 0-base indexing 
model.

(As fast as yesterday) The base-1 versus base-0 would be accountable 
for a minute delay (less than 1% of the addressed numbers in the 
array, the 0-th and the last). The use of variables in the register 
looks more likely imho. Good point for the wishlist.

this would be an nice way for users to try red and progressively 
replace their binary code base, one source file at a time... instead 
of a whole project at once.

I think you have a complicated mental representation of what pointers 
and arrays are in C and Red/System. It's simpler and more straightforward 
than your descriptions. Basically, Red/System pointers act the same 
way as C ones (including "array" support). The only difference is 
the base for indexed accesses (1 vs 0).

One bug need to mention:

After doing mod operation, I use the result as index to access the 
array,it's OK in C, but will cause strange behavior in Red/System. 
Because mod will produce 0 and Red/System use 1-base array.
n: c + state-half-size % state-size
Then I modified the code as below to solve this issue:
n: c - 1 + state-half-size % state-size + 1

BTW, Arnold's and XieQ's work, and my own recent struggling with 
1-based Red/System low-level issues are hints that I need to reconsider 
1-base vs 0-base indexing in Red/System. Low-level algorithms are 
not 1-base friendly.

this will create an eternal pressure from technical people to make 
Red 0 based

 In fact, I've decided since a while to add PICKZ and POKEZ to Red 
 so 0-base algorithms would be more natural to implement. I need to 
 add an entry in Trello about that or I will keep forgetting about 
 it...

Now in Red/System, we can't pass a function as parameter to Red/System 
FUNC,
but we can pass it to external C FUNC, right?


cmp-func!: alias function! [left [byte-ptr!] rihgt [byte-ptr!] return: 
[integer!]] 
quick-sort: func [
	base	 [byte-ptr!]
	n		 [integer!]
	size	 [integer!]
	cmp-func [cmp-func!]	
][
	; can't use cmp-func in this function
]

I'm also adapting my other Red bindings to use this common base, 
which was previously included in the C library binding

To support the OpenCV binding, I've split the C library binding for 
Red into an ANSI standard base and a BSD extensions part:

http://red.esperconsultancy.nl/Red-C-library/dir?ci=tip


Instead of %C-library/C-library.red and %C-library/C-library.reds 
you should now #include %C-library/ANSI.red and %C-library/ANSI.reds.


%C-library/BSD.reds includes %C-library/ANSI.reds automatically and 
provides new functions NaN?, finite?, infinite? and infinity-sign-of. 
It can only be used on platforms that have them.

Because the Red compiler doesn't support preprocessor conditionals, 
I have split console-pro into red, red-core and red-base, to be able 
to supply different functionality per platform:


http://red.esperconsultancy.nl/Red-common/dir?ci=tip&name=examples

They each include different extra bindings:
red-base: ANSI C library, cURL
red-core: red-base + SQLite
red: red-core + GTK+


I've updated the test binaries. Different versions of the red console 
are supplied for different platforms:

http://red.esperconsultancy.nl/Red-test/dir?ci=tip


I rewrote the multi-line parsing in the console to be more accurate 
and straightforward.

I dropped the cURL dependency from my red-base distribution. This 
means that it now only depends on a few libraries that can be expected 
to be included in all platforms. This version of the Red interpreter 
can now be used on Windows as a single executable, without any extra 
libraries. The Windows version red-base.exe is here:

http://red.esperconsultancy.nl/Red-test/dir?ci=tip&name=MSDOS/Red


It has versions of READ and WRITE for local file I/O, but no network 
I/O. It also has the other functionality from the C library, such 
as INPUT, ASK, GET-ENV, CALL, NOW and RANDOM, but for more functionality 
you still have to use red-core and red, and download the extra libraries 
for Windows.

I'm happy to announce that we reached a major milestone and can release 
a bunch of new things. All the different versions have been merged 
into one code base which makes things easier for us. This was possible 
because the new 'retargetable' graphics subsystem was finished. This 
allows us to port R3 to other platforms much easier. Next target 
Linux. The release in detail:


R3-GUI: Quite a lot of fixes and enhancements. Thanks for all the 
feedback. The main milestone we achieved was to switch to a resolution 
independent sizing system. This will scale your app widgets to look 
the same on different display densities. It's a must have for mobile 
apps. Next for R3-GUI is to create a simple mobile style set. Fruther, 
we are going to push the source code to GitHub. We need to setup 
a bridge to our internal SVN repository, so expect some back and 
forth on Github before we are stable.	Anway feel free to help making 
R3-GUI better and better.


Android: This release is now mostly the same as the windows release. 
So, yes, it's now possible to do R3-GUI apps on Android. I'm going 
to try to run Treemapper on it. Type DEMO to see the new R3-GUI version 
and widget scaling feature. Post as much screenshots / pictures of 
your phone as you can :-)


R3/Saphir: New version for windows with bug-fixes are released as 
well. Please see the change-log on our web-site for details.


Thanks to all the team for the great work! I really think we are 
close to have a very good and stable base with R3 and R3-GUI. Looking 
forward to see more and more people joining and becoming part of 
it.

Links:
http://development.saphirion.com			(Change Logs, Downloads, etc.)
http://development.saphirion.com/experimental	(Android)
https://github.com/organizations/saphirion		(Documentations)

This is the benefit of speaking another language than English that 
is the base for so many computerlanguages. You can say things like 
rij: array [100] where array: array [100] would be a sure syntax 
error, and rij means array in Dutch off course. If you are in need 
of additional translations, just say so. Next I will build a multi-lang 
support lbl-something/text: lbl-something-tekst and a preferences 
panel with file (mirror.ini or mirror-pref.ini) for language (En 
De Nl Fr Es Pt additional wishes?), mirror line-width normal(1)/bold(3 
wide) for placed or both kinds and/or the grid, color of added mirrors, 
color for ok color for not ok.

and I base that on what Carl said in the past.

Yes, but it seems to make sense to base body text on this and build 
the rest around it. MDP has a particular way to format body text, 
but we've found that it's hard to extend. I would like an MDP2 that 
much better is capable of outputting right down from a single paragraph 
of markdown to a full multi-page document.

http://en.wikipedia.org/wiki/Telephone_numbers_in_New_Zealand

learnt something new .. 02 is for Scott Base in Antarctica ;)

yeah... though he won't be in Scott Base but the USA base there

Still probably a local call from Scott Base though. ;-)

date-to-epoch: func [
    "Returns a unix time (epoch) format from a date."
    date [date!]
][
    ; If no time is given, negate our zone to give us 0:00 UTC
    if none? date/time [date/time: negate now/zone]
    ; This uses the epoch base in UTC, so we assume that either
    ; the date is also in UTC, or has a zone offset included.
    ; DIFFERENCE fails for huge time differences, so we subtract
    ; them instead, giving us a difference in days, and multiply
    ; by the number of seconds in a day.

    either attempt [positive? res: to integer! difference date 1-Jan-1970/0:0:0] 
        [res]
        [date - 1-Jan-1970/0:0:0 * 86400.0]
]

And now for something completely different. I have a php based form 
I want to make into a REBOL cgi program. It is to upload some fields 
into an article-base in my mysql database. Where action is article.php 
in the php version I changed this to article.r for the REBOL version. 
I have now the article form shown and when I fill in some fields 
(but not all) and send the form I get the cgi object ( I use safe-cgi-data-read) 
but the contents of the formfields is now empty? Any clues what may 
be the case please?

(Pardon the level-up in the lesson.)

That's not necessarily the case for R3, it's just the case *now*. 
COPY and PICK are just actions, which could easily be defined for 
the issue! type. You could get most of the R2-like behavior for issues 
in R3 by emulating the way tuples pretend to be series when they're 
really not.


The type classes in Rebol aren't like base classes in OOP languages, 
they are more like behavioral conventions, and those conventions 
are more like Go interfaces than anything OOP. Something is series-like 
to the extent that it behaves like a series is supposed to behave. 
But the acrions that are defined for series types are in some cases 
also defined for other types as well, and the corresponding behavior 
for those types can be similar enough to that of series to allow 
both series and, say, tuples, to be operated on by the same code. 
All that matters is how it seems to act from the outside, not what 
it really is.

Nick -- Have you looked at using a variable base algorithm? It may 
be fast, and it should be amenable to windowing:
   http://rosettacode.org/wiki/Permutations/Rank_of_a_permutation
Even if neither, it should be fun to write the script.

(check the OS_Request_Dir() function in src\os\win32\host-lib.c as 
a base for the feature)

Cyphre redoing the View engine is the same as not wanting to use 
the current one anymore, isn't it?

 - Well, I actually use the current one with R3 almost everyday ;-) 
  And to make things clear I won't be redoing it...my plan is to update 
 it to 'next generation'  also add more features and improve some 
 parts of the current base etc.

Kaj, yes, but the changes I plan will allow you to relatively easily 
use different renderer component. Even in current host-kit I would 
just replace the agg renderer with something more suitable for slow 
or not sufficiently equipped  ARM cpus but the "framework base" of 
the sytem would remain same.

so the user base is significant?

It seems to me that under Red, one marvelous tool which could be 
created would be similar this new one - which I just discovered ... 
at least with my not too long vision  - based on the Cheyenne HTTP 
server, it seems it could be realized using a similar approach, to 
begin with ... http://www.wakanda.org/overview- Also available 
on Github for those interested to look at the code (may be Topaz 
friends - sinc it is base entirely on Javascript).

Does anyone know if it would be possible to have Rebol included in 
Ubuntu now that it's open? I don't mean just to make a package available, 
but to have it be installed in the base system.

AdrianS: R3 can now certainly get into the package repository. I 
think that having it included in the base install is unlikely, but 
it will only be an `apt-get install rebol3` away.

AdrianS: I think scripting languages are only part of the base installation 
if they are needed by some other part of the base installation.

But I'm not sure Ubuntu has a published or defined policy for what's 
included by default in  the base or desktop installations. I think 
it's a decision made by a board.

Me too, Graham.


Why would we *not* want to put them in %base-constants.r, or a new 
%base-charsets.r? Colors are in %mezz-colors.r, and I would certainly 
vote to remove a number of those. Pretty sure I've never used 'papaya. 
:-)

There's this - https://github.com/rebol/r3/blob/master/src/mezz/base-funcs.r

It's actually pretty easy to see how they managed it. It was:

- A multi-language IDE (not a programming language, people already 
get those for free)
- With a GUI with an emphasis on modern graphic design (pretty!)
- With a fancy demo (more pretty!)

- With an initial focus on programming languages and development 
platforms that are already popular (built-in customer base)


Powerful IDEs are some of the only development tools that people 
are still willing to pay money for (i.e. Visual Studio). Most people 
can't choose what language they write in, but they more often can 
choose their IDE. And for crappy-but-IDE-friendly languages, an IDE 
can make all the difference in your productivity. They're not as 
helpful for really powerful extensible languages like Rebol or Perl, 
unless the language is so bad that just about anything would help 
(Perl). Plus, since an IDE is an end-user app you can afford to GPL 
it, since the only stuff built on it are add-ons - that doesn't work 
for programming languages unless they have a clear distinction between 
user code and built-in code that is distinct enough to not violate 
the GPL distinctions, because most of the competition is permissive 
- and without the GPL restrictions there is nothing to sell, so there 
is no business model to get a return on investment.


It's nice to point to other open source projects and say "See! We 
could have done that!" but unless those are comparable projects their 
success isn't comparable either.

Moving from the 'random topic back to prot-send.r, I found a somewhat 
serious bug with attachments and base-64 encoding.  I sent the exact 
same attachment using webmail and R3.


at position 32677 in the email sent by webmail (the headers are slighly 
different sizes and the base-64 line breaks are different between 
the two clients) we have the following data:


eMHgCm4jUznXtDnpVKaErkAc107QbjVC6siyHYBu96hxLUjnXDKeWqPOTzVmWxuUY7kJ+lRGF16x

tn6VmO4ncYpZX34HYU0qw7EU3afSgdyUKCvy1s6DpEN3doL93jtyD9089Caq6bZO0g3Llj0Wu8t9

OhsNDu7uUK9wYiq/7OeOK1p03Mwq1eXRbnnUVuZJcKCecD3rctbVbYjdy5/Si1ks7WTLyAerYzUH


at position 32521 in the email sent by R3, we have the following 
data:


vaHNtZYHTmoHtcDpXRSQDk1UeMHgCm4jUznXtDnpVKaErkAc107QbjVC6siyHYBu96hxLUjn
XDKeWq

doL93jtyD9089Caq6bZO0g3Llj0Wu8t9OhsNDu7uUK9wYiq/7OeOK1p03Mwq1eXRbnnUVuZJ


I copied the three lines of data around where the problem occurs. 
 On the short line in the R3 data, the following sequence is missing:


POTzVmWxuUY7kJ+lRGF16xtn6VmO4ncYpZX34HYU0qw7EU3afSgdyUKCvy1s6DpEN3


You can imagine the kind of trouble that causes with binary data. 
;-)

I prefer

split-path %foo
== [%./ %foo]


The reason is because I believe split-path shouldn't require an extra 
check if all you want to do is read the base directory that a file 
is in.  I think this is a common use of split-path.

For us docs stay on github. From there we integrate back into our 
mainline and make official releases. And from our mainline the docs 
on our web-site are generated.

Everyone is free to use the github as base for a wiki.

Continuing from #Red group. A johnk asked for multi-line source from 
Carl. This is my W_GETS code in World, which has multi-line (blocks 
and long strings). I don't know, if you can use it, as World might 
be different internal:

char prompt_str[]	= "prin system/console/prompt";
char block_str[]	= "prin system/console/block";
char string_str[]	= "prin system/console/string";

#define W_GETS \
	if (W->line_read) { \
		free (W->line_read); \
		W->line_read = NULL; \
	} \
	if (W->top_of_series > W->series_base) { \
		W->stack = W->stack + 1; \
		int trace = W->trace; \
		W->trace = 0; \
		if (*W->top_of_series == BLOCK_BEGIN_T) { \
			tv.newline = 1; \
			do_string (W, block_str); \
			int i; \
			for (i = 0; i < W->top_of_blocks - W->blocks; i++) \
				w_printf ("    "); \
		} else { \
			do_string (W, string_str); \
			w_printf ("    "); \
		} \
		W->trace = trace; \
		W->stack = W->stack - 1; \
	} else { \
		W->top_of_code = W->code - 1; \
		W->top = -1; \
		if (NULL != W->P) \
			printf ("**** W->P != NULL ****\n"); \
		W->stack = W->stack + 1; \
		int trace = W->trace; \
		W->trace = 0; \
		do_string (W, prompt_str); \
		W->trace = trace; \
		W->stack = W->stack - 1; \
	} \
	W->line_read = w_readline (&auto_brackets, &tab_completion); \
	reset_stack (W); \
	if (W->line_read == NULL) throw_error (W, ERRMEM_S); \
	if (W->line_read[0] == KEY_CTRL_D) throw_error (W, QUIT_S); \
	W->save_line_read = W->line_read;

I think it makes a lot of sense to publish all notes in a structred 
way, so it's easier to work on the R3 code base.

need help compiling the R3 code base.   I must use GCC so can't use 
the microsoft vanilla :-(

...we wouldn't need of 2 standard versions of Rebol (core and view)...

That would be great, I remember that it was very confusing to me 
to have Core, Base, View, Face, Command etc.

Kaj, thx for the info. now I am on the serverside (nix) to compare 
the handling and performance with the current Lua stack I am using.

Would be great if we could work on some extensions later, on the 
base we did before if you like ;-)

There are plenty of possibilities here. 

Either port VID and have to deal with it's flaws and the history 
with it
or go the path of the RebGUI
or redo VID 

I have read somewhere that Carl expected someone to come up with 
something better than VID. 

I like VID yet it has its oddities, like when positioning elements 
using 'at. It could be improved in some of its behaviours, if you 
import it you may be hindered by this aspect, and it may get harder 
than restarting with a restricted base set of widgets.

From the "design architecture" POV we should focus on stabilizing 
the GOB abstraction mechanism and DRAW/TEXT/EFFECT dialects syntaxes. 
If these layers are fine-tuned you have great base that allows us 
make experiments at the low-level graphics and also as well at  the 
high-level GUI abstraction layer.

We made it to compile R3 into a single EXE. Filesize:  855566  can 
be packed with UPX down to 368654   (43.09%) That's the base we use 
for encapping R3 apps into a single EXE.

Bit of both in my view. Money to support full time development. And 
the knowlegde to know how to is also sparse. A little bit extra on 
info and tutorial like stuff could maybe get some more people started. 
Google's summer of code like the HAIKU project is putting to use 
is beyond reach for the small base of devs for instance.

We are on the other hand lucky to have the enthousiastic giants we 
have now. It is enough to let the projects live on, but not in the 
way blooming as we feel should be the case. 

Yet the progress even in the last weeks is a great accomplishment, 
cannot be said enough..

We need more momentum. Meaning a small usable base to start serious 
advocating the pro's with and possibilities of generating a little 
money. Attracting young programmers/students willing to contribute, 
one advantage for students is that not everything is carved in stone 
yet. (Only what we want to achieve and the toolset is chosen)

What I would do if I could afford is, is to re-implement R3 using 
the D language. This should result in a more simple code base (Carl's 
code base is in a very good shape, so don't take me wrong), and using 
this we would close the most fundamental missing parts in R3. There 
are around 5-8 topics that need to be addressed. Andreas and I just 
had a short chat about this this week.

There are several levels of work that can be scaled up. The base 
layer stuff, that's the C & D level.

We have a template based dynamic site here at work,  we use a base 
page to define the common logic, we use CSS "templates" to define 
the areas of different pages... the above code is Template 3 area 
3, which is the body area for a page that has a header, left navigation, 
body, and footer area.

CSS Workflow -- easy: create a concept based on information needs; 
plan how to acheive this with the box model; create a base HTML template 
and build up styles around that, incorporating background images 
as required; then test and revise, test and revise, test and revise, 
etc.  Simplified somewhat.  Basically the same as any legacy HTML 
project, only easier.

I'm not sure, if you can run it from Rebol/Base, you may try it.

is is parse base, each rule consist of a match block!, a transform 
block! and a logic! to continue thru next rule or break