AltME groups: search

a matching rule, will expand the segment's area, but not its index. 
 rules are stacked based on end-to segments.  if a rule has a segment 
of size 0 (as in the none rule) there is no index change in the next 
rule segment. i.e. it shares its index since its index is previous 
index + 0

hmm.. why do the binaries for 2.7.0, 2.7.1 and 2.7.2 all take up 
the exact same size of 655360 bytes?

I believe the PE file format has sections that are padded, so it 
may be that the internal padding is different, as are the code segments, 
but the resulting EXE is the same size. I suppose you could do a 
binary diff to see.

I do have very small apps that can run for weeks and weeks and never 
make trouble, but as soon as the apps grow in size, the crashes get 
more frequent.

using MIN on offsets and MAX on size you get the enclosing box


when you use MAX on offsets and MIN on size you get the intersection 
of both boxes

its independent of gobs as you can use it inside draw already - eg:

text 100x100 [font "Arial" size 20 240.240.0 "this is some text" 
255.0.0 "this is some more text"]

is there any plan to remove viewtop from R2/View? To reduce the size. 
I always use View but almost never used viewtop.
second, there will be viewtop on R3?

give me glyph size to pixel size or an automated internal way to 
composite text on a line having different size and bang ritch text 
area will be possible ...

How about including a few common parse rules ... such as digit, digits, 
alpha alphanumeric in the standard build.  Adds nothing really.to 
size.

the return slot is the first argument in the frame.  AFAIK the argument 
frame is always the same size no matter how many arguments to actually 
supply (0 to 8)

OH... forget it... the correct way is using:

	REBSER *ser = RXA_SERIES(frm, 1);
            char *srcData  = RL_SERIES(ser, RXI_SER_DATA);
            u32 srcLen = RL_SERIES(ser, RXI_SER_SIZE);

Correction... the right result is:

	srcData = RL_SERIES(ser, RXI_SER_DATA) + RXA_INDEX(frm,1);

 srcLen =  RL_SERIES(ser, RXI_SER_SIZE) - RL_SERIES(ser, RXI_SER_LEFT) 
 - RXA_INDEX(frm,1) -1;

so I don't know what is better.

and yes.. it's fine that RL_SERIES(ser, RXI_SER_DATA) returns string 
at it head. Than I would like to have the RXI_SER_LENGTH as a shorthand 
for: RL_SERIES(ser, RXI_SER_SIZE) - RL_SERIES(ser, RXI_SER_LEFT) 
- RXA_INDEX(frm,1) -1 


and the bug is, that the binary is not using wide, but reports it 
and counts the pointer position as wide - as Kay reported.

I personally think of the RXIARG (which is a neutered REBOL "value") 
as "the series", and of the REBSER as a subordniate helper structure 
(holding width/size/left and data).

RSA is significantly slower than symmetric key encryption algorithms, 
and a single encryption or decryption operation can only process 
an amount of data up to the size of the RSA key. For encrypting or 
decrypting large amounts of data RSA is usually used in combination 
with symmetric key algorithms or secure checksums as follows:

Also, from Wikipedia - AES has a fixed block size of 128 bits whereaas 
Rjindael can have a blocksize in any multiple of 32 between 128 and 
256 bits.

It would seem from the docs at http://www.rebol.com/docs/encryption.html#section-3
that there is no way to specify the block size with Rebol.

It may well be that REBOL uses a 128-bit block size with Rijndael 
but it isn't clear from the documentation.

For a scanner (also called lexical analyser), I can recommend studying 
the UNIX command lex. The code produced might be a bit bigger in 
size, but it's fast and produce good result.

But it's most likely smaller in size, the code for the scanner.

This is about the HTTP scheme, but I can't find a group for R2 schemes.


