AltME groups: search

If not, the mindset is closer than you might think. If someone is 
going to use only Red/System, which you claim being closer to C than 
Red, than such person can just use - a C :-)

But - as Red/System is mostly out of my scope, I will acept any decision 
...

Also, it's too early in the project to be nitpicking, you'll have 
plenty of time for that when Red will be out. ;-)

Will some alpha Red come in 2012?

Do you want to use ?? in RED as well? Because as Pekr said, it will 
just cause confusion... I have enough problems not to write TRACE 
instead of PRINT :)

Another view is that a very small audience of REBOL programmers is 
used to PRIN. The big audience for Red is people that don't know 
or even dislike REBOL

yes, because most Red/System users, are going to be also a Red users. 
Red/System is not for C ppl, that is an illusion imo. Why would anyone 
C oriented would like to use Red/System, if he/she would not also 
want to use Red later? :-)

Well, now I restrain ... I am most probably not going to be a fluent 
Red/System user, so I don't want to influence such a decision, if 
other ppl feel differently about the topic ...

Also, I didn't say "incidental" about R2 and R3, I said it about 
Red and REBOL

I've renamed the print-string in the C library binding to make way 
for the Red/System one

The testing framework done by Peter WA Wood is documented here: http://static.red-lang.org/red-system-quick-test.html

You can also browse inside %red/red-system/tests/source/ to see how 
tests are done. Basically:

- language unit tests go in %tests/source/units/<feature_name>-test.reds

- compilation passing tests and compilation error tests go in %tests/source/compiler/<feature_name>-test.reds

I would like to write tests for enumerations: https://github.com/dockimbel/Red/pull/201

I removed run-test.r as it was becoming difficult to get working 
once we needed to have tests not only in the red-system/tests dir. 
(I now use a script in another language which seems to be more flexible 
in it's file path handling.)

I've emailed a copy of the run-test.r to Oldes.


I'll take another look at getting run-test.r to run a test from any 
directory. If I can I'll restore it, if not I'll chane the docs.

A warning could be added easily, the issue is that it would then 
make all datatypes names reserved words that would need to be added 
there: http://static.red-lang.org/red-system-specs.html#section-18

Any idea what else should be tested? https://github.com/Oldes/Red/blob/float-partial/red-system/tests/source/compiler/enum-test.r

done.. you can find complete diff for the pull request here: https://github.com/dockimbel/Red/pull/201/files

Struct aliases are there for that. See http://static.red-lang.org/red-system-specs.html#section-4.5.5

I am currently entering a formal EBNF Coco/R .ATG grammar for Red/System 
as specified in the BNF doc at the site.

Coco/R is LL(1)/LL(k). This grammar would automagically yield a new 
lexer for Red/System.

Just remind me please .. when is work starting on RED itself?

Is http://www.red-lang.org/p/roadmap.html
Bootstrap 4 referring to the RED language?

In the roadmap, Red refers to Red proper, Red/System to Red/System. 
Easy as pie :)

So yes, bootstrap steps 3, 4, 5 refer to implementing parts of Red 
proper.

Evgeniy: you can email the fixes to Rudolf directly or to me ([nr-:-red-lang-:-org]).

Graham: it should have started a month ago, but I've postponed it 
to add floating point support to Red/System. The work on Red should 
start in a week.

If the grammar is OK, there will be new interpreter for Red/System 
soon :)

It would be nice for newbies in the about page to have a statement 
of what you will be able to do with RED when "complete"

I suppose there are some internal priorities for Red as well, such 
as when for example networking becomes relevant.

I would hope Red adopts one of the existing GUI solutions.

Newbies info: well, from all the presentations slides, you can see 
that Red is meant to be a "general purpose" programming language, 
so making any list of possible applications would be restrictive 
and probably also premature as Red is not yet implemented.


GUI is certainly a feature to have, but I wouldn't make it part of 
the "core" language, rather handle it as library. One remark about 
future Red GUI support, there will probably be several GUI frameworks 
available (we already have GTK+, I'll add a native one, and someone 
could contribute a View clone), I'll try to put a common VID-like 
dialect on top of them, so we can quickly switch from one to another 
with minimal changes needed.

