World: r3wp

We can upgrade to doubles in the future, in the 64bit builds - AGG 
uses them already. Though I don't know the effects that would have 
on rounding and such.

exactly, I wouldn't want a 64 bit build to perform different maths 
on values.  it should just be faster for bigger numbers.


if we go with floats, I feel that we'll be forced to keep them even 
in 64 bit builds.


also, generally, all graphics libs and most math related libs now 
use doubles.  so if we need to convert the floats from rebol everytime 
we use the value within an extension its going to incur some speed 
hits no?

An extension like AGG, which also uses doubles. But we can't fit 
two doubles in a value slot on a 32bit build, sorry.

And if we don't fit a pari into a value slot, it changes its whole 
behavior.

yeah, I see the problem.

they could be stored like vectors internally, but would that make 
them MUCH slower?

Yes, due to at least one added pointer indirection, and added code 
to prevent aliasing (in the pointer sense, not the graphics sense). 
And they could be modifiable, unless we are careful, and that brings 
in another whole host of issues.

well, I guess they could just be stored as a two double struct, but 
then we still get the added indirection everytime they are used.

Development roadmap. There's also Carl's blog about it. I just wonder, 
if it differs from the priority page that much?

http://www.rebol.com/roadmap.html
http://www.rebol.com/priorities.html

AT LEAST THE ROADMAP  !!!  i'm about to cry ...

no in fact I don't havec feelings but if i had some feelings i would 
cry ... eventually...

Thinking that the java jdbc bridge I was working on in "Other languages" 
might be used for R3 database access until we have ODBC support

I guess I need to serialize the data on the java side so that it 
looks like Rebol values .. a la 'mold

doing a java bridge to access a database ? hum really ? but what 
would be the gain ? instead of having it in direct access i thought 
rebol had odbc acces through odbc://

This is R3 group

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.