Does anyone have a patch for the HTTP scheme that handles 204 (No 
Content) responses where no headers are returned? The standard scheme 
throws an error as there are no headers to parse. Here is the 'success 
case handler:

        success: [
            headers: make string! 500

            while [(line: pick port/sub-port 1) <> ""] [append headers join line 
            "^/"]

            port/locals/headers: headers: Parse-Header HTTP-Header headers
            port/size: 0

            if querying [if headers/Content-Length [port/size: load headers/Content-Length]]

            if error? try [port/date: parse-header-date headers/Last-Modified] 
            [port/date: none]

            port/status: 'file
    ]


For anyone familiar with the scheme, would the proper behavior be 
to set all related 'port fields to zero or none? e.g.

            port/locals/headers: headers: none
            port/size: 0
            port/date: none
            port/status: none

I did some a long time ago Henrik. It isn't fast enough to work on 
data of any size though. I can dig it out if you're interested. Can't 
remember what state of completion it's in.

Any *significant* size that is.

2 amacleod: time protocol is not very accurate, the same levely of 
accuracy you can get by reading any HTML size and distile the time 
from HTML header. OTOH NTP protocol is able to get milisecond accuracy 
but by quite difficult handshake and as far as I know not yet written 
for rebol

size = site

It certainly worked (file size was 400MB not 600MB).

another proposal:


have info? support more datatypes.  it would be very nice for a single 
function to return information about any datatype in a single call.

ex:
>> a: make string! 1000
>> a: next append a "12345678"

== make object! [length: 7 index: 2 size: 8 buffer: 1000 references: 
1]

each layer creates a tiny object for every widget, but the size of 
the draw blocks is immense, so it will save memory in the end.  if 
we have 10 objects storing  10000 items 10 times 

vs 10 storing parts of those 10000 objects 10 times the memory saving 
should be significant.

See http://issue.cc/r3/1573for remove-duplicates and the reason 
it's not as good an idea as you might think. It turns out that the 
set functions have to allocate a new series to do their work (for 
series larger than trivial size), even if they were changed to modify 
in place. So you can't avoid the allocation; might as well benefit 
from it.

Not much less RAM. The "interpreter wrapper" is pretty much constant, 
no matter the size of the data. Remember, the data you are doing 
set operations on is REBOL data already.

there might be some ideas to rip out of that compiler.    my favorite 
low-level feature was that all types where natively the same size 
in ram and where all aligned to that size.     in E all datatypes 
where 32 bits in RAM


so for example, chars actually had 4 bytes which you could dump bytes 
into, making them ideal for many purposes which strings and numbers 
are commonly used instead.  you coud compare chars with LONGS as 
though they where both integers, etc.

Max: the current supported types in Red/System are all of same size. 
Makes a lot of things easier, but I will need 8 and 16-bit sizes 
very soon, so the simplicity of implementation will probably suffer 
a little from that.

Thanks. Sounds good, except for the size

I agree that the library size is too big anyway for a direct inclusion 
in Red's core.

re the size of executables, for comparison: basic 0MQ examples ("hwserver/hwclient") 
written in C compiled & linked dynamically with GCC & gold on Linux 
are ~6KB in size.

0:bash::bash : Error: load_image() Invalid section size 0, expected 
40

0:bash::bash : ERROR : execve(./empty) failed. Too late to recover, 
will exit

Ok it seems it relies on section headers rather than program headers: 

if ( sElfHdr.e_nSecHdrSize != sizeof( Elf32_SectionHeader_s ) )
{

    printk( "Error: load_image() Invalid section size %d, expected %d\n", 
    sElfHdr.e_nSecHdrSize, sizeof( Elf32_SectionHeader_s ) );
    nError = -EINVAL;
    goto error;
}

builds/hello:     file format elf32-i386

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .shstrtab ...

Here we go, hello.reds now results in a 1065 bytes binary (882 previously). 
For this bloat, you get the following information:

Section Headers:

  [Nr] Name              Type            Addr     Off    Size   ES 
  Flg Lk Inf Al

  [ 0]                   NULL            00000000 000000 000000 00 
       0   0  0

  [ 1] .text             PROGBITS        08048074 000074 000290 00 
   AX  0   0  4

  [ 2] .data             PROGBITS        08048304 000304 000085 00 
   WA  0   0  4

  [ 3] .shstrtab         STRTAB          00000000 000372 000017 00 
       0   0  1

