AltME groups: search

The minimal requirements for Red would be something like: a 32-bit 
CPU or MCU and 1MB of RAM. 


For Red/System, a 32-bit CPU/MCU and 32KB of RAM (at least 1KB for 
stack) would be enough to run some small programs. A 8-bit version 
is still possible though.


ARM Cortex-M controllers: no problem for running on them as long 
as we implement a Thumb instruction-set backend (could be merged 
with current ARM backend).

Depend on what you mean by "debug version" and what debugging tools 
you're thinking about. My plan for Red is to deeply integrate it 
with the IDE, so that you'll be able to have advanced debugging capabilities, 
like step-by-step debugging. Such feature could maybe also be ported 
to the console version, so you'll be able to use it even without 
the IDE installed.


Also, I have thought the Red execution architecture to be as reflective 
as possible in order to try to support memory image loading/saving 
and stopping/resuming (think Smalltalk). It's very tricky (not sure 
we'll have it in the end), but if we can achieve it, you'll be able 
to get a snapshot of a running Red program on file, transfer it and 
resume it somewhere else....ideal for reproducing exact bugs occuring 
conditions. EDIT: the right expression for that is "Image-based persistence".


In the meantime, we already have some "debug mode": -d switch for 
Red and -g switch for Red/System (we'll probably adopt -d for both, 
-g will be reserved for gdb support). It's mainly intended for internal 
usage for now, the Red/System one can be useful to locate runtime 
errors in source code (usable, but still needs some fixes though).

I would like to ask about the architecture of Red. I am looking into 
datatypes directory, e.g. string. Those functions don't have any 
arguments, they seem to work with the stack directly? Strange concept. 
Are those real Red functions? But what I don't understand is e.g. 
'back function, its body contains block/back. Where does "block" 
come from? It is not passed as an argument, so is that any kind of 
system wide value?

Kaj, I just watched your talk. It was great, but you can probably 
benefit by putting in a diagram or two, showing the relationship 
between REBOL, Red and Red/System.

I see update of docs typo in red-system-specs.txt saw in this file 
that mat operators including % are supported yet in BNF on line 1076 
it is not mentioned.

Yes (both modulus and remainder operators). Of course, this is for 
Red/System, Red doesn't have yet floats support.

number! is a virtual type used only internally by Red/System compiler.

Sorry - Red/System[] 4.0 // 2.0 compiles and runs.

Red/System[] f: 4.0 // 2.0 gives the type mismatch compile error.

(Red/System could already be added though)

It's about dealing with different Linux kernel incompatible ABI for 
float support on ARM platforms. Red/System uses the FPU unit (named 
VFP in ARM family) directly, but when having to pass/receive float 
arguments from libc or 3rd-party libs, Red/System needs to do it 
respecting the installed system ABI, which might be `softfp` or `hardfp` 
(there's a third one, but it's for not a concern for us). 


Currently, Red/System floats are passed using the `softfp` convention, 
so it works only on ARMEL platforms (while ARMHF platforms require 
`hardfp` convention). `hardfp` is a much more performant, while `softfp` 
is for legacy  systems or systems with no FPU unit).

BTW, Red or Red/System apps that do not use floats seems to work 
well with both ABI.

I simplified many of the bindings by using the new get-word functionality 
in Red/System 0.2.6 for getting the address of variables

Basically, Red/System compiler is doing automatically what C compiler 
requires you to do manually (i.e. specifying function prototypes 
separately in headers).

Yes, in the computation of the time difference. As long as it stays 
within Red/System, float computation is fine, like in Mandelbrot

So, we can now say that Red/System is more advanced than R3, as it 
can make sophisticated GUI apps on ARM devices. ;-P

That's a domain we can perfectly address with Red dialect + Red/System 
low-level access abilities.

I am in a hurry, I want to report them before release

 drive faster so you will be home before you are out of gas.  "But 
 yes, it's the domain I always wanted to target with REBOL" the domain 
 you want to target is the world isn't it?


I am studying the Red and Red/system sources these days to get more 
of a feeling what is going on.

Start

 might not be the appropriate term in this context, as the code is 
 modular. What you're probably after are the compilers wrappers:

