AltME groups: search

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

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.

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"

And if there's a plan for a GUI

As opposed to writing a dialected GUI?

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.

Sure .. people can read the slide presentation, but a few words might 
help :)

Dockimbel: Re: native GUI - will this be X gui or you plan to write 
a native code for every card driver? ;)

BTW, we could also make the View face/gobs hierarchy a common layer 
on top of all those GUI frameworks, if the overhead is not too high.

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.

The R3 host-kit is a good source for how to do it.

Xlibs are a nightmare to work with for me, at least last time I had 
to use them at university 20 years ago, I don't think it has changed 
much since then.

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

I would personally want a View clone with a GUI dialect on top. The 
R3 GUI could be appropriate.

( though I have this nagging suspicion a dialected GUI trades ease 
of use for sophistication and flexibility )

That will be the real challenge, define a GUI dialect good enough 
to cover the common parts and backend-specific extensions for been 
able to fully use backend-specific features.

I guess that a context-free grammar would have required some arguments 
list delimiter, such as C and most other languages have.

Also, the "Each context-free rule" expression on page 1 of the BNF 
grammar description is not accurate, it would need a specific comment 
for <fixed-arguments-function-call> rule.

if you want to parse function calls into a call tree, you'd need 
some argument delimitations

so if you want a context-free grammar which models nested calls, 
you'd need funcall delimitation

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.e. you won't get a "funcall" node in the AST

well. I'll go rest a bit today =)

<code-block> ::= [ {<statement> | <expression> | <comment>}+   ]
      A

Evgeniy, the : is part of the first token in the first case, and 
part of the second token in the second case, it isn't a separate 
token. The values a: and :a are related semantically, not syntactically.

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

Or you could think of it as a higher-level syntax, above the tokenization 
level.

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

I was just talking about the token portion of the Coco/R syntax rules, 
as opposed to the parse rule portion. But agreed, any Oberon-like 
language will have a simpler syntax than any REBOL-like language, 
and will have been designed with LL(1 or so) in mind.

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

Oldes, wrap it in a struct. I call those references

If you mean a pointer to the string payload, that's what a c-string 
already is

I guess R3 is 2-byte head and 10-byte payload.
 - that is a wrong guess

Oldes: A c-string is a byte-ptr!. It can be cast to an int-ptr! if 
needed.

Kaj: I gave a new try on making the GTK+ binding work on Linux/ARM, 
I was able to track the crash up to the call to `gtk-append-container` 
from `gtk-window` function. The argument values passed are:

    window: 0006C000 value: 12

which results in a Runtime Error 1: access violation (segfault)

Kaj: my problem is, that I have a routine: MagickRelinquishMemory 
which should release memory from routines where some returns c-string, 
and some for example pointer to array values... So the best would 
be to accept pointer! with MagickRelinquishMemory, but still to be 
able return just c-string from some routines, if you understand me. 
I know there are workarounds, but it could be quite simple

Pull request #201: Oldes, thank you very much for your changes. It 
should be ok now for merging, I will just run a few more tests before 
that.

Kaj: I gave a new try on making the GTK+ binding work on Linux/ARM, 
I was able to track the crash up to the call to `gtk-append-container` 
from `gtk-window` function. The argument values passed are:

    window: 0006C000 value: 12

which results in a Runtime Error 1: access violation (segfault)

value is supposed to be a widget object, so the 12 is bogus

Good! At least we have a clue to follow.

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)

So type seems to be correct, but value is not the label object. At 
a guess, could value = type ?

They're set like this, so I expect a bug there:

I think there's definitely a stack offsetting bug in the ARM backend 
for typed/variadic functions.

Kaj, I've been able to reproduce a similar behavior (having 12 in 
list/value instead of an address) using a small program, I'm analyzing 
it right now.

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?

I've been considering a VLC binding, but it isn't a priority for 
me right now

It would be a problem for an R3 binding, because the GPL doesn't 
allow VLC and REBOL to run in the same process

That makes a Red binding much more interesting

It's a video stream player, not an image viewer

Kaj - that is just an excuse imo. My 3 years old TV played just audio 
plus images. New versions can play namely anything. Ommiting ability 
to display images is a big design flaw imo. Because you can do it, 
or you can't do it. And VLC can't do it. You are also not right, 
that it is only a stream player - it is also a normal player, so 
it should try to display us much content as possible. Imagine you 
want to build small hw media player - will you ommit ability to display 
photos? And if not, it is clear you have to use another kludges to 
combine VLC with something else ...

No, not anything, but what normal consument expects. There is plenty 
of bare bones DVD players, DVB-T tuners, and apart from video, all 
handle even photos, as I think, that in the age of digital cameras, 
it is pretty normal to request such a feature. But - whatever ...

If you want a program that simulates a TV, you should use MythTV 
or something like that

VLC is doing just fine with "normal consumers". They downloaded it 
a billion times, a good deal less than competitors such as MPlayer

a good deal more, I meant

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

If you don't think you can create a contribution with time, you could 
make a donation in money

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.

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

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.

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

An incentive to live a little longer. :-)

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.

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?

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

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

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

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

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

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?

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

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

I think so, but the C code is also doing an indirection through a 
function pointer, hence the fp

Are all C functions defined as pointers (with * and fp markers)? 
Can you give an example of a binding that works?

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.

uff, team viewer had someproblem switching focus, or it was me :-) 
so, turning on and off the screen works ... not just a - led screen 
reacts ...

Well, maybe there actually is a LSN_Power function in the DLL you 
are linking to :)