AltME groups: search

Size depends on what modules you want to include, but I estimate 
it would usually amount to a few MB

One could also just use the drawing library, which then seems to 
be about double the size of Cairo for example, but is much more intelligent

In case, you wonder why Red needs both UTF formats, well, it's simple, 
 Windows and UNIX worlds use different encodings, so we need to support 
both. Red will use by default UTF-8 for string values, but on Windows 
platform, it will convert the string to UTF-16 on first call to an 
OS API, and will keep that encoding later on (and avoid the overhead 
of converting it each time). 


We might want to make the UTF-16 related code platform-depend and 
not include it for other platforms, but I think that some text processing 
algorithms might benefit from a fixed-size encoding, so for now, 
I'm for including both encoding for all targets.


It will be also possible for users to check and change the encoding 
of a Red string! value at runtime.

Keep in mind that even UTF-16 is not a fixed-size encoding. Each 
codepoint either takes 2 or 4 bytes.

UTF-32 (aka UCS4) is a fixed-size encoding. It's rarely used though.

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.

Normally I do not announce my upload to rebol.org but this time is 
different. I have uploaded an upgraded version of  my interface to 
opengl: http://www.rebol.org/view-script.r?script=opengl-glu-glut-h.r
and I am asking you to insert "GLX_DOUBLEBUFFER" in the block of 
the line: "attrList-def: reduce [GLX_USE_GL GLX_RGBA  GLX_DEPTH_SIZE 
16 GLX_RED_SIZE 4 GLX_GREEN_SIZE 4 GLX_BLUE_SIZE 4 0]"  to see if 
doublebuffer works since in my virtual machine it is not working 
(an empty window is opened and no gl rendering occurs)

Normally I do not announce my upload to rebol.org but this time is 
different. I have uploaded an upgraded version of  my interface to 
opengl: http://www.rebol.org/view-script.r?script=opengl-glu-glut-h.r
and I am asking you to insert "GLX_DOUBLEBUFFER" in the block of 
the line: "attrList-def: reduce [GLX_USE_GL GLX_RGBA  GLX_DEPTH_SIZE 
16 GLX_RED_SIZE 4 GLX_GREEN_SIZE 4 GLX_BLUE_SIZE 4 0]"  to see if 
doublebuffer works since in my virtual machine it is not working 
(an empty window is opened and no gl rendering occurs)

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

This tool lets you visualize information by specifying how a value 
is mapped to a visually recognizable property like color, font, font-size, 
line width, etc.


You get a complete interactive editor to make such models. Immediate 
visual feedback is the major goal of our tool.


You can mix data from different sources to visualize multi-dimensional 
information. Here is an example of such a model:

@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.

Something like this should work:

>> ;; position at 2nd last char of ln+nl
>> ln+nl: back back tail ln+nl
== #{0D0A}
>> ;; see if the first of the two chars is a linefeed
>> either #"^(0a)" = first ln+nl [size-nl: 1] [size-nl: 2]
== 2

This is only partly true.


It is in fact faster to SHOW the whole window, rather than calling 
SHOW multiple times for single elements, when there are sufficiently 
many elements in the window. Still, SHOW also depends on the size 
of the area to display, so if you have, say 10 fields, wrap them 
in a PANEL style and then perform the SHOW on the PANEL instead of 
the whole window or the individual fields.

It seemd that when the size of the text returns to 0 the text area 
is not correctly updated and some characthers are being taken from 
memory.

Perhaps it helps to learn about the mechanisms: There are several 
ways to generate a dynamic UI:


The LAYOUT function works by creating an object tree, a tree of faces 
that are simply ordinary objects. When passing this to the VIEW function, 
a layout is displayed. The layout function is part of VID and is 
as such a high level function. VIEW is a low level function to interpret 
the face tree.


The face tree consists of objects that contain other objects through 
the FACE/PANE word. If the FACE/PANE contains an object, that object 
is a single face, that is displayed inside the parent face. If the 
PANE contains a block, that block may contain multiple objects that 
are simply multiple faces. As such, a typical window is a face with 
a FACE/PANE that is a block that contains other objects.


Graphically, the face is represented by a region on the screen that 
has the size and offset, possibly an effect, such as coloring, blur 
or mirroring or a text attached to it, and image or other faces that 
are only visible inside that region.

A window is also a face.


To navigate to the parent face from a face, use the FACE&/PARENT-FACE 
word. Note that FACE/PARENT-FACE is many times not set by VID, which 
is sometimes problematic.


