AltME groups: search

actually i have a whole app source fes, at least i think. but there 
is not much to look into, that is just an utility to parametrose 
led screen. I dont want to bother anyone with it, I thought you might 
see some obvious error i am doing, but apparently the issue is more 
complex ...

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.

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

I understand the first two steps, but I don't understand, how such 
a function wrapper in Red/System would look like ...

hmm, as I am not loading the library myself (IIRC R2 had something 
like addres-of), but Red/System is doing so. I wonder, if there is 
a way of how actually get the library handle ...

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

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

I used that, I changed it later to give it a try ...

well, I am bothering you here more, than if I would upload somewhere 
a project file with all sources. The app is really small, but I might 
be missing some obvious setting or something else :-)

An initialisation function is indeed a good candidate for the problem

Ah, that's only supported in import functions, I think. That's why 
I handle them as integers everywhere, but then you can't call it 
as a function. So game over

Anyway - it was a good way to learn a few bits in a practical manner 
:-)

Doc may need to have a look at it

why would it be a proof?

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.

The sample code uses the Ex functions. There may be a bug in the 
simple functions, so you should try the Ex functions instead

#ifdef _AFXDLL

 Enable3dControls();			// Call this when using MFC in a shared DLL
#else

 Enable3dControlsStatic();	// Call this when linking to MFC statically
#endif

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

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

Rodit' in Russian means 'to give a birth'.

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.

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.

I propose to start a RED v2

Red/System v2. Without a preprocessor directives at all.

Haha. So you advicate a sShort time progress with Eternal

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

Okay my intent is derive ROD from REBOL... Not sure I will reach 
a result.

I hate preprocessors installed right in the language. That's a sin 
of mixing layers into one layer.

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

That's reduction of meaning of a program. Reduction of its semantics.

#either macroname cond [ a if macroname ] [ b if macroname ] either 
macroname

Maxim, from a R/S spec: "Red/System ... will be embedded in Red scripts"

AFAICT, Red/system is used more like a high-level VM (compilable 
source rather than interpreted opcodes) which can be natively compiled. 
  RED won't have RED/System semantics.

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

That is what I call a protecting C nonsense. We are REBOL, not C, 
period. I am so mad about it, that if there would not be option to 
use print along with block, I would stop using Red/System ...

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

I feel that there is a lot of merit in Evgeniy's approach, not least 
the possibility of a one-pass compiler. 


I think it is worth remembering that the current version of Red/System 
is a "bootstrap" version with which to build Red. Once Red is built, 
Red/System will be re-written in Red.


It is most likely that there will be many imporvements to Red/System 
, some may involve syntax changes. 


I feel we should all expect to have to re-visit existing Red/System 
code when the "real" Red/System is released.

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

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.

:-) yeah, we generated quite a lot of a stir here. At least you know, 
that Red is a lively project :-)

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.

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

OK, so if I understand it correctly, Red/System loads the library 
at an executable load time, whereas load/library does so dynamically 
in the app run-time. Stil - I wonder, if we could get a handle to 
such a library? I mean, syntactically #import is just like preprocessor 
construct - you can't assign it to any variable. Not sure it would 
be usefull, to be able to retrieve a handle to such wrapped library 
plus handles (entry points) to wrapped function calls?

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

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

LedCtrl.dll (from ledset-source package): 

1) How is it supposed to react if a board is not connected?


2) The DLL is a C++ program with static functions (acting as wrappers 
I guess). Have these static functions been compiled with an "extern 
C" directive? If not, there's no chance it can work with anything 
other than a compatible C++ compiler.


I think that the crash has nothing to do with Red/System, the "unknown" 
error might be caused by the DLL functions corrupting the data segment 
of the Red/System binary where the runtime error data is located. 
I will try to track it anyway, just to be sure, it's not a missing 
code in the Red/System runtime error processing routine.

I think too, it is not a Red/System. I used the generated exe also 
on a LED screen PC. I can turn screen on/off, led-is-power? works 
correctly, ditto for led-is-locked?, but led-get-brightness fails 
... so if some functions work, it means that DLL has properly exported 
values? All use the same declaration ...

It is a pity that my first attempt has some such problems. Just don't 
loose the time with it, if you have more important stuff to do. Kaj 
tried to do his best here, ditto Andreas.

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

