AltME groups: search

My response to a query aboit REBOL3 on REBOLtalk would not make a 
marketing person happy:
-- year old alpha
-- no obvious contact details for those wanting to get involved.
Could someone better connected do a better job, please?

http://www.reboltalk.com/forum/index.php/topic,1827.msg4644.html#msg4644

Some status (not much since Pekr told most of this):


- Improved console presentation (sounds so Windows-like, doesn't 
it? :-)) in the latest R3 alpha. http://rebol.hmkdesign.dk/files/r3/gui/178.png

- Carl wants to do a larger release of R3 "soon". This involves a 
merge of my skin or parts of it. I'm not sure everything you see 
in screenshots can go in, because those parts are not clean enough.
- Still working on RebDev.

- Carl noted that RebDev helped him find many bugs in R3. Some of 
those are fixed.

- GUI has not progressed for a couple of weeks as I'm working on 
a big R2 project. I will get a few days in January to help, but I 
won't get more time until mid-March at best.
- Some Devbase submitted changes and fixes are added to R3.

The intended priority for RebDev front-ends is:

1. R3 Shell (doing this now)
2. HTML mobile (doing this now)
3. R3 GUI
4. HTML pretty
5. R2 Shell
6. RSS feed
7. Whatever people want to do.

Maxim - have you read my proposition to start wiki page to define 
our needs for library component? We should really do so!

also, for lib usage a GC-independant alloc() dealloc() equivalent 
would be VERY usefull.  something we can manually free, in order 
to work with large dataset we really don't want the GC to grab.  
for example, using image magic, I can work with 10GB image files. 
 composing 100 of those images into another.  I can't let rebol's 
GC play around with such specific needs... this is just one example, 
but there are others.


sometimes handling stuff manually is easier than hoping an automatic 
system will do so properly.  in R2, images are never freed, for example, 
so for a task which rebol would be the ultimate image manipulator, 
I can't use it cause the third image I load from disk craps out rebol, 
since it grows beyond 1.5GB of RAM.

