AltME groups: search

Not a big deal to implement though, just time-consuming.

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).

(And an index that does not correspond to a value in the series, 
at this point in time.)

I would hardly ever use elect* actions as I almost never use first, 
second... actions. Actually my english is so bad that I see elect 
for the fist time:)

I would just like to know if it's an issue (the 0 gap) you hit once 
in your lifetime or if it's something people encounter from time 
ot time or even often (depending on the coding style).

Hard to answer that now, but as the optimizing compiler will have 
a plugin architecture, it won't be limited, in the sense that you'll 
be able to add your own specific code optimizations, that if generic 
enough, could make its way into the official   repo. If the optimization 
processing time is short enough, it can be used for the JIT, else, 
it will be used only in for AOT compilations.

Jerry: I don't have enough time for that, I am counting on the doc-strings 
and extraction tool to generate such documentation automatically. 
Peter is working on such tool.

I still fail to see a real-world use-case where you need both negative 
and positive indexes at the same time (in other words, compute indexes 
*over* current position). Even in such rare case, you can still do 
the computation using INDEX? SKIP values (so switching to absolute 
indexes instead of relative ones).

I am able to do any work-arounds necessary at any time. However, 
I prefer to use a working solution.

Ladislav, thanks for bringing a tangible example that demonstrates 
our both points. I will try to be brief:


1) I will start by repeating again that nobody contests that having 
a continuous numbering is better than a discontinuous one (for pure 
arithmetic efficiency, as you've showed).


2) Brian showed that R2 is not "broken" as the head-index? function 
can be written. 


3) I have never needed to write such "workaround" in R2, nor did 
I remember seeing it in others code (if someone did use such workaround, 
please step in, we need real-world use-cases).


4) According to 3), I think the issue you are showing with head-index? 
function covers extremely rare use-cases. 


5) I often use series with an offset and I do index computation on 
them, but usually, in a single direction at a time (using only positive 
*or* negative indexes). In the very rare cases where I need an index 
computation "over 0", I switch to absolute (from head) indexing, 
but not relying only on index arithmetic, but also on series navigation 
using the INDEX? SKIP idiom. This short idiom gives exactly what 
your head-index? function gives to you, but using series navigation 
abilities rather than pure index arithmetic. Of course, it works 
because SKIP is an implicit 0-based system with no hole.


6) INDEX? SKIP in R2 solves the "hole issue", for the very rare cases 
where we need to solve it. So, allow me now to propose my own head-index? 
implementation:

    head-index?: func [s [series!] i [integer!]][index? skip s i]


It is not pure arithmetic for sure, but we are programmers, not mathematicians 
(except you who is both :-)), so this solution is IMHO as acceptable 
as pure arithmetic ones, from a programmer's point of view.


So, what I contest is the trade-off required for "fixing" index arithmetic 
in R3, resulting in IMHO "broken" PICK and path notation for 0 and 
negative indexes. Also, given that INDEX? SKIP is available in R2, 
the "fixing" seems even less necessary. Still, I am open to discussing 
options for improving index arithmetic but *without* having to break 
other features.


I think we will agree to disagree about the right trade-offs between 
R2 and R3.


So, can we now all focus on studying the different improvements proposed?

For example, when traversing two series at the same time while using 
just one index variable (which is pretty common), you need to be 
able to use the variable to correctly point to the corresponding 
places in both series, which logically *needs* some version of "index 
arithmetic".

'So, what I contest is the trade-off required for "fixing" index 
arithmetic in R3, resulting in IMHO "broken" PICK' - this is the 
main point, as I see it. If I remember well, you consider PICK broken 
since "0 points (maybe unnaturally for you?) backwards for PICK"? 
If that is what you dislike, then I can sympathize, having similar 
feelings:


It is necessary to realize what PICK SERIES INDEX is supposed to 
do. In my opinion it is a "relative operation" (relative to the current 
series "index" - having two series with common head but different 
"indices" we expect the PICK function to yield different results). 
Us such, we need to realize that we already have a "relative operation" 
for series for quite some time, which nobody contests to be "relative" 
- it is the SKIP operation. So, we have SKIP SERIES I being relative 
and we should have a natural obtain-value-of SKIP SERIES I shortcut 
instead of the whole nonsense, which is what you instinctively do 
presenting your (in R2 wrong!) HEAD-INDEX?.