Evgeniy: you're sounding like you're volunteering for writing the 
X back-end, thanks, that would be nice! ;-))


The native GUI I have in mind for Red is a SWT-like one, but as light 
as possible (SWT has some really heavy widgets). So, yes back-ends 
for Win32, X, Cocoa and Android are planned. The Cocoa and Android 
back-ends would need obj-c and java bridges.

Since we either do a Lua GUI or perhaps can adopt Red ;-) and do 
the GUI there, I think there will be some choices.

Saphirion could migrate to RED :)

Robert: I hope Red can be ready fast enough for you, so that all 
those REBOL experts you've hired could continue to make wonders in 
a REBOL-like language. :-)

Oh, I forgot to mention Flash also as a possible back-end for GUI, 
if Oldes makes the AVM2 port for Red/System some day. ;-)

So, Red/GUI is complete and awaiting RED

on the other hand, i'm certain that you can model Red/System's syntactical 
structure with a context-free grammar. it's just that the CST/AST 
would look quite different from other languages (i.e. in that it 
does not explicitly model function call structures)

I suppose there are some internal priorities for Red as well, such 
as when for example networking becomes relevant.

The assignment is semantic, not syntactic. Other Red dialects may 
or may not associate a set-word with assignment.

You could try to make the Coco/R syntax specific to the Red/System 
dialect or you could make at least the tokenizer general for Red 
code and implement the Red/System dialect in the parse rules. The 
latter would be a more useful approach for REBOL-like languages :)

Well. I give up. I don't like languages with preprocessors since 
they are slower than languages with no preprocessor. So I send an 
original .ATG to Dockimbel, and stop my work. Looking at the RED 
spec made me sigh about the preprocessor.

Paths are made up of tokens, yes, just like the other block types 
except with more restrictions about what types of data may go in 
the paths. I don't (currently) know what subset of path syntax and 
semantics that Red/System supports though.

In some other REBOL-like languages there are some inherent conflicts 
between some path element types (notably dates) and the path separator 
/ itself, plus the final : on a set-path is considered part of the 
path instead of being a set-word element contained in the path, and 
the same for a leading : in a get-path not being part of a get-word 
first element (in R3). There's a fairly well-defined set of precedence 
rules, but for REBOL-like languages other than Red those rules are 
not very well documented, and they can therefore sometimes vary from 
language to language.

Evgeniy, function calls are not really part of the syntax in REBOL, 
or Topaz and i think even Red/System. So, yes, it is a CFG, it's 
just not like other languages (more like XML or JSON).

Doc - congrats on finishing floating support in Red/System. Now all 
to-do list items seems to be done right? So time to move on onto 
Red itself? :-)

Doc, According your slides, Red's boxed value composes of 4-byte 
head and 12-byte payload. Why so? I guess R3 is 2-byte head and 10-byte 
payload. Just curious. :-)

Raspberrypi shipping any day now! http://www.raspberrypi.org/Lets 
see Red on it!

Here http://red.esperconsultancy.nl/Red-GLib/info/12c18cb30c?

gtk-view label "Hello, Red/System GTK+ world!"

Right, I've added a lot of debug logs to GTK to follow the calls...(the 
planned stack trace feature for Red/System is climbing in priority)

What's your experience with Red/System wrapping interface? Is it 
suitable to wrap (relatively saying) "any" C defines? I am recently 
scripting VLC a bit, to see if I can use that player instead of LED 
Studio (which is really bad chinese standard LED accompanying sw) 
for our LED screen.


So far, I am fine talking to VLC via TCP - 10 lines of Rebol code. 
But their RC (remote control interface) missess advanced playlist 
handling. I was looking into vlccore library API, and I found various 
wrappers, and e.g. Python one, is auto-generated, by going thru includes.


IIRC, Max worked on something similar for R3, but never released 
the code. Now I wonder, how difficult would it be to achieve using 
Red/System?

Red/System's way to write bindings is the best I've seen. Barring 
C features it doesn't have yet, it should be able to bind any C function. 
Mostly only 64 bits integers and importing data values are still 
missing by now

That makes a Red binding much more interesting

A lot, I'd say. Enhance Red, write bindings, write example programs, 
write documentation. etc.