yess I did, but in this case, the goal is to do interactive AGG manipulation 
of one image at a time and stamp it on a layered composition.  by 
the time I load the third image (from a digital camera at 7.1 MPixel), 
rebol crashes  :-(

I am not very experienced in how making bindings in various scripting 
languages work but I have fiddled around this a little... python 
by itself doesn't do anything automatic I think - and to my knowledge 
python isn't the best example of easy binding to c libs, but there 
are comunity provided tools that help you generate the interface 
code etc...  most people I saw used SWIG (which works for a lot of 
languages) http://swig.sourceforge.net/.. but the chat was that 
if you use that tool you geet quite a bloated code for interface.

If you want to look for languages that provide very elegant way of 
making bindings you should to my knowledge look at Lua (lua started 
with this) , lua provides simple to understand stack approach. Then 
there is haxe which provides even more elegant way to do this . Both 
languages also enable to embed the VM/interpreter into C++ app. I 
have used both to do both and it was very simple as I am not a power 
low level programmer

Does anyone know if REBOL3 will include REBCODE functionality?  If 
not, then it would be cool if we could DO rebcode from a REBOL3 script 
somehow.  Such as DO %rebcode.bin to give us the functions of REBCODE 
to use in our scripts.

Henrik, do you know if Carl  would be up to building a rebcode based 
2.7.6?

and giving a dead-simple way to ignore or trap it is in line with 
rebol's kiss philosophy IMHO.  


but I do think that for serious *parsing* and dialecting, your proposal 
is much better.

I do agree with brianh and Carl that I refuse to have to deal with 
commas within rebol code.

Do you not see the simplicity of foreign! data?   No speed problems, 
the lexical gets to a point where it would throw and it stashes a 
foreign!, keeps on truckin'.

Here's the current source for LOAD:

load: func [
	{Loads a file, URL, or string.}
	source [file! url! string! any-block! binary!]

 /header  {Includes REBOL header object if present. Preempts /all.}

;	/next    {Load the next value only. Return block with value and 
new position.}

;	/library {Force file to be a dynamic library. (Command version)}
;	/markup  {Convert HTML and XML to a block of tags and strings.}
	/all     {Load all values. Does not evaluate REBOL header.}
	/unbound {Do not bind the block.}
	/local data tmp
][
	; Note: Avoid use of ALL func, because of /all option
	if any-block? :source [return :source]

	data: case [
		string? source [to-binary source]
		binary? source [source]
		; Check for special media load cases: (temporary code)
		find [%.jpg %.jpeg %.jpe] suffix? source [
			return load-jpeg read/binary source
		]

  url? source [read source] ; can this possibly return not binary! 
  ?
		file? source [read source] ; binary! or block of file!
	]

 ; At this point, data is binary!, a block of file!, or something 
 weird.

	if binary? :data [
		unless find [0 8] tmp: utf? data [
			cause-error 'script 'no-decode ajoin ['UTF tmp]
		]

		; Only load script data:
		if any [header not all] [ ; Note: refinement /all
			if tmp: script? data [data: tmp]
		]
	]

	unless block? :data [data: to block! :data] ; reduce overhead

 ; data is a block! here, unless something really weird is going on
	tmp: none
	
	; Is there a REBOL script header:
	if any [header not all] [ ; /header preempts /all
		tmp: unless any [

   ;not any [file? source url? source] ; removed: hdr in string is same
			unset? first data ; because <> doesn't work with unset!
			'rebol <> first data
			not block? second data
		][ ; Process header:
			attempt [construct/with second data system/standard/script]
		]
		; tmp is header object or none here
		case [
			tmp [
				remove data
				either header [change data tmp][remove data]
				tmp: tmp/type = 'module ; tmp true if module
			]
			header [cause-error 'syntax 'no-header data]
		]
	]
	; tmp is true if module, false or none if not

 ; data is a block!, with possible header object in first position

	; Bind to current global context if not a module:
	unless any [
		unbound
		tmp ; not a module
	][
		bind/new data system/contexts/current
	]

 ; data is a block! here, unless something really weird is going on

	; If appropriate and possible, return singular data value:
	unless any [ ; avoid use of ALL
		all
		header ; This fixes a design flaw in R2's LOAD
		;not block? :data ; can this ever happen?
		empty? data ; R2 compatibility
		not tail? next data
	][data: first data]
	; If /all or /header, data is a block here

	:data
]

Ok, I'd gladly accept a separate function, but ship it with REBOL 
for grandma and the professors of the world.  Don't make them hunt 
it down and DO it as a special case.    But to be honest, I'd still 
prefer a foreign! datatype! and advertise REBOL as a human readable 
language.  Much power in that ad imho.

Steeve, do you mean:
>> to-wtf none
== "BRIAN !!!!!"

Adding a lexical foreign! means you add the overhead of checking 
for valid syntax to *all* REBOL code, not just LOAD. It removes your 
ability to trust that what comes out of LOAD is valid. That is a 
huge overhead to all REBOL code, and would be the source of most 
REBOL bugs in the future. It is a horrible thing to do to the community.

Can't you see how cool it would be to let a person   load %textfile.txt 
and do analysis?  With foreign! sitting there ready to trigger if 
evaluated?

I was working. I just fixed LOAD, DO and CLEAN-PATH, and they will 
be incorporated tomorrow. The current build has built-in functions 
to get to DocBase, RebDev and CureCode. We're really close to release.

OK, but what do you gain? I would like to know, what is the usage 
case, other than being cool showing someone tricks directly in console? 
:-) You would have to parse the junk! datatype by string parsing 
later anyway, no?

In your cases, I do:

result: copy []

foreach line read/lines %kinggames.txt [parse-the-line-and-append-to-result-structure]

Well, a refinement and a datatype with semantics of junk, power in 
my opinion, scary REBOL breaking crud to others (others that I do 
respect the opinion of), but I can't see the fear of this datatype!

Maxim - you can do so via added functionality, no? Adding some objects, 
storing them as references to pointed data ...

adding some kind of tags to a data element means you are describing 
IT.  you can do whatever you want with it, that info always stays 
with it.

what about sound ports in R3 ?
have we the same bugs (unable to do streaming in real time) ?

The visual design is still up for change. I may figure out something 
better tomorrow if I get a good idea. It should also be evident from 
the screenshots that it's an iterative process. There are still a 
lot of things left to do to make this UI really "sing".

For a GUI version to do this, one could open N windows in the same 
RebDev script. I would love to see that.

do we have to trace the http to figure out what's going on?

pekr, no, r2 console version is low priority. Carl wants to do R3 
GUI version next.

it appears to me that most of mezzanines who have to do such conversions 
could be 1) shorter and faster 2) with less memory overhead