Brian: it might be too high-level for Red/System. I need to have 
a fine-grained control on memory accesses. A variable-size datatype 
would get in the way. But I admit I didn't consider that option, 
I would need to think about it deeper to see if it could be an advantage.

Doc, by multibyte chars I wasn't talking about variable-size, I was 
talking about fixed-size with Unicode support. A char! would have 
a single size, but that size would either be 1, 2 or 4 bytes depending 
on whether the base plarform supports ASCII, Unicode2 or full Unicode.

The old C way was based on legacy byte-size chars. It is better to 
be Unicode-aware from the start than it is to retrofit it.

Andreas, the target platform's pointer type points to something. 
Unless you know at least the size of that something, let alone its 
type, it is unsafe to use such a pointer. It is best to pretend that 
an untyped pointer is not a pointer at all, just a pointer-sized 
opaque value like R3's handle!. You can then explicitly convert that 
value to a typed reference in order to be able to use it as a pointer.

C structs are what I'm talking about, particularly ones declared 
with the pragmas. The quirks can go in the settable defaults, including 
things like the size of certain datatypes that have ill-specified 
types in the C standard.

About a possible binary! datatype in Red/System, I don't think it 
would be more useful than an array! of byte! values, just maybe providing 
a safer alternative to array! (as binary! value size would have to 
be encoded somewhere). If someone has good pros for a binary! datatype 
at Red/System level (it will exists at Red level anyway), let me 
know.

I.E: the rebol's VM size is small, that's an adventage if I work 
on a computer with 1.44Mo flopydisk as main support, it's just stupid 
if I have 1Tera e sata hard drive. Or rebol vm runs everywhere your 
script the same, you take area-tc and surprise it doesn't work on 
windows seven on linux and macOS X.  Or it's easy to do networking 
with rebol. If you do TCP or UDP yes if you do something else you 
are unable to proceed ... see that's always double side half truth 
in rebol and that's really what I don't want to see in Red this is 
not a big contribution but it's important enough for me to be said.

Shad, I don't have a 2TB hard drive on my phone. Size still matters 
in some important cases.

Are there size limits to these parameters and return values?

~size of the stack, I'd guess

no size limits, but it's obviously a lot easier to blow the stack 
if you pass around lots of large structs as values

Kaj: "I tested the new section headers on Syllable Desktop.

memmap_instance() RO overlap RW (08048000 + 00001000 -> 08048000)"


besides the entry point address being a problem, this could also 
be due to segment alignment, which we basically ignore, at the moment. 
could you try changing "page-size: 4096" to "page-size: 1" and see 
where that gets us?

I have to set the start address back to the Linux one to be able 
to compile with a changed page size

A page size of 1 works on Linux, but on Syllable the load error is 
still exactly the same

send: func [  ; Send message.
	socket		[pointer!]
	data		[pointer!]
	size		[integer!]
	flags		[integer!]
	return: 	[logic!]
;	/local		message [pointer!]
][
	either zero? as-message message data size none none [
		either zero? send-message socket message flags [
			zero? end-message message
		][
			end-message message
			no
		]
	][
		no
	]
]

I think I am going to port Red to this USB key size platform, once 
available: http://www.raspberrypi.org

vsm-data1	[integer!]  ; unsigned char [ZMQ_MAX_VSM_SIZE] (default 
30)

 => we will need a better way to handle such arrays when interfacing 
 with third-party libs...

I'm trying to use pointer! as much as possible instead of integer! 
because it makes clear that we're talking about an address size, 
not what happens to be the compiler's integer size

In a strongly typed language, which even Red/System is, dereferencing 
a pointer means getting a value back that is of a known type; pointer 
arithmetic means adding in increments of the size of that type. A 
void pointer references nothing, and that nothing has no size. You 
must be required to typecast to another pointer type explicitly if 
you want to dereference the pointer, or to know how much to increment 
or decrement it.

