World: r3wp

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

It is more of a philosophy, what is more confusing to whom. E.g. 
Carl proposes dialecting as the same word, being simply used in different 
context. In real life, it might work, but not sure about programming. 
E.g. 'copy in 'parse having slightly different aspects than 'copy 
in REBOL itself. That is why I thought that make! could be used even 
in Red/System, but not sure ...

The reason why I am also opting for such an aproach is, that there 
will be possibility to inline Red/System in Red itself, so it should 
look similar, where possible. I e.g. liked how Cyphre did JIT to 
R2 - the code still looks like REBOL, it is just a limited subset 
...

I share some of your uneasy feelings about the overuse of preprocessing 
constructs. I would like them to become first-class, but it's hard 
to come up with the best solutions

I think Doc will say that we'll reconsider them in the Red/System 
rewrite in Red

Your binding looks quite good to me, but how is your #import defined, 
and how is WINAPI defined in the C code?

Yes, that might actually happen, after all Red/System is the target, 
so new needs might show-up during the Red design, who knows ....

They will, and they have

I tried stdcall and iirc even cdecl. How do I find out?

It should probably be cdecl, and the WINAPI definition probably contains 
the answer. Did it make a difference?

The issue looks to be that the C functions are defined as WINAPI 
pointers, instead of just WINAPI functions

No, still error ...

Is LSN_GETBRIGHT really defined as LSN_GetBright, etc, or are the 
function names different?