Maybe this question has more to do with when to use to-block verses 
modifying it.

If I want my data to be the same, I do not apply an operation on 
them.)

to-string does the same oas to-block.  even I have come to depend 
on the copying aspects of it, and I can assume that many others do 
to.

one question I have... does the object type also copy every series 
included like in R2 ?  that, IMHO one of the biggest regressions 
in rebol's history.   reversing the copy is impossible to do perfectly 
(scanning the new object, and attempting to link back the old series). 
plus it slows down rebol in a few ways.

to do the same work he did on parse evolution

How do I submit a request for Carl to include a feature in R3?

The thing is that such facilities may be higher level now, to get 
more performance on the lower level. It's still possible to do, I 
think.

Oh I know it would be possible to do but at a cost in performance 
I would suppose.

but if you want to store binary data, just add binary data, i do 
not any conversion, store your data int he format you want

Yours sounds like what Chris wants to do.

but it would nice to be able to do something like this:

fnc: func[a [string!] /default $10 ][print a]

fnc 
>> $10

It has nothing to do with the implementation language though - it's 
a syntax thing.

Nope, still doesn't work.
>> write %blah to-binary "hello^/rebol [] print 1"
>> do %blah
** syntax error: Script is missing a REBOL header: hello

** Note: use WHY? for more about this error

f: func [n] [if n = 1 [print 1] else [print 0]]
f 2
Re else;
** Script Error: else has no value
vs
** Script Error: else is obsolete. Use the EITHER function


Second one far better for new to REBOL people imho.  The'll only 
do the second case twice in a career, the first may have them scratching 
head for 10 minutes and giving this new REBOL thing the boot.

Do you guys get to get down to the C code at all or is that strictly 
controlled by Carl?

[Virtual blocks] What do you think of an option to allow fixed-size 
records only, so that there is no need to create a file index (faster 
access but data file possibly bigger)

Janko, I can't be completely sure that they will stay that way. This 
has something to do with the Wildman project, which is about getting 
R3 to run standalone on embedded hardware with a minimal OS underneath. 
So whether R3 will then employ its own threading model or always 
use OS threading, I don't know... and Wildman is not something that 
will happen soon.

But the real attribute that we would need to take advantage of is 
registers and we can't do that.

Gabriele, it's your opnion not mine. we shouln't have to use DBMS 
or other external products (having to install them) for rebol applications 
which are standalone and not multi-user.

The file scheme of Rebol can do the job with a simple scheme wrapper 
(to hide complexity).

This has been requested by the community since long time ago. If 
you don't see the interest, good for you but let the other hope.

By the way, as Brian say, RebDev can stay as it is for a moment. 
It's simple Rebol data, so it could be easily transform to whatever 
new storage mechanism is needed when the time will require.

And, I don't think the client need to load the whole msgs db as most 
of the time (99.9%) user just read the lasts msgs. So It can be changed 
to cache last 10000 msgs and will only deal with the full db if user 
ask it to do (ie : search).


And to finnish, 24MB is not much for 100'000 msgs. I would not bother 
until it reach 200MB (It's what FF3 take after half a day of surfing) 
so I have 800'000 msgs left :-)

Yes it's cool, it's something i try to do with Virtual blocks (blocks 
which are synchronised with files). it"s a tiny scheme (script size 
less than 5 kb).
It doesn't allow sorted blocks currently but it could be.

I am also sure DB's will specialise and already do (couchDB, bigtable..), 
and I plan to make few simple specialised storages to for some my 
projects.

It's hard to plan at the alpha stage, especially since R3 is not 
at feature freeze at this moment. I use REBOL full-time here, and 
I won't be using R3 in my own projects for another year or so. It 
would be crazy to start doing that now for me. For new users, it's 
a matter of waiting. There is simply nothing else to do.

Nicolas, you could do what I did: Instead of waiting, help. If you 
passively wait you get back exactly what you put into it. All of 
that eagerness was wasted energy that could have been applied to 
helping get R3 out, or writing documentation, or even discussing 
semantics here. Complaints are a waste of time that could instead 
have been spent volunteering.

It is easier to add the VCS parts of DevBase to RebDev chat and rename 
RebDev to DevBase (the current plan) than it would be to get DevBase 
into a usable state. I know - I am the lead programmer of DevBase.


