AltME groups: search

SWITCH and CASE not only simplify the source code, but they also 
significantly reduce the emitted code size.

After looking at the diff-ed code, I think that replacing all the 
assignment in IFs bodies, by a single one before the SWITCHs is what 
produced the code size gain.

# rebol -qw red.r %red/tests/hello.red

-= Red Compiler =- 
Compiling red/tests/hello.red ...

...compilation time: 	 30 ms

Compiling to native code... 

...compilation time: 	 1282 ms
...linking time: 	 	 25 ms
...output file size: 	 	30912 bytes

# ./hello
42

Nick: thank you very much, I appreciate such help and "continue to 
work without interruption" is really all I desire. I'm afraid anyway 
that donation would not be enough with the current community size, 
so I will probably start searching for other ways of funding by the 
end of the year.

Note that you need to get the system page size with sysconf():

I've been very busy since yesterday on a new tool for Red: I've built 
a proper REBOL code profiler! (I wonder why I haven't done that since 
a long time...). I went through the profiler scripts on rebol.org 
and couldn't one suitable for my needs or that works with complex 
code, so I wrote one. It is able to deal with complex code, all datatypes, 
recursive calls and it's very simple to use.


Here's a demo profiling Red compiler (output is properly aligned 
when monospace font is used):

-= Red Compiler =-
Compiling red/tests/test.red ...

...compilation time:     40 ms

Compiling to native code...

...compilation time:     10189 ms
...linking time:         60 ms
...output file size:     37888 bytes
>> profiler/report/time


Function                       Count      Elapsed Time         % 
of ET

------------------------------------------------------------------------

compile                        1          0:00:10.249          100.0

comp-dialect                   205        0:00:09.659          94.24

fetch-expression               7505       0:00:09.628          93.94

comp-word                      5668       0:00:08.209          80.09

fetch-into                     427        0:00:07.519          73.36

comp-assignment                597        0:00:07.049          68.77

run                            3          0:00:06.492          63.34

comp-context                   21         0:00:06.398          62.42

comp-with                      1          0:00:05.565          54.29

comp-expression                3172       0:00:04.479          43.70

ns-find-with                   24277      0:00:03.962          38.65

finalize                       1          0:00:03.327          32.46

comp-natives                   1          0:00:03.274          31.94

comp-func-body                 180        0:00:03.271          31.91

comp-call                      2775       0:00:02.732          26.65

comp-func-args                 2861       0:00:01.862          18.16

find-aliased                   9650       0:00:01.86           18.14

resolve-type                   8032       0:00:01.799          17.55

get-type                       10758      0:00:01.546          15.08

ns-prefix                      21765      0:00:01.518          14.81

check-enum-symbol              7509       0:00:01.241          12.10

comp-block                     283        0:00:01.05           10.24

comp-variable-assign           417        0:00:01.034          10.08

Arnold - that's the old altme url bug. In order to be able to read 
such lines, just change the size of text for a while (aA button above 
the text field)

Pekr: your remark about the stack made me think about it. I might 
change a bit the current internal API, collecting arguments from 
stack in trampoline functions (actions.reds) instead, and then calling 
datatypes-specific actions passing them the arguments directly. This 
would reduce the runtime code size a little bit and might simplify 
the construction of the future public API. I need to see first if 
they are drawbacks before deciding to refactor the code in that way.

When I put one of the cURL callbacks behind the function that uses 
it, the code size increases by four bytes, even for Intel. But when 
I then remove the [cdecl] it goes back to the original size

The executable file size is 59904 Bytes, quite big :-)

Also, currently ARM binaries are about twice larger than for IA-32. 
It has several causes, costly 32-bit literal handling in ARM, 32-bit 
fixed size instructions,.... We'll deal with these issues mainly 
during the rewrite process of Red and Red/System. Possible solutions 
are:


- good literal pool allocator (there's an optional one currently 
in ARM backend, but not good enough for big apps).

- code optimizations that will reduce the number of 32-bit literals, 
like good registers allocation.
- support for Thumb instruction set.

Having just each 

