World: r3wp

thought he was working on redoing the r3 docs ...

There's a real paucity of news at present.

The only news is recent Twitter post: "AltME.com website, DNS, WNS, 
and various other changes quite disruptive today, but should settle 
down soon."

nothing regarding R3 development

I know ...

2 years ago, in times like this I were really upset: "were are we 
going ?", "when will it be usable ?", "I need it !" ...

Now follow the various REBOL channels with curiosity. I expect nothing. 
When it will be ready I'll be happy and start using it.

(* I follow)

Expect nothing and that's what you'll get

The truth is, that I was claiming to guys here, that we are at 80% 
of the dev stage, one or more years ago. But we are still there. 
Unless HostKit is released and contains stuff devs need, we can't 
move much forward. I hope we are close to that stage. It is just, 
that we are close to it for several months already :-)

Everyone ( well, perhaps not Henrik ), is on hold ... just waiting.

But there is still lots of work to do for Core too. E.g. tasking, 
or other stuff listed in priority doc.

Graham... things go this way on REBOL. We have to wait...

I am encountering a crash, dunno if easily traceable. I start R3, 
type-in "chat". Then I quit the chat by "q", then I type "demo" .... 
and R3 crashes ...

I'm not on hold. I'm just using only R2 regulary.

Pekr, the procedure you describe works for me on Rebol3 version 2.100.97.3.1. 
My %rebol.r in the same directory is virtually empty.

Pekr, same happens to me

Why would chat kill the demo ... unless http is modified or something?

Oldes, this is the R3 group ... so on hold means on hold with R3 
!

Pekr, putting a trace before demo and it doesn't crash.  Very odd.

of course I can't do much with the trace running ...

Still tracing ... seems to be doing a lot with nothing happening. 
 I would have thought the whole GUI would be in a wait

I've been misleading, what I wanted to say was: I do not get the 
error Petr describes, the demo comes up.

Still tracing .. what on earth is it doing??

It's working here on XP

So, the demo comes up okay for you after exiting chat?

I tried the chat then demo trick under linux and Rebol crashed with 
a segmentation fault. Normally, the demo gives a script error. I 
also tried on Mac OS X but that was okay - the demo gave a script 
error.

This should be reported in CureCode.

I was wondering why some messages don't show up on chat.  Eg. #6993

when I do a 'n, but show when I type the number in...

6993 wasn't a message, it was a move of 2 of Paul's messages to the 
right heading. Not every number is a message - everything gets a 
number, including headers, moves, deletes, file operations, etc.

Only messages show with n. Some file operations show with nf. Other 
operations don't show at all, except in effect.

Some messages don't show because they are private messages that don't 
involve you. If you can see those even by entering their numbers 
directly, please report that serious bug.

any news?

Yes, but can't report it ...

sigh :)

Carl is still tidying up the GUi documents ... taking much longer 
than was expected

and other issues http://twitter.com/rebol3

Is Doc's MySQL driver working in R3? Has anyone tried to get it up 
& running?

Petr, Graham, have you checked the >>CHAT >>Q >>DEMO problem after 
Carl has restored the chat server to an up-to-date version? That 
may be related? The sequence still works here.

works for me now...

I think i will change again some habits in the way I code.


It seems that the try/except idiom has better perfs than EITHER if 
you use it  that way:
>> try/except [...frequent case...][...rare case...]

Try this and give me your results...

f1: funct [v][either zero? v [0][1 / v]]
f2: func [v][try/except [1 / v][0]]

print dt [loop 100000 [f1 1]]
print dt [loop 100000 [f1 0]]

print dt [loop 100000 [f2 1]]
print dt [loop 100000 [f2 0]]

if the condition to check is more complex then the gain can be tremendous

Wow, I never realized what overhead TRY/except has, but that overhead 
seems to be fixed. As long as you can safely run until an error without 
having to roll back changes, that could be a good strategy. Sticking 
to the R3 safety model (generating errors before it matters with 
functions like ASSERT) you can make code that runs faster in the 
default case, and safely always.

We still are stuck in Cathedral mode ...

:-)

Still need to be confirmed.
What are your results for the test I provided ?

But we can't check anymore for the type of the last happend error 
with try/except.

>> try/except [1 / 0][error? probe system/state/last-error]
none
== false.

it's a problem, we can't have an accurate process error handler.

I think it's a missing feature (or the error is somewhere else in 
the system object).

>> f1: funct [v][either zero? v [0][1 / v]]
>> f2: func [v][try/except [1 / v][0]]
>> print dt [loop 100000 [f1 1]]
0:00:00.063264
>> print dt [loop 100000 [f1 0]]
0:00:00.044331
>>
>> print dt [loop 100000 [f2 1]]
0:00:00.050118
>> print dt [loop 100000 [f2 0]]
0:00:00.124219
>> print dt [loop 100000 [f2 0]]
0:00:00.121766

That last one was so surprising that I ran it again.

But, that overhead should be fixed, regardless of what's in the blocks.