Doc says he is starting soon on Red ?

He has started months ago with the memory allocator and the tokeniser, 
but Red/System keeps postponing the rest

On the other hand, implementing things such as the allocator yields 
experience for further developing Red/System

Kaj - donation is not a problem imo. I donated and will donate again 
in March. At least a bit, but the question is, if it can speed anything, 
apart from the fact, that Doc will be able to work on the Red fulltime 
eventually. I think that Graham might be in a position of need to 
work on new stuff, and is deciding what tool should he use. In such 
a case, it is a bit preliminary to consider Red imo. But who knows, 
how quickly the RED itself can be written.

We will have to wait for Doc's estimate. It is also a question, if, 
when implementing e.g. Red "natives", he will accept the work of 
other developers, or will want to write it himself.

I am also not sure, that in the case of Red, eventual R3 source release 
would help to speed things up, as Red "natives" are going to be written 
in Red/System, not C, or so is my understanding of the platform.

I don't think any R3 development could speed up Red, but R2/Forward 
may

I had something other in mind - RT releasing sources for R3, it might 
be easier for Doc to rewrite R3 C code into Red/System, than implementing 
all functions "from scratch".

Also, the plan is to implement as few functions as possible in Red/System. 
Red will be preferred instead, to work at a higher level

And I take it we are not waiting for Red/System to be rewritten in 
Red/system before work on red starts?

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

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

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.

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.

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

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

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

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

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

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

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

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 think Doc will say that we'll reconsider them in the Red/System 
rewrite in Red

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

Never mind, I just wanted to try it in Red. Good way to become familiar 
with the system trying to use it for practical purpose. I might try 
to continue investigatin COM communication, but R2 serial communication 
is also not much to be desired :-)

typedef int (WINAPI *LSN_GETBRIGHT)()


^^ That defines LSN_GETBRIGHT to be another name for a pointer to 
a stdcall function that takes no arguments and returns an int. (WINAPI 
== __stdcall)

extern LSN_GETBRIGHT		fpGetBright	;


^^ That now is the actual "function", although held indirectly as 
a function pointer. So somewhere in a library is a fpGetBright value 
which holds a LSN_GETBRIGHT function pointer.


In C you can directly call that as e.g. `int brightness = fpGetBright();`. 
However, I fear in Red/System it's at the moment not possible to 
perform that call.

The complex issue is that the functions are imported through pointers. 
Red/System can use function pointers if you write wrapper functions 
and pass them the function pointers. But Red/System can't import 
simple values yet, only functions, so you can't import the function 
pointers the way the C code does

btw - does that mean, that Red/System is still not generally good 
enough, to wrrap "any" C interfacing?

I guess you're correct;  Red/System is not generally good enough 
to wrap "any and all" C libraries yet.


What is most important to me about Red/System at this time is that 
it needs to be good enough to allow Red to be developed. I believe 
the addition of partial float support to Red/System was not absolutely 
essential for the development of Red though I'm sure it will help. 


There are lots of other improvements that could and will eventually 
be made to Red/System but they don't seem as important as work on 
Red ... at least to me.

btw - is/will something like inlined/included C/ASM code be possible 
in Red/System?

Lua's C interface design is not applicable to Red/System; it can 
provide inspiration for Red, but I think the plan is to interface 
with C/C-level code from Red via Red/System.

Re "inline C/ASM in Red/System":


Possible in general, yes. Neither planned (afaik) nor worth it (imo), 
at the moment. Remember that Doc's primary reason for Red/System 
is to use it to bootstrap/write Red.

http://static.red-lang.org/red-system-specs-light.html#section-19.9

What your binding still does differently than the C code is that 
the C code loads the functions dynamically, while Red #import embeds 
loader symbols in the executable format. I think GetProcAddress is 
the standard Windows function to load symbols manually at run time

You should bind the GetProcAddress function (I think there are already 
Red/System Windows examples floating around that use it), find out 
how to get the value of the g_hLedCtrlInst library handle, and use 
them to load the functions like the C code does

Then for each function you have to write a Red/System wrapper function 
and pass it the function pointer as if it were a callback function, 
and call it. There are examples of such constructs in my bindings