hello world" app to take 60KB etc. is a bit too much ...." You're 
not having the right metrics in mind. What matters is not the size 
of a "Hello World" app, but size of a real app. A typical real app, 
like with REBOL + /Encap, will be just a few dozens KB bigger than 
the runtime library. So, most Red apps will be less than 500KB and 
still less than 1MB for really big ones (not counting additional 
resources data). A "Hello World" using Appcelerator (one of the leader 
in Android dev tools market) is around 600KB. Also have a look at 
the size of apps installed on your Android devices, most of them 
are bigger than the typical apps size Red will produce.


If you want to compare with app size that Java can produce, take 
Red/System in order to compare apples to apples. Anyway, Java apps 
are cheated, because the JVM is built in Android. I don't remember 
seeing any way to install a shared library across different apps 
on Android, but maybe there's a way?

The efficiency of Red will mainly come from the optimizations we'll 
add to the compiler that will "unbox" some expressions and bypass 
the runtime library. Anyway, we'll also improve performances and 
reduce size of runtime library as much as possible, but you shouldn't 
expect the biggest gain from there.

Run-All    v0.8.2
Quick-Test v0.9.1
REBOL       2.7.8.4.2
Red/System Test Suite

ok - logic.............................81 / 81
ok - byte..............................40 / 40
ok - c-string..........................20 / 20
ok - struct...........................116 / 116
ok - pointer...........................69 / 69
ok - cast..............................88 / 88
ok - alias.............................23 / 23
ok - length............................11 / 11
ok - null..............................11 / 11
ok - enum..............................19 / 19
ok - float.............................60 / 60
ok - float32...........................55 / 55
ok - lib...............................13 / 13
ok - get-pointer........................5 / 5
ok - float-pointer.....................61 / 61
ok - namespace........................109 / 109
ok - not...............................44 / 44
ok - size..............................37 / 37
ok - function...........................6 / 6
ok - case..............................64 / 64
ok - switch............................85 / 85
ok - exit...............................9 / 9
ok - return............................25 / 25
ok - modulo............................29 / 29
ok - math-mixed.......................114 / 114
ok - infix..............................2 / 2
ok - conditional.......................13 / 13
ok - common............................16 / 16
ok - byte-auto.......................3636 / 3636
ok - integer-auto....................2778 / 2778
ok - maths-auto......................1661 / 1661
ok - float-auto......................1617 / 1617
ok - float32-auto....................1023 / 1023
ok - alias-compile......................3 / 3
ok - cast-compile......................16 / 16
ok - comp-err...........................2 / 2
ok - exit-err...........................3 / 3
ok - int-literals-err...................1 / 1
ok - output.............................3 / 3
ok - return-err.........................5 / 5
ok - conditions-required-err...........23 / 23
ok - inference-err......................1 / 1
ok - callback-err.......................2 / 2
ok - infix-compile......................3 / 3
ok - not-compile........................1 / 1
ok - print..............................3 / 3
ok - enumerations compile..............12 / 12
ok - pointer-compile....................2 / 2
ok - namespace compiler tests...........5 / 5

ok - Red/System Test Suite..........12031 / 12031
       in 0:00:42.94891

Changed how? Size or content?

Content, I suppose. Probably not size, as Windows works with pages. 
I checked them in, so they can be retested

Jerry, remember that variables are, semantically, just labels to 
variable-size containers in Red/System. The memory model is similar 
to C's one, so totally different from Red or REBOL.

Jerry: here is a quick overview:


Red values are stored contiguously in series slots (128-bit cells). 
Series buffers are allocated from large chunks of memory of type 
series-frame!. Series value in slots store just a head offset and 
a pointer to a node!. The node! is another pointer to the series 
buffer. So series buffer are indirectly accessed, allowing them to 
be moved in memory (for reallocating with bigger/smaller size or 
moved by GC).

A series buffer has header, with OFFSET and TAIL pointers that define 
respectively the begin and end of series slots. The OFFSET pointer 
allow to reserve space at head of the series for optimizing insertions 
at head. Series slots size can be 1 (binary/UTF-8/Latin-1), 2 (UCS-2), 
4 (UCS-4) or 16 (value!) bytes wide.

If you had an ability to create an opaque value of any size that 
will fit in a value slot, or maybe just limited to pointer size, 
only accessible from Red/system code, that would be a good replacement 
for handle!.

A couple of observations: I would think that the slow going with 
View had a lot to do with the size of the community as well as an 
architecture that didn't easily permit the use of vector graphics, 
preferably designed using external tools, for drawing widget states. 


