World: r4wp

BTW, for those not following me on Twitter (raise your hand!), I 
just got my first Red/System DLL working on Windows. ;-)

So now, who wants to write R3 extensions in Red/System? ;-)

As Red/System compiler is written in R2, you could imagine a full 
toolchain library for R2 that could integrate Red/System deeply with 
R2, imagine:

>> foo: make-native [a [integer!] return: [integer!]][a + 1]
>> foo 123
== 124


MAKE-NATIVE here would compile the Red/System function, emit a DLL, 
load it and map the function back. ;-)

I don't receive notification emails anymore for the newly added github 
issues...If I activate Settings->Notification->Watching->Email, I 
get them again, but also from all others repo I'm watching...Is there 
a way to only get the notifications by email for the repos I'm owning?

Does this help? https://github.com/blog/1204-notifications-stars

Someone else wrote:

So the 'solution' I found to this was to set up filters for the various 
repository emails by filtering on email list. The list filtering 
is mentioned here on the github blog: https://github.com/blog/967-github-secrets
(scroll down the page a bit).


I would then just forward the emails from selected repositories to 
the "correct" email address.

Thanks for the links James, I'm watching and have starred my Red 
repo, so I should receive those notifications...

R3 extensions in Red/System sound interesting. Does Red/System have 
some easy way to replicate what the R3 extension macros do with unions?

Have you done experiments in JIT compiling yet? R3's extension/command 
model is really easy to use to implement JIT compiled functions.

R3 unions: I'm not familiar with R3 extension macros, got a link?


JIT compilation: not yet, but I guess it could be interesting to 
do it for R3 as an extension (not on my roadmap though).

Not R3 unions, C unions. The arg type for R3 extension commands is 
a union, with the different potential datatypes being alternates.

The macros are defined in the headers that come with the R3 host 
kit.

A Red/System extension kit would need to replicate the functionality 
of the macros, to implement the datatypes involved.

DLL: excellent! Does Windows not need PIC or something?

Unions: I had to match them for the SDL binding. Red/System doesn't 
have them, but I just define STRUCTs for each variety, and then cast 
a particular instance to the right one

PIC is not required for Windows libraries. There's a relocation mechanism 
though, that I haven't implemented yet, to solve libraries loaded 
on overlapping memory areas.

Unions: I am not a big fan of them, if a better alternative exists 
in other languages, we might borrow it for Red/System?

Not sure that's practical, as the main purpose would be to support 
C interfaces

We could be ABI-compatible with C while using something different 
than C unions.

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.