What we really need to do to is get the project to the point where 
we can release it to the developing public without it turning into 
a disaster and the project dying. We needed a way to enable and organize 
development discussions, completely integrated with DevBase, to help 
people cooperate instead of hinder the project. We have that now.


I agree that the CLI client for RebDev sucks, and that we need a 
GUI client. We don't need it *now* though: RebDev already works better 
than AltME for our purposes, and we can do the GUI after the public 
release. The messages we write now will still be there later, ready 
to be read in the GUI client if you want to wait for that.


We absolutely do *not* want chat in CureCode - comments in CureCode 
are *documentation*, not chat.


Because we went the route we did R3 is nearly ready for release to 
the developing public (as an alpha). If we had done as you suggested 
we would not be so close to release. Keep in mind that what you are 
suggesting we do is what we were doing before, and it failed badly. 
That is why we are doing what we are doing now, which is succeeding.

yes Paul , it's an alpha, help us to add many improvements, documentation 
or tests if you have time to do

No GUI yet, as I'm still busy with something else. I need to do a 
serious code audit before it's included. Many things are still up 
in the air.

The RebDev Web Client seems to be broken :


*** RebDev Error: client is out of date ** Script Error: cause-error-here 
has no value ** Where: error ** Near: cause-error-here


I guess this is to do with the changes being made to the server to 
fix the "unicode" problem.

Nice trick that works in R2 and R3: If you put
    rebol []

before the code you would otherwise paste in the console and include 
that header in the copy, you can
    do clipboard://
to do the code :)

hi,  i am very to play with R3 but  i don't find a way to do a round 
of a amount or decimal with a scale example i would like to 1/3 in 
a interest amount with 8 decimal . how a can do this with R3  ?  
the simplest way or the better way ?  thank of you all

Like Oldes, I have a do-clip func in %user.r, along with a cc func 
to copy, vv to paste, and cdr to "change-dir to-rebol-file". Handy 
stuff.

Ah...I didn't know you could load the gui.  Thanks.  And the button 
action isn't in a block because you're executing the block with 'do. 
 I guess it's not that big of a deal, but it's annoying to me that 
view[button "test" print "test"] is also valid

'do and 'print are valid actions usable in the dialect.

check the content of the guie/actions object to know all the authorized 
actions.
>> first guie/actions

== [self do browse run launch view alert close halt quit set of attach 
submit reset clear focus scroll print dump moved signal]

you need to 
   load-gui
first.
Then, don't use layout, that' sso R2. Just:
  view [button "press" do [print "pressed"]]

Anyone able to send messages to rebdev? They do not appear in my 
chat and I have duplicates of headings and messages in some places.

kib2, if there were a way to give positive feedback about things 
you really like in R3, would you do it?

Thas is what I think too. When I do compare functions of RebDev - 
there is already plenty of commands. IOS was one lever more abstracted. 
Upon IOS you could build something like RebDev, DevBase, Chat, Filesharing 
etc. We will see, I posted question to Carl :-)

Pekr, I want to do a code audit, but I'm thinking now whether I should 
do that in the open to speed things up a little. I'm not sure.

We need help. There is only so much Carl and Henrik can do, and I 
am busy with work right now so I can do even less. I have seen people 
putting in bug tickets for changes to the wiki - when they could 
easily make these changes themselves. It's frustrating.

in R2, we have to do the "#"/" = last file" check

Kaj, I understand it's very frustrating only to be able to do limited 
testing. Being on OSX, I have to waste a lot of resources running 
WinXP in VMWare to test R3. I think it's a good idea to keep some 
talks going with the Wine people to make sure and verify that it's 
a Wine bug rather than an R3 bug. This is in order to keep Wine out 
of Carl's hair, so to speak, so he can continue development of R3 
as rapidly as possible. I deeply respect the daunting task it is 
to emulate the Windows API and I would not like to be in their shoes.

It is easy to report bugs in CureCode, and they get reviewed, tested, 
discussed and eventually fixed. It is much easier to report bugs 
in CureCode than it is to do so here. Please don't complain about 
the need to report bugs - that is what alpha means.

Graham, if you want to form file paths without checking whether the 
directory portion has a trailing #"/" do this:
    blah: %dir
    f: blah/(file)
instead of
    f: join blah file

what would fileize do that to-file does not?

I start to lose control where to post what. How do I:

