AltME groups: search

Enumeration branch from Oldes merged to float-partial branch. Thank 
to Oldes for this nice addition and quality work!

Guessing further, did you maybe swap type and value in the struct 
when adding 64 bits floats?

And the swapping should be transparent.

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

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

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

My conclusion is, that VLC does not fit my requirements needs, and 
that's all. No wonder, that if you look into their website, trying 
to find projects which build their solutions upon it, you find only 
few projects actually. mplayer is much better in that regards. Dunno 
why though, as both build upon ffmpeg, so I expect their core having 
similar features, and API wise VLC seems to be ven better (LUA interface), 
but mplayer seems being more popular indeed.

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

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.

Perhaps with some functions, but in general probably not. REBOL C 
code will be very R3 specific. Interfacing with external systems 
is still sparse, and those examples can be looked up in many other 
projects

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.

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

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.

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

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.

And use google to index

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.

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

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

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

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

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?

But some functions  work although defined the same way. There might 
be some more functionality happenening under the hood, and who knows, 
that the code tries to return. OTOH the specs are clear enough - 
if it is supposed to return integer, then integer is simply an integer. 
And dialog windows work - I e.g. got dialoc saying "LED screen not 
found", so the GUI is inside the dlls ...

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

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

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.

Doc, take a look at how Lua does the C interface. It's really great. 
Both ways, simple and works.

Lua is a scripting language, probably closer to languages like Python 
(and REBOL), than to C.

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

There's not much still missing to have Red/System inferface to any 
C code. Basically just importing external variables and support for 
64 bits integers. I think 16 bits integers can be faked on most CPUs

I think I understand what you think, but I got lost in translation 
:-) I will have to think about it few times and try to do some experiments.Thank 
for putting some time into the topic ...

Besides GetProcAddress, there's a set of a few function for loading 
libraries and symbols. You'd need to bind them and use them to load 
the library, which yields the library handle, and then load the functions. 
They're what load/library and make routine! in REBOL use

Hmm, so in my case the situation in Red/System is even worse than 
possibly in R2 and World, where I could get such a handle from load/library 
directive, whereas in Red/System, what you describe, is writing completly 
separate layer. In fact, C's LoadLibrary is not difficult to handle, 
but still - a C level coding, which I thought is almost eliminated 
for wrapping purposes ...

The Red/System situation is certainly not worse: it's the other way 
around. You can program manual loading with just a few well defined 
functions, the same that R2 and World use. But normally, you use 
automatic loading by the operating system, which is the standard 
and most efficient way to do it, and which R2 and World can't use 
because they execute bindings at run time

So, if I would wrap LoadLibrary and GetProcAddress, I could get what 
you describe? :-)

Can you show your complete #import specification and the definition 
of a function that doesn't work?

R2 and World crash. In fact I think that those functions just try 
to write to serial port ...

If R2 and World crash the same way, manual loading doesn't help

Maybe there's no default language so that's needed. Or the default 
is Chinese and you don't have Chinese support installed or something 
like that

I wrapped a dialog box call, as DLL can cal e.g. LSN_BrightDlg, and 
it opens in English. When I explicitly call a language setting function, 
later on, set/get brightness still crashes ... I will see moving 
to the PC, where the sending card to LED screen actually is.

(See also: Not REBOL) In this way, RED could be renamed to ROD with 
many positive and complex connotations :)

ROD in modern Slavic mythology is a god of birth and of ansectry.

And RED is a color of war (including a nuclear war).

I'm thinking about deriving my own (simpler) ROD from RED :) All 
in all---Slavics must deal with their own mythology, and I am Slavic 
:)

This preprocessor is a BIG step BACK for a REBOL-like language and 
is completely counterproductive, and I can prove and explain why. 
I have a lot of insights into this issue.

I find a code with preprocessing TERRIFIC, AWFUL, and TERRIFYING. 
It slows down compilation to orders of magnitude.

Since compilation of included file is done everytime, and for IMPORT/DEPENDENCIES 
it is done once, and then a compiled version of a dependency is used 
everytime, which is infinite orders of magnitude faster.

#define may be replaced by MACRO keyword (more specific) or by DEFINE 
keyword (if you want to use a broad term). # is redundant and ***misleading*** 
since it makes one think it's C #define.

#if and #either are easily replaceable by "if" and "either" with 
an optimising compiler

and are completely redundant

So, all preprocessor directives can easily be removed from a language 
of Red/System, and replaced by normal keywords.

They give no pros, and give only slowdown of a translator and also 
much greater complexity of a code (try to analyse it metaprogrammatically 
and you will understand what I tell about!) and they also give a 
redundant extra layer of complexity.

Sorry. So you advocate a short time progress with Eternal regress 
and pain of recompiling included files and unavailability of metaprogramming 
possibility? No-preprocessor languages can easily be analysed metaprogrammatically 
and transformed, and preprocessor languages cannot (almost).

Steeve, such cleaning removes important information from a code. 
That's reduction. And removing the preprocessor removes this reduction.