BTW, 0 is the reason why many arithmetic algorithms work, so getting 
rid of 0 helps only to get back in time before 0 was invented, to 
the time when those algorithms did not exist. (the word algorithm 
itself is actually pointing to the city where a zero proponent and 
matmenatical giant Muhammad ibn Musa lived).

FYI, it means at least 1282 years back in time, but, actually, much 
more, taking into account that even before some nations used 0 successfully.

Now Red supports 21 datatypes. In the following R3 datatype list, 
datatypes with a minus prefix are not supported in Red yet.


action -binary -bitset block char -closure -command datatype -date 
-decimal -email -end -error -event -file -frame function get-path 
get-word -gob -handle -image integer -issue -library lit-path lit-word 
logic -map -module -money native none -object op -pair -paren path 
-percent -port -rebcode refinement set-path set-word string -struct 
-tag -task -time -tuple -typeset unset -url -utype -vector word

to be exact R3 is 300-500 time slower than c compiled code in my 
last tests.
So at least Red should be at leatst 30-50 times faster than Rebol

Arnold, the time does not include the compilation. That's a one-time 
operation, so it would be unusual to include it

Not really on the run-time performance, it will boost compilation 
time only. The main motivation for being self-host is the JIT-compiler 
(we need to embed the target compiler in Red runtime).

I have used FOURTH once or twice, a long time ago, never used others 
above that.

Possible to port Red to RISC OS too? Or a lot of work too %Y\ ?

I could contribute to the wiki (which one are we talking about here?) 

Now I have my 10x10 checkers game in Version 1.0.0 released I have 
some time to spend on the script Doc asked for. Can the specifications 
be reposted please?

VID-like: definitely. Not only because it is a simple and efficient 
way to build GUI, but also because it nicely shows the power of dialecting, 
applied rightly, so it "validates" the whole concept behind REBOL 
and Red. 

I was planning two approaches:


- prototype a VID dialect for cross-platforma native GUI once we 
have the right interfaces between Red and Red/System. (That part 
will include also mobile platforms, if possible, else, they will 
have rely on a mobile-oriented GUI dialect). I will probably start 
to play with it around Christmas, and try to reach an alpha/beta 
in Q2 2013.


- prototype a VID dialect for HTML frontend, having GUI frameworks 
as backend targets (Sensha, jqueryUI,...). The hard part here is 
abstracting the client-side coding, Topaz would be great for that, 
if Gabriele can find time to continue working on it. Else, I will 
need to work on my own Red to JS compilateur.


It would be also nice to have a wrapper over R3/View or a Red/System 
port of it, but it would need contributors to take it in charge. 
There are also more possible GUI options.

Curious too about time frames for file access, network protocols, 
2D drawing API, sound, etc.  Are those things on the horizon yet? 
 Looking forward to when you can port higher level things like mysql 
dialect, games demos, etc.

Great explanations Nenad! My apologies if sometimes I seem to ask 
for the known things.. 


For the documentation we need a Red marker pen and mark the REBOL 
documentation where appropriate for Red.

I took a little time (just 5 minutes LoL) to see if I could find 
a starting point for the documentation extraction script from the 
suggested makedoc2.r script but 'parse is not my best REBOL skill.


Besides graphics and a killer application as Pekr described, having 
CGI support for Red can bring a lot of attention to Red too imho. 
(And this could bring financing Red up too when Red programmers are 
making money making websites using Red.)

Docs are always a hard question. I have always appreciated the docs 
that Carl and others spent time and care creating; the old Core manual 
appeals to me. Wikis are good for many things, though I seem to lose 
or confuse wiki logins more than other accounts, and their presentation 
rarely impresses me. It's an easy way to make things open for contributions 
though.

