World: r3wp

The WebKit binding is now here:

http://red.esperconsultancy.nl/Red-GTK-WebKit

Great news!

Implemented a separate SCROLL widget in the GTK binding, that can 
be used as a container for other suitable widgets to make them scrollable

Red/System can now compile hello.reds (including the Red/System runtime) 
for ARM, and the resulting binary works fine.

That's ARMv5, isn't it, not ARMv7? On what targets does it and does 
it not run?

It should work fine on all ARM9+ CPUs, which is pretty much any ARM 
platform used these days.

ARMv5, yes. Should work on ARMv5+.

For ppl non-familiar with ARM naming conventions: http://en.wikipedia.org/wiki/ARM_architecture#ARM_cores

So on ARM9, ARM11, Cortex A.

Cores, that is.

As Doc said, that covers most ARM systems in use today (except for 
the original StrongARM (historic; for those who happen to own an 
Apple Newton or Compaq iPAQ) and the current Cortex M microcontroller 
cores.

Wow! Exciting news indeed.

Red/System hello.reds now runs also on Android. If you have a rooted 
device, you can get and run the binary from here: http://sidl.fr/tmp/hello

is there any other possibility than using rooted device?

If you use a native exe loader (like "Run Native Exe"), the ANSI 
escape codes won't be interpreted.

Other possibility, yes, just install this app: http://gimite.net/en/index.php?Runnative executable in Android App

as for Cortex MCUs -  are those too low level MCUs, or is it just 
a matter of some work to do?

I haven't check their specs, but I guess that the current ARM backend 
should work for them too.

Isn't it possible to change debug level durring compilation? I would 
like to see the traces for my code, but not for the included runtimes.

It is

[-v <integer!>]

How it's supposed to be used during compilation? When I use:
do/args %rsc.r "-v 3 %tests/hello.reds"


i can see a lot of traces for files like %runtime/common.reds %runtime/lib-C.reds 
%runtime/win32.reds %runtime/utils.reds which I'm not interested 
in.

Not sure what the levels mean. I suspect the runtime can't be excluded

(I'm just trying to jump in and understand what the compiler does 
and in which steps) I know they must be there to create the app runable 
but I don't need such a app at this moment:)

It's probably more easier for me to add some probes here and there:)

You can use -v 6 and echo all output to a file and use a text editor 
to review the output for your code.

Disabling debug output for runtime files sounds like a useful option 
though.

(and it should be the default option)

Pekr: re "Cortex MCUs -  are those too low level MCUs, or is it just 
a matter of some work to do?"


Cortex-M raises two issues: first, these cores just support the Thumb 
instruction set (which Red/System does not support, at the moment). 
Second, most -M cores have no memory management unit (MMU).

Do they support the Thumb2 set (32-bit instructions)?

Depends on the core.

Cortex-M3 supports _only_ Thumb2, for example.

I can use -r for no-runtime :)

Yep, but you'll be quickly limited, unless you rewrite the runtime 
at least partially. ;-)

I am making some changes to the compiler debug logs output to avoid 
being pollute by runtime lib logs.

(Cortex-M0 supports Thumb plus a few Thumb-2 insns, IIRC.)

Oldes: I've pushed a change in master branch, you can now use -v 
5 to get the output of your own code only (with max details).

I agree with Gregg, great job. I tempted to pull out my Sharp Zaurus 
SL-6000 (xscale-based) just to see if I could get Red to compile 
on that but I had better return to my "work".  :-(

Oldes: about floating point support, I have made a short review of 
required changes in current compiler. I will publish it tomorrow, 
so we can decide on the priority with Kaj and others.

James: thanks!

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

How are non-block series going to be allocated, for example binaries 
of one byte per cell?

Alloc-series: right, the comment is obsolete, it accepts any integer 
value as argument and leave it to alloc-series-buffer to round it 
to 16 bytes.

Non-block series: in fact all series will use the same allocator, 
so 128-bit (16 bytes) is the minimum allocating unit.

Is there any roadmap to know what comes next? E.g. when work on RED 
itself will begin, etc?

Red: it has already begun, the lexer has been implemented.

I will be back to Red compiler as soon as I finish debugging the 
ARM backend.

I might start also working on floating point support but we'll see 
that tomorrow.

For anyone interested, here's a direct link to the GTK+ example that 
shows all currently implemented widgets: