World: r3wp

A bit of host kit news:


--- Win32 window and event code now compiles and links successfully 
within the host-kit.
 - Carl.

YEAH baby

Database work is only waiting for a community discussion of the semantic/dialect 
model, afaik. Something to integrate with the new port model, not 
the old one.

j: open jdbc://localhost:8000
insert j {select first 2 * from staff}
r: copy j
>> length? r
== 2

My jdbc protocol working

Any reason why we can't use R2's semantics?

Yes: The port model is different. For one thing, you don't insert 
to and copy from ports.

So just rename the actors

And async needs to be considered as well.

My jdbc protocol is async

With a handler, like in R3?

All protocols are async unless you do special trickery to try and 
make them look sync

My jdbc protocol is a R3 protocol ... this is the R3 group!

scheme I meant

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 ...