I do remember the times when Win95 came. All the world was claiming 
- your apps need the menu, a toolbar, etc. Free style Amiga like 
apps were a dirty world. Now, 15 years later, such aproach looks 
archaic, laughable. The time has changed. Let's target mobile platforms.

And I even don't agree with Henrik. I really can't see, how your 
top-down aproach might work. You need a solig gfx engine (View), 
general enough, to build up. Carl's GUI was OK. And imo Saphirion 
did a bad mistake - we heard, for so long time, that the look is 
the final step. All those years, and the look is really a crap. Much 
worse, than what Carl brought up, even if I can see many improvements 
in engine itself. Look sells, take it, or leave it, and then - please 
don't even try to do your own GUI. No matter how good it is, if it 
looks like 80'ties Solaris, it will never get accepted ...

Pekr, the look is only crap, because I don't have time to work on 
the skin yet.

I want ALSO View/VID, which is being kind of dismissed here both 
by Doc and Kaj :-)

 Absolutly not, I'm just saying that I will build a native GUI solution 
 first, a View-like solution is not my priority but it is welcome. 
 If nobody makes a View-like engine, nor wraps R3/GUI engine, I will 
 consider making one myself when I will have more time.

I do not want to make you look dumb Petr. My goal is to save us all 
time and keep important information stored, so we don't have to go 
through the same discussion(s) again. I will put your final wishlist 
note in the file, so when this comes up again, you can just direct 
people to it. See, I'm saving you time too. :-)

AltMe is really bad for keeping up with more than one single topic 
at a time. The discussion about the Red documentation slipped away, 
while being a very important question to me where I need feedback 
and inputs. So I would like to resume it. 

What should Red reference documentation look like ideally?

On the subject of hot-patching, I've thought for a long time that 
the ability to instrument apps--like DTrace--would be very helpful. 
I know DTrace is deep kernel voodoo, and not available on all OSs. 
If Red supported probe points for DTrace, that would be great for 
those who use it. My question is whether it would be better to use 
a DTrace model, where the analysis happens from outside the app, 
or if having an instrumentation/tracing/logging model internally 
is better. Or can you support both with the same set of probe points 
in an app?

I might make a 0.3.1 release tomorrow to set a milestone for functions 
support. If you have Red scripts, it's time to test them with latest 
commit.

I agree that objects should be used sparingly, but not being able 
to expand them makes it expensive to implement VMs for substantial 
dialects. I did that and started out with blocks only, but over time 
I had to decide to use objects in places crucial to the user dialect

I am a bit short on time for testing on all platforms, did anyone 
find any regression in Red before I release v0.3.1?

It would be really nice to have automatic builds+tests running on 
all major supported platforms for each new commit on main branch, 
and an automatic report generated online. That would really saves 
us time and avoid missing some obvious regressions.


I know that Andreas started working on that. Andreas, do you already 
have a good plan to achieve it?  Do you need help/resources?


I can provide a Linux server for Linux/x86 targets. Having a Windows 
machine online + MacOS X would be great. Also a Linux/ARM (RPi for 
example) that is always up and reachable from the net could nicely 
complete the list.

youre welcome my friend ;) Did you find time to read my latest reply 
on the mailing list?

Arghhh! My first time compiling something to Red:
-= Red Compiler =-
Compiling red/tests/sorting.red ...
*** Red Compiler Internal Error: Script Error : copy expected ran
ge argument of type: number series port pair
*** Where: process
*** Near:  [stack/push to type copy/part s]

I like having the numbers in binary! values, but not as much for 
this. My brain says "this is a binary in base 16 notation", but for 
hex or binary literals, I want to think of the words 'hex and 'binary, 
rather than "this is a base-16 number, which means it's in hex format". 
I think I looked for alternate notations a long time ago. Have to 
see if I can find my notes.

In REBOL, 'a and 'A are aliases of the same symbol. Red/System converts 
them to their integer identifier, right?


Symbols have two representations in Red compiler, one is at runtime 
(like in REBOL), the other is a compile-time, in the form of Red/System 
variables. In a very early version of the compiler, I was using integers 
(indexes in symbol table) instead of variables, but quickly realizef 
that it was obfuscating the generated Red/System code a lot, making 
it difficult to debug. Also, the integer approach had an additional 
runtime cost at it required to make an array access in order to retrieve 
the symbol value.


