World: r3wp

I think that we need - plugins, security, gfx, gui, few protocols 
(later some engine like cheyenne inside), well, we need many things. 
Also current implementation of codecs is absolutly useless, no concept, 
just a workaround ...

We needed the system object changes for modularity and security too. 
Once we clean up for those, multitasking won't be that hard.

BrainH: I'll point you to one article, wait a min., I need to find 
it. Actually - it was Cyphre who found it IIRC.

http://www.codeproject.com/KB/system/timers_intro.aspx


we imo need multimedia timers, definitely. So "small" change can 
make big difference. We don't ned to look pre W2K imo. And it is 
crazy that MS has all this mess in their API. The good thing is, 
that timers are host layer, so community can advance it ...

could this help in R3? http://www.cilk.com/The Cilk++ cross-platform 
solution offers the easiest, quickest, and most reliable way to maximize 
application performance on multicore processors.

The reason Carl is focusing on these simple datatype changes now 
(like vector!, image! and money!) is because they affect rebin, and 
rebin not being done is currently what is blocking the release of 
the host code.

Will, that's not cross-platform enough for R3 :(

I wonder how he resolved the problem he advised in R3 Chat, that 
with his initial idea not everything could be dynamic (draw). Hopefully 
he found some solution.

is R3 coded in C or C++

Well, if Carl uses CureCode, I should post Timer related ticket probably 
:-) ... and maybe BlitJit/AsmJit ones too :-)

Mostly C, though AGG is written in C++.

Max - I think it is C, although AGG is C++

BrianH: what is FIRST+? What is the difference to pick port 1 or 
just first port?

FIRST+ takes a word that refers to a series and it advances the word 
to the next position while returning the first value.

It's a speed/simplicity thing.

Something like: str: next str?

ah, ok, should have read all your post :-)

Many new funcs play with the supplied series which is great!

Here's the R2-Forward version:

first+: funco [
	{Return FIRST of series, and increment the series index.}
	[catch]

 'word [word! paren!] "Word must be a series."  ; paren! added for 
 R2
][

 ; Workaround for R3 change in lit-word! parameters with paren! arguments
	if paren? :word [set/any 'word do :word] 
	throw-on-error [also pick get word 1 set word next get word]
]

what is funco? I read its help, but don't understand. So normal function 
creation in R3 creates copy of body, whereas funco shares it?

funco remains me pulco citron (pulco citrus) a beverage

there starts to be too many function related functions: function, 
func, funct, funco ....

Right. FUNCO is basically like R2's FUNC - only sa to use under certain 
circumstances.

Pekr, you have the sources of func and funco in R3

But without the throw-on-error stuff.. Just use it for functions 
with correct syntax.

funco: make function! [
	"Defines a function, but does not copy spec or body."

 spec [block!] "Help string (opt) followed by arg words (and opt type 
 and string)"
	body [block!] "The body block of the function"

][ ; For functions known to have no syntax errors or recursive issues.
	make function! spec body
]

just weird naming which makes no sense. REBOL always tried to name 
things full-name, not some weird abbreviations ... this is not the 
case with function related functions ...

That's the R2 version.

would it be much slower to have just one with refinements?

surely

It's short for func-original. It's the function used to define many 
mezzanine functions in R3. Fast, no error checking.

Pekr, the answer to your question is yes, it would be *much* slower 
to have one with refinements.

That's why the only function creation function with a refinement 
is FUNCT - since it does so much work anyways that the refinement 
overhead is much lower in comparison to the rest of the code.

Then we need new format supported in native code - having named sections, 
which would be just a jump point for refinements: body: [copy [this 
is copy code] nocopy [this is nocopy code]] :-)

We have that: EITHER.

The problem is that what you suggest isn't any faster than EITHER 
or PICK.

... or switch or case ....

Yup :)

R3 alpha 54 released...... Two days after A53, and 32 curecode issues 
addressed.
That's fast work!

http://www.rebol.net/wiki/R3_Releases#View.exe_2.100.54_14-May-2009

Not in the Mac ghetto  :-(:

>> upgrade
Checking for updates..
.

R3 current version: 2.100.51.2.5
 
It was released on: 6-May-2009/0:42:42 



Your version is current.

OK - no problem to ping Carl about it, no? I think he just did not 
generate it yet ...

Is this our Meijeru? :-) http://users.telenet.be/rwmeijer/

same name as in chat

yes, although no mention of REBOL on his programming subsite - http://users.telenet.be/rwmeijer/proglang/


btw - I found out he was announcing complete DOM implementation for 
REBOL? Has anyone actually seen anything like that? 
http://www.mail-archive.com/[rebol-bounce-:-rebol-:-com]/msg03548.html

I got a copy but it was not useful for me.

I don't think it is.  Didn't he live in the States?  The link provided 
indicates he is living in Belgium.

the guy above is living in belgium.

He is slightly sloppy with his english, in a way that made me think 
it is not his first language.

Everyone who is interested in the typeset debate, look here: http://curecode.org/rebol3/ticket.rsp?id=820

The question is whether binary! should be part of the any-string! 
typeset in R3. Since the Unicode conversion, binaries are arguably 
*not* strings anymore. Even if they support the same operations, 
all of the other string types contain characters, while the binary! 
type contains unsigned 1-byte integers (which characters are not 
in R3). What do you think?