World: r3wp

I disagree with "it doesn't matter what strings are internally". 
If Rebol3 is going to be extensible as promised, the internal representation 
of all dataypes matters.

If you want precise control of the content of string data, use binary. 
String! is no longer meant to be used for such tricks.

From file list example: "text-list files do [set-face ca read-string 
pick files value]" - where does the 'value come from? Is it internal 
facet of 'text-list style?

If by "precise control" you mean accessing a string! from C, how 
would you use binary! instead?

string! internals are not OS dependent afaik, and technically it's 
not UTF-16 either. currently, R3 switches automatically between an 
array of 8-bit unsigned values, and an array of 16-bit unsigned values. 
i assume a 32-bit mode will be added in the future as not all codepoints 
will fit 16 bits, though those that don't are very rare.

Peter, if you're talking about plugins, then you *won't* have *direct* 
access to the internal datatype representation, but there is always 
an abstraction layer. in any case, that abstraction layer hasn't 
been finalized yet, so, at this point it doesn't matter what strings 
are internally.

Thanks for the information, Gabriel. Yes, I was taking about plug-ins. 
It will be interesting to learn of the details once things have been 
worked out.

Is the array to 16-bit unisgend values effectively UCS-2?

Sorry that should have been :

Is the array of 16-bit unsigned values effectively UCS-2?

Pekr, yes, VALUE comes from the face itself, just like in old VID.

Henrik - thanks for third video. Still uses lower frame rate? Scrolling 
still seems being rather slow. It will probably need some optimisations 
by Cyphre in low level ...

Pekr, it was meant to be 40 fps, but it ate almost 100% CPU. Rendering 
is usually about twice as fast.

h264 realtime encoding is CPU intensive :-)

I was referring to subpanel, seems slow anyway. When you run R3 alpha 
script called button-colors.r, it is painfully slow. I asked Cyphre, 
and he told me it would need some optimisations. Those things really 
should be realtime, or we will not be able to write Office 2007 clone 
in R3 :-)

I'm not sure if it's related. Carl has only just inserted this feature, 
so I don't know what optimizations are missing. I would guess it 
does very excessive ON-DRAW on each of the faces in the panel.

what is on 061.png? Just boxes? :-)

just boxes

For the fans of REBOL - bbrv posted new blog. You can see there an 
advert, containing ED set-top-box. It was done during Viscorp times 
in 1996, when Viscorp was about to take over Amiga from Escom. OS 
was done by Carl Sassenrath, Jim Goodnow, and Carl even talked RJ 
Mical to join the group. The project was fiasco, but look at the 
screenshot. ED set-top-box UI was done in ABL\E, predecessor of REBOL 
...

http://bbrv.blogspot.com/2008/10/everything-everywhere-ii.html

Pekr, subpanel was slow on Henrik's demo because of his debug settings.

Peter, the array of unsigned values would effectively be UCS-2 if 
it behaves the way Gabriele says. This would mean it would be faster, 
but use more memory for those with characters outside the BMP. It 
would also cause a problem on Windows because Windows >= 2000 is 
internally UTF-16, as are all of its Unicode APIs.

You could store UTF-16 in an array of unsigned 16-bit values as long 
as your length, insertion and deletion routines are UTF-16 aware.

INDEX? and LENGTH? would be O(n) though.

Henrik - you'r from Germany? :-)

no :-)

Then contact Carl to fix his blog :-)

I did :-)

why debug red lines can't be seen, if full gob size is utilised? 
Can't it be layered inserting new gob into gob/pane?

It's not supposed to be seen, because otherwise I wouldn't be able 
to see the lines that are supposed to occupy those pixels by the 
style itself. The debug function is activated like this:

view [button "hello" debug]


and the red box appears in the face, not around it. The red box stretches 
to the very edge of the gob, so you can see where you draw.


The box is generated in the same draw block, by simply inserting 
a red box in the beginning, if the debug flag is enabled.

Having this box, helped us solved numerous layout bugs.

Yes, but why not insert it at the tail then? Because, when not seen, 
it does not work for you, no? What about styles, which do utilise 
the whole gob size?

Read the first line in my response for your first question. :-)

Anyway - I was surprised by addition of debug modes. It will greatly 
improve situation over R2 VID.

... when you debug, you don't want to see your lines that are supposed 
to be there :-)