Currently, the Red/System ~<name> variables directly point to a word! 
value version, instead of a symbol! for simplicity and efficiency.

I have implemented a compile-time aliasing system for same words 
but different casing. It works fine so far and is cheap compared 
to other options (it requires a conversion table (symbol->alias) 
to be maintained during the compilation).

Yes I wanted to give it a try for the doc scripts. But parse is not 
my expertise, and at the moment I am short in time as I can make 
extra hours at work. So everybody step in please and publish your 
baby-doc-scripts so we can all contribute little bits.

This is a code pattern I use often, but always find it annoying to 
have to add a to-logic call each time in front of refinements.

I haven't had time yet to think about such replacement solution, 
so ideas are welcome.

Actually, I still haven't found time to read the whole R3 sources 
base. I was too busy this week designing some new parts of Red.

Doc, will you spend some time making Red/Sys support loop BREAK/CONTINUE 
in the near future? or at least GOTO. Thanks. Programming without 
them is like drinking soup without a spoon ...

Doc, it wpuld be nice to have cool console, if time permits. Do you 
remember r2 one, with possible cursor positioning? Fond rememberance 
of Amiga and color console :-) Really, some of my user experience 
of r3 was destroyed by crappy console experience ....

@ Doc : Will the interpreter have included (some time in the future) 
some of the debug features planned for R3 (Hooks, stack ops, etc...) 
? That would be nice but it's just my wish list ;-)

Currently yes, I thought making a ncurses-based one too, but my time 
was sucked out by bugfixing.

@Doc : About the R2/R3/Red console enhancements, I've always missed 
the MS way to move/select  from left to right (on a word by word 
basis - MOVING on a word-by-word is CTRL+left / right Arrow and adding 
the SHIFT key in combination with the CTRL means SELECT - it's that 
simple) but going to the beginning or ending of the line is at least 
a welcome start ... if we want to go this way - and then going right 
or left on a character basis - as is for now!  And for right-handed 
ppl it would also be welcome to restore the old MS way of handling 
the current left-handed ppl to do CTRL-X / C / V  - which were CTRL-DEL 
or SHIFT-DEL / CTRL-Insert / SHIFT-Insert - but this kind of thing 
I can add myself when time comes ... it's just a matter of being 
more productive - it's far from being a "caprice des Dieux". For 
opponents : If you've never experimented it - you then never used 
it either on a regular basis and you can't catch why I regret this 
not being supported anymore in recent MS software too ... but this 
is deceptive either from them since it costs so few to leave it there 
in the first place. However I must admit that on my iPhone and other 
mobile tools I will miss it in anyway - until I code my own keyboard 
for this use too !!!

Gerard: those are details that can be easily added once the cross-platform 
console will be implemented. If you or someone else will send me 
pull requests for such features at the appropriate time, I will be 
glad to accept them.

@Doc : I never thought you would do so much work in a so short time. 
If my support can help you a bit to go further and leave behind - 
with the help of the other donators - the bad feeling of having to 
work elsewhere to  get money for your living, then it's a pleasure 
for me to do it as much as I can.  Keep up the good work Doc and 
have a happy new Year form Quebec, Canada.

That's great Endo! I'm glad Doc's hard work is turning into donations, 
so he can see real support for the project from others. Kaj and Peter 
are doing a lot to help him, and I hope to make time in a few weeks 
to show my support with action as well.

Marco: some antivirus have too aggressive heuristics, there's not 
much we can do for that. From time to time, I send some reports to 
AV vendors for notifying the false positive, most of the time, they 
take it into account.


Doing a quick test on virustotal using the latest console exe, it 
seems that my reports have been successfully processed, I don't have 
the old virus reported anymore (except with Panda): https://www.virustotal.com/file/a8c189ed790fd1d5bce2d86878e85445c21880dafb4220605df4ef2e4d4f4ce5/analysis/1356894544/