- diplay latest # of messages content? We have L #, but not LM #
-  how do I display particular message, and all its replies?

Chat system feels good. But if we do add concepts like reply to particular 
message, and system is no more flat, we are not able to easily handle 
it without GUI anymore. Some commands are changed in quick pace, 
some changes don't make sense to me.

Pekr: "why do we need special exists functions"


Those functions tell us whether the file exists *and* is of the ttype 
we need it to be. Files and directories are used differently. You 
use those functions to make sure that things are what you need them 
to be, so your code will be safer (or at least not crash).


Pekr: "Gee, I hate all those read-* - they are proof there is something 
wrong"


You are correct, that is exactly why the READ-* functions are there. 
They are temporary, until we get the Unicode conversions model finalized. 
Good catch.

The particular binding order effect that matters in REBOL is that 
"outer" and "inner" scopes are faked with the binding order. Any 
attempts to revise the "inherited" contexts that the code is supposed 
to have, after the code has started running, is unpredictable at 
best and crashworthy at worst - a bad idea in any case. This means 
that if you want to import words from other modules into your code, 
you should do it *before* your code starts running. This means import 
headers, not import funcctions.

Why do we need an undirize when it is already so simply to do such?

The point to making these mezzanines is to make them *well*. The 
fileize code above is the least you can write that does what the 
function is supposed to do. If this is not the case, improve it. 
We are improving REBOL by writing these functions, as they give us 
insight into how the system can be improved - look at the difference 
between the two EXISTS? functions above for an example of this. Simple 
code that you could inline if you need to is what we want.

Think of these as a standard library of helper functions that you 
don't have to use if you don't need to. If you do use them, you can 
count on them working as correctly as the REBOL experts can make 
them work, and as efficiently. Either way REBOL is better.

Adding an option to a function that changes its behavior makes it 
harder to learn than a seperate function. The only thing you have 
to remember with a new function is the name. You have to do refinement 
processing in your head too, remember :)

probably you have to modify do-request.
save %do-req.r mold do-request
edit in do.req.r the line 
User-Agent: "REBOL"
to whatever you desire, add the rebol [] header and do the file.

Well, in some cases to fix, but yes, lots of exceptions. The guideline 
is that maps and objects don't have position, but series do. So the 
position-dependent functions don't work but their non-position-dependent 
counterparts do. Ports don't work like series either, so there is 
another whole set of differences to remember.

Good point Pavel, how does map! handle the key/key case? (being able 
to exchange the role of key<=>value). Would it require to use two 
map! to being able to do fast lookups in both cases? So n-tuple stored 
=> n map! value to hash everything?

no to Kaj, no to Paul :-)

To kaj: Brian is talking about lists, not blocks. Your test do not 
append or insert data in the input blocks, it's not relevant.

To Paul: No, the 2 blocks are created before entering in the dp function, 
dp doesn't create them.

If the block needs to be expanded because there isn't enough allocated 
the system does a block copy. If there *is* enough allocated, as 
when you preallocate using make block!, then the system doesn't have 
to do a block copy. That is R2 and R3.


What is new in R3 is that the "head" pointer of a block doesn't have 
to point to the beginning of  the allocated memory, just like the 
"tail" pointer in R2. This means a remove from the head of the block 
just shifts the pointer over one in R3, while in R2 you had to copy 
over the rest of the block contents to shift it towards the head 
of the allocated memory. Preallocated memory can also exist before 
the head of the block contents in R3. This means that there is no 
difference in overhead between inserts at the head or the tail of 
a block in R3.


In theory, inserts inside the block in the first half could be more 
efficient because you would only have to shift from the nearest end, 
not the tail. I don't know whether this optimization has been implemented.


Block operations in general could be faster because with no list! 
type we wouldn't have to special-case as much code, so we could make 
our code much faster through more aggressive optimization.


Btw, I submitted a tweak to DP to make it more accurate by subtracting 
its own overhead. It still has some variance though - have to tweak 
the native to fix that. Plus there is the extreme variance caused 
by Windows.

There is a proposal (looking likely to be implemented) to have FOREACH 
work on object! and map! types. The word list syntax would be restricted, 
but you could do your traversal that way. In the meanwhile you have 
WORDS-OF to get the keys in a block, VALUES-OF to get the values 
in a block, BODY-OF object! to get both in a block (map! proposed 
too) and TO-BLOCK of map! to get both in a block. It works, but the 
FOREACH proposal would create fewer intermediate blocks.