*** Compilation Error: invalid definition for function send: [
    socket [pointer!] 
    data [pointer!] 
    size [integer!] 
    flags [integer!] 
    return: [logic!]
]

*** in: %/users/administrator/Red/Red-ZeroMQ-binding/examples/../ZeroMQ-binding.reds 
*** at:  [func [
        socket [pointer!]

Kaj: 
I tested the new section headers on Syllable Desktop.

memmap_instance() RO overlap RW (08048000 + 00001000 -> 08048000)"


besides the entry point address being a problem, this could also 
be due to segment alignment, which we basically ignore, at the moment. 
could you try changing "page-size: 4096" to "page-size: 1" and see 
where that gets us?"

I've uploaded a new empty with page-size 1

in line 183 of formats/ELF.r, change data-ptr: code-ptr + code-size 
to data-ptr: code-ptr + page-size

and change back page-size to 4096 before that

Andreas, shouldn't it be rather:
data-ptr: code-ptr + code-size + (page-size // code-size)

A define would still generate code, so it wouldn't lead to reduction 
of source or binary size

Strings are terminated properly with gets/input-line but you must 
allocate an unknown storage size, which is warned for in the source 
of the binding

That might only be useful with integer! as it should be extended 
to 64-bit when Red/System will be ported to 64-bit platforms. But 
I think that a specific macro would be more appropriate (something 
like integer-size?).

or rather: get-integer-size

Doesn't it get the size of the pointer then?

An alias is an abstract definition, it doesn't allocated anything. 
So we can decide that the size of an alias is the whole struct size.

Cool... I'm able to obtain image size from red using iMagick

as-message: "zmq_msg_init_data" [  ; Convert to new message.
	message		[message!]
	data		[byte-ptr!]
	size		[size!]
	free		[function! [data [byte-ptr!] hint [handle!]]]
;	free		[handle!]
	hint		[handle!]
	return: 	[integer!]
]

either as-logic as-message message data size none none [

for example a struct of an 8-bit char! and a 32-bit integer! takes 
up not 40-bits but actually 64-bits in size (due to alignment constraints, 
in this case).

message!: alias struct! [
	content		[handle!]
	flags		[byte!]  ; unsigned char
	vsm-size	[byte!]  ; unsigned char

 vsm-data1	[integer!]  ; unsigned char [ZMQ_MAX_VSM_SIZE] (default 
 30)
	vsm-data2	[integer!]
	vsm-data3	[integer!]
	vsm-data4	[integer!]
	vsm-data5	[integer!]
	vsm-data6	[integer!]
	vsm-data7	[integer!]
	vsm-data8	[integer!]
]

Bytes don't require alignment, 32-bit values do. In message!, vsm-data1 
is aligned on a 32-bit boundary, leaving a 2-bytes hole after vsm-size.

You could compensate for that by splitting vsm-data8 in 2 bytes values, 
so that the global size remains the same as the C struct. The cleaner 
solution should be to introduce an array! type, which we will do 
at some point.

Not on my screen size

In the current implementation for IA-32, arguments total size is 
limited to 255 bytes. No special limit is set on variadic functions 
other than that.

The number of arguments, or the combined size of the arguments?

Combined size on stack.

So it's an integer, while there are already two integers for the 
size. Because they can be required to be adjacent, you can detect 
one more integer if it's at the proper distance of the pair, but 
that's the limit

Compiling /resources/Red/tests/empty.reds ...

*** Compiler Internal Error: Script Error : Cannot use path on none! 
value 
*** Where: build-debug-lines 
*** Near:  [records: job/debug-info/lines/records 
files: job/debug-info/lines/files 
rec-size:
]

stream!: alias struct! [
;	data				[binary!]
	index				[binary!]
	rest				[integer!]
]
fetch-audio: function [  ; Read sound buffer to be played.
	[callback]
	source				[stream!]
	sink				[binary!]
	size				[integer!]
	/local slice
][
	slice: source/rest
	if slice > size [slice: size]

;	copy-part source/index sink slice
	sdl-mix-audio sink source/index slice sdl-mix-max-volume

	source/index: source/index + slice
	source/rest: source/rest - slice
]

I'm looking into the allocator. alloc-series says it takes a size 
in cells of 16 bytes, but then it relays it to alloc-series-buffer 
unmultiplied, which says it takes a size in bytes, and only rounds 
it up to 16 bytes

The runtime error handler now better catch unknown errors and the 
use of SWITCH has decreased the runtime code size significantly.

The WebKit I use of a few years old is 18 MB installed size, on Syllable 
Server. It has quite a few more dependencies, though, and on Windows 
that would be more because none of the dependencies are preinstalled

Single precision purpose: I guess the only advantage is smaller storage 
size. Some Intel FPU operations are even slower in single precision 
than double precision.

I also think that 256-bit VM insn size sounds a bit wasteful. That'll 
thrash the data cache easily.

If so, I'd probably try splitting immediate complex-loads into two 
insns. Then reduce insn size to 128-bit (if possible) and check the 
effect on code size.

But it's an even stronger incentive to keep instruction size small 
:)

Andreas: So in the case of register-based hardware architectures 
with a lot of 64bit registers (AMD64, PowerPC, Alpha), for a value 
space that rarely has direct values more than 64bit in size (the 
JVM model) implementing a variable-based procedural language rather 
than a stack-based language, a register-based model is faster than 
a stack-based model. Yup.

Brian, the size of a Geomol bytecode is twice the size of a Rebol's 
cell

No, it has nothing to do with VLIW except large insn size.

Thanks for all your work on World, and the QA John. It's very exciting.


As far as the outrageous bytecode size, from one who hates bloat 
as much as the rest of you here, I am happy to make certain tradeoffs 
in return for other benefits. If I have the choice of REBOL, World, 
Red, and Topaz as "mindset compatible" languages, I can choose which 
one to use for a given purpose. Yes, that opens up other questions 
and issues, but I'm happy to see more REBOL-like langauges.

Thaks for the kind words, Gregg. I was very much in doubt when growing 
the instruction size to 256 bit, but I must do something right, as 
the performance shows. This is an alpha, and things will change. 
And I haven't done much compiler optimization.

Size is probably because of some Windows includes/libs. From my mac:

-rwxrwxr-x+  1 john  staff  360286  4 Dec 09:53 world_linux
-rwxr-xr-x   1 john  staff  346216  3 Dec 11:27 world_macosx
-rw-r--r--+  1 john  staff  515991  4 Dec 09:50 world_win32.exe


The OS X and Linux version is much smaller. I have to dig into that 
at some point. But I don't think, it's so important right now.

My first experience with LLVM.


I tried to compile World with llvm-g++ under OS X. When compiling 
with gcc, I normally use -O2 option. I compared performance with 
the Mandelbrot test. Between compilations, I deleted all .o files 
and executable, so new compile started from scratch.

Compiling with llvm-g++:

With -O2 option, file size grow to 105% and execution time extend 
to 105% (slower).

With -O3 option, file size grow to 106% and execution time is the 
same.

With -O4 option (also Link Time Optimization), file size extend to 
122% and execution time grow to 107% (slower).


Then I tried to compile with gcc and -O3 option. Now file size grow 
to 105% and execution time shortened to 85% (faster).

Has anyone had similar experience with LLVM?

I tried compile with clang. More results, first with gcc, then clang:

gcc -O2 option
size: 346136
time: 0:00:00.681560

clang -O2 option
size: 349976
time: 0:00:00.736821

clang -O3 option
size: 354072
time: 0:00:00.643053

clang -O4 option
size: 382888
time: 0:00:00.734845

gcc -O3 option
size: 362304
time: 0:00:00.579858


It seems, gcc beat LLVM and clang here on performance, if I use -O3 
option.