World: r3wp

and?

and pekr likes to say "and?"

R3.0 is gonna be released in 2010, so what is your point with 2015?

Jerry, the inner FOREACH loop bind/copies its code block with every 
iteration of FOR - this is a lot of overhead. Use FORALL instead.

A lot of code needs reoptimization when converted to R3 - particlarly 
since all loop functions are native now.

You might also consider
    primes: make block! max-value

instead of 10000 for speedup of prime calculation of max-value over 
10000. Trade memory for speed.

Using the algorithm: Sieve of Eratosthenes
it's just ligthning fast.
For 50000 max prime, i got those results:

; Eratosthenes 
== 0:00:00.089
; Jerry :-) 
== 0:00:10.099


get-primes: func [n /local primes mul p limit][
	primes: make bitset! n + 1
	p: 2
	limit: square-root n
	for p 2 (to-integer square-root n) 1[
		if p > n [break]
		unless primes/:p [
			mul: p + p
			until [
				primes/:mul: true
				n < mul: mul + p
			]
		]
	]
	primes
]

It returns a bitset. False Bits are prime numbers.

(probably, the real gain comes from using a bitset to store numbers)

remove the limit line in the source (n

not used

geez, some other lines are useless

get-primes: func [n /local primes mul p limit][
	primes: make bitset! n + 1
	p: 2
	for p 2 (to-integer square-root n) 1[
		unless primes/:p [
			mul: p + p
			until [
				primes/:mul: true
				n < mul: mul + p
			]
		]
	]
	primes
]

arghhh, one useless line again, abandon :-)

Looks good to me (minus the p: 2 line) :)

You can use FUNCT too instaed of specified locals. The p will be 
local to the FOR.

yep

The TO-BLOCK bitset! proposal would help here. Then the return could 
be
    to-block complement primes
which would return a block of integer primes.

yep, i asked this in curecode IIRC

both of us actually

I'll verify that later, and add it if it's missing :)

the point is not to use a good algorithm to get primes. the point 
is using the same algorithm to compare Java and REBOL

it"s not fair because we know java VMs use JIT compilation.

WOW, forall is really fast. Much faster than FOREACH

I rewrite it using FORALL, now REBOL is even faster than Java

Thanks, BrianH.

shortened version of yours:

get-primes: funct [max-value [integer!]][
	primes: insert make block! n / 2 1
	for i 2 max-value 1 [
		unless forall primes [
			if zero? i // primes/1 [break/return true]
		][
			append primes i
		]
	]
	head primes
]

even if you don't want it faster, you can have it more rebolish

bitset version. If max-value > 65536, it won't work.

>> a: make bitset! 100000
>> a/65535: true
== true

>> a/65536: true
** Script error: cannot set 65536 in path a/65536:

FORALL vs. FOREACH: interesting

about bitsets, the bug is already in curecode

Steeve, JIT compilation can't always beat precompiled and optimized 
native code. If you stick to native!, action! and op! functions REBOL 
can be faster than Java for some kinds of code.

i know

It's true that Java's JIT makes it an unfair comparison, but sometimes 
the unfairness goes in the other way :)

R3  needs to name itself Rebol 3.00 a 96  instead of rebol 2.100.96.3.1

I have one R3 TCP server, and two R3 TCP clients. When the second 
client starts to send data to the server, the server will stop handling 
data from the first client. This is very bad for my system.

What can I do? thanks

we shold probably push RT to fix the bug. IIRC Oldes (or someone 
else) found himself in the same situation, and it should be now reported 
in CureCode ...

There are 230 open issues in Curecode now.

So I guess this bug won't be fixed soon.

For work around this, I am trying to develop a middle-tier program 
using Java or Erlang.

yes - few months back we fixed ca 80 tickets a month. Now Carl is 
on Extensions and Host kit. However - some bugs could be bumped-up, 
and this one seems being pretty serious ...

Jerry - I sent private message to Carl, trying to point him to your 
and Oldes's ticket - those are imo related. Hopefully Carl reads 
my message ....

Perk, thanks. I hope this bug will be fixed soon, so my system developed 
in R3 can be online soon.

Has anyone developed some new styles for R3 GUI? Even the VID stuff 
is not yet ready IMO doing styles should be possible and the chances 
of lost-effort seems to be low.

Robert - I think not. Henrik named few fundamental changes Carl is 
after. You surely remember e.g. frames concept, which was later removed 
for e.g. IIRC, things like - better resizing, changes to layout engine, 
layers, etc. are planned. What is interesting is, that it would take 
imo max 1 week to implement them. So - dunno when Carl is back on 
GUI. As for me, I would not like him to jump from topic to topic, 
which happened today, as Carl is moving to website topic for few 
days. BUT! - I think he just needs break from heavy coding ...

Jerry, from observation, Carl fixes bugs related to specific topics, 
so at some point, I'm sure he'll revisit ports as long as people 
put clear and simple reports in Curecode.

it should read: "specific topics in one go"

So I guess this bug won't be fixed soon.

 Also not easy to know. I've before put reports in that were fixed 
 on the same day. (But it definitely won't be fixed, if it's not in 
 curecode).

Henrik - it's there, actually two tickets, probably the same #1369 
and #1397

good