What AV are you using?

I recommend you to switch to MSE (Microsoft's one), it integrates 
better with Windows and has no annoying ads and  is totally free 
(I was an Avira user for long time before trying MSE).

'm offering a matching funds drive to for Kaj and Esper Consultancy's 
work on Red.  I'll match funds donated to them by January 31, 2013, 
up to a total of $200.  If you're interested in Red, please help 
them devote some additional time and effort to this project.

If someone wants to add music, he can make a new video using gource 
and add appropriate music, I hadn't the time to  also work on the 
audio part. :-)

Symbols are structs in the Red runtime. If you have an app server 
running that handles issue!s, it will accumulate memory over time 
that you can't collect. It will be indistinghuishable from a memory 
leak

Hardly, the symbol table purpose is to provide a mapping between 
an integer value (the symbol ID) and a string representation. If 
we could allow the removal of a symbol, we would need: 


1) to be sure that a symbol is not used anymore anywhere (would require 
an equivalent of a full GC collection pass) before removing it.


2) maintain a list of freed "slots" in the symbol table for re-use.


3) being able to trigger the symbols-GC at relevant points in time.


Even with that, it would still be hard to counter a LOAD-based attack 
on the symbol table.

An altenative for preprocessor command could be
.if
(It starts in column 1 doesn't it?)

On the other hand isn;t it possible to get the meaning from the context? 
#if #define etc could be preversed preprocessor words?
(or I am on a complete other level again this time)

The compiler needs to do that at compile-time, so it needs to recognize 
what is a function! call and what is not.

Red/System is in beta stage. Whether or not it is a good choice for 
a GUI app is matter of personal taste. I personally gave up building 
GUI apps in a C-level language a long time ago. However, if you want 
to give it a try, I recommend you Kaj's GTK+ binding, which now works 
fine on Linux ARM, as shown here: 

http://static.red-lang.org/rpi-gtk-widgets.png

You can see the source code for this GTK+ demo here:

http://red.esperconsultancy.nl/Red-GTK/artifact/3453dd410a1c64ca8f842f75c7431b6f7fc3c4b3


As you can see, Red/System has some limited dialecting capabilities 
that Kaj leveraged to build a very nice GUI dialect (which is quite 
an achievement for a low-level language).

Thanks Doc for sharing this information and Kaj for doing this GUI 
binding, paving the way for newcomers and sharing the source for 
deep study. When I will be going back to my former status (more free 
time) I plan to deeply study Red/System in parallel with the C language 
just to be able to write some small doc (or book) to help newcomers 
to start with Red/System after coming from the C environment. In 
fact it's a long time I planned to do it for myself first but never 
found the time to do so when I worked as a teacher in the past. Now 
I hope I will better drive my diary to cope with this new planniing 
!!!

Doc or Kaj, do you think it would be usable on my Android tablet 
- since it uses Linux on Arm as basis ? Already I can use the R3 
port from Cyphre and the console is working fine. The single problem 
I see for now is that the Red/System app is still not working on 
my tablet ... but I suppose some time in a near future this will 
be a thing of the past. Bue Doc I don't tell you this so you feel 
yourself as if you would put more time on this issue. This is not 
even disturbing me for the moment sinc in any case I don't have much 
time left for now - so even if it already worked I couldn't use it 
anyway. It's damage I don't know more by myself about all these new 
computers and environments but I have to think I'm not alone in this 
case ... Regards

Another thing: are natives more efficient than routines?

  Routines and natives are both Red/System code that use Red runtime 
  internal API, so they perform the same. In case of routines, you 
  might have a tiny overhead for integer! and logic! that are converted 
  back and forth between Red and Red/System, but it is really very 
  small, and only significant if you iterate a lot of times over a 
  routine call.


From the memory and boot time perspective, natives are more efficient 
because their body block is not stored internally  for reflection 
like routines. So, for functions like QUIT that should be part of 
Red core, it is better to implement them as natives, to save memory 
and booting time.

About reflection, will there be a compile option to turn it off, 
for commercial code that should stay closed?


What I planned so far is a compile option to switch between different 
modes of bundling the functions/routines source code into the final 
executable. Main options are: 

- in form of native "build instructions" (the current behavior)
- in form of compressed text


The latter option will generate smaller executables, but will be 
slow down boot time a little, as it will require the interpreter 
to process it. The former option provides a high level of obfuscation, 
that requires a lot of work to decompile (cracking REBOL's SDK protection 
is probably an easier job).

So the "interpreted functions" do not exists at compile-time nor 
in the executable in source form, as their are created at runtime.

The problem might be, that it has to be decided during compile time, 
so the source code would have to be analyzed. Otoh it might be the 
right place (instead of preprocessor) to fit in, along with catch, 
throw ....

Congratulations: the rhythm of changes in Red is just fast!

I scripted a little command that I run from time to time, just to 
see how both Rebol3 and Red are going:
cd ~/dev/Red/ && git pull && cd && cd dev/r3/ && git pull

And I can see through gitk that the rythm of Red's work is just amazing. 
Courage!

I would wait with the new site until it is possible and realistic 
to do it using Red.
long ago

 I explored a bit into themes for blogger that would give a better 
 fit for Red, but in the end the one chosen by Nenad turned out to 
 be far from the worst choice. (There were nice blue and green themes 
 but 'red' kind of limits the possibiities in that sense) The generated 
 CSS is like any generated webfile: big and bloated. I had no lust 
 in reducing it, spending a lot of time on it.

Time is another fine thing. The OS should support one or another 
timestamp that can be picked up and molded into a preferred representation?

#DEFINE seems to become obsolete towards version 2, no preprocessor 
anymore, so any progress on a decision?


It is not the time for taking decision about Red/System v2. For the 
preprocessor replacement, we are for now just gathering ideas in 
the wiki.

Arnold, I've said it before, but there are time and random functions 
for Red/System in my C library binding:

Arnold, I've said it before, but there are time and random functions 
for Red/System in my C library binding:
 

I must have missed that remark before. But then again, I like to 
try this using Red or Red/System as an exercise or for fun or to 
not be dependent of using C (Why not do it all in C? Because we have 
Red/System.)

That it is a target I can see now I have viewed the presentation 
a second time. Do you have a faint idea of a timeline when various 
stages of Red could become part of the real world? So version 4 in 
april and the first binary Red in 2015?

Ok, thanks. I unfortunatelly hadn't chance to check Red/System in 
last few months. I'm very glad it can be done, I have to find some 
time for Red/System again.

Bo, it depends on the code in question and the processor it's running 
on. It could be the same speed, it could be many times faster, and 
for some code it could be resolved completely at compile time and 
replaced with a constant.

Some optimizations will be very difficult or impossible to do if 
Red/System is used as the intermediate language, because those optimizations 
sometimes depend on the semantic model of the intermediate language, 
and Red/System doesn't have the semantic model of a compiler intermediate 
language. Optimization is hard work and people get PHDs for doing 
it. We can hope to catch up with modern C compilers, but don't expect 
it. One advantage is that Red is a high-level-enough language that 
an optimizer can make assumptions that a C compiler can't, so it 
is possible that we could get better code - it depends on the language 
and how much time we want to allocate on optimization.

Thanks. A website is planned, but I haven't gotten around to it yet. 
I figure the time is better spent doing Red work

I saw that you wrote a 6502 emulator, but haven't had time to look 
at it yet.  Sounds like a fun project!

It's more like USE. CONTEXT exists as such in Red/System, but it's 
a compile time namespace instead of a runtime object

OpenCV binding is done by François Jouen, it's a work in progress. 
There's a Red/System version that you could find from this page (in 
french):


