World: r3wp

So a few natives get written in R/S, and then use those to write 
the core of Red.  And those that need to be rewritten in R/s can 
be done as a later optimization.

I think that's the plan. World has similar goals I believe.

And in a few years we'll be able to write apps :)

An incentive to live a little longer. :-)

I don't think any R3 development could speed up Red

 - perhaps only already taken design decisions, as design can take 
 time and mistakes can be made.

A few points releting to recent posts:

Nenad is already working fulltime on Red.


He has already accepted contributions to the Red/System compiler 
from both Andreas and Oldes.


Finding bugs by using Red/System will help speed the process of Red 
especially as Nenad's current design is to generate Red/System code 
from Red.

Yes, design decisions are important, but we were talking about potential 
new R3 development

Graham, programs can be written in Red/System right now

You were asking what anyone can do to help, and the most obvious 
way is writing programs

Ok, though I can't think of anything I need to write in R/S at present. 
 I need GUI based apps though

if one wants to test Red/System: port some simple C stuff?

FYI, I'm on trip until Saturday, so I won't be able to work much 
on Red until there. I will try anyway to release the version 0.2.4 
that includes floats support this week.

Speed up the process: you'll be able to add easily new datatypes 
to Red. I won't code myself all the 50+ REBOL datatypes, only the 
basic and important ones. For example, I would very much appreciate 
if date! and time! could be contributed by someone. The basic types 
will be quick to add as soon as the underlying Red runtime (think 
MAKE, LOAD and a few basic natives) will be operational.

Is there going to be a central repository for code snippets like 
rebol.org ?

Certainly, maybe we could use a github repo for that as a start?

And use google to index

Right, or build a simple search service using github's public API.

After adding the float! support, the main thing is a series! datatyte. 
Should we wait for Red to implement it properly or do we want ti 
in red/system as well? (I know I can use pointer math to access values, 
but it's not so easy for ordinary scripting)

Red/System is not meant for scripting but low-level and system programming. 
Red is for scripting, so series! support as well as all others scripting 
facilites will be provided by Red.

So what one can do now to help you move Red to usable state? :)

Red/System: already anwsered by me, Kaj and others (also, there's 
a todo list on red-lang.org for contributors that are searching for 
tasks to handle).

Red: you need to wait a few weeks until the first alpha is out to 
start adding new datatypes.

todo list - you mean the roadmap?

No, the one from here: http://www.red-lang.org/p/contributions.html

(it's the "Community" menu, I guess I forgot to rename the page, 
will have to fix that)

@Oldes .. how about a black text on white background blogger theme! 
 That would help a lot.

It does not sound like much creative work... you can just download 
some existing theme like http://www.bloggerthemes.net/heliumified/demo
and tweek it a little bit... but it requires access to the site.

I very much like the Heroku style: http://www.heroku.comIf I could 
find a similar blogger theme, I would switch at once.

I'm aware that the current theme is not always very readable, if 
someone with good design and CSS skills wants to tweak it, I'll see 
if I can give you access to the admin form.

I can agree with Oldes, that when wrapping some C stuff, things like 
series would be handy - namely - a block! type, to have an array, 
plus accompanying series handling functions. But - where would that 
end? :-) Wouldn't we then want also a path, etc. to work?

I am for a quick solution to appear, so - Red. If that turns out 
being slow, there is a later chance to reimplement some stuff in 
Red/System. Of course such aproach itself does not bring more comfort 
to Red/System, as e.g. availability of array type would be for e.g. 
But there are some priorities ....

Arrays are possible in reds, just it's not so clear like in Rebol:) 
Example:

	*count: declare int-ptr!
	query: MagickQueryFormats "*" *count
	count: *count/value

	?? ["======================================"]
	?? ["=== Supported image formats: " count   ]
	
	while [count > 0][
		?? query/item
		query: query + 1
		count: count - 1
	]

Ok, though I can't think of anything I need to write in R/S at present. 
 I need GUI based apps though

A cross-platform GTK+ binding is available, with a REBOL like dialect

if one wants to test Red/System: port some simple C stuff?

Yes, that's a good approach