- for Red: %Red/red.r
- for Red/System: %Red/red-system/rsc.r

Not exactly, I read rsc.r as if system-dialect is not set then start 
with the compiler.r script. (after that or else the rest of the script 
follows) but then is has some do other scripts and a modular part 
and the other scripts are modular too. It look all very sound bu 
somewhere <there must be/I expect> a first action or function call.

BrianH asked: "Was the BSL chosen because it allows you to distribute 
a binary without requiring that you distribute the license, unlike 
MIT and almost all other open source licenses?"


With the sole 3-clause BSD, users would need to provide a copy of 
the license with each compiled program, because of the runtime code 
included. So to avoid that, we chose to publish the runtime parts 
of Red and Red/System, under the more permissive BSL terms. The binaries 
that include the compilers (currently that would mean encapped version 
of Red and Red/System compilers) are still under BSD.


When Red will be self-hosted, it will include a JIT-compiler that 
will need to be released under also BSL or similar terms.

Also, when you try to build an operating system with Red, you'd get 
into GPL 2 territory in kernel space, and you'd have a problem with 
the many GPL 2 drivers. The media codecs and some networking protocols 
mirror that situation in user space

It was a bit painful commit anyway, as the internal API is not yet 
fully stabilized and to do it right, I would need to fully define 
the public runtime API first, but that would delay the 0.3.0 way 
too much, so we'll deal with that later.


What I mean by "public runtime API", is the Red API exposed to Red/System 
and to other host languages loading Red as a library. I'm still uncertain 
if such public API can be just some internal exposed or will need 
a thin layer of wrappers to make it handier (and in some cases, safer) 
to use. 


The R3 extension isolation model is too strong for my taste and makes 
the extensions harder to write than they should. I'm also uncertain 
if this model was stricly motivated by providing the safest possible 
interface with the core or, if the willing to keep the core internals 
as secret as possible was also playing a big part in this model choice.


Once the `dyn-lib-emitter` branch merged, I plan to study the Lua 
(and others) public API, to see if and how we can do better for Red. 
I already have a rough idea of how it should look like, I just need 
to refine it.

In my view, the R3 interface is also motivated by the wish to be 
independent from any operating system loader mechanisms, to discard 
them for Wildman in some unknown future

Red/System extensions will usually be compiled together with the 
Red runtime, so they will be much more flexible. For interfacing 
with precompiled binaries, a more stable interface would be needed

Anyway, we want to expose Red API to host languages/apps, not Red/System's 
one (at least not for now).

Red/System is already easy to expose to other languages, because 
it's C compatible, and you made the dynlib interface. :-) However, 
alias IDs break it

Another interesting side effect of the strong separation is that 
it would be possible to implement the client-side of the extension 
interface in other languages, such as Red, so that it could use R3 
extensions without changes. The REBOL portion of the extension might 
be trickier to implement though, because that code tends to be more 
tied into the actual R3 runtime model. You could write your own wrapper 
code if your system model is different, but the native code could 
be used as-is.

Hi Kaj on my macbook:

Last login: Fri Oct 19 07:21:16 on 
ttys001

 MacBook-van-Arnold-160:~ Arnold$ 
 /Users/Arnold/Downloads/Red\(/System\)\ 
 Testing-dc1b702068063b65/Darwin/Red/hello 
 ; exit;