Yes Pekr, this has nothing to do with zero based indexing. Series 
are still one based:
>> b: [a b c d e]
== [a b c d e]

>> b/1
== a

>> b/0
== none

Petr, I have been proposing that new PICKZ and POKEZ functions be 
added to do a 0-based PICK/POKE, instead of having vector! be 0-based. 
This would give us 0-based referencing abilities for all series, 
not just vectors, then we could make vectors 1-based like the rest. 
There are real advantages to 0-based indexing so it would be good 
to have it, but consistency is better here.


Carl was not proposing to make a change to PICK and POKE in his blog: 
he already (half) made the change. He was asking us in his blog if 
he should change it  *back* to the old, buggy R2 behavior. I think 
he should finish fixing PICK, POKE and AT instead.


Henrik, INDEX? returns a 1-based index from the *head* of the series 
- that's why it's always positive.

Yes. But not for (RE)JOIN because JOIN or REJOIN /into is exactly 
the same as INSERT and INSERT REDUCE. What we *do* need to add /into 
to is (RE)MOLD, (RE)FORM, REDUCE, COMPOSE, READ, COLLECT (needs changes), 
MAP and EXTRACT.

; Here's a version of COLLECT without /into, a typical example of 
a builder.
collect: func [

 "Evaluates a block, storing values via KEEP function, and returns 
 block of collected values."
	body [block!] "Block to evaluate"
	/local output
][
	output: make block! 16
	do func [keep] body func [value /only] [
		apply :append [output :value none none only]
		:value
	]
	output
]

; Here's COLLECT with the /into option.
collect: func [

 "Evaluates a block, storing values via KEEP function, and returns 
 block of collected values."
	body [block!] "Block to evaluate"
	/into "Collect into a given series, rather than a new block"
	output [series!] "The series to output to"
][
	unless output [output: make block! 16]
	do func [keep] body func [value /only] [
		output: apply :insert [output :value none none only]
		:value
	]
	either into [output] [head output]
]


Note that the version with /into also lets you use other series types 
than just block!. This option added to REDUCE and COMPOSE would let 
you create parens and paths as well, even though REDUCE and COMPOSE 
can only take block! specs.

Janko, to reanswer your question: "will R3 have a way to define custom 
infix words?"

Yes, at least custom words to refer to existing infix functions for 
now. In theory this new behavior could be used to make new op! functions, 
but there will likely not be a facility to do so until the plugin 
model is finalized, and the redirect-to-an-action functionality may 
remain even then.

>> help apply
USAGE:
        APPLY func block /only

DESCRIPTION:
        Apply a function to a reduced block of arguments.
        APPLY is a native value.

ARGUMENTS:
        func -- Function to apply (any-function!)

        block -- Block of args, reduced first (unless /only) (block!)

REFINEMENTS:
        /only -- Use arg values as-is, do not reduce the block

huh.... I see rebol has many intereting words that I haven't even 
known about what even thought what they alow me to do .. like these 
that you mention apply and collect

Brian .. some most certanly a crazy question ... is there a way you 
could walk/execute a block of code in steps ... this is probably 
possible (if they take no arguments)  [ func-1 func-2 func-3 ] ... 
but is there some "magic" way to execute make func consume their 
arguments, like this >> b: [ print "hello" add 4 6 ]<< and >>do get-expr 
b 1<< would print "hello" and >>do get-expr b 2<< would calcualate 
10 ... I know this is probably not even remotely possible

I am trying the do/next .. I can execute first expression but then 
I am a little lost of what to *do next* ( hehe)... >> b: copy [ empty? 
"" empty? "a" ]     do/next b == [true [empty " "]] <<  I tried >> 
b: next do/next b <<

>> do/next [1 + 1 2 + 2]
== [2 [2 + 2]]

That last block is an offset reference to the original code block.

would this enable us to do some sort of "green threading" without 
the need to maually yield even?

You have no idea. TYPES-OF was the only reflector that had no corresponding 
hack in R2. I had to do it from scratch.

I agree with Paul. This group served as general R3 info channel for 
those, who were not available to other altme R3 related private worlds. 
Now as we go more into details, I propose to set-up groups as needed: 
R3-mezzanine, R3-plugins, R3-whatever ... what do you think?