World: r4wp

OK. Any idea when you'll publish the AVR backend? It would be useful 
for reference

You mean the linker backend?

Yes, but anything that's fit for inclusion :-)

It's already published since several months: red-system/formats/Intel-HEX.r

Oh, great :-)

As you will notice, it uses a minimal C-based kernel and some imports 
are linked to it using syscalls.

An Arduino? I'll look into it

Yes, that's a kernel for a Arduino Uno board.

OK, great

I would like to get rid of the compiled C part, but never found the 
time to recode it in Red/System. It would also needs some addition 
to Red/System, like interruption handling (already planned) and other 
non-planned features, like a way to initialize RAM/SRAM from Flash 
memory (basically, it needs to copy the firmware data section from 
ROM to RAM), or initialize properly the timer clock (which should 
be doable with the hardware I/O support I've planned already).

In fact, once done, it would be the first nano-kernel written in 
Red/System. ;-)

Thanks, that's useful info

Here are the syscalls that should map to that kernel version (I've 
changed it often):

#syscall [
	init-runtime: 02F0h []
	
	init-serial: 05C8h [
		object	[int16!]
		baud	[integer!]
	]
	prin: 084Eh [
		object	[int16!]
		msg		[int16!]		; string pointer!
	]
	prin-int16: 09FEh [
		object	[int16!]
		value	[int16!]
		type    [int16!]		; unsure about the meaning of this parameter
	]
	prin-int32: 0992h [
		object	[int16!]
		value	[integer!]
		type    [int16!]		; unsure about the meaning of this parameter
	]
	set-pin-mode: 046Ah	[
		pin		[byte!]
		mode	[byte!]
	]
	digital-write: 04B6h [
		pin		[byte!]
		value	[byte!]
	]
	wait: 023Eh [
		delay	[integer!]
	]
]

The kernel does not use pure C, but Processing, a C/C++ hybrid.

Do you have int16! implemented in the AVR backend?

Well, I do have something, but it's messy, buggy and incomplete. 
I can send you the AVR8 backend if you want to play with it, I don't 
want to publish it until it gets a stable and correct support for 
basic datatypes.

I'll keep it in mind, but don't need it now

In Red/System, can I assign a value to a variable of different type? 
say    a: 1 a: "1"

Nope, Red/System is statically typed, you can never change the type 
of a variable. You can just do type casting to convert the variable's 
value to a compatible type.

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.

I've activated the doc-strings in all the Red/System bindings that 
I had prepared when I wrote them

If someone writes the doc tool that Doc proposed, you could generate 
separate documentation for the bindings

I've removed the / from the repository name for the test binaries. 
Fossil was using the title in the download file names, so the slash 
was creating odd results

I can run the Windows executables under WINE on Linux. Oddly, cURL 
and SDL sound work there, so for now I'll blame Windows 7 for their 
failure there

Maybe I will take a shot at the tool. Outline would be handy and 
specs.

In allocator.reds, the only struct I know is cell. What are node 
and frame here? Doc.

Line 35:

#define node!				int-ptr!

The various frame struct!s are declared in lines 79, 86,and 94

Peter, I mean, What are they used for?

I guess it's not a good question. After all, I am not good at memory 
management. I should wait for Doc's Doc on Memory Management.

I think only Nenad understands that at the moment though the code 
in Unicode.reds may give some indight into using the Red Memory Manager.

indight -> insight

Recent Red tweet: "All path datatypes (path!, lit-path!, set-path!, 
get-path!) implemented. "

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.

From ~Links group: "Could Red eventually become a contender for #6? 
 How strong will support for parallel processing be, eventually, 
in Red?"


#6: yes, that is one of the goals I want to achieve with Red. For 
parallel processing, the model I have in mind is the "parallel collections" 
from Scala. This means that when you are looping over a series, Red 
should be able to parallelize the loop code over n (CPU and/or GPGPU) 
cores at the cost for the user of only a change of the loop function 
name (in Scala, they use a "par." prefix for such functions). This 
requires that the compiler do a deep static analysis of the loop 
body to determine if it can be parallelized (e.g. iterations not 
dependent on results from previous ones). Now, if you also add SIMD 
support in the equation to leverage intra-core parallelism, you get 
a good picture of what I want to achieve. ;-)


So, I think a semi-assisted parallelization/vectorization of loops 
in Red is doable. To what extent and which final efficiency, I'm 
not sure before we build some prototypes.

To what extent and which final efficiency
 may be a key factor in your billionaire-worthiness ;)

Remind me to start a space ship building company when I get to that 
point. ;-)

Path notation preliminary support added: you can use it on any series 
with integer! or get-word! values as accessors (nested word! values 
need SELECT action to be implemented first).


See changes in demo script: https://github.com/dockimbel/Red/commit/88fd1ff1da855a383e91566903fe373ea4d41eca

Doc, apart from Twitter, please don't forget about using another 
marketing channel - Facebook :-)

Pekr: I try to use each channel for what it is worth for. :-)

Set-path notation support for modifying series added.

Functions refinements support added. /ONLY option implemented for 
MOLD, much more to come soon.

In R3, There are 56 actions, 159 natives, 21 ops, 56 datatypes. Now 
in Red, there are 19 actions, 21 natives, 10 ops, 15 datatypes, respectively.

Just a simple comparison.

DO you need all 56 datatypes, 159 natives. Development last years: 
R3 nil Red exponential just a comparison ;)

There is also the basic work to do, like the lexical scanner, port 
system, etc. Some of the work on actions and natives can be outsourced 
later.

Bad comparison: Active project vs. suspended project.

They aren't even in the same stage of development, as R3 is much 
more mature at this point. This is not a criticism though, as Red 
was years away from existing yet when R3 was at the stage Red is 
at now. There is still much to look forward to from both projects.

R3 has about 190 mezz functions, Red has none so far, which will 
be supported soon.