World: r3wp

:-) .... yes, but one aspect remains ... you work, I talk :-)

>> a: [a 1 2 b 3 4 c 5 6 d 7 8]
== [a 1 2 b 3 4 c 5 6 d 7 8]

>> head move/to/skip find copy a 'd 1 3
== [a 1 d 7 8 2 b 3 4 c 5 6]


Looks like a bug to me. [d 7 8] should be at offset 1 rather than 
3. This is also present in R2 forward.

sorry, plain R2.7.7, not R2 forward.

Nope, 2.7.7 has the R2/Forward code. I see the bug, though have a 
question: Should the index obey the skip?

When /to is not specified and /skip is, offsets are multiplied by 
the record length, so you are counting in records. This is intentional, 
to allow you to work with fixed records without messing them up. 
If we keep that behavior then the index will be the record index, 
not the series index. It's not a difficult trick, but it should be 
noted.

If you agree that this makes sense, I'll write up the CureCode entry 
and submit the fix to all three locations.

It's so sad that after 3-4 years there's so few people working on 
R3

 - I can take it if it would be "...working with R3". That's true. 
 People should use it and tell what's the most critical (that means, 
 what blocks you from making a product) thing that needs to be done 
 in R3.

It's not about x-mas and what we would like to see in R3. I have 
a very simple priority list: What do we need to get to scale R3 development 
and avoid Carl being a bottelneck? What do we need to do to use R3 
to do a commerical app?

And, yes, I'm very happy that things move on and the support from 
all helping to make it happen. The team size is good, the paces is 
good and the results are good.

What's blocking is that questions don't get answered because no one 
knows the answer

Maybe we should have our own stackoverflow for questions on R3 so 
that unanswered questions are obvious?

Or, just ask them on SO ...

For now I'll assume that Henrik's answer to my question is yes.

Graham, can you give an example question?

Sure.  If the remote server closes a connection, can you re-use the 
sub-port to re-open the port?

Have you tried it?

Yes.  And no it didn't work.

Do you have a workaround?

Well, I guess I can just recreate the subport and try it that way, 
but I would like to know why ....

Are there flags or other things that need to be reset or what is 
the issue?

Ok, as the current focus on R3 is to get the infrastructure and basic 
things done first, these detailed questions (even if valueable) are 
not our focus. But this doesn't mean, that it's a showstopper for 
you to use R3.

How about adding a category in CureCode to collect these so it's 
not lost?

that's up to doc I guess ...

My goal is to get R3 out of alpha, beta to release. To get the GUI 
to a state that you can create apps with it.

Like the Issue type?

Well, a GUI a nice, but the working out network details seems a little 
more basic :)

BrianH, you are right, my response is "yes".

Ticket submitted, R2/Forward being fixed now, the rest to follow.

cool

as for apps - GUI, networking, DB drivers ....

some things can be postponed (e.g. db drivers), if 'call would support 
/wait/output at least ...

Fixed in R2/Forward 2.100.80.2, check it out.

Submitted R2 and R3 fixes, they should be in the next versions of 
each.

good

The source is there already in case you need to use it before the 
next version comes out. The R3 version is:
move: func [
	"Move a value or span of values in a series."
	source [series!] "Source series"
	offset [integer!] "Offset to move by, or index to move to"
	/part "Move part of a series"
	length [integer!] "The length of the part to move"

 /skip "Treat the series as records of fixed size" ;; SKIP redefined
	size [integer!] "Size of each record"

 /to "Move to an index relative to the head of the series" ;; TO redefined
][
	unless length [length: 1]
	if skip [
		if 1 > size [cause-error 'script 'out-of-range size]
		offset: either to [offset - 1 * size + 1] [offset * size]
		length: length * size
	]
	part: take/part source length
	insert either to [at head source offset] [
		system/contexts/exports/skip source offset
	] part
]

thanks

I have meet ROBERT a couple of years ago and his work is pulling 
string to people. He is paid for this and seems to be very good in 
this role. Companies pay a lot of money to Robert and we have his 
work here for free. (Note: also other people here are working for 
free).

Graphics extension loads:

http://rebol.hmkdesign.dk/files/r3/gui/217.png

List of graphics functions:

http://rebol.hmkdesign.dk/files/r3/gui/218.png


There was a small demo to display a random collection of gobs, but 
a bug in the host kit prevents me from taking a screenshot.

hah, ha! New milestone in R3 development seems to be close :-) I 
hope we get delayed modules too, so that gfx can be loaded on demand, 
which would be good for the X-less server - still one rebol version 
to use :-)

Henrik - I saw small mention of some speed-up, due to more streamlined 
command interface (probably in opposite to DELECT). So - any chance 
we get updated 1000 cows demo or so, to see "the difference"? :-)

we'll probably see that. I think he wants to work out all the bugs 
first.

I've found that VirtualBox is a really bad testing platform. It slows 
down in places by a factor of at least 10, so I can't do any benchmarks.

Is the API complete? Box, pen etc seems strange, there should be 
more, no? :-)

I don't think it's complete. He's just testing whether the whole 
thing fits together.

Good progress anyway. I noticed Twitter message mentions OpenGL. 
Well, I hope we get VID 3.4 with some nice bunch of styles first 
:-)

I'll promise to update 1000 cows when the new gfx engine is ready 
:)

:-) I also like Cyphre's rotoobjects demo, or bounce one. Simply 
random draw shapes, with various levels of alpha, flying on the screen 
:-)

btw - will DELECT still remain? New COMMAND type seems to remove 
the ability to have random order of parameters. And quite honestly 
- I don't like it. It might be good for very fast low level engines, 
where speed matters, but I still want the flexibility of random parameters. 
So - will DELECT remain for dielact builders, or will we have to 
fall-back to full parse in such a case?

Nobody said anything about removing DELECT, so I think it will stay. 
I never used it anyway, so I don't care.

DELECT could be used to convert a dialect block with unordered and/or 
parameters to commands into a command block with ordered, mandatory 
arguments. It does it already; all that would be necessary is to 
have if generate its results in a flat block rather than nested blocks. 
There would be no need to remove it - just change the output format.