World: r3wp

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.

i think that carl need it for DevBase

until we have a odbc plugin. we need a good diskbased datastore in 
R3

If you look inside devbase you can see kind of DB there, but finally 
it should be a Module with methods, or Protocol with functions both 
simple and for general use IMHO.

It is not problem of ODBC you can have it today in Rebol 2, even 
better use SQLite or MySQL layer you have at hand, but SQL is not 
the only solution

a good demo In My Humble Opinion, will be a CRUD example application 
full R3

that take avantage of all greats features of R3

You can see frm discussion in this thread R3 need to be fixed first

From CRUD you have CRU nowadays

I've just been reading a little about something called Unobtrusive 
Javascript which aims to separate the behavior from the structure 
of html document.  


Doesn't VID suffer with the same problems where behavior is closely 
tied to the structure of the GUI?  And shouldn't we be looking at 
also solving this problem?

So  for instance from the wiki we have this

files: read %*.r

view/across [
    text-list files do [set-face ca read-string pick files value]
    ca: code-area
]

when maybe somet hing this is preferable

actions: [
	tl:.on-click [  [set-face ca read-string pick files value] ]
]

view/across [
    tl: text-list files 
    ca: code-area
]

ignore the double [[ ]]

Couldn't you do something like this, using compose?

actions: [

 my-text-list [set-face my-code-area read-string pick files value]
]

view compose/only [
	my-text-list: text-list files do (actions/my-text-list)
	my-code-area: code-area
]

And the same for every other possible event?

Sure ... but just looking at cleaner ways of doing this separation 
... getting rid of the 'do

It should be pretty easy to write a function that maps an ACTIONS 
block such as the following into a window:

	actions: [
		my-text-list [
			do [set-face ... ]
			"other-event" [ blah blah..]
		]
	]

where "other-event" could be on-click etc..

then the window doesn't have to specify any actions.

But I know what you're saying. You probably want such a function 
built in and used in the examples, so it becomes commonplace.

Yes

Maybe there could be a stylize type of way to deal with actions

Function name and arguments?
set-actions: func [window actions ...

anonymous windows?

I think it should be defined inside the window definition

set-actions view window-spec actions-block

(Assuming VIEW returns the newly created window object.)

modal windows??

(which it does.)

don't return until closed

AFAIK