Okkkkkk, I know what the word means in its regular sense. I just 
feel you should make clear yourself with the context and provide 
some use cases.

And we should switch the discussion into another thread

Max, I share some sentiments with Evgeniy. I too don't understand 
some design decisions - my first take is, that Red/System should 
be as much compatible to Red, as possible. Hence I will never agree 
to decision for 'print differing from its Red counterpart. I don't 
give a <censored> to C users, as imo noone will use Red/system, unless 
that person also plans to use Red itself.


My take is, that compatibility between Red and Red/System is much 
more important, that compatibility between the Red/System and C.


Ditto the strange aproach to use kind of preprocessor for importing 
the libraries, whereas R2 and World are OK with just make routine!

Ditto for strange declaration stuff:

declare struct!
alias struct!
#import for a library

Intead of:

make struct!
make lit-struct!
make routine!


If Red/System is going to be inlined in Red, the aproach to costructors 
should be as much the same as possible. This is a dialecting - the 
same words have different meaning in different context usage. I don't 
give a <censored> about protecting a possible C user's knowledge 
...

The decision was based clearly upon the fear, that Red/System is 
going to be used mainly by C ppl, and that in C print doeas not add 
new line by default ... that is imo a wrong design decision ...

Pekr,  Red and Red/System don't have the same semantics so I see 
no reason why they have to be compatible in any way except lexically.

My approach would also decrease a number of layers by one. This greatly 
reduces the complexity and greatly improves compilation speed.

I.e. after each #define and after it the #include, we would need 
to recompile the included file. That's enourmous lossage of time 
and resources.

But I am sure that NO strategy justifies #include and NO strategy 
is speedier than IMPORT of a compiled library.

Back from my trip to Paris, took me 3 days to come back home (Montenegro) 
due to huge snow. All roads closed, no train/bus/plane, state of 
emergency declared since saturday. I will answer the questions brought 
by Pekr and Evgeniy here later today, when I'll finish reading all 
the posts and emails I got since a week.

It all started by me trying to wrap some specific case. That's probably 
the most importat - Red allowing to wrap more outer world. As for 
syntax and other sugar, that's a secondary ... for now :-)

Pekr: (short answer) Red/System (and Red) generate executable binaries 
while R2/R3, while World and all other interpreted languages just 
run code in an interpreter or VM. This is a big difference, because 
Red can use the OS to load libraries at "load-time" instead of having 
to write code to do it (as all others interpreted languages require). 
This is also faster than loading manually. Red/System doesn't have 
yet a x-platform extension for adding "run-time" library loading 
support, just because we don't need it at all for now, but it can 
be added easily, by wrapping libFFI for example, or implementing 
it purely in Red/System.

But all the OS and third-party libraries we're currently using in 
Red/System have stable API, not the need for runtime loading has 
not appeared yet.

We tried to manual load library and get the proc address to be able 
to wrap a function, which crashes Red (as well as REBOL, World). 
It might be, that the library is not properly constructed for such 
a case. But Kaj mentioned something like parameter being a function! 
type, which is not supported, nor do we know, if it is planned, or 
if it even help our case ....

Evgeniy: (short answer)


1) IIRC, there's no recompilation of included files in Red/System, 
the only overhead is parsing the preprocessor directives and reducing 
them. I agree that the whole compilation process would be significantly 
faster without a preprocessor, but that's another topic.


2) Preprocessor is a handy addition for compiled languages, that's 
why it was introduced in Red/System, not because it was a planned 
feature, but just because we _needed_ it for going further. The distinctive 
# prefix is used to make it clear both for users and the compiler 
that these parts are reduced at "compile-time" instead of "run-time" 
and avoid confusing both users and the compiler. For example, from 
your examples, the compiler has no way to distinguish a "compile-time" 
IF from a "run-time" IF, unless you make it a lot slower by doing 
static analysis and complex inference (the cost would be huge compared 
to the preprocessor). Also, this might also introduce a lot of new 
restrictions in the language semantics, which is not desirable.


3) IMPORT is better than INCLUDE: you might have missed it, but we 
can't yet generate libraries, so importing Red/System code now is 
not an option.

Pekr: you've mixed up completly "load-time" and "run-time" library 
loading. You don't need a library handle at "load-time" (unless you 
want to hack something in the OS). Also, you don't need any of your 
code above, just the #import declaration with the right function 
names (finding the right names seems to be the most complex part 
in the case of the library with the weird API you're using)

I was not using preprocessor in my Rebol/Flash dialect and I must 
say, I find the Red/System way useful. It may be true, that additional 
pass may slow the compilation a little bit, but it also provide additional 
features. Also I don't expect that it will be used in some huge projects 
with MB of sources so if it's a few ms slower is not a problem. And 
as Red/System is open, everybody can provide own version:)

Doc - we have got the right function names, that is not the problem. 
The problem is the crash, and we were trying to identify, if Red/System 
library wrapping system still needs some improvements for some cases, 
or simply the DLL is doing something internally, that some functions 
work, and some crash. Here's example:


