World: r3wp

Maarten - you probably don't believe your own words, righ? Or are 
you going to write pixel manipulation in 'foreach or any other REBOL 
loop? :-)

I think R3 will be fast enough for all things you don't want to code 
in C

I'm looking forward to the reduce/into enhancement. In general we've 
had a lot of clever optimizations through better design, and I'm 
sure there are many more that can go in.

Small status update:

- CureCode is now the official bug tracker for R3.
- Clipboard now supports unicode. This took longer than expected.

- HTTP 1.1 has been degraded to 1.0 due to some problems with 1.1. 
Rebtalk will continue to work as always though. Maarten is looking 
into this.

- Carl is attacking font code (this does not involve altering the 
poor anti-aliasing unfortunately) and text handling, so text areas 
will finally grow up and act like real text areas. This makes Rebtalk 
usable for more than messages. :-)

- Also yesterday, code was added to allow cell based vertical and 
horizontal alignment of faces. It's interesting to see these changes 
in VID3.4: A new feature like this is rarely more than 5-10 lines 
of code, which is a sign of a great design.

- MAX-SIZE won't go away. Instead it might (I'm not sure Carl is 
convinced there is a problem) be split in two. It currently acts 
as both a pressure factor and maximum size for a face, which is the 
cause for most of its problems.

Pekr, making new execution engines for R3 is one of my goals, so 
yes.

Rebolek, math is not REBOL's strong suit, true. The speedup comes 
from other areas.

Maarten: I don't want to code anything in C :)

REBOL's syntax is bad for math - too verbose, too much required whitespace. 
We can do a better dialect than that.

Brian coul you give an example how  to  define a new execution engine 
in R3, i don't see the point

perhaps a work to do in the wiki

I can explain, but not give you code yet because it depends on user-defined 
datatypes and we don't even have the syntax for those yet.

ok i take it

Perhaps you have noticed that in R2 there are 4 function types, 5 
with rebcode builds: function!, native!, action!, routine!. Each 
of these behaves completely differently on the inside, but are called 
the same on the outside. This is because each of these datatypes 
defines a different execution model. R3 will have allow the user 
to create their own datatypes, and that includes function types. 
All a datatype needs to do to be a function type is to act like a 
function on the outside. How it behaves on the inside is up to it.

but in what langage will be writed the inner code of such new functions 
? (rebol, c, ...)

User-defined datatypes (UDT) depend on the R3 plugin model (that's 
not done yet either) and plugins are a REBOL module wrapper around 
native code. UDTs can be defined in REBOL code or a mix of REBOL 
and native.

ok

One thing you are missing is that the input data of the MAKE action 
of a datatype does not have to be the same as what is on the inside 
of the value created. That means that you could pass a block of code 
or string containing another language's syntax to MAKE and the datatype's 
MAKE handler can translate that data to whatever internal format 
it needs. This means we can compile.

this means we could compile some c code in the fly with something 
like tcc

Yes, that is one of my plans.

sounds sweet

The datatype's execution engine deals with the internal data that 
the MAKE handler creates, not the input syntax. This means that the 
internal data could be anything: bytecode, native code, graph structures, 
whatever.

You can't get a reference to the internal data in R3 like you can 
in R2, so no hot patching.

using struct! ?

I mean the value returned by the body-of reflector of a function 
is at best an unbound deep copy of the body, not the original. You 
can't patch functions. This means that your datatype could return 
a copy of the input data, a disassembly of your bytecode, or nothing 
if you like.

hum i see

This was a security fix.

Nonetheless, I am doing whatever I can to speed up regular R3 whereever 
it is reasonable to do so. The profiler is my friend :)

what is the name of the REBOL world again for 2.7.7?

r2-beta, I think

quick question about R3.... does the GC *release* memory from the 
process properly, as opposed to R2 growing infinitely?

R2 does that?

yep.

R2 does not grow infinitely, but it does not hand back memory -- 
it prefers to keep what it's got and use that again when needed.

That is faster than continually handing back and reacquiring memory 
in many cases.

But if an application needs a large amount of memory at start-up 
(or some other peak time), it keeps that memory until the end. That 
is not very friendly!

any memory use which grows the global pool is never de-allocated 
 :-(

but the actual effect is that if R2 grows, memory wise, its GC slows 
down.  so the argument of handing back the memory is ultimately flawed.

I've even witnessed this with altme, when doing the initial sync, 
it grew to almost 200 MB.  it then started to freeze sporadically.

so I just quit, started back... got me a nice 50MB process and all 
is well.

and sunanda... I've also discovered that it doesn't always recycle 
the memory its got !  image manipulation is an example of that.

does any one know if all of this is still an issue with R3 ?

There is a bug in R2 that causes a memory leak related to a specific 
use of GUI events and network ports. I've encountered this a few 
times.

How R3 handles memory, I don't know. There are several new debugging 
functions to explicitly let you know what is used and what is released. 
I would guess that Carl has also tried to make sure it's easier to 
find leaks.

I just hope that we can *force* a memory shrink.  I've got an application 
which needs a 900MB bitmap to be generated and drawn on... this works 
in rebol... but the moment I try to allocate a new one... it crashes. 
 the one is never released  :-(

(... the *old* one...)

or the memory reused for that matter  :-/

Thanks Henrik

Hm, sounds like one of the root causes why the AltME server can overflow 
the memory and swap space when a slightly larger file is downloaded

very possible.

IPv6 connection works in rebol3 ?

I am not sure it has anything in common with R3 itself? Isn't it 
task of underlying OS layers?

- but, for .e.g. with Cisco VPN client, we had to turn IPv6 off in 
order to get it work properly.