• Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r4wp

[#Red] Red language group

BrianH
20-Oct-2012
[2952x2]
The same method that is used for compressed scripts could be used 
for encrypted scripts too, or for precompiled modules that you are 
packaging together. The same method used for checksums could be used 
for cryptographic signatures as well.
This also lets you store scripts or modules in databases too.
DocKimbel
20-Oct-2012
[2954x2]
You should take upcoming red|rebin format also into account. That 
might be a preferable method sometimes rather than compressed scripts. 
Red will pre-compile most of the scripts content, but we might keep 
some "code" blocks in source form for reflection (when used by the 
script and inferred by the compiler).
I wanted to publish my redbin specs earlier, but stopped when I read 
that R3 might use a copyleft license.
BrianH
20-Oct-2012
[2956]
The community is leaning more towards Apache now, so as long as you 
don't patent redbin (or grant use of the patent) it would be usable.
DocKimbel
20-Oct-2012
[2957]
An asymetric permissive licensing model between Red and R3 might 
prevent me from publishing info about what we'll do next, to prevent 
the features from being implemented first with a copyleft license 
attached. It would just be unfair to Red, so I would have to be cautious 
about that.
BrianH
20-Oct-2012
[2958]
Don't underestimate the value of treating the header and the rest 
of the script differently. It lets you put a lot of static information 
in the header without even looking in the sctipt data at all.
DocKimbel
20-Oct-2012
[2959]
Right, the header is a great source of metadata.
BrianH
20-Oct-2012
[2960]
Yes, most of us are wary of copyleft licenses for that reason.
DocKimbel
20-Oct-2012
[2961]
If Carl is really honest about cooperation, he should just pick one 
of the permissive licenses and be done with it.
BrianH
20-Oct-2012
[2962]
Given that he's getting advice from Rosen, something like Apache 
seems likely. He has already shown a certain scepticism for the need 
for copyleft in this case. One can hope, at least.
Arnold
21-Oct-2012
[2963x3]
I threw in a hint for a new license, the URL or Unified REBOL License, 
for the best of both worlds.
Given the momentum on Red and huge potential, the similarities to 
the original. To me the wait on the license almost cannot take long 
enough. But waiting is boring and the longer it takes that is not 
in the interest of any party.
Sorry that should have landed in Licenses.
DocKimbel
21-Oct-2012
[2966]
Doc-strings are now allowed in Red/System function spec:

https://github.com/dockimbel/Red/commit/b7f46eafe75b43f43d7cb282d4415e89c2858a5e


So, who's going to write a short and nice REBOL script now to extract 
them (extracting also the context where they are defined)? :-) Ideally, 
those info should be collected into a simple nested block structure 
that can be easily processed for generating formatted text output, 
HTML, PDF (using pdf-maker lib), ... (take make-doc.r script as example 
of parser/emitter separation, and plugable emitters).
Endo
22-Oct-2012
[2967]
Another 30 euro for the great works..
DocKimbel
22-Oct-2012
[2968]
Thanks Endo!
Endo
22-Oct-2012
[2969]
You're welcome! I use Cheyenne too in my business and I didn't donate 
for it before, so I feel guilty a bit, and do it for Red :)
DocKimbel
23-Oct-2012
[2970]
Merge of 0.3.0 branch into master done. Do not use v0.3.0 branch 
anymore for new commits.
Pekr
23-Oct-2012
[2971x2]
I have just succesfully run demo.exe and got nice Ascii Red, created 
from Red letters :-)
The executable file size is 59904 Bytes, quite big :-)
Henrik
23-Oct-2012
[2973]
isn't there a Red interpreter in there?
DocKimbel
23-Oct-2012
[2974x5]
No, it's Red runtime.
Mainly: memory manager and all datatypes.
Also, the literals series construction is taking much more space 
than it should. The boot.red script is precompiled and stored as 
code in all binaries, we should rather keep it in compressed source 
form or, even better, in redbin format. But currently, precompilation 
is the only option we have.
When I write "Red runtime", you should read "Red runtime library".
Also, we only have ~200 unit tests for Red so far, so I'm unsure 
how stable is the current Red codebase. In a few weeks, we should 
have enough features to port QuickTest to Red, then we should be 
able to have an exhaustive test coverage.
Henrik
23-Oct-2012
[2979]
DocKimbel, alright. I take it, the somewhat equivalent in REBOL would 
be to encap a REBOL/Core? That would of course be much bigger.
DocKimbel
23-Oct-2012
[2980]
Exactly.
Henrik
23-Oct-2012
[2981]
ok, then 59 kb is nice :-)
DocKimbel
23-Oct-2012
[2982]
The current runtime library will grow quickly, I expect it to reach 
150-200KB with all actions/natives/datatypes + network protocols.
Henrik
23-Oct-2012
[2983]
will it be possible to not include unneeded parts?
DocKimbel
23-Oct-2012
[2984x2]
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
Henrik
23-Oct-2012
[2986]
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.
DocKimbel
23-Oct-2012
[2987x2]
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.
Pekr
23-Oct-2012
[2989x2]
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 ....
DocKimbel
23-Oct-2012
[2991x2]
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?
BrianH
23-Oct-2012
[2993]
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.
DocKimbel
23-Oct-2012
[2994x2]
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.
Pekr
23-Oct-2012
[2996x3]
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 ....
GrahamC
23-Oct-2012
[2999]
DLL hell?
Pekr
23-Oct-2012
[3000]
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 ...
Andreas
24-Oct-2012
[3001]
DLL hell always started as "just one shared lib" :)