The second question: Some styles will occupy the entire gob size, 
yes. That's no problem. The red box is mainly there to display where 
the border is on the gob. Nothing else. I had great trouble aligning 
styles without it.

your site's down ....

Pekr, correct.

I see, perhaps it's one of the mysterious Cheyenne crashes.

BrianH: As I understand UCS-2 cannot be used to encode characters 
outside the BMP. It is a full subset of UTF-16. It should not cause 
problems with WIndows Unicode API except that it would not be able 
to display characters outside the BMP. (It would instead include 
 an non-displayable character for each 2-bytes returned by Windows.)

The problem would come from the Windows API returning characters 
that can't be handled which would appear to REBOL as 2 non-displayable 
characters, or REBOL code inserting characters inbetween double characters 
by accident, or copy grabbing partial characters.

Henrik - re your new screenshots - calculator - what is the reason 
grouped buttons of math operations are not precisely aligned vertically 
(at the bottom) as the num pad? Is it a bug in layout, or is it like 
it should be?

e.g. numbers 68, 69 ....

Pekr, illustrations for Carl to use for fixing those alignment bugs.

Henrik - is the gradient type/structure the same for the above mentioned 
calculator buttons and for the normal buttons in another screenshots? 
That calculator one looks good. But maybe it is because of white 
text color ....

The button style is called MINI-BUTTON and is derived from BUTTON. 
It's meant to be used in groups and confined spaces. It took about 
5 minutes to write. The font is custom for this application.

BrianH, can you talk about the set [a: b:] issue and what it means 
for us?

Brian: same as there is a conversion between the Linux UTF-8 APIs 
and the internal 16 bit array, there is a conversion between the 
Windows UTF-16 APIs and the internal 16 bit array. In the same way, 
we can eventually support 32 bit arrays and convert those UTF-16 
strings that can fit into it to just 8 bit arrays.

Gabriele, cool, I was just concerned about speed. I suppose calls 
to external APIs are likely to be less frequent than internal manipulations, 
and UCS encoding would make the internal code faster. Either way 
I'm sure that it will be handled :)

The SET [a: b:] issue:


In current REBOL a block argument to SET for the word parameter needs 
to be filled with values of the word! type, not any other word types. 
This is in contrast with just passing a single word value, which 
can be of any word type. The result of this is that values in word 
block argument need to be converted to word! before being passed 
as a parameter.


There is no reason that those words need to be of the word! type, 
particularly since the block isn't evaluated. One interesting thing 
about REBOL is that a word! bound to a context will refer to the 
same value as words of the other word types with the same spelling 
otherwise. This means that if you set a lit-word! to a value, you 
can get the same value from the corresponding word! or get-word!.


Now, the current behavior has some bad consequences as well, usage 
issues. Some word block arguments had to be preprocessed. The big 
problem we ran into was when we wanted to use SET inside of functions 
created with the new FUNCT function (temporary name).


FUNCT collects set-words from the code block and nested blocks and 
adds them to the function's locals. This is cool and works a lot 
better than I thought it would, and all action handlers of the new 
GUI are turned into functions with FUNCT. The problem we ran into 
is that when we had to use block SET to set local variables, those 
local variables would leak into an outer scope, wreaking havoc. If 
you are specifying the function spec directly there is an easy workaround 
for that: Just specify the locals that aren't caught with your own 
/local vars. However, you can't specify the function spec of an action 
handler in the dialect, just the code blocks (security/stability). 
This meant that if you wanted locals to be captured, you had to set 
them to none earlier in the function. How soon do you expect that 
to fail?


An easy solution to this would be to specify the words you want local 
as set-word! values in the literal word block argument to the SET. 
Those set-words would then be caught by FUNCT without any overhead. 
No problem, except for that SET doesn't allow it right now.


This is what we are going to fix in the next build: You will be able 
to do SET [a: b:] value.

In some circumstances like with FUNCT above, you will likely *have 
to* do SET [a: b:] value. This is where we get to the implications, 
what it means for us: We are making changes to the core, sometimes 
subtle changes with big implications. These changes are coming as 
a result of the work on the new GUI. Some of them are bug fixes, 
some of them are new functions or other enhancements, some are fixes 
to design flaws in the language expressed in functions we have already. 
They will affect the code you write even if you aren't doing GUI 
code. Every change like this is going to make R3 a cleaner, easier 
and more powerful language than R2, even with the backports. Something 
to look forward to :)

There are going to be more of these fixes in the next build. Stay 
tuned for more treats :)