World: r3wp

It seems like speed is more important than memory in this function.

Henrik, if you can write up a CureCode wish for this function I can 
mark it as pending.

For GATHER? Should I just copy your code and credit it to myself? 
:-)

yes, we all do that :)

Write up a descriptive request, explaining why you need it, or reference 
your R3 chat message number.

Sounds bureaucratic, but OK :-)

CureCode is documentation of the new functions. We need the bureaucracy 
for the users' sake.

If we don't have a record of why the function was added we won't 
know where to puut it when we modularize R3.

Posted.

Henrik, don't forget to add: "Approved by the politburo"

:-)

And 10 lines for signatures.

That's my job (read the ticket comments :)

Curecode needs a trigger for rebdev links.

It will get one, but for now I say something like "R3 chat 1436".

That is the /into option message, so I remember it :)

Here's the R2 version of GATHER:

gather: func [

 "Get the values of a given field from all objects in a block that 
 have it."
	block [block!] "A block which may contain objects"
	word [word!] "The field to look for"

 /into "Insert into a buffer instead (returns position after insert)"
	output [series!] "The buffer series (modified)"
][
	unless output [output: make block length? block]
	foreach item block [all [
		object? get/any 'item
		in item word
		output: insert/only output get/any in item word
	]]
	either into [output] [head output]
]

Do you want a /deep option?

That will require switching to PARSE for speed.

I don't think it's worth it.

for me it makes the most sense to gather values from a particular 
level.

We can always add another CureCode wish for /deep if we need it. 
The current function is fast, so that's nice.

I marked the ticket as pending, with the particular submitted files 
that contain it.

I think there is merit for a cookbook recipe which briefly describes 
a table of all block manipulation functions, or we have a way in 
HELP to relate these functions, so they become very visible to beginners. 
The problem is that beginners are not likely to be looking for them, 
because they don't expect them to be there. They were created by 
experienced users who have been coding REBOL for years.

Breaking them up into modules will make it easier to understand - 
digestible chunks.

will there be something like mezz fold/reduce function for r3? I 
would use it a lot

Fold is called ACCUMULATE - only functional languages call it fold.

ACCUMULATE is basically fold-left.

Would you need a /reverse option? ACCUMULATE is already almost as 
fast as we can make it in REBOL, and more options would slow it down. 
The only way we could speed it up more now is to fix an APPLY bug 
with op! functions.

Filter is called REMOVE-EACH in REBOL.

I apologize, ACCUMULATE is whichever version of fold that starts 
at the beginning and ends at the end of series (left? right?).

thanks Brian :) great ! I don't have any use cases where I would 
want accumulate/reverse so far

This group needs more abstraction.  The group is turned into mainly 
an R3 mezzanine group.  Should we have a different group for that? 
 Originally, I thought this would be about how R3  is developing 
  more along the native level.

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?

... untill there is GUI to DevBase, many ppl will prefer Altme channel 
for quite some time ...

I think it is a good idea Pekr.

I prefer to have such discussions in R3 chat. Having them here means 
more work for me, since most of the rest of the crew that knows the 
internals doesn't come here, so it ends up being up to me to answer.

the rest of the crew
.. do you mean Carl or someone elseas well? :)

Mostly Carl, though Gabriele and Cypher also work on the C-level 
stuff. I mostly know about the C stuff because I get involved with 
the discussions and remember them. Also many of the C-level changes 
to the core functions (not graphics or ports) were based on discussions 
I started.

If the data from users R3's command are correct, Gabriele last logged 
in 31 days and Cyphre 7 days ago. Both were here today.. so it was 
not good example:)

Yes, but they haven't been involved with the discussions that resulted 
in the core changes and new functions of the last year.

I was speaking on Gabriele's behalf dring that time because he was 
busy. Now he doesn't answer these questions here.

Unofficially, of course. He's still busy.

I was just wondering, it there is someone else "who know the internals"... 
I know that Cyphre is waiting for new sources from Carl to do something. 
And of course it's good to have a place where one can write message 
to Carl and with a feeling, that Carl will read it one day.

Right now Carl is busy getting things in place to get the source 
out. Then we can discuss native changes that *don't* affect core 
code. We have already been discussing native changes that *do* affect 
core code, here and in R3 chat, a lot lately :)

comment on #632.

Maybe it os not the right place to ask this request, but I would 
like to know if I can get access to the sources for MediaWiki.  If 
it is yes, the next question is How can I get access.  Thx.

hi, i would like to know if carl have a rebol3-db for us within R3 
 like the very good rebDB http://www.dobeash.com/rebdb.html?

Many of us is waiting for diskbased datastore proposed RIF, on this 
you can build any DB schema of your need, other solutions are walking 
this way VBS or Tretbase, but neither finished or general, Cals will 
have final step.

Rebdb is not diskbased, rather memorybased with possibility to read/save 
to disk, no paging etc, otherwise very good.