World: r4wp

It depends how you define "unneeded parts". It's more complicated 
to define that it seems at first look. For example, you might want 
to drop date! type from runtime library if your code is not using 
it...but if you LOAD some external data that might contain some date! 
values, you'll have a problem.


Anyway, we'll provide options for stripping from end binaries everything 
that can be stripped without altering program behavior.

*than

ok, I was just thinking in terms of, say, not needing networking 
or FTP protocols for a very specific app. I don't think it would 
be a good idea to eliminate datatypes, although perhaps it makes 
sense in some cases.

Also, currently ARM binaries are about twice larger than for IA-32. 
It has several causes, costly 32-bit literal handling in ARM, 32-bit 
fixed size instructions,.... We'll deal with these issues mainly 
during the rewrite process of Red and Red/System. Possible solutions 
are:


- good literal pool allocator (there's an optional one currently 
in ARM backend, but not good enough for big apps).

- code optimizations that will reduce the number of 32-bit literals, 
like good registers allocation.
- support for Thumb instruction set.

Henrik: networking protocols at mezz level shouldn't take much space. 
In compressed souce form, each should weight only a few KB.

hmm, I thought, that once compiled = you know what is resolving to 
what, we end up to some 5KB to 100 KB max. Other than that, we are 
really not much different to REBOL/Core, which is really bad, thinking 
of the kind of e.g. Android apps, which will require the "interpreter", 
to be always built in.

as I think about it, it would be best to have some kind of interpreter/library, 
which would download just once, and then only the app package would 
be downloaded. But that's just most probably prohibited by mobile 
platforms. Having just each "hello world" app to take 60KB etc. is 
a bit too much ....

I thought, that once compiled = you know what is resolving to what

 Certainly not possible with a REBOL-like language, as it needs only 
 one "unresolvable" expression to force you to attach whole runtime 
 library.


Don't expect any Red app to fit in 5KB or anywhere close, that would 
be magic, not computer science. Higher-level abstractions have a 
cost, if you don't want to pay for them, there's Red/System.


There's also no "magic" in compilation, some expressions can be reduced 
to very close to CPU counterparts, most can't. Don't expect the first 
Red alpha bootstrap compiler to do extensive optimizations (it does 
none currently). Also, a sentence you will probably hear from me 
very often: "Don't expect a v0.3.0 to be a v1.0.0!".

Having just each 

hello world" app to take 60KB etc. is a bit too much ...." You're 
not having the right metrics in mind. What matters is not the size 
of a "Hello World" app, but size of a real app. A typical real app, 
like with REBOL + /Encap, will be just a few dozens KB bigger than 
the runtime library. So, most Red apps will be less than 500KB and 
still less than 1MB for really big ones (not counting additional 
resources data). A "Hello World" using Appcelerator (one of the leader 
in Android dev tools market) is around 600KB. Also have a look at 
the size of apps installed on your Android devices, most of them 
are bigger than the typical apps size Red will produce.


If you want to compare with app size that Java can produce, take 
Red/System in order to compare apples to apples. Anyway, Java apps 
are cheated, because the JVM is built in Android. I don't remember 
seeing any way to install a shared library across different apps 
on Android, but maybe there's a way?

Any app that can convert string/binary data into internal datatypes 
like blocks and such will pretty much need the whole datatype collection 
and their associated actions. That's most of a Rebol-like language 
right there. Given how rare Rebol-like apps are without those features, 
we are better off making the runtime efficient rather than trying 
to figure out how to break it up.

For more open platforms, you'll be able to compile your Red apps 
to a binary with externalized runtime library (in form of a shared 
library pre-installed or to install with the app).

The efficiency of Red will mainly come from the optimizations we'll 
add to the compiler that will "unbox" some expressions and bypass 
the runtime library. Anyway, we'll also improve performances and 
reduce size of runtime library as much as possible, but you shouldn't 
expect the biggest gain from there.

Ah, that's it, stupid me - it makes sense. All the wonder was, because 
I compared it to previous hello world, which was done using Red/System 
though ...

As for shared lib, etc, eg Apple strictly prohibits any kind of runtine 
IIRC, so some idea of having REBOL there (an interpreter, runtime), 
which would just run scripts, is not allowed imo. Not sure about 
the Android, but I expect just the same. Well, maybe Red will become 
so popular with Google, that it gets into the distro by default :-)

But thinking about it, those mobile platform policies make it really 
innefficient. I know that most app you download, are just megabytes, 
but still - why not to allow a runtimes to find their shared place 
on the device? Then, all your apps would need just kilobytes of the 
traffic, and mobile operators would be happier. But maybe it is not 
easily technically solvable on such OSes, who knows ....

