World: r3wp

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

R3 ports don't do auto-lookup? Hmm, maybe it is logical, on low-level. 
I tried Oldes' example in CC ticket, and something like open tcp://localhost:8080 
does not work here ...

those examples are bad and difficult to use. I should probably port 
my short "multiserver" script to R3 and give it a try ...

so try another port! that's the only reason why  open tcp://localhost:8080 
 should not work

And the example is the simplest I have been able to produce... if 
you have better, just write it to comments.

And I agree with Jerry, that it's quite urgent bug. It's hard to 
start writing some network schemes when you can simply test, that 
there is something wrong inside. If someone is able to "beep" Carl 
a little bit, please do it.

I think that OSX host kit can wait a little bit.

beep
 Carl: Mark the bug urgent.

Another IP related bug is affecting the amount of transferred data, 
when you try a few megabytes you can find the error just after 4300000 
bytes or 215 chunks, I've reproduced this a few times.

Unfortunately this I can't write to curecode because my login is 
unactivated still, where to activate it?