World: r4wp

That would be nice indeed

I would prefer an elegant solution that covers both bitfields and 
unions.

In fact, if we could merge struct, unions and bitfield in a single 
concept, with a nice syntax, that would be the best option.

Agreed, I always felt unions were a bit shaky, too

Fortunately the R3 host kit unions are tagged, so they can be used 
a bit more safely. Most higher-level languages that implement this 
kind of thing do something basically equivalent to the Variant type 
of VB, COM and .NET; even Objective C, Smalltalk, most Lisp/Scheme 
languages, and REBOLs have variant types. A variant is basically 
a tagged union type underneath. Having a cleaner way to do this in 
Red/System would be good., perhaps something like the polymorphic 
types in most functional languages. Red itself could have a dynamic 
value type like REBOL, which is basically another variant type. Red/System 
should have a way to specify different variant types because the 
variants of different platforms tend to not be compatible with each 
other.

There is no literal form for float32! datatype values, so why not 
use literal form used in C, mostly seen in GL functions like:  glColor3f( 
1.0f, 0.0f, 0.0f ); ?

Values like 1.0f could be recognized by loader and converted to (1.0 
as float32!)

Brian: thanks for the input. 


Oldes: I think this has been discussed in same channel on Rebol3 
world long time ago. Basically, the problem is that it  breaks REBOL's 
syntactic rules (digits as first characters of a word are not allowed). 
Also, this kind of syntax looks cryptic, it's IMHO, and goes a bit 
in opposite direction of what REBOL wants to promote (readable syntax).


Maybe we can do some implicit casting when a float literal is passed 
as argument to a function expecting a float32!.

Preprocessing by loader: I think it's not doable because matching 
rules would be ambiguous (you wouldn't catch some typo errors for 
example anymore).

I'm giving a try to implicit float32! casting...

I've pushed the change in master branch, no regression it seems so 
it should be a safe change. Let me know if it works well for you.

Nice! I've missed that. It will make parts of my OpenGL binding look 
much nicer

Fine, I will try it and it could be even more elegant solution. Anyway, 
when you say it would break REBOL's synactic rules, does not your 
hexa format breaks it as well? Personaly I found very annoying to 
change many values like 0x00FF (usually in C's defines) into 00FFh. 
But I can live with that as I can always use some  converting script.

I see no reason why Red/System could not support typically used 0xx00FF 
format ... IIRC, when designing R3, we were also thinking to extend 
the syntax to support more formats, but nothing concrete appeared 
...

0x00FF format would kill pair! syntax, remember that Red/System is 
a dialect of Red and that Red will have pair!.

Hexa format: you're right and I hope to fix that once we rewrite 
Red/System in Red (then we'll have our own lexer instead of been 
limited by LOAD).

BTW, we can also decide that C-like hex format is more important 
than pair! syntax and find another literal form for pairs, but that 
would push us further away from REBOL (and clones) compatibility.

Pekr: from my little experience with lexers, I found it surprizingly 
difficult to design a set of consistent rules for a simple and readable 
syntax. If I had to design a new language syntax from scratch, this 
would probably be the hardest part.  Carl did a fantastic job when 
designing REBOL syntactic rules (even if it's not 100% perfect, R3 
did fix a lot of those issues).

Ok then ... I think we have more iportant things to solve/design 
:-)

How do I generate DLL? I added #export but it stills create .EXE 
file. Should I just rename it, or is there some compiler switch?

You need to use the WinDLL target: -t WinDLL

Thanks.

Note that currently your exported function will have cdecl calling 
convention forced on them. I'll change the #export syntax  today 
to allow optional convention to be specified (default will still 
be cdecl).

So I build my first Red/System DLL, but R2 refuses to load it with: 
** Access Error: Cannot open builds/temp.dll as library.

It is probably not related, but you might try with secure none, but 
I does not seem to be problem of REBOL's security or licence missing 
...

secure none doesn't help.

Let me test if there's no regression in last commits...

Works fine here. I'm testing with:

Red/System [ ]

i: 56
foo: func [a [integer!] return: [integer!]][a + 1]

#export [foo i]

You're sure that you're in `dyn-lib-emitter` branch?

(just in case)

If you still can't make it work, send me a copy of your DLL, I'll 
see what's wrong with it.

Yes, I'm in dyn-lib-emitter branch, otherwise compiler throws #export 
directive not found (or something like that)

My DLL is almost same as your example ('i is missing and function 
is called 'f1 instead of 'foo but otherwise it exactly same :)

RED/System[
	Title: "RED/System inline compilator test"
]

f1: func [a [integer!] return: [integer!]] [a + 1]
#export [f1]

(FYI: I'm trying to implement your make-native example)

Your code works fine here (REBOL 2.7.6): 

>> lib: load/library %builds/test.dll
>> f1: make routine! [a [integer!] return: [integer!]] lib "f1"
>> f1 123
== 124

Hm, I'll try with 2.7.6, I'm using 2.7.8 this may be the problem.

Works here from 2.7.8 too. Try from a freshly cloned repo.

Or just send me a copy of your DLL at [nr-:-red-lang-:-org], I should be 
able to quickly see what's wrong.

The DLL is here: http://box.lebeda.ws/~rebolek/temp.dll
source is here: http://box.lebeda.ws/~rebolek/temp.reds
But I guess it's just some stupid mistake on my side.

Let see that...

Works fine here: 

>> lib: load/library %builds/temp.dll
>> f1: make routine! [a [integer!] return: [integer!]] lib "f1"
>> f1 123
== 124

Are you running it under Windows XP?

(I wonder if it's not an OS compatibility issue)

No, W7. I will try this under virtual XP

I'm running it under W7 too, should be ok.

Mystery deepens...:-)

Are you preloading other DLL in your REBOL session before loading 
temp.dll?

Same under WXP (virtual) with both 2.7.6 and 2.7.8 . It's probably 
some bad day :)

>> lib: load/library %temp.dll
** Access Error: Cannot open temp.dll as library
** Near: lib: load/library %temp.dll

No, clear session