DLL hell?

Graham - do you regard having REBOL/Core interpreter of certain version 
available being a DLL hell? We are talking about just ONE shared 
lib, a runtime for certain language. Anyway - the discussion is most 
probably meaningless, for Red architecture itself, and even more 
so for the mobile platforms, well, just in my opinion ...

DLL hell always started as "just one shared lib" :)

We'll do our best to spread libRed everywhere. ;-)

Pekr, runtimes interpreters are allowed on iOS now, as long as they 
are approved by Apple. What is prohibited is running external scripts 
or scripts downloaded from the internet. All interpreted scripts 
need to be bundled with the app, so the app can be evaluated as a 
whole by the app store gatekeepers. I've given this some thought, 
and it may be possible to cripple an R3-like interpreter sufficiently 
to meet these criteria; all you need to do is put some limits into 
the LOAD and DO mezzanine code. Red could be similarly crippled if 
you want.

So, 0.3.0. is merged - will there be any official announcement/follow-up, 
or are we silently moving forward?

As I said before, I'll announce it officially. I still have a couple 
of things to do before: decide about one bugtracker ticket and write 
the blog entry to announce it. :-)

I've cleaned up the open tickets today and created a wish list page 
in the project's wiki on github.

Freddy reports a number of strange problems with the MSDOS and Darwin 
versions of the test binaries. I'll relay more when I get more info 
from him

Kaj: do you have more info about that? Just to know if releasing 
0.3.0 tonight is safe or if I should wait more?

HI Kaj, I download Your Gtk Bindings and and GLib too, put it in 
red-system directory (it's a write place ?) and I have too problems:

first  error in GLib line 35 %include ../common/common.reds and it's 
runtime/commons.reds. After correction i

-= Red/System Compiler =- 
Compiling RedGTK/examples/hello-GTK-world.reds ...
*** Compilation Error: alias name already defined as: [struct! [
        item [c-string!]
    ]] 
*** in file: %runtime/common.reds 
*** at line: 62 
*** near: [
    str-array!: alias struct! [
        item [c-string!]
    ] 
    typed-value!: alias struct! [
        type [integer!] 
        value [integer!] 
        _padding [integer!]
    ]
]

I am not shure this is all clear :) but if you can help......

You need the Red-common repository, too, installed in a subdirectory 
called common/. Same pattern as GTK and GLib. See the Announce channel 
a few announcements back

You're confusing it with a Red/System file called common. They have 
nothing in common ;-)

Thanks Kaj ! I have My "Hello Red/system GTK+Hello World !"  :) I 
have to reed some docs and wait for Red 1.0 .. does it come whit 
some hight level VID or RedGUI ?

Not yet

Freddy has the following problems on Windows 7 Home Premium:

Alvira thinks there's a Trojan in Red/Hello.exe and Red/Fibonacci.exe 
( TR/Crypt.XPACK.Gen )

Access denied on executing all exe's in MSDOS/Red

:(

hello-unicode in MSDOS:

Hello, world!
+º+¦ß+û¤ü+Á, +¦¤î¤â+++Á!
õ¢áÕÑ¢, õ©ûþòî
Dobr+¢ den sv-øte

Not like in linux.....

Indeed

Mac mini Intel Core Duo:

Only RedSystem/empty returns to prompt. Rest hangs (hello, Fibonacci, 
Mandelbrot)

OK, thanks for your time, I have to see my bed... tomorow long day 
of Irish music and maybe long night ;)

Have fun :-)

Antivirus alert: I've scanned Hello.exe with virustotal.com, no virus 
signature detected at all:

https://www.virustotal.com/file/ecde1916047993067be692235fb87352860b4596f5a2d54ba7efbf7482bcbe3a/analysis/1351329447/

Fibonacci.exe does raise some alerts from a few AV:

https://www.virustotal.com/file/6a86ef360727e907b6fc8cd7f9c0607a3ccb11f8f953747167b349dc43d6bf8a/analysis/1351329779/


I will look into these false positives signatures to see if I can 
improve that. Not sure it will be possible if they are caught by 
undocumented heuristics...

hello-unicode in MSDOS: has he switched the DOS console to Consolas 
font?

I get virus alerts all the time from red. I just turn it off. The 
only thing that ever got as many hits as red was rainbowforth which 
was another very minimalistic program. AV programs seem prejudiced 
against small executables :(

I've sent a few info requests to various AV vendors, I hope to get 
some clues about what's triggering their heuristics.

I will release v0.3.0 in a couple of hours, if you want to do some 
tests to track regressions, that would help.