You can manipulate the face tree by adding removing objects dynamically 
and calling the SHOW function. You can also change values in existing 
face objects in the tree, such as for resizing or moving the faces 
and then calling SHOW again. You can also build a face tree entirely 
by hand, and this is usually the starting point for different layout 
engines, such as RebGUI, that simply build face trees in their own 
way.


The prototype face is FACE, which is a minimum requirement face for 
the View engine. The prototype face for a VID face, which contains 
a few more words, is SYSTEM/VIEW/VID/VID-FACE, which is the minimum 
requirement face for VID.


One condition for the face tree is to not use the same object in 
multiple locations. The VIEW or SHOW function will return an error 
if that is the case.


A simpler way is also to generate a new face tree every time you 
want to change the layout. Although this is slightly more computationally 
heavy, it allows you to manipulate the block that was passed to the 
LAYOUT function instead of manipulating the face tree directly. This 
technique is best used, when the face tree changes dramatically by 
each manipulation.


Another important concept is the DRAW engine which is a separate 
entity in REBOL2. It can be called to draw on an image bitmap, using 
the DRAW function or as in effect for a face object, by adding a 
parameter in the VID dialect block or by changing the FACE/EFFECT 
word. DRAW is used by calling a dialect. if you just want to use 
fields, buttons and simple user interface designs, you may not need 
to use DRAW.

I wrote another simple example as a one-liner, not useful in a real-world 
app. but gives an idea:


view f: layout/size [btn "add" [append f/pane layout/tight/offset 
[backcolor random white btn random "abcdef"] 50x50 + random 300x300 
show f]] 400x400

It actually adds new faces to the main face's pane, not the new styles. 
So, not a useful example. 
;no need to backcolor.. shorter:


view f: layout/size [btn "add" [append f/pane layout/tight/offset 
[btn random "abcdef"] 50x50 + random 300x300 show f]] 400x400

The simplest way how to write the FIND-TERMINATOR would be recursive:

find-terminator: [terminator | skip find-terminator]


However, this version is recursive, which means that it fails when 
the search is "long" exceeding the available stack size.

By "it fails" I mean that the recursive expression would not be able 
to find the terminator even if it were present when the length of 
the search would exceed the available stack size.

You can't simply switch the style by putting a new word in the STYLE 
facet. Each style is a prototype object with very different code 
to manage its internals. Generating a style using layout therefore 
involves getting a face from the style library, performing a set 
of operations on it for correct size and offset and run its initialization 
procedure. Only then is it inserted at the right localtion in the 
pane of the parent panel.

>> help sort
USAGE:

    SORT series /case /skip size /compare comparator /part length /all 
    /reverse


DESCRIPTION:
     Sorts a series.
     SORT is an action value.

ARGUMENTS:
     series -- (Type: series port)

REFINEMENTS:
     /case -- Case sensitive sort.
     /skip -- Treat the series as records of fixed size.
         size -- Size of each record. (Type: integer)
     /compare -- Comparator offset, block or function.
         comparator -- (Type: integer block function)
     /part -- Sort only part of a series.
         length -- Length of series to sort. (Type: integer)
     /all -- Compare all fields
     /reverse -- Reverse sort order

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.

#! "C:/wamp/bin/apache/Apache2.2.11/cgi-bin/rebol-core-278-3-1.exe" 
-cs
REBOL [Title: "Table"]
print "content-type: text/html^/"
print [<HTML><BODY><TABLE  bgcolor="black" border="1">
{
<tr bgcolor="white">

<td style="width:30px; height:30px;"><input name="one-one" type="text" 
size="1"></td>

<td style="width:30px; height:30px;"><input name="one-two" type="text" 
size="1"></td>

<td style="width:30px; height:30px;"><input name="one-three" type="text" 
size="1"></td>
</tr>
<tr bgcolor="white">

<td style="width:30px; height:30px;"><input name="two-one" type="text" 
size="1"></td>
<td style="background:black; width:30px; heigth:30px;" ></td>

<td style="width:30px; height:30px;"><input name="two-three" type="text" 
size="1"></td>
</tr>
<tr bgcolor="white">

<td style="width:30px; height:30px;"><input name="three-one" type="text" 
size="1"></td>

<td style="width:30px; height:30px;"><input name="three-two" type="text" 
size="1"></td>

<td style="width:30px; height:30px;"><input name="three-three" type="text" 
size="1"></td>
</tr>
}
]
print [</TABLE></BODY></HTML>]

