World: r3wp

Cool. So set up a discussion for the database semantic/dialect model. 
I think one of those DocBase wiki discussions would work for this, 
with chat in the DB Chat group here.

Just going to copy r2

The R2 model wasn't very good, in my experience, so a refined model 
that can also be adapted to NoSQL databases would help here.

ha!  I'm not an architect!

This is just something to get me up and running on R3 with databases

That's nice then :)

I don't understand why in the actor block, we can do this:

		close: func [
			port [port!]
		] [
			if open? port [
				close port/state/connection
				port/state/connection/awake: none
				port/state: none
			]
			port
		]


In the r2 schemes we had to specify the system word 'close, but in 
r3, we don't ... so what stops the stack overflow here?

apart from the fact that it stops the 'if by closing the port ...

If the remote client closes the port, can one just re-open the port 
to make another connection?

First window opened!  Animates with thousands of alpha colored gob 
blits..
 - Carl on Hostkit work.

good news  :-)

Host-Kit: Just GOBs yet, no DRAW.

Sounds really cool. Getting DRAW to work might be a bit more difficult. 
If I understand it correctly, DRAW dialect is processed by the kernel, 
whereas drawn by the HostKit, hence draw api will have to be created 
in the HostKit layer, which will be called by the kernel?

having a working DRAW img [] in R3 would be nice too - and probably 
easier to do once we get it in hostkit?

There is a new command block evaluator that needs to be used a bit 
differently. Hence the DRAW dialect loop needs to be adjusted. As 
the AGG interface

didn't changed and is brought in as extension, the binding should 
not change significantly (all my guess).

Graham: the seemingly self-recursive "close" call works, because 
of how the actor functions are bound. Compare:

>> foo: func [] [42]
>> bar: compose [foo: (func [] [foo])]
== [foo: make function! [[][foo]]]

>> bar/foo
== 42


The situation with protocol actors is similar. (With the binding/reduction 
stuff is "hidden" in make-scheme.)

BTW, as I was working on this, I realized how much you are going 
to like this new R3 build.  The entire graphics, including the view-related 
mezz functions are now a module stored in the host kit.  So, all 
of our new graphics support code can go there and be updated as needed.
 - Carl

/me likes it :-)

Robert - you should ask Carl for the permission to Tweet those nice 
messages :-)

I can.

I did.

Cool!

Andreas, so this binding was not done in R2 schemes?

Hence the need for scopy, spick, severything?

No, the binding *was* done in R2 schemes, hence the need for scopy, 
etc. It is not done in R3 schemes, so you don't need those extra 
references because the originals are not overwritten anymore.

They may be overwritten though, if instead of giving a block of specs 
you furnish an object of actors to the make-scheme function:)

Not only that, you may replace the actors of a port at anytime.

Hey Steeve, I think my scheme is working now  :)

Looks like all R3 development work is occuring inside darknets inside 
darknets

Kinda defeats the idea of open source components

yeah, I was hoping to have a bit more feedback published from the 
daily scrums

I guess there's been more feedback than before, though

What feedback do you expect?

The thing is to concentrate and focus that we can deliver something. 
Disussions about non-priority things don't help us at the moment.

The daily scrum is not that interesting as there is nothing DONE 
until the end of a sprint. We are currently using 1 week sprints. 
This means every Friday afternoon we review what has been DONE.

Graham: I expect something to be released (open-sourced), once there 
is actually something to open-source. I mean - untill the HostKit 
isolation is done, we can't proceed. Once View is completly separated 
as module, it can, and hopefully it will be released ...

I don't know about anything why it shouldn't be released.

I'm looking forward what will be done with the host-kit. Not sure 
why it's a mandatory component for so many to use R3 but OK, maybe 
I just don't get it.

IMO it's more critical to use to get a good GUI up & running with 
a broad set of styles.

Pekr, I was just saying that all R3 development is either practically 
invisible, or, perhaps is just not happening.  r3 chat is also dead.

well, I think that if Carl's developments from the private world 
is posted on his twitter account, that should be enough.

Is the lack of developer activity just a sign of lack of interest 
in R3?

I'm not sure I understand what you mean. There is probably more developer 
activity now than in the past 2 years.

There's no unpaid activity

People are waiting for the host kit.

I'm busy again, and just chatted with Carl today about what I'm working 
on. For better or worse (mostly worse), that's unpaid.

Robert is pulling a lot of strings (namely by getting hold of all 
the right people, while they are not busy) to focus R3 development 
and I'm impressed that he was able to get Carl in on it. It's what's 
needed now to move forward at greater speed, just like any other 
serious development effort. Robert's motivation is to deliver products 
as soon as possible and there is nothing strange about that.

For the main things I was working on, I am now unblocked. Thanks, 
Robert!

ANd Pekr, who has also done a lot of behind-the-scenes work.