World: r3wp

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.

unordered and/or parameters -> unordered and/or optional parameters

thanks. Then - let's request the change then :-)

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


I agree Robert. Even if the set of styles is not broad, if we have 
a few good examples of how to write styles (and maybe some docs, 
which I am willing to help with), we can turn the community loose.

We should also have a list of styles, and if a core GUI team member 
sketched out rough designs or inheritance/composition thoughts and 
prototypes, we stand a better chance of our work being used.

Correct, that's what we will do.

And, at this time I will drive it cooridnated with everyone wanting 
to help via a SCRUM process.

And, I'm pretty sure it takes a couple of months and all the baseline 
stuff is lighyears ahead.

http://www.rebol.net/r3blogs/0324.html

Update on host kit.

Is that not the time to reveal some sources. I'll like to have a 
look.

Sounds like the latest hostkit is just a few months away from release.

Well, delayed modules are going to have to wait until late next week.

I suppose that's appropriate :)

I don't expect something complete now, but it's nessessary to be 
accustomed when the code stay light.

I don't want to discover the big one in one cast and feeling lost.

You want to be acclimatised and not get a sudden culture shock!

exactly

you have to be part of the gui developement team ...