Hello, world!
§±ÖÁµ, ºÌüµ!
`O}Y, NLu
Dobrý den sv
te
logout

[Proces voltooid]

 /Users/Arnold/Downloads/Red\(/System\)\ Testing-dc1b702068063b65/Darwin/Red/Fibonacci 
 ; exit;

MacBook-van-Arnold-160:~ Arnold$ /Users/Arnold/Downloads/Red\(/System\)\ 
Testing-dc1b702068063b65/Darwin/Red/Fibonacci ; exit;
Fibonacci 35: 9227465
logout

[Proces voltooid]


MacBook-van-Arnold-160:~ Arnold$ /Users/Arnold/Downloads/Red\(/System\)\ 
Testing-dc1b702068063b65/Darwin/Red/empty ; exit;
logout

[Proces voltooid]
I took the programs from the Red tree under Darwin

Could you test the Red/System programs, as well?

Most extension module scripts are currently IDL-like, but that is 
only because they aren't (and don't need to be) very ambitious in 
their system integration because they just export a bunch of functions. 
Any native implementation of a port scheme, native dialect, or other 
system enhancement would need Rebol code to integrate that enhancement. 
Doing that in Rebol code is what allows the actual native interface 
to be that simple. It is also what would allow Red wrapper code (which 
could be returned from the same RX_Init function in the same string) 
to use the same native code unchanged, even though Red's runtime 
model is likely to require different integration code.

Ah, but the interface is too simple to need an IDL - make command! 
will do. The extra stuff is for system integration, which is only 
needed when you are doing port schemes, dialects, anything that you 
wouldn't expect to be cross-language compatible anyways, unless you 
explicitly implement a compatible system model. If you're just exporting 
functions then you can implement a simple IDL just by interpreting 
the (cooincidentally the same) module spec code with a very limited 
IDL dialect processor if no Red script wrapper is found.

I don't expect Red and R3 to have the same system model, because 
if they did there would be no point to having Red at all. Being able 
to have extensions that can integrate into both would be an unusually 
amazing bonus :)

For that matter, I expect to make my own Rebol spinoff language that 
will follow a completely different system model than either Red or 
Rebol, and the only reason to do so is because those other languages 
don't cover that situation (otherwise I would have been more active 
in Red so far). Being different justifies their existence; interoperating 
with each other justifies their cooperation :)

Semantics will be very close, probably 99% close, as I've moved from 
a statically typed system to an hybrid static/dynamic typing system.

So, my module system will end up being of more use to you. I'll be 
sure to write up that TRANSCODE/part option request for R3 in CureCode, 
for your reference.

Well, maybe. :-) I must admit I haven't yet dived into R3 module 
system to see if it fits well our needs.

Being simple

 is probably the most important feature I would require from a module 
 system.

Resolving import cycles

: we've solved that in Red/System compiler by having a simple "included 
files" list and it stops inclusion if already done once. But we do 
that at compile-time, so it's easy.

A module system is where you would find a lot of places where the 
internals would be different, due to the compilation thing, but the 
external behavior could appear to be the same. There are a lot of 
nice tricks in R3's module system, and I've gone through a lot of 
trouble to make it possible to have the module system be handled 
by a preprocessor that doesn't have to execute any of the code in 
the modukle bodies to resolve dependencies. It was designed with 
preprocessors like prebol or Ladislav's include in mind. And all 
of that is in the specifications of how modules are declared, not 
in the actual mechanism that implements it, so the concepts would 
be portable to Red.

Certainly, but AOT compilation would be a big plus. Also, in Red 
we need to modularize the compilation process itself, so  we can 
do incremental AOT compilation on multi-files projects instead of 
having to rebuild everything (include runtime libraries) each time. 
We need to, somehow, match those compilation units with the higher-level 
module system (it's not the only option, but probably the most simple).

It allows to write R3 extensions in Red(/System), and there's some 
support for writing custom R3 hosts in Red

Currently it only works on Windows, and you need the dyn-lib-emitter 
branch of Red/System

It's not completely tested yet. The do-string call into R3 doesn't 
seem to work. We don't know yet whether this is a bug in Red/System 
or a bug in R3

I wonder Carl would entertain the idea of reworking the extension 
mechanism in R3 to allow even lower overhead access to Red/System. 
Or is the overhead about as low as you can expect it given that R3 
is interpreted?

I fixed support for push/pull connections in the ZeroMQ bindings 
for R2, R3 and Red/System:

http://syllable.cvs.sourceforge.net/viewvc/syllable/syllable/system/apps/utils/Builder/packages/ZeroMQ-Binding--current/

Rebol [Purpose: {make wikibook entry}
Author: "Max Vessi"
version: 1.0.0
]
my?: func [
    "Prints information about words and values."
    'word [any-type!]

    /local value args item type-name refmode types attrs rtype temp
][       
    temp:  copy ""
    if all [word? :word not value? :word] [word: mold :word]

    if any [string? :word all [word? :word datatype? get :word]] [
        types: dump-obj/match system/words :word
        sort types
        if not empty? types [
            print ["Found these words:" newline types]
            exit
        ]
        print ["No information on" word "(word has no value)"]
        exit
    ]
    type-name: func [value] [
        value: mold type? :value
        clear back tail value
        join either find "aeiou" first value ["an "] ["a "] value
    ]
    if not any [word? :word path? :word] [
        append temp reduce [mold :word "is" type-name :word]
        exit
    ]

    value: either path? :word [first reduce reduce [word]] [get :word]
    if not any-function? :value [

        append temp reduce [uppercase mold word "is" type-name :value "of 
        value: "]

        append temp either object? value [ reduce ["^/" dump-obj value] ] 
        [mold :value]
        exit
    ]
    args: third :value
    append temp  "= USAGE: = ^/ "

    if not op? :value [append temp reduce [ uppercase mold word " "] 
    ]
    while [not tail? args] [
        item: first args
        if :item = /local [break]

        if any [all [any-word? :item not set-word? :item] refinement? :item] 
        [
            append temp reduce [append mold :item " "]

            if op? :value [append temp reduce [append uppercase mold word " "]
	    value: none]
        ]
        args: next args
    ]
    append temp  "^/" 
    args: head args
    value: get word
    append temp "^/= DESCRIPTION: = ^/"
    either string? pick args 1 [
        append temp reduce [first args]
        args: next args
    ] [
        append temp "^/''(undocumented)''^/"
    ]

    append temp reduce [ "^/^/"uppercase mold word " is " type-name :value 
    " value."]
    if block? pick args 1 [
        attrs: first args
        args: next args
    ]
    if tail? args [exit]
    while [not tail? args] [
        item: first args
        args: next args
        if :item = /local [break]
        either not refinement? :item [

            all [set-word? :item :item = to-set-word 'return block? first args 
            rtype: first args]
            if none? refmode [
		append temp "^/= ARGUMENTS: =^/"
                refmode: 'args
            ]
        ] [
            if refmode <> 'refs [
                append temp "^/= REFINEMENTS: =^/"
                refmode: 'refs
            ]
        ]
        either refinement? :item [	   	  
            append temp reduce ["*'''" mold item "'''"]

            if string? pick args 1 [append temp reduce [" -- " first args] 
	    args: next args]
            append temp "^/"
        ] [
            if all [any-word? :item not set-word? :item] [
                if refmode = 'refs [append temp "*"]
                append temp reduce ["*'''" :item "''' -- "]

                types: if block? pick args 1 [args: next args first back args]

                if string? pick args 1 [append temp reduce [first args ""] 
		args: next args]
                if not types [types: 'any]
                append temp rejoin [" (Type: " types ")"]
                append temp "^/"
            ]
        ]
    ]
    if rtype [append temp reduce ["^/RETURNS:^/^-" rtype]]
    if attrs [
        append temp "^/= (SPECIAL ATTRIBUTES) =^/"
        while [not tail? attrs] [
            value: first attrs
            attrs: next attrs
            if any-word? value [
                append temp reduce  ["*'''" value "'''"]
                if string? pick attrs 1 [
                    append temp reduce [" -- " first attrs]
                    attrs: next attrs
                ]
                append temp "^/"
            ]
        ]
    ]
    editor temp
    exit
]

I've updated the test binaries for Red/System fix #279, fixing GTK 
window icon loading

I've cleaned up the Red bindings for the #enum passing bug that was 
fixed in Red/System 0.3.0. Most of the bindings need Red 0.3.0 now

Today I updated my Red compiler script on rebol.org. The script now 
can now also compile Red scripts, not just Red/System scripts.

You can find the new script here http://www.rebol.org/view-script.r?script=redcompiler.r

I've updated the Red(/System) test binaries. Instructions are in 
my recent Syllable article:

Here's a 6502 CPU emulator written in Red/System:

However, I rewrote it from a fairly complete Atari XL/XE emulator 
that I did in C a long time ago. The new code is a third shorter, 
mostly due to abundant use of preprocessor macros, which are less 
horrible in Red/System than in C

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:

I've tried several operating system ROMs. They seem to work, although 
it's still hard to judge without a real machine emulated around the 
CPU

It is common to use this FAQ entry as a way to make GPL extensions 
that wrap proprietary components: http://www.gnu.org/licenses/gpl-faq.html#WindowsRuntimeAndGPL


Developers commonly put links on their web site to the vendor's web 
site to download the DLL. However, it's iffy with GPL2 because the 
actual exception is worded like this:

However, as a special exception, the source code distributed need 
not include anything that is normally distributed (in either source 
or binary form) with the major components (compiler, kernel, and 
so on) of the operating system on which the executable runs, unless 
that component itself accompanies the executable.


Read literally, it would exclude runtime libraries that aren't bundled 
with the OS. It's more unambiguously OK with GPL3.

Ladislav, most of what Andreas and Maxim are saying here is true, 
but it doesn't matter. Reading comprehension requires reading the 
whole thing. The relevant part you missed is:

    or we could get a FAQ entry declaring that the functions built into 
    R3 are "part of the interpreter" rather than "library code", despite 
    R3's actual system model.


I am actually an expert on R3's system model as it relates to dynamic 
linking of code, and how code is bundled, since I wrote most of the 
code that does that. The mezzanine code is dynamically loaded and 
linked in the startup code, and is statically linked as data into 
r3.exe, so as far as copyright is concerned it is linked two ways. 
At least in the laws of the country of origin of REBOL, the code 
vs. data distinction is irrelevant to whether the code/data is covered 
by copyright, or the GPL, which only relaxes copyright. All that 
matters is that the mezzanine data is statically linked into the 
program. For that matter, it's not even bundled as a resource, so 
it's really hard to make the "mere aggregation" argument even if 
they weren't explicitly in the same program. Embedded extensions 
and embedded REBOL code are both statically linked into the program, 
and are both dynamically linked at runtime.


Nonetheless, that system model doesn't have to matter. A published, 
official FAQ entry (or even a blog post) can be used as evidence 
in a trial, so a FAQ entry that clearly states that all bundled native 
and mezzanine code is "part of the interpreter" would be sufficient 
to make it so our scripts whouldn't be affected by R3's GPL at runtime. 
Without such a FAQ entry it could be plausibly argued in court that 
your code is dynamically linked to GPL'd code, which would then extend 
GPL requirements to your code. With the FAQ entry, it's unambiguous.

'or we could get a FAQ entry declaring that the functions built into 
R3 are "part of the interpreter" rather than "library code"' - that 
is where I do agree with you, except for the fact that we do have 
such an indication:


1) the functions *are physically/* part of the interpreter, they 
are "linked into it" (I would say "statically", since the interpreter 
does not need to look for them "elsewhere in the system", they are 
"inside")

2) the functions are a part of the interpreter, the interpreter documentation 
specifically mentions the functionality of the interpreter (the documentation 
mentions that the "ordinary version" of the interpreter "understands" 
FUNC, DO, PARSE, whatnot...)

In the official statements that refer to the versions of R3 that 
have the current system model (approx. the last dozen versions), 
the functions included with R3 are referred to as the "Runtime Library". 
The other online docs haven't been updated to reflect the current 
system model, and most of them haven't even been updated for R3 yet, 
still referring to their R2 behavior. There are indications either 
way, enough to drive a trial through. We need an unambiguous published 
statement to be sure we won't be sued for using R3, or that at least 
such suits will fail.

So, would this mean that you maintain eg. the one curl binding for 
red/system and then also use the same for R3 ?

I don't understand the example. My imagination was, that I will have 
some make-native function or make-extension in R3, and somehow very 
easily I just plug in the red/system code, without the need of knowledge 
to cumbersome and cryptic R3 extension interfacing at all - I don't 
want to know anything about RX_Init etc functions ...

Currently it only works on Windows, and you need the dyn-lib-emitter 
branch of Red/System
 I did n't know you have a Windows machine ;)

Do the Red/System programs work?

Please also test the Red/System examples. They're more extensive

Just noticed I have a folder (Red and within that there is a folder 
System)  :D

Kaj, How do you want the results of the Red/System test back?

From http://msdn.microsoft.com/en-us/library/abx4dbyh(v=vs.80).aspx:


What is the difference between msvcrt.dll and msvcr80.dll?

The msvcrt.dll 
is now a 

known DLL," meaning that it is a system component owned and built 
by Windows. It is intended for future use only by system-level components."


Looks like another Windows oddity, so I guess XP users needs to install 
msvcr80.dll...testing that on my fresh new XP image.

In most cases, the name of the binding tells you which library you 
need. Then find the official site, the official download for your 
system and see if you need any dependencies

Rebol [Purpose: {make wikibook entry}
Author: "Max Vessi"
version: 2.0.0
]
my?: func [
    "Prints information about words and values."
    'word [any-type!]

    /local value args item type-name refmode types attrs rtype temp
][       
    temp:  copy ""
    if all [word? :word not value? :word] [word: mold :word]

    if any [string? :word all [word? :word datatype? get :word]] [
        types: dump-obj/match system/words :word
        sort types
        if not empty? types [
            print ["Found these words:" newline types]
            exit
        ]
        print ["No information on" word "(word has no value)"]
        exit
    ]
    type-name: func [value] [
        value: mold type? :value
        clear back tail value
        join either find "aeiou" first value ["an "] ["a "] value
    ]
    if not any [word? :word path? :word] [
        append temp reduce [mold :word "is" type-name :word]
        exit
    ]

    value: either path? :word [first reduce reduce [word]] [get :word]
    if not any-function? :value [

        append temp reduce [uppercase mold word "is" type-name :value "of 
        value: "]

        append temp either object? value [ reduce ["^/" dump-obj value] ] 
        [mold :value]
        exit
    ]
    args: third :value
    append temp  "= USAGE: = ^/ "

    if not op? :value [append temp reduce [ uppercase mold word " "] 
    ]
    while [not tail? args] [
        item: first args
        if :item = /local [break]

        if any [all [any-word? :item not set-word? :item] refinement? :item] 
        [
            append temp reduce [append mold :item " "]

            if op? :value [append temp reduce [append uppercase mold word " "]
	    value: none]
        ]
        args: next args
    ]
    append temp  "^/" 
    args: head args
    value: get word
    append temp "^/= DESCRIPTION: = ^/"
    either string? pick args 1 [
        append temp reduce [first args]
        args: next args
    ] [
        append temp "^/''(undocumented)''^/"
    ]

    append temp reduce [ "^/^/"uppercase mold word " is " type-name :value 
    " value."]
    if block? pick args 1 [
        attrs: first args
        args: next args
    ]
    if tail? args [exit]
    while [not tail? args] [
        item: first args
        args: next args
        if :item = /local [break]
        either not refinement? :item [

            all [set-word? :item :item = to-set-word 'return block? first args 
            rtype: first args]
            if none? refmode [
		append temp "^/= ARGUMENTS: =^/"
                refmode: 'args
            ]
        ] [
            if refmode <> 'refs [
                append temp "^/= REFINEMENTS: =^/"
                refmode: 'refs
            ]
        ]
        either refinement? :item [	   	  
            append temp reduce ["*'''" mold item "'''"]

            if string? pick args 1 [append temp reduce [" -- " first args] 
	    args: next args]
            append temp "^/"
        ] [
            if all [any-word? :item not set-word? :item] [
                if refmode = 'refs [append temp "*"]
                append temp reduce ["*'''" :item "''' -- "]

                types: if block? pick args 1 [args: next args first back args]

                if string? pick args 1 [append temp reduce [first args ""] 
		args: next args]
                if not types [types: 'any]
                append temp rejoin [" (Type: " types ")"]
                append temp "^/"
            ]
        ]
    ]
    if rtype [append temp reduce ["^/RETURNS:^/^-" rtype]]
    if attrs [
        append temp "^/= (SPECIAL ATTRIBUTES) =^/"
        while [not tail? attrs] [
            value: first attrs
            attrs: next attrs
            if any-word? value [
                append temp reduce  ["*'''" value "'''"]
                if string? pick attrs 1 [
                    append temp reduce [" -- " first attrs]
                    attrs: next attrs
                ]
                append temp "^/"
            ]
        ]
    ]
    append temp "^/= Source code =^/"
    append temp  reduce ["<pre>" join word ": "]
    if not value? word [print "''undefined''" exit]
    either any [native? get word op? get word action? get word] [
        append temp reduce ["native" mold third get word]
    ] [append temp reduce  [ mold get word "</pre>"] ]
    editor temp
    ;write clipboard://  temp
    exit
]

Kaj, do you have specific instructions for running test apps? e.g., 
for Red/System on Windows, should all GTK stuff work, or does it 
require other installations?

Basic MS DOS Red tests ran fine here.

\Red(System) Testing\MSDOS\Red>hello
Hello, world!
?a??e, ??sµe!
??, ??
Dobry den svete

\Red(System) Testing\MSDOS\Red>Fibonacci.exe
Fibonacci 40: 102334155

Doc, it's firmly an 8-bit CPU emulator, but it can certainly serve 
as a general example to implement other emulators in Red/System

Yay!

$ ./r3 --do 'print system/version'
2.101.0.4.4

Of course, but Red will always be a lot slower than Red/System

Looking for a direct link that I can give someone to download the 
latest red and red/system windows binaries

Looking for a direct link that I can give someone to download the 
latest red and red/system windows binaries

But you need the SQLite library from the Red/System directory:

Anyway, as I've announced many times, if you don't want to deal with 
the versioning system, you should just download everything in one 
package:

I'm just using the standard functions in the C library, so the details 
are up to the operating system

I'm just using the standard functions in the C library, so the details 
are up to the operating system

 - aha, so different interpreters will yield different random numbers?

Hi Ladislav, I have tried to make a random function in Red (Red/System) 
I saw your name in theR3 source too. That is Knuth's algorithm adapted 
for R3 and adaption to REBI64 type so you made 62 digits possible.

But my problem with Red/System is amongst others no array, so you 
would keep administration using pointers, but than comes the question 
where to keep it? What starting address to use. And so on :)

But indeed I do think for such relative simple algorithms you would 
not use calling of C functions unless you want speed etc.

@Kaj, I heard you ;) That would be on http://static.red-lang.org/red-system-specs.html
about section 14.1 examl=ple using malloc I guess. I have very limited 
time off atm :(

Is this the expected behavior ?

>> do %download.r
Script: "Download or update all Red(/System) extensions" (none)
Target test
Opening Red-test.fossil failed
Target common
Opening Red-common.fossil failed
..
..
And then there are many empty directories.

A free compiler? Red and Red/System are the free compilers

Bo, Rebol2 is used to create the Red/system binaries

I'd sponsor work on engineering a new chat system.

Routine are basically Red/System code which require a compilation 
step, so it can't run as-is in the interpreter.

All fine now. I've switched the Syllable build system to the community 
source:

http://syllable.cvs.sourceforge.net/viewvc/syllable/syllable/system/apps/utils/Builder/packages/REBOL-Core--current/

Kaj, what is the system/version of your build?

, i.e. if you really get identical builds when getting identical 
system/version

Yes, but there already are some Rebol scripts examining system/version 
to "know how to call system libraries" or some such. I guess it may 
be a good reason to define a platform?

Yes, that would be a good reason. In my patches to port Python, for 
example, I solve it by looking if the /system/index/ directory exists, 
which would identify not only Syllable Desktop, but also Syllable 
Server

http://syllable.cvs.sourceforge.net/viewvc/syllable/syllable/system/apps/utils/Builder/packages/Syllable/REBOL-Core--current/

We get hits from many of the same search phrases as Linux, since 
most of the same software is in Syllable, and we have an extra Linux 
system

I added Fork's preliminary R3 port of Red to the build system, with 
an overlay for Syllable Desktop so it can be experimented with there:

http://syllable.cvs.sourceforge.net/viewvc/syllable/syllable/system/apps/utils/Builder/packages/Red--current/

http://syllable.cvs.sourceforge.net/viewvc/syllable/syllable/system/apps/utils/Builder/packages/Syllable/Red--current/

Yes, I wanted to do that even before EC2 opened up, to get a business 
model going. But regardless of their promises, after all these years 
they still don't support their payment system outside the US