World: r3wp

Of course, other operations, like conversion to integer, e.g., are 
needed sometimes, and for those, the situation would be the other 
way around

Oh, ok, so R3 is still mainly being built 32-bit.

Ladislav, no example that shows an advantage springs to mind.

Could you also measure conversion to int for 96-bit pairs and pairs 
of floats?

Pairs of floats look more advantageous to me now.

I agree on the pairs of floats... much better programatically, especially 
since the pairs will be used for things other than simple "pixel" 
coordinates.

it would also be VERY nice to be able to do tripplets or quads.

hmm, actually, triplets of floats may be possible

(96 bits)

one thing I wonder is that when 64 bit builds do get released, are 
we sacrificing the future by tuning the present, using only floats 
now?

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?