WRT Red, it makes sense to use native controls in order to get off 
the ground quickly, but the UI subsystem should allow for owner drawn 
controls. By allow for, I mean that these should be able to exist 
side-by-side with native controls, and, if defined using a vector 
source, widgets should do bitmap caching at the appropriate times 
for better performance. I guess what I'm saying is to please think 
about how owner drawn widgets would fit into whatever is the initial 
implementation.

I have found an issue with word! value casing in Red. The Red/System 
code generated for:
	print 'a = 'A
is:
          stack/mark-native ~print
          stack/mark-native ~strict-equal?
	word/push ~a
          word/push ~A
          natives/strict-equal?*
          stack/unwind
          natives/print*
          stack/unwind


The problem is that Red/System is case-insensitive, so ~a and ~A 
are the same variable. So, no way to make it work like that. I see 
two options for solving it:

1) Make Red/System case-sensitive.

2) Deep encode each Red generated symbol to distinguish lower and 
uppercases.


Solution 2) works, but it makes symbol decoration operation very 
costly (each symbol letter is prefixed with a sigil for lowercases 
and another one for uppercases). The example above becomes:

          stack/mark-native ~_p_r_i_n_t
          stack/mark-native ~_s_t_r_i_c_t_-_e_q_u_a_l_?
          word/push ~_a
          word/push ~-A
          natives/strict-equal?*
          stack/unwind
          natives/print*
          stack/unwind


So, it is not nice, it doubles every Red symbol size that is handled 
by Red/System and slows down Red compilation by 25%.

So, my questions are:
a) Does anyone see another cheaper solution to this problem?

b) In case of option 1), do you have anything against making Red/System 
identifiers case-sensitive?

Do you know how REBOL handles it? I prefer case-insensitive in general, 
but doubling the size of identifiers seems bad, even if hidden from 
us for the most part.

It shouldn't have any effect on the generated code size. Can you 
send me the function?

Then, that's normal, the added size is for dynamically creating the 
extra literals you've added to the spec block. Remember that the 
source code of your function is built-in the final binary, so you 
can use reflection and soon, rebuid the function dynamically at runtime.

Well good thing is that I have access to good size lab at work.

World's value slot size is 256 bits, which only makes sense for big 
data, not for mobile platforms like iOS. Its semantic model is basically 
that of R3 (plus all of the changes that he had requested R3 make 
that were rejected), and that semantic model is not really compatible 
with the iOS App Store review process. So I'm not surprised to see 
him not use World for iOS - its target market is completely different.

I suggest to change the relaive part of "Readme.md" to:

Running the Red/System hello script
------------------------

1. From the REBOL console type:

    `call/show ""` ; (type this only once to fix Rebol 2 bug)

    `change-dir %red-system/`

2. Type: 

    `do/args %rsc.r "%tests/hello.reds"`
	

    the compilation process should finish with a `...output file size` 
    message.


3. The resulting binary is in `red-system/builds/`, go try it! type 
(on Windows):

    `call/wait/shell/console %builds/hello.exe`

Given the block size limit, I used a block with 60K elements in it:

