World: r3wp

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

It is slow because he reuses the same spec block over and over, which 
means that with every loop iteration another #[none] is added to 
the spec block. This means that the spec block has to be expanded 
many times, with reallocation overhead.


The OBJECT function was meant to be used with specs that aren't reused 
- it's a convenience function for high-level objects, which may be 
replaced by a change to MAKE object! to have an implicit none on 
the end of the spec instead of needing to add an actual one.

Why not just have it use JOIN internally, rather than APPEND?

Append is native too, no?

But APPEND changes the spec block, which caused the speed issue Peter 
pointed out.

At this point, I don't see the value in the OBJECT func myself.

Because of the speed issue?

No, that's incidental.

Yes, looking at object, there are two problems:

  1. it is slow .... though as Gregg says, that looks like it can be 
  fixed by changing its pith to:
                       make object! join blk none

  2, it is unnecessary. I never realised until now that this works 
  fine to set default values:
        make object! [a: b: c: d: none]