Btw - if some func retunrs void, how should my return value look?

 Void is the C way to indicate "no return value". In Red/System, you 
 just don't add a RETURN: clause in such case.

OK, thank, that just clears the situation for me a bit ....

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.

I am able to disrupt R2 compilation session to the state, where its 
restart is needed. Not a big deal, but maybe you will see something 
obvious. The code causing it is as follows:

print ["led-set-language: " led-set-language 3 lf]


The trouble is, that led-set-language does not return any value (void). 
This is understandable, that 'print has problem with such a clause. 
The error returned was:

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

*** Compiler Internal Error: Script Error : Out of range or past 
end
*** Where: resolve-path-head
*** Near:  [second either head? path [
compiler/resolve-type path/1
]]


Correcting the issue (moving function call away from the print block, 
I get another error:

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

*** Compiler Internal Error: Script Error : Out of range or past 
end
*** Where: resolve-path-head
*** Near:  [second either head? path [
compiler/resolve-type path/1
]]


This error repeats, untill I restart the R2 compiler session, which 
is a proof, that I corrected the source code, as aftern the R2 restart, 
I can get clean pass ...

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?

Maxim: thanks, that was my idea. Will learn a bit of C too :-)

I tried to resync my repository but lot of errors pop up. Can I rebuild 
a clean version without deleting my fork first ?

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.

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?

There's a problem with the WebKit binding:

Webkit: can't run it on Windows, I was able to get a suitable libwebkit 
but it fails to find some functions in the dependent DLL. Trying 
on Linux.

I am not sure, but it might be a collision with C init routines.

I'll search deeper tomorrow, sleep time now. I'll postpone the 0.2.4 
release until I get a clearer view on this issue.

It seems that the issue is caused by FPU control word settings used 
by Red/System that make webkit crash. I need to find a common setting 
that would work for both.

Pekr: don't you know that we already have a GTK-webkit-powered web 
browser? :-)

Yes, I just realised it today :-) But my friend told me something 
like WebKit library having 100MB? (maybe a typo)  So I expected the 
wrapper being thousandns of lines, whereas it is just few functions 
:-) So what kind of wrapper do we have? It surely is not complete 
wrapper to all the WebKit  functionality?

It wraps the webkit component of GTK, so you can add a webkit view 
in a GTK window and pass it an URL to open. As we already have a 
pretty broad support of GTK components, you can now build your own 
custom web browser in Red/System!

Ah, another one of those. It must be a regression, that's why I've 
seen it before

The WebKit I use of a few years old is 18 MB installed size, on Syllable 
Server. It has quite a few more dependencies, though, and on Windows 
that would be more because none of the dependencies are preinstalled

Almost, I need to have a look at C init routines first, probably 
tonight or tomorrow, then I'm free to work on Red. ;-)

Yes, that would be good, otherwise I don't have a browser anymore

I would like a less formal syntax description if possible. I would 
like to remove all the `+`.

when I compile following line, I got "*** Compilation Error: redeclaration 
of enumerator c from colors"
#enum [a b c]
print-wide [a b c]

#enum colors [a b c]

That's a name clash

Its given as example for #enum directive, but it cannot be compiled.

#enum [a: 1 b c d: e: 10]   ;<--- missing <name>
print-wide [a b c d e]

#enum colors [A B C D E]   ;<--- redeclaration
print-wide [A E]

and if #enum colors [a b c]  declares a,b,c; then why we need a <name>?

shouldn't it be
#enum colors [a b c]
print-wide [colors/a colors/b colors/c]

it is very difficult to declare an enum without a name-clash, if 
<name> is not used.

No, the name should be colors! and the purpose was to use is as a 
pseudo-type when declaring an argument or a return value.

where it should be declared then? in the example on the web site:
#enum colors [red blue green yellow]
a: red

colors
 used nowhere, so "red" is global. No?

How do we know that "red" is an enumaration from "colors", if we 
don't use "a: colors/red" or somethink similar?

in many other language we should give the name of the enumaration 
to get a value from it.

without using this way, it is almost impossible to use enumarations 
without a clash.

That's the way C works, the enumerations in Red/System is a direct 
transposition, works the same way.

Even in C we specify where we take the value, 
enum color {red,green};
color col = red;  <-- col declared as a color.
red is not defined as global.