b: append/dup copy [] [1 b #c "d"] 15000

; JS-like MAP. The order of args to the function is a bit odd, but 
is set

; up that way because we always want at least the value (if your 
func takes

; only one arg), the next most useful arg is the index, as you may 
display

; progress, and the series is there to give you complete control 
and match

; how JS does it. Now, should the series value be passed as the head 
of the
; series, or the current index, using AT?
map-js: func [

 "Evaluates a function for each value(s) in a series and returns the 
 results."
	series [series!]

 fn [function!] "Function to perform on each value; called with value, 
 index, and series args"
	/only "Insert block types as single values"
	/skip "Treat the series as fixed size records"
		size [integer!]
][
	collect [

  repeat i length? series [   ; use FORSKIP if we want to support /SKIP.
			keep/only fn series/:i :i :series ; :size ?
		]
	]
]
;res: map-js [1 2 3 a b c #d #e #f] :form
;res: map-js [1 2 3 a b c #d #e #f] func [v i] [reduce [i v]]
;res: map-js [1 2 3 a b c #d #e #f] func [v i s] [reduce [i v s]]
;res: map-js "Hello World!" func [v i s] [pick s i]

It would be best to do the conversions on the fly, that is why I 
want to wait for I/O get done to implement such conversion routines. 


Anyway, for doing it now, you need to allocate a new string, the 
best way to do it is:

    str: as red-string! stack/push*
    str/header: TYPE_STRING
    str/head: 0
    str/node:  alloc-bytes size


The new string! value will be put on stack, so any other call to 
a Red internal native or action might destroy it. Also, keep in mind 
that the GC is not there yet, so intensive I/O might quickly eat 
up all your RAM.

Oh, you meant a c-string!, not a string!, so it's even easier, just 
use: alloc-bytes size

My first impressions on your proposition:


1) arr[i] is a useless syntactic addition as we already have indexed 
accesses: arr/i


2) #7 and #8 are going way too far from the Red/System application 
domain, it's basically  a series abstraction. Red internal API already 
provides series (the internal API is not yet completed nor formalized 
though), so this is both unneeded and overlapping with Red standard 
library.


What you might not realize is that you already have array-like capabilities 
with Red/System pointers (including structs and c-strings). If you 
want automatic memory management in Red/System, you won't have it, 
low-level programming requires a manual management of memory for 
accuracy and avoiding unnecessary burdens.


The only array-like part that Red/System is really missing right 
now is the literal array-like declarations, which can be achieved 
without a new formal array! type. As I said earlier, adding a array! 
type would only add bound-checking abilities (which is a nice feature 
to have) and provide you with #5 as a side-effect (not very useful 
anyway, as array would be fixed-size).

>> do/args %rsc.r "%bridges/java/JNIdemo.reds -o %bridges/java/JNIdemo"

-= Red/System Compiler =-
Compiling bridges/java/JNIdemo.reds ...

...compilation time:     114 ms
...linking time:         4 ms
...output file size:     6656 bytes
...output file name:     bridges/java/JNIdemo.exe

Hi Doc, I was messing around with the PE.

Added section: [.rsrc  [-   #{00000000000000000004000000000000}]] 
in compiler (this should be just empty .rsrc, and trying to build 
it in PE.r using:

oh/rsrc-addr:			section-addr? job '.rsrc
oh/rsrc-size:			length? job/sections/.rsrc/2


but the address is pointing into wrong position (512B less). You 
probably don't know without some deeper examination, what may be 
the reason, do you?

Btw. there should be:
    .rsrc				#{40000040}	;-- [read initialized]

at this line: https://github.com/dockimbel/Red/blob/master/red-system/formats/PE.r#L119
(the section name starts with a dot).

So far adding the rswr section modifies these values:   [ entry-point-addr 
code-base data-base ] which should be same as without rsrc in my 
tests, and not increasing init-data-size.

Line 369: it's for getting the memory pointer for last section, but 
it seems it's lacking an offset for skipping that last section size.

Ok, so the main problem will be, that oh/headers-size = 1024, but 
the pointer to code as a first section is 512. Now I must find why.

I've reduced the size of the package, now hello.apk weights just 
153KB.

Thanks for the compliment Doc, not really sure what you mean exactly 
by making it more like Red/System and less C: use more descriptive 
names? I will take a closer look at some ed/System examples out there.

Thanks Kaj for finding those and for the tips, the size of MM makes 
it the same in effect in this case, but it has to be <= then. Program 
not crashing, I was lucky then! off-by-one errors? My index goes 
from 1 up, where in C it is from 0 up, I had to debug this to make 
sure elements were swapped in the same way as in the original program. 
That is also why I declare KKP and LLP to as to save from adding 
1 to KK and LL over and over again. 


Knuth's algorythm was the first one I found, and I knew already of 
its existence, so it made sense to use what you have. Sure my Red/System 
code is not optimised.


Going to work on it now and tomorrow, and later I take on the Twister. 
It is a good exercise!

That change alone should make a significant difference in speed (I 
expected it close to twice faster) and code size compared to the 
current approach.

One bug need to mention:

After doing mod operation, I use the result as index to access the 
array,it's OK in C, but will cause strange behavior in Red/System. 
Because mod will produce 0 and Red/System use 1-base array.
n: c + state-half-size % state-size
Then I modified the code as below to solve this issue:
n: c - 1 + state-half-size % state-size + 1

Now in Red/System, we can't pass a function as parameter to Red/System 
FUNC,
but we can pass it to external C FUNC, right?


cmp-func!: alias function! [left [byte-ptr!] rihgt [byte-ptr!] return: 
[integer!]] 
quick-sort: func [
	base	 [byte-ptr!]
	n		 [integer!]
	size	 [integer!]
	cmp-func [cmp-func!]	
][
	; can't use cmp-func in this function
]

Added a parameter to make read-file-binary return the file size

And or adding lines where you print information to the console

print [" before call to read-file-binary, size of size1: " size1 
lf]

So you're pointing img3 to a semi-random memory area that happens 
to have an address equal to the size of the first image. That will 
crash the first time you try to access the image

The calculation is okay.

Code:

Red/System []

red: as byte! 240
green: as byte! 120
blue: as byte!  60


greyscale: ((as integer! red) / 3) + (as integer! green) + (as integer! 
blue)

print [greyscale lf]

OUTPUT:
-= Red/System Compiler =- 
Compiling /Users/peter/VMShare/Code/Red-System/test.reds ...
Script: "Red/System IA-32 code emitter" (none)
Script: "Red/System Mach-O format emitter" (none)

...compilation time:     122 ms
...linking time:         10 ms
...output file size:     16384 bytes
...output file name:     builds/test
260

Oops, here's the proper code and correct answer:

Red/System []

red: as byte! 240
green: as byte! 120
blue: as byte!  60


greyscale: ((as integer! red) / 3) + ((as integer! green) / 3) + 
((as integer! blue) / 3)

print [greyscale lf]

OUTPUT
...compilation time:     133 ms
...linking time:         13 ms
...output file size:     16384 bytes
...output file name:     builds/test
140

My Red/System script (through some technical wizardry) can now process 
10 seconds of video from an HD source at 30fps and isolate motion 
areas of a particular size in a fraction of a second on a 700MHz 
Raspberry Pi.

In the above example, dirs.txt is a text file of size 524 bytes.

My motion detection executable on the Pi is 30KB.  The same executable 
compiled for Windows is 15KB (50% the size).

Yes, the ARM instruction set is optimised for speed at the expense 
of size

My motion detection executable on the Pi is 30KB.  The same executable 
compiled for Windows is 15KB (50% the size).


Red currently emits only the standard ARM opcodes, so 32-bit per 
instruction. We'll add support in the future for Thumb mode (more 
compact instruction set). In the meantime, you can try to activate 
the literal pools by adding the following option to the Linux-ARM 
config block (in %config.r):

literal-pool?:	 yes


That should both reduce final binary size and give you a little speed 
improvement. But be sure to test is well as this mode has not been 
much used yet. Also, it might fail to compile if you use very big 
functions, or a lot of code in global context.

Bo, your make-c-string leaks memory. read-file will allocate memory 
of the size to fit the file contents

Kaj, you said that 'read-file in Red/System automatically defines 
a large enough memory space for the file.  How about 'read-file-binary? 
 That one has a 'size parameter.  How can one determine how big to 
make that 'size parameter before reading the file?

You don't make it any size. It works the same as read-file and the 
READ function in REBOL: it allocates the storage for you

In the case of read-string you get a c-string!, so you can get the 
size with LENGTH?. For read-file-binary that's not possible, so you 
pass a pointer to an integer! to be informed about the read size

gets() requires you to allocate a buffer of adequate size. Empty 
c-string! literals ("") will statically allocate an empty string, 
unsuitable for use with gets(), resulting in buffer overflows ('boo 
is allocated just after 'foo). Try rather: 

foo:  allocate 100
boo: allocate 100


This will dynamically allocate 100 bytes for each c-string!. You 
need to ensure that gets() won't overflow those buffers (which in 
practice is impossible, so one should just avoid using gets() in 
production code).

Red/System: Could it be that if you 
#define MAX-SIZE 100
my-array: as int-ptr! allocate MAX-SIZE * size? integer!
then using  
my-array/MAX-SIZE 
gives a compilation error??
*** Compilation Error: undefined pointer index variable

My 6502 emulator in Red/System now takes the name of a ROM file as 
a command line parameter. It can load any ROM that's a multiple of 
2 KB in size:

New Android release:

URL		: http://development.saphirion.com/experimental/

Direct URL	: http://development.saphirion.com/experimental/r3-droid.apk

Changes:
-added DH and AES 128/256 encryption
-rewritten console syncing code
-TLS scheme improvements
-fixed runtime stack size issue
-fixed FP math using dtoa()  (thanks to Ladislav!)
-fixed shared lib unloading issue
-fixed "exit on script error" bug
-minor app handling tweaks

Please give it a try and have fun.

In addition to these added programs, the existing interpreters and 
other programs have been rebuilt with the latest Red enhancements, 
including the doubled maximum size for series.


These new Red interpreters are candidates to be used in filming and 
streaming the presentations on the DevCon in Montreal.

In conjunction we did a new R3-GUI release as well.


added DETAB flag support
fixed TEXT-AREA issues
fixed TEXT init-size handling
fixed SIZE-TXT bug
built new R3GUI release (version 4897)
delete "experimental" layout-sizing-independent.r3
improve rouding
move docs/r3-gui/ to documentation/r3/r3-gui/

remove documentation/r3/r3-gui/license/ directory containing obsolete 
license
Copyright notice update
license update
typo fixed
Rounding correction
improved rotate event handling

improved drag handling code (removed duplicate gui-events/drag reference)
improved android text input handling
fixed progress resizing
improved text-able cell font handling
fonts are antialiased by default on android now

http://development.saphirion.com/resources/r3-gui.r

@Rebolek Thanks, that wil be on the list together with line width 
and color and font-size preferences, a multilingual help function 
and a resize mechanism. ((:

Android binary is twice the size of Linux one because ARMv5 architecture 
is bad at dealing with 32-bit literal values, so it takes much more 
space than for IA-32.

Even with my experimental literal pools allocator, it decreases the 
final size by 10KB only.

BTW, wrt to ARM big size binaries, it's also caused by ARM using 
32-bit words for every instruction, while IA-32 has still a lot of 
8 or 16-bit ones. For example, there's a lot of PUSH 0 instructions 
emitted for the datatype registration block (the unimplemented action 
pointers), that's 16bit on IA-32 and 32-bit on ARM.

:) It's hard to get the best wording. When I read "the iPhone default 
compression is 85%", I would expect the JPEG file to be 85% the size 
of the uncompressed TIFF file. This is not the case. An uncompressed 
TIFF file from GCam is 23.9 MB, a JPEG is 10x smaller at around 2 
MB. The quality is 85% meaning you loose 15% information, if you 
save as JPEG and not TIFF.


I went with "The JPEG format is compressed at 85% quality setting, 
as is customary on the iPhone."

Thanks again, guys.

I meant system. exec didn't work. I still prefer system above passthru. 
I have integrated my first REBOL module within my website. I needed 
to add a cookie section to obey the new cookie law anyway. I even 
used a REBOL script to generate all cookie pictures to the same size 
and png format.

The biggest overhead there comes from not preallocating the output 
block, so there's some reallocation. I don't know how to estimate 
the size of the output though.

Endo: you should rather bench on one long series rather than 1M times 
on a small one in order to avoid function calls overhead and get 
a more fair comparison. When I try with a 1M size string with random 
a,b,c chars, my parse solution is twice faster than the mezz one 
(Brian's one is crashing so can't test it). I was expecting a greater 
difference though.

providing an optional output buffer  (which the user can pre-allocate 
to some ideal size)  would make a VERY big difference on large inputs.


usually, when it goes into the hundreds of thousands, repetitive 
series re-allocation on growing mutable series,  will kill any kind 
of optimisation you can dream of. 


rle: func [s [series!]   /into out  [block!]  /local out emit pos1 
pos2 cont][
	out: any [ out     make block! 2 ]
 ...
]


this is especially effective on repetitive calls to the above function 
and using clear on the given buffer so that it auto-grows to an optimal 
size and is fast on later calls.


just today, I was doing some encryption benchmarking and when I hit 
strings larger than 1MB it was taking several minutes... thats until 
I realized that it was my dataset generator (a looped string insert) 
which was taking 98% of the cpu time.  !

Unless you make it so it treats integers specially. This would slow 
down the encoder and decoder, but reduce the compressed size.

You could reduce the compressed size of a string-specific RLE by 
putting runs of singletons into strings, like this:
>> rle "Hello World!"
== ["He" 2 #"l" "o World!"]

it's also possible to simply add a pane of faces that construct the 
text in the necessary parts. with SIZE-TEXT you can then calculate 
the necessary size of each part and write a little routine to lay 
it out. it's a bit of work, though.

Henrik, my initial idea was that it should be possible to make such 
a text/label facet where the text and markup are stored in array/blocks. 
The markup could just be a referral to a markup defined elsewhere. 
Not that I am afraid of a little work but right now I think I can 
manage what I want using just a new textcolor ;)


I named my Text+ field piep and calculated size-text piep to be 0x15. 
Doesn't look correct. Also "word' url" should be "word 'url" in render-rich-text 
/local declaration?

I usually use a test face first for SIZE-TEXT. It's important that 
the test face has the dimensions to at least contain the text, as 
you want it formatted. When you then use that face as an argument 
to SIZE-TEXT, it returns the face size. That face size can then be 
used to set the size of the real text face.

loaded all i686 extensions to the 64bit instance
now get:

$ ./rebol -v
** User error: Bad face in screen pane!
** Near size text self

I don't rememeber who did the neon effect, but here it is.

font-C: make face/font [style: [ bold ] size: 64]
neon: "REBOL BAR"
coord: 30x15
inc: 0.25.25
draw-block: compose [
	line-join round font font-c

 pen (inc * 1 + 255.0.0.230) line-width 11 text vectorial coord neon

 pen (inc * 2 + 255.0.0.205) line-width 9 text vectorial coord neon

 pen (inc * 3 + 255.0.0.180) line-width 8 text vectorial coord neon

 pen (inc * 4 + 255.0.0.155) line-width 7 text vectorial coord neon

 pen (inc * 5 + 255.0.0.130) line-width 6 text vectorial coord neon

 pen (inc * 6 + 255.0.0.105) line-width 5 text vectorial coord neon

 pen (inc * 7 + 255.0.0.80) line-width 4 text vectorial coord neon

 pen (inc * 8 + 255.0.0.55) line-width 3 text vectorial coord neon

 pen (inc * 9 + 255.0.0.30) line-width 2 text vectorial coord neon

 pen (inc * 10 + 255.0.0.5) line-width 1 text vectorial coord neon
]

view/title layout [ box black 450x200 effect [ draw draw-block ] 
] "NEON"

I was wrong. Simple programs like (print "Hello World") compile and 
execute, but programs with a lot of code compile but produce a series 
of errors when executed. I noticed a pattern. Wherever a word is 
not followed by ':' causes errors, examples below. Perhaps it's just 
this linux version of enface?

    stylize [
        fld80: field 80x28 font-size 17 white ivory center
        .......
    ]

produces the error:

    ** Script Error: stylize has no value
    ** Near: new-styles: stylize [
        fld80: field 80x28 font-size 17 white ivory center 
        fld400: field 400x28 font-size 17 whit...

I'll try this on windows when I have the opportunity.

a quick update on elasticsearch.

Currently I have reached 2TB datasize (~85M documents) on a single 
node.

Queries now starting to slow down but the system is very stable even 
under

heavy load. While queries in average took between 50-250ms against 
a 

dataset around 1TB the same queries are now in a range between 900-1500 
ms.

The average allocated java heap is around 9GB which is nearly 100% 
of the
max heap size by a 15 shards and 0 replicas setting.

elasticsearch looks like a very good candidate for handling big data 
with 

a need for 'near realtime' analysis. Classical RDBMS like mysql and 
postgresql

where grilled at around 150-500GB. Another tested candidate was MongoDB

which was great too but since it stores all metadata and fields uncompressed

the waste of diskspace was ridiculous high. Furthermore query execution 
times 
differs unexpectable without any known reason by factor 3.

Tokyo Cabinet started fine but around 1TB I have noticed file integrity 
problems

which leads into endless restoring/repairing procedures. Adding sharding 
logic

by coding an additional layer wasn't very motivating but could solve 
this issue.

Within the next six months the datasize should reached the 100TB 
mark. 

Would be interesting to see how elasticsearch will scale and how 
many
nodes are nessesary to handle this efficiently.

when you create the disk, there's an option to pre-allocate it - 
I chose that (the size had was a 1 GB disk). Not sure if that would 
make a difference as to how small it would compress

same size with the disk not pre-allocated

Andreas, what size HD did you have for the VM you had?

Andreas, thanks for the Windows build changes. Works fine here with 
VS2012 installed. Question re. size - the exe seems about twice as 
big as the r3.exe before open sourcing - is the debug version being 
built by default?

For me Altme is almost unusable if not used on Windows. I miss a 
way how to customize it. Just 2 font size versions and hardcoded 
font is a big problem.

JPG support in R3 would be amazing, even though I know it would bloat 
the size of the executable by a significant amount.  Maybe it could 
be available as a plug-in so if you don't need JPG support, you don't 
have to sacrifice the space.

>> write http://www.rebol.com/index.html[ HEAD ]
make object! [
    name: none
    size: none
    date: none
    type: 'file
    response-line: "HTTP/1.1 200 OK"
    response-parsed: none
    headers: make object! [
        Content-Length: "7407"
        Transfer-Encoding: none
        Last-Modified: "Sat, 15 Dec 2012 07:02:21 GMT"
        Date: "Wed, 09 Jan 2013 09:24:53 GMT"
        Server: "Apache"
        Accept-Ranges: "bytes"
        Content-Type: "text/html"
        Via: "1.1 BC5-ACLD"
        Connection: "close"
    ]
]

Is this the best way to perform this check in http://www.rebol.com/r3/demo.r:

errout case [

 not value? 'size-text ["This R3 release does not provide a graphics 
 system."] ; this one
	load-gui <> 0.2.1 ["Wrong GUI version for this test script."]
	true [none]
]

what exactly does mode do?

)
>> query/mode %tiger.png none
== make object! [
    name: %/E/r3gui/tiger.png
    size: 6515
    date: 26-Apr-2009/9:12:54+13:00
    type: 'file
]

>> query %tiger.png
== make object! [
    name: %/E/r3gui/tiger.png
    size: 6515
    date: 26-Apr-2009/9:12:54+13:00
    type: 'file
]

>> query/mode %tiger.png 'size
== make object! [
    name: %/E/r3gui/tiger.png
    size: 6515
    date: 26-Apr-2009/9:12:54+13:00
    type: 'file
]

buffer size here https://github.com/gchiu/Rebol3/blob/master/protocols/prot-smtp.r#L66

wonder if reducing the buffer size in r3/droid might help?

Reducing the buffer size causes breaks at each boundary.  Increasing 
it seems to fix the problem for my attachments less than 64k,

so if it fits inside the buffer size it's ok?

Yes.  If it fits inside the buffer size, it works perfectly.  Tested 
and verified.  It may be fixed in the latest build, but I don't have 
the latest ARM Linux build, and won't have time to build it until 
tomorrow at the earliest.

Hello everybody,  after some months using R3GUI I still doesn't realize 
the causes of the changing syntax from Rebol 2 VID.

My impression is that all become very complicated.  Now to decide 
every action you have to put "on-action" or something similar before 
the action block, before it wasn't needed; but the worst part that 
all is inside the gob object of the graphical object. This way you 
have to write very long commands to achieve the most simple tasks 
(show mybuttob/gob ... mybutton/gob/size). Is it just my impression?
Is there any simpler dialect?

Another interesting thing I noticed:

    facets: [
        init-size: 28x28
        bg-color: 80.100.120
        border-color: 0.0.0.128

        pen-color: ; set by on-draw
        area-fill: ; set by on-draw
        material: 'chrome
        focus-color: guie/colors/focus
        draw-mode: 'normal
        materials: none
        face-width: none
    ]


Normally, in regular Rebol code, 'pen-color and 'area-fill, would 
be set to 'chrome, if I would use it to construct an object. But 
maybe it is just a spec block, so I should not care? I mean - what 
about setting them initially to 'none too, for a convenience? :-)

MaxV: "This way you have to write very long commands to achieve the 
most simple tasks (show mybuttob/gob ... mybutton/gob/size). Is it 
just my impression?"


My guess is you are not using R3GUI correctly. If you are using the 
current included R3GUI styles you shouldn't be forced to write any 
SHOW commands at all(the SHOW command is considered 'internal' in 
R3GUI and shouldn't be used anyway). Just use the SET-FACE/GET-FACE 
api to make changes to the specific style.

In worst case (usually when some ON-GET/ON-SET handler is unfinished/incomplete 
in some style) you can either try to enhance/fix that style part 
or

if this is too difficult for you you can try to use SHOW-NOW <face> 
to really force 'show' on the specific element.

I think the first thing to look at is the structu sizes. Either press 
it back to fit 32bit size, or expand it into 64bit space. Not sure 
what kind of side-effect this will have.