World: r3wp

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.

What is the best way to handle HTTP encoding in R3?  For example 
if I get an email that has been encoded as paul%40tretbase.com?  
How could I convert that easily to [paul-:-tretbase-:-com]?  Not sure if 
I need to build my own decoder or if we already have that capability.

I think Power Mezz has some url en/decoding functions.

Or you can look at the source of DECODE-CGI in R2 and make something 
useful of it for your purposes. Nothing built into R3 though.

Sorry, DECODE-CGI won't help.

As parse rules go, it wouldn't be difficult. Try this:
>> hex: charset [#"0" - #"9" #"a" - #"f" #"A" - #"F"]
== make bitset! #{000000000000FFC07E0000007E}

>> parse a: "paul%40tretbase.com" [any [to "%" [b: skip copy x 2 
hex (b: change/part b to-char first debase/base x 16 3) :b | skip]]] 
a
== "[paul-:-tretbase-:-com]"

Now that is a modifying method, but it should be easy to adapt that 
to a copying method.

And that parse rule would work in R2 or R3. We can't R3-optimize 
it yet with the change rule since change rule paren hasn't been implemented 
yet.

With the full change rule it would be this:

>> parse a: "paul%40tretbase.com" [any [to "%" [change [skip copy 
x 2 hex] (to-char first debase/base x 16) | skip]]] a

But that doesn't work yet - no computed changes.

Yeah, thanks Brian.  I might role my own.

look like I don't need to

R3 has what I need already.

This works pretty good:

>> dehex "paul%40tretbase.com"
== "[paul-:-tretbase-:-com]"

:-)

that was easy

hehe yeah - I thought there might be something like that.

Is there a new method to send email in R3?

Ok doesn't look like it.  Looks like we have to build a new send 
function for R3.

dehex doesn't totally totally decode urls.

I use 'use a lot attached usually to GUI buttons.   Wonder if it's 
worthwhile to have a version like funct that automatically makes 
all set words local so that we don't have to declare them

Or, I could just create anonymous functions  as in 'do funct [][ 
............. ]

I built my own decoder for the query-string and it works pretty good. 
 But I was wondering what the /only refinement is for  construct. 
 This looks new in R3.

I really wonder what's RT cooking (or not) right now :-) The silence 
is really strange ...

They probably had to break away and do some projects to pay some 
bills.

Is there a list of  words reserved for parse, as

>> parse "a b" [ copy limit to " " ]

** Script error: PARSE - command cannot be used as variable: limit
** Where: parse
** Near: parse "a b" [copy limit to " "]

>> parse "a b" [ limit ]

** Internal error: reserved for future use (or not yet implemented)
** Where: parse
** Near: parse "a b" [limit]

CONSTRUCT by default translates the built-in logic words to logic 
values, unset values to none, lit-words to words, and lit-paths to 
paths. This makes it easier to use it to handle headers. CONSTRUCT/only 
doesn't do any of those things - it only constructs the object with 
the data provided.

Sqlab, 'limit is reserved for a planned parse ooperation that Carl 
doesn't know how to implement yet.

Sunanda, once again you seem to be the best source for CureCode tickets 
that show off the most subtle distinctions in REBOL semantics, even 
if most of those tickets have to be dismissed. The latest example 
is bug#1506, where you give an example of wanting to catch an error 
before it is an error. Great stuff :)

Thanks for the kind words, Brian,

But I am not sure we can yet agree on the issue involved. I've added 
my response to your detailed analysis:
  http://www.curecode.org/rebol3/ticket.rsp?id=1506

Without the ability to catch _all_ errors, REBOL is vulnerable to 
sudden, unexpected and unhandlable crashes.

attempt needs to as lean as possible since it could be within loops 
being called a lot.  So I would propose that another solution might 
be to add another function.  Like to DEFUSE the block being passed 
to ATTEMPT.  So you can do something like ATTEMPT DEFUSE [some block] 
     The defuse function would return/pass the defused block to attempt 
to be evaluated.