World: r3wp

hmm, we are appending char into string ... who knows what it does 
internally :-) In charset, there are some escape/control codes, so 
maybe it causes a beep, I don't know :-)

I reported the strange beep into CC too ...

I copied the dataset before each parse ... very odd

Pekr, are you sure it's not just control chars printing to windows 
console causing beep?

could be a GC problem? Maybe above "beep" means there might be some 
memory leak?

maybe ... who knows ... should not beep ....

it surely is about control chars ...

why should it not beep?

Petr, most likely you get the beep when the string is printed to 
the windows console.

R2 does not beep (but it has its own console)

that is, windows does respect the BEL character.

ie. try print "^(07)"

yes, but I am denerved by that beeping :-)

and this is the windows console

don't include that char in your tests then, or don't print it out 
;)

Yes, it does so ... I will suggest the ticket dismissal ...

more unnerving is the non reproducible parse!

Graham - sqlab's code uses random sets, no? What is non reproducible 
exactly?

parse dataset "^/" returns a different value

for each consetutive run on the same dataset?

consecutive

length? parse data "^/"

do that a few times

>> parse "abc^/def^/ghi^/" "^/"
== ["abc" "def" "ghi"]

I get three value block for each run ...

on the large set ... not small sets

OK, I will try ...

he just generates a large set of random chars

strange ... I even tried to do those consecutive parse examples on 
the copy of data ... the result is still random ...

I thought that first parse might disrupt the input, which is used 
for the second parse too. But it does not work even for the copy 
of the data ...

Following code almost kills my DualCore notebook. View exe consumes 
almost 1GB of RAM :-)

c: ""
for i 0 255 1 [	append c to-char i ]
data: to-string array/initial 255 * 255 random c 
print length? data
m: parse copy data "^/"
print length? m

print length? data
i: parse copy data "^/"
print length? i

did you calculate how many strings you build ?

I tried that code in R2 and R3.....R3 took about twice the memory.

UNICODE strings plus unoptimised data structures may account for 
the difference.

Worth noting too perhaps: after trying the test three times, unsetting 
'c and 'm and recycling .... R3 got stuck trying to get into 'chat 

Possibly some screwed up garbage collection when recycling large 
elements? The failure is repeatable.

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

A bit of work to do for those interested.

I looked at Ratio's import-email function on the blog and was wondering 
if R3 is supposed to have an import-email function? He claim's R2's 
import-email function is buggy and there is really an unfixed report 
in RAMBO.

Is there any RFC related to the email string which is being parsed?

RFC 2822?

I'm not aware of any bugs with import-email... but of course it does 
die if you get non compliant email

I used to run a routine to fix an email first before running import-email 
on it .....  ie. add missing fields etc

R3 chat seems to be so much slower these days ...

Is there something wrong with the server?

I think there is a blog entry about this...

and a chat message .. tcp outages on rebo.net

Here's a newbie question:  In general, do scripts written for R2 
run under R3 as is or are there specific changes one must go through 
first.  I read that many of you are running older projects in R3 
and wondering how you are approaching the changes that might exist. 
Thanks.

there are many subtle changes, so I wouldn't expect too many scripts 
run out of the box. GUI scripts won't work at all.

OK, thanks Henrik. BTW, since your last info on the vid-kit. It's 
been working like magic, even the list-view!

Ladislav and I have both written about our early experiences:
   http://www.rebol.org/art-display-index.r?a=R3

Note the use of the RCO object (REBOL Compatibility Object)  that 
attempts to make scripts R2 and R3 runnable.

Thanks Sunanda. I've been holding off R3 as it takes "my all" just 
to write stuff in R2 and generally they are tools that "have to work." 
I feel badly though because so many of you are putting so much effort 
into it. I could definitely give a non-guru perspective. Thanks for 
all you guys do.

james, cool :-) I hope to get back to work on it soon.