World: r3wp

Nevermind, I got it. I'm writing the ticket now.

Carl asked me to ask, what is general opinion to my suggestion - 
to remove parse /all refinement altogether. Current proposal is to 
swith parse by default to /all mode for block rules, and to recent 
default behaviour for string rule. As for myself I don't mind compatibility, 
so I prefer removing /all refinement and switching pase internally 
to /all mode ....

I proposed an /ignore stuff option that would replace the old default 
behavior, and be more general. Then we could toss /all.

That tuple bug applies also to R2 ... will such bugs be fixed?

Not in R2, unless we can prove that code won't be broken. We have 
a lot of incompatible fixes of R2 problems in R3..

Submitted as bug#1069.

What do you think about current progress? Progress is imo great, 
but when do you think we will get to more strategic parts like Plugins, 
etc?

I think pretty soon. That got delayed because Ladislav and meijeru 
started being really thorough about reporting inconsistencies in 
the core semantics of the language, so we started working on resolving 
those in case any changes affect the rest of the system. For instance, 
the equality change includes changing the equality actions to natives, 
which changes the action list - that might affect plugins.

Removing binary! from any-string! definitely would affect plugins. 
It affected everything else - there's a lot less buggy code now :)

That is good to hear :-) Was there any resolution to various make 
methods? Will we be able to precisely decide, what gets copied and 
what gets referenced?

That is still pending, but the discussion about that reached a consensus, 
so it will come after we finish up the equality changes.

re tuple....

....I thought it technically was  not a bug. Just a surprise that 
is explicable when you remember that tuples are padded with zeroes 
for equality tests:
    1.0.0 = 1.0.0.0
    == true
     (length? 1.0.0) = length? 1.0.0.0
    == false

It turns out that the length of a tuple is set at tuple creation 
time, and that length affects LENGTH? and PICK, which are called 
by LAST.

It was technically not either a bug or a feature - it was a side 
effect that had not been discussed. The bug ticket will start the 
discussion

The amount of space a tuple takes is fixed, as are the trailing zeros. 
The "length" is just a number.

The result of all of these discussions is that R3 is going to be 
much more rigorously thought through and consistent than R2. The 
little improvements are going to be the ones with the greatest impact 
in the long run.

Brian - I don't understand proposal for invalid-utf-8 function. What 
is it good for? Is it about some binary code not being able to be 
converted to regular char?

It's about finding UTF-8 encoding errors, particularly the overlong 
forms that are used for security breaches. We can't do that check 
in TO-STRING because of the overhead (+50%), but it can still be 
a good idea to check in some cases, and the code is better written 
in C than REBOL.

That is what came to my mind - if to-string should not care itself. 
Well, not even sure it is about to-string, but about particular decoder?

TO-STRING is the primary decoder of UTF-8 in REBOL.. TO-CHAR is the 
other one, and it complains about invalid UTF because it can.

How do I get 
   stack
to do anything useful?
I assume I have to enable it with
   system/options/debug   or secure

But just poking around has not found the magic words (ditto, web 
searching).

You mentioned the security, but the trick is that STACK is undocumented 
and you have to poke around and try things out for it to work. To 
my knowledge, I am the only one who has come up with proof-of-concept 
code that uses STACK, but the concepts proven were meant to highlight 
security holes :(

I haven't tried out all of its options yet either.

Stack has teaser documentation, but the examples no longer seem to 
work:
  http://www.rebol.net/r3blogs/0075.html

A70 released. GUI demo runs once again ...

... is that on Windows only?

dunno ...

http://www.rebol.com/r3/downloads.html- Win and Linux this time. 
I expect non-Win platforms being Core only too ...

Great to see GUI Demo back up...even "text view" demo works now...


I saw Carl made some more changes to GUI not yet included in build. 
Any ideas on what changed?

the changes are not yet implemented. the layout system will be changed 
to contain a guide system and multiple layers. if it works, there 
will not be any more trouble with the layout engine.

I hope we can dictate into these text entry fields ... windows speech 
recognition is apparently quite good.

if it works like a generic keyboard, then you should be able to do 
it in R2 as well. try putting up a view layout [field] and see if 
it works.

It works under Vista, but can't get it to work under Windows 7

why am I not surprised... tried other non-native programs?

Yes .. they don't work either ( Chrome )

Curiously IE8 is okay.

I wouldn't be surprised if they made it so it won't work in other 
than through certain APIs.

Having the OS vendor also an application vendor is the problem.

They should split up MS like they did to the Bells

But is speech an OS thing or an application?

It should most definitely be an OS thing. It should work like generic 
keyboard input. There would, though, be two kinds of input: One for 
dictation and one for GUI control. The latter might be harder to 
do in REBOL without some OS friendly extensions.

It's more sophisticated than just keyboard input.  It can be used 
to select words, undo selections etc

all dialect driven

I think what they should have done here, is lift ordinary keyboard 
commands. You would simply say the key names, along with a few extra 
commands, like "again". This way you don't have to remember an entirely 
separate command set.

This is also a problem in MacOSX, because the command set is very 
limited and nearly useless.

R3 function for creating objects with default values. Neat!
      object [a: b: c:]
      == make object! [
            a: none
            b: none
            c: none
      ]

... and slow!


>> do [st: now/precise loop 10000 [object [a: b: c:]] et: now/precise]
== 11-Jul-2009/23:55:57.406+8:00

>> difference et st
== 0:00:04.36


>> do [st: now/precise loop 10000 [make object! [a: #[none] b: #[none] 
c:#[none]
]] et: now/precise]
== 11-Jul-2009/23:56:13.578+8:00

>> difference et st
== 0:00:00.032

That's functions for you :-)

well, how often do you create 10K objects at once? :-)

I find it a little strange that it is so slow:

>> source object
object: make function! [[
    "Defines a unique object."
    blk [block!] "Object words and values."
][
    make object! append blk none
]]

P: well, how often do you create 10K objects at once? :-)
frequently