I am trying to wrap our LED screen control dll. I am not sure how 
well it is defined, as LED Studio and surrounding SW is rather weak 
and sometimes crashes, but I tried in R2, thinking I again reached 
some R2 DLL interfacing limit/bug, and am trying now in Red/System. 
Well, my first attempt to wrap some DLL functions here. So - I can 
turn-on/off led screen, even if I don't set COM port, open-sending-card, 
etc. But when I try to call functions to get e.g. brightness, contrast, 
it crashes. Those funcs are defined as e.g.:

typedef int	 (WINAPI *LSN_GETBRIGHT)();       // 0..100
typedef bool (WINAPI *LSN_SETBRIGHT)(int);
typedef int (WINAPI *LSN_GETCOLORTEMP)(int);//ScreenNumb

typedef bool (WINAPI *LSN_SETCOLORTEMP)(int,int);//ScreenNumb,nColorId 
0,1,2,3


None of above functions work for me, although above code is from 
sources to LEDSet application, where those funcitons work, those 
are just being set via dialog boxes (which I can invoke even from 
Red/System, so those are part of DLL ...

My definitions are:

      led-get-brightness: "LSN_GetBright" [
         return: [integer!]
      ]           

      led-set-brightness: "LSN_SetBright" [
         brightness [integer!]
         return: [integer!]
      ]

      led-get-color-temperature: "LSN_GetColorTemp" [
          screen-number [integer!]
          return: [integer!]
       ]                 


etc. So what coul be causing run time error? I am running on a PC, 
where I don't have internal LED screen communication card. I thought, 
that DLL functionality might check for the screen, can't find it, 
and so the app returns error, which does not fit return value - e.g. 
some error code/string, or a dialog box. But moving the exe to the 
PC where the card is, it i just the same - some functions work, I 
can see LED screen being turned on/off, but those brightness etc. 
don't ....

The error I get is something like this:

*** Runtime Error 99: unknown error
*** at: 7572FC56h

Reading the docs, i have one question - could we say, that aliased 
sctructures are the same what we know as a literals in REBOL? I can 
imagine the declaration being :

book: literal struct![]


so instead of calling it a virtual datatype and suggesting to use 
exclamation mark to distinguish it in a code, it could as well be:

'book: literal struct! []

Anyway - it does not matter, just curious ....

Maybe one another question - I know Red/System is supposed to be 
closer to C, but it will be also used by those, who would like to 
proceed using Red itself (that is why I did not like the print-line, 
?? vs print/prin) - so the question - why is there so many constructors, 
instead of one make! and e.g. a block format? I mean:

declare struct!
alias struct!
#import for a library

Intead of:

make struct!
make lit-struct!
make routine!


? I will understand the answer of a type, that it is better to be 
understood by those knowing C language. So far, I can't e.g. understand, 
why a library is wrapped in a preprocessor kind of way, using #import, 
which does not fit those preprocessor things like #define, #ifdef, 
etc.?

Btw - once you add TYPE? function,I wonder how you distinguish declared 
struct! from an aliase one :-) I know that function will return integer, 
but you will surely print some name in the end, so will you come 
with an artificial type-name for an aliased struct to distinguish?

If it would be upon me, I would better try to stay consistent with 
the Red level - so if Red will have make!, Red/System should have 
make too, no matter how C users will aproach it. Those who will use 
Red/System, are going to use Red most probably too, so I can not 
see much reasons to differ, just because we can state - Red and Red/System 
are two different things :-) I am curious how you will keep up with 
such a differences in future, once Red layer becomes available :-)

c: 2

p/c: 1234                              ;-- writes 123 (4 bytes) at 
40000004h


Isn't there a typo? Shouldn't it be - "writes 1234 (4 bytes) at 40000004h"?

Looks like it was written with a sleep deficit :-)

just a small typo, so other than that, docs are good :-)

Literals are a quite generic concept from REBOL. An ALIAS is a much 
more specific thing: it's a name for a struct!. If you want to compare 
it to REBOL, you could say that it's bound to the struct, so not 
just a literal

I wonder if TYPE would be a better name for it

so that is has already a type, and the type is struct, whereas literal 
is just a literal?

There are no literals in Red/System, at least not as symbols

because "alias", although I am not a native english speaking person, 
in my understanding, is something already existing, which we reference. 
But a struct alias is just like a class, it is not structure yet. 
But, it does not probably matter. Simply put coming from REBOL I 
would like to see those two similar. Reading further in docs I can 
see, that REBOL can't be easily mapped to C, so some specialisties 
might be needed ...