#! "C:/wamp/bin/apache/Apache2.2.11/cgi-bin/rebol-core-278-3-1.exe" 
-cs
REBOL [Title: "Table"]
print "content-type: text/html^/"
print [<HTML><BODY><TABLE  bgcolor="black" border="1">
{
<tr bgcolor="white">

<td style="width:30px; height:30px;"><input name="one-one" type="text" 
size="1"></td>

<td style="width:30px; height:30px;"><input name="one-two" type="text" 
size="1"></td>

<td style="width:30px; height:30px;"><input name="one-three" type="text" 
size="1"></td>
</tr>
<tr bgcolor="white">

<td style="width:30px; height:30px;"><input name="two-one" type="text" 
size="1"></td>
<td style="background:black; width:30px; heigth:30px;" ></td>

<td style="width:30px; height:30px;"><input name="two-three" type="text" 
size="1"></td>
</tr>
<tr bgcolor="white">

<td style="width:30px; height:30px;"><input name="three-one" type="text" 
size="1"></td>

<td style="width:30px; height:30px;"><input name="three-two" type="text" 
size="1"></td>

<td style="width:30px; height:30px;"><input name="three-three" type="text" 
size="1"></td>
</tr>
}
]
print [</TABLE></BODY></HTML>]

you have to mix them something like  

#! "C:/wamp/bin/apache/Apache2.2.11/cgi-bin/rebol-core-278-3-1.exe" 
-cs
REBOL [Title: "Table"]
do %mysql-protocol.r 
db: open mysql://[root-:-localhost]/test
insert db {create table data (
    name            varchar(100),
    address         text
  )} 
insert db {INSERT into data VALUES 
    ('raj', 'pune'),
    ('ekta', 'delhi'),
    ('ankur', 'mumbai')
    
}
insert db "SELECT * from data"
results: copy db
print "content-type: text/html^/"
print [<HTML><BODY><TABLE  bgcolor="black" border="1">
{
<tr bgcolor="white">

<td style="width:30px; height:30px;"><input name="one-one" type="text" 
size="1">} 
print results/name 
print {</td>}


etc

#! "C:/wamp/bin/apache/Apache2.2.11/cgi-bin/rebol-core-278-3-1.exe" 
-cs
REBOL [Title: "Table"]
do %mysql-protocol.r 
db: open mysql://[root-:-localhost]/test
insert db { DROP TABLE IF EXISTS data1;
create table data1 (
    oneone        varchar(1),
    onetwo        varchar(1),  
    onethree      varchar(1),       
    twoone        varchar(1),
    twothree      varchar(1),
    threeone      varchar(1),
    threetwo      varchar(1),
    threethree    varchar(1)
  )} 

print "content-type: text/html^/"
print [<HTML><BODY>]
print [<form><input type="submit" value=" submit !" />]
print [<TABLE  bgcolor="black" border="1">]
print {<tr bgcolor="white">

<td style="width:30px; height:30px;"><input name="oneone" type="text" 
size="1">}
insert db ["insert into data1 (oneone) values (?)" ]
results: copy db
print {</td>}

i should write like  fname:<input name="oneone" type="text" size="1">????

when i write like this :print [<form><input type="submit" value=" 
submit !" />]
print [<TABLE  bgcolor="black" border="1">]
print {<tr bgcolor="white">

<td style="width:30px; height:30px;"><input name="oneone" type="text" 
size="1">}
insert db ["insert into data1(oneone) values(c)"]
results: copy db
print {</td>}

Create 2 files. Call the first one e.g. cgi-test.html, and upload 
it to your server. The only thing you have to change is the link 
to your .cgi script in there:

<HTML>
<TITLE>Simple Web Form</TITLE>
<BODY>
<b>Simple Web Form</b><p>
<FORM ACTION="http://www.xidys.com/cgi-bin/cgi-test.cgi">
<INPUT TYPE="TEXT" NAME="Field" SIZE="25"><BR>
<INPUT TYPE="SUBMIT" NAME="Submit" VALUE="Submit">
</FORM>
</BODY>
</HTML>



Create a second file, called cgi-test.cgi (it has to align to how 
you name it in the above source file). Upload it to your cgi working 
directory. Remember to change the first line to contain the path, 
where your REBOL executable is placed:

#!/usr/local/bin/rebcmd -sqc

REBOL []

print join "Content-type: text/plain" newline
start: now/time/precise

submitted: decode-cgi read-cgi
values: construct submitted

prin "Submitted: " print mold submitted
prin "values: " print mold values
prin "values/field: " print mold values/field

print now/time/precise - start
print newline
 

Now go to your URL, and try to submit some values. You can test it 
on my site at: http://www.xidys.com/cgi-test.html

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.

Very roughly speaking, when you add up the libraries, Enlightenment 
is half the size of GTK which is half the size of Qt

also, is there a way for the desktop size to be remembered?

That would double the size. Not good for a download :-)

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.