http://www.digicamsoft.com/cgi-bin/rebelBB.cgi?thread=%3C25May2012200150764026200%3E


There's a Red version that François sent me privately a few days 
ago for testing, but I haven't had the time yet to review it.

Compilation time seems to be reported modulo one minute or so, at 
least in the Red/System compilation phase

I don't have a lot of experience with C and library bindings, but 
I've done a bit and I can give it a shot when I have a bit of time.

Sorry Doc, it is hard to get-and-keep up to what you all achieve!! 
(And Kaj too) Even though I myself have less hours at my job I do 
not have as much time to follow it all. (More projects and chores 
in and about the house to do now and less 'spare' time at work for 
a quick review.

time is up now sorry.

It's impressive and depressing at the same time, because there are 
so many differences between R2 and R3. My CMS was much less work 
to port because I wrote it in very basic REBOL specifically to avoid 
these problems

It is my hope that the R2 legacy can be shed, but clearly it is not 
the time today...maybe a couple of months.  R3 patches must be taken 
in a timely manner. The current situation is untenable, so we are 
going to have to agree on a development branch.

Alright now that I'm getting a bit of time on my hands, I hope to 
start digging into Red a bit.  Looking forward to this project.

Yes, Github is a bit of a problem - it gets some time to orientiate 
oneself ... But otoh, on the main screen of Git, you can download 
latest archive, just see ZIP button - the link is - https://github.com/dockimbel/Red/archive/master.zip

Red is certainly not ready for prime time now. What we need now is 
testers and contributors. So just putting a link to source archive 
in a Download section wouldn't help much, as users would have no 
clue what to do with it. Again, there's a "Fork me on Github" button 
on top of all pages on red-lang.org. If users have no clue what Github 
is, then they are probably not ready for contributing. I will add 
a Download section once we have binaries for Red compiler (encapped 
versions of R2 compiler for now).


Once Red gets ready (documented and in beta state), I will open a 
new site that will be fully user-oriented (in contrary to the current 
one which is followers/contributors oriented).


About Red/System: it is meant to be a dialect embedded in Red, however, 
its intrinsic value seems to be high and will be higher as we add 
more feature and optimize it. Maybe it could be a good selling point 
for making some low-level programmers come to Red.  As Red/System 
is much more mature than Red, maybe I should think about opening 
soon a dedicated web site for it (would still need a binary version 
of the compiler)... What do you think?

As for creating R/S specific site - I am not sure, how much time 
it would take to create, but unless we are able to adress devices 
like Arduino, Android devices, BeagleBoard(Bone), RaspberryPi, I 
would postpone such a solution imo ....

Git was not designed for humans, AFAICT. It was designed to let loose, 
informal teams manage huge open source projects. Now it has become 
the default hammer, and every software project a nail. I don't mean 
git is bad in any way, and it is successful for a reason. It has 
become friendly enough that a lot of people can use it, but I still 
see notes about how most people don't know how to use it effectively. 


I imagine you could build a great, human-friendly wrapper over git, 
providing 90% of the power with 10% of the effort. It would take 
a git expert and a good designer, but maybe not too much time.

that for normal user, in order to just give some tool a try, such 
user should use systems like Fossil or Git?


That's precisely my point, it's not ready yet for "normal users". 
That's what I mean with not ready for prime time.


I really don't  want to have to maintain two copies of the same instruction 
page on both red-lang.org and github site, just because of people 
passing by and not curious enough to click on the very visible "Fork 
me on github" red banner.

Pekr: trust me I know what I'm doing. But as it will take me less 
time to add that Download button than keeping arguing with you about 
that, I will add it. :-)

I could have used you in the past week, but I just fixed cURL networking 
on Windows, after setting up a Windows installation for the first 
time in almost a decade

I do my share too from time to time using IDA Pro. ;-)

I franckly sometimes wouldn't mind some more arms for debugging native 
stuff as it can be quickly time-consuming.

I have that bookmarked, but haven't yet looked it over thoroughly. 
I noticed that the last time I tried to determine R3 syntax the effort 
generated a lot of bug tickets. The same would likely happen once 
I get a chance to go over Red syntax, and they may end up being a 
lot of the same bugs. Some syntax issues are an inevitible result 
of being in the same syntactic family, and not realy arbitrary when 
you consider the balance of the entire syntax.

ONE MORE TIME: IT'S NOT GPL!

First line got dropped somehow: Agreed with NickA here. As much as 
I like to contribute time and random to Red/system, I face