fpGetBright= (LSN_GETBRIGHT)GetProcAddress(g_hLedCtrlInst, "LSN_GetBright");
wrapped as:
led-get-brightness: "LSN_GetBright" [return: [integer!]]


Btw - how do I wrap properly function, which does not return any 
result? I tried just without the return clause, but it is not possible. 
Is e.g. return: [] (empty block allowed?)

Pekr: I will test your lib later today and see what's wrong. As I 
read that it crashes with also R2 and World, it seems obvious that 
something is wrong (a) in the lib or (b) you're not passing the right 
arguments or (c) you're not calling the right functions in the right 
order.

 it is about the process of building app vs dynamic prototyping using 
 interpreter


Well, I don't know how you build apps, I have never built one from 
the console, but only from a code editor. Console is nice for testing 
some small snippets when unsure, but coding is usually done in a 
decent code editor, where you usually launch your script using a 
shortcut. From that POV, there will be no differences with Red for 
the users. And to avoid further misunderstanding, Red will have a 
console, like R2 does, with similar features and possibilities.

Btw - how do I wrap properly function, which does not return any 
result? I tried just without the return clause, but it is not possible. 
Is e.g. return: [] (empty block allowed?)


It's in the spec document and same as the routine! interface in R2, 
just do not put a RETURN: definition if the function does not return 
anything:

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

Doc - I use text editor too, for some complex stuff.Yet for trial 
and error I use console. Several users expressed in the past, that 
one of the nice values of R2 is its console, for the quick prototyping 
around.

Also - what is a difference in passing a "void" to func, and passing 
it no value? Aren't following definitions just the same?

typedef void (WINAPI *LSN_BRIGHTDLG)(void);
typedef int	 (WINAPI *LSN_GETBRIGHT)();

Steeve: The Red/system's compiler is not that far advanced. It can't 
perform dead code analysis. it's why it will get stuck with macros.


Evgeniy: dead code analysis for boolean constants is fairly simple 
and straigtforward

I could even help write


the only thing necessary is a boolean flag for a value that it is 
a CompileTimeConstant


if we have "IF(value)" and value is FALSE, we just remove the false 
code branch

from memory. And do not output code for it.

This renders #if useless...


Steeve: Yeah it seems pretty straightforward, feel free to ask in 
#Red :-)))))


Evgeniy: In Oberon, you can write VAR Procedure1: PROCEDURE1; BEGIN 
IF (ARCH1) Procedure1:=Arch1Module.Procedure1 ELSE Procedure1:=ArchOther.Procedure1 
END END


that's not so simple: there can be absent libraries and headers and 
files in dependent files on different archs. This must be taken into 
account and makes an implementation slightly complex.


Steeve, I've already asked that by previous discussion. I thought 
that this technique is obvious.

Oldes: And as Red/System is open, everybody can provide own version:)


Evgeniy: It seems to be necessary. I won't be attached to a language 
with a preprocessor. That's UNDERTHOUGHT OUT language.

After using `??` a few hours, I realized that it was a mistake to 
use it as a shortcut for `print-line`. It is readable when used on 
a word, but with a block, it looks too esoteric and hurt the feelings 
of old rebolers that see it as a syntax error. So, I want to get 
rid of `??` but can't find anything to replace it that would be both 
short and consistent with `print`and `print-line`. I think that I'll 
just deprecate `??` but won't remove it for now as some of you are 
heavily using it.

FYI, I am currently merging the float-partial branch and preparing 
for the 0.2.4 release.

Downloaded new branch, and now my error message changed. Was there 
any change to error handling?

*** Runtime Error 101: no value matched in SWITCH
*** at: 004013ADh

Sorry, wrong cut and paste. The first error was:

Compiling led/led.reds ...
Script: "Red/System IA-32 code emitter" (none)

*** Compilation Error: return type missing in function: led-set-language
*** in file: %led/led.reds
*** at line: 87
*** near: [led-set-language 3 lf]

pekr, in this case, wrap another dll around it, a.k.a. "thin layer" 
dll.


use a C++ compiler, but use the functions within a C sourced dll 
project.  this dll will then serve as your translation from the C++ 
libs to Red/Rebol whatever.    If the C++ use requires special steps 
on function entry/exit, the compiler will add these for you (when 
it compiles) and from outside the C function you'll be back into 
"normal land". 


 I've even read that some C++ compilers can't even properly use libs 
 from a different C++ compiler.

Kaj: I did a few tests for the 0.2.4 candidate with some of your 
bindings on Windows and Linux. No issue so far. Could you please 
check if all your bindings latest versions are working fine before 
I make the release?

The runtime error handler now better catch unknown errors and the 
use of SWITCH has decreased the runtime code size significantly.

just a note - solved the ledctrl problem. I noticed it generated 
system.con configuration file, but this file was just 210 bytes. 
So I copied over the larger one from real set-up, and those affected 
functions started to work. Tomorrow I will try directly with the 
ledscreen. So, although the library is said to be C++ only, it now 
works even from R2.