World: r3wp

Remember that R3 chat is the direct replacement of Devbase we had 
for R2.

Years, ago I said that information channel fragmentation in a small 
community is evil. We still have the same situation or add new channels.

But OK, I use R3-Chat and will post to Extension group.

R3 chat is just not being advertised enough, I think. And even if 
Carl forgets to check there, be sure to let him know, so he doesn't 
forget his own tools.

BrianH: looks good. Maybe we should add platform-linux? platform-win32? 
and platform-osx? predicates to get rid of those evil magic numbers 
in cases like the above.

That won't work when we have support for a hundred platforms, which 
is more likely than you might think.

ARM, ARM, ARM :-)

Apple has two slightly incompatible ARM platforms for the iPhone 
OS alone. Even though they're both ARM, they still go Universal.

With a hundred platforms you'll have a hundred numbers. What's wrong 
with having at least a hundred predicates hiding those numbers?

If the influx of gobal words is a problem, use some universal predicates 
(os? cpu? arch?) returning symbols instead, allowing e.g. `if os? 
= 'win32 [...]`

Reported a boiled-down version of this wish as bug#1454 and submitted 
an initial implementation in chat#6785.

so did anyone start on the R3 /library  extension?  if not I can 
work on that for windows, and make it so its very easy for someone 
else to map it to linux ( as a few stubs to re-implement  ).

good news maxim, this would be highly appreciated .

I never understood why the lib development is not forced muched stronger. 

A functional interface will double the value of rebol. Unfortunatly 
my

knowledge is not sufficient to create it by myself.  therefore I 
would like 

to support this with the commitment I made before, even if this is 
not the 
first motivation for you.

so I've been looking into this a litle bit, and it seems like a portion 
of the /library extension might be a pain to implement... so far 
it seems like I will have to add in-line assembly, since I haven't 
found any C routines or macros which handle the puch/call/pop aspect 
of the program stack (not saying it doesn't exist, just that I haven't 
found any).

and since this code is totally compiler dependent... it means, the 
extension will be tailored to be compiled on one specific compiler... 
(but will be useable by others AFAICT).

I'm still looking for a definitive dll calling convention example... 
AFAIK this has to be pretty set in stone... or dlls would quickly 
be incompatible between vendors.  

Then again, its possible the DLLs contain some calling convention 
parameter...   if anyone has a bit of experience in this (and can 
point me to understandable docs) I'd welcome a few pointers (pun 
intended ;-).

uff, sounds complicating. I think robert could have some practical 
experience or advice with that.

I just found a few good references.  so I will test some of this 
later this week.  I am pretty confident its going to work  :-)

the rebol part of things should be pretty straightforward.

I might even be able to support C++ object methods  :-)

cool maxim, I have a significant interest in connecting a powerful 
lib for 
complex financials analysis with rebol. A very dry area but

if I can support your activities in the way I have mentioned before, 
please 
let me know.

maxim the thing you are looking for is known as ABI, application 
binary interface

basically the ABI specifies (among other things) the calling conventions

and yes, that's extremely platform-dependent stuff

for windows, the calling conventions used by the OS seem to be pretty 
standardized and simple.  which is nice.  So far it seems to be a 
bit more sprawled for linux.


first release of the /library extension will be 32 bit only, but 
when we have a 64 bit REBOL it will be pretty easy to adapt... in 
fact, MS/intel did their homework for 64bit, it seems, and there 
is only ONE calling convention for that platform.

afaik microsoft has different calling conventions for x86 and x64

and iirc they have at least 3 support cconvs anyway (cdecl, stdcall, 
fastcall; maybe more)

yep, the x64 is better in fact.  x86 has three official conventions, 
some on the stack, some using registers, and different cleanup.  
 the x64 has only one and is based on __fastcall

because the x64 has much more registers.... it makes sense.

but as i suggested a few days ago, using e.g. libffi or dyncall would 
really help getting started quickly

maxim, any change the extension will be capable to handle nested 
strucs and pointers?

dyncall is BSD and should even work with MSVC

tom, yes.    that will start out simple, but will be handled in the 
rebol & extension part of the code.  


once I have the actuall subroutine jump (ASM call) code in place 
with an unlimited number of run-time functions registering, we'll 
see how the community wants to evolve the struct! dialect.


I am thinking of a rebol to struct converter and a way to keep handles 
to those structs, and even use them within sub structs, so that we 
can easily reuse allocated structures without doing the convertion 
over and over.

so you can work like draw, keeping just the rebol version and convert 
it at every call, or manually convert it once, and then reuse it 
over and over.  

this will allow us to chose between ease of use or raw speed (with 
a bit more management in our code).

internally, it won't make a difference.  depending on how you call 
the library function, it will convert on the fly or reuse the handle.

Andreas, I won't need an external lib, as we are in effect building 
a dyncall specifically for rebol.  which makes it simpler and faster... 
and it seems very simple to implement ourself, in fact.

dyncall is precisely what you will implement anyway :)

supporting a multitude of platforms quickly becomes a PITA

but i won't stop you in doing that :)

in fact i'll happily cheer you along :)

hehehe  I'll do my first tests, and then I'll see If I can wrap the 
platform-specifc parts of the process through dyncall's source code. 
 this way we will be able to compile the /library extension for any 
platform without any source code changes.


my design is to use header file macros which actually map the calling 
conventions based on your platform... THAT I can definitely borrow 
from dyncall if it BSD licensed :-)

ABIs are a bitch :)

this whole project is fun... I haven't done any ASM since my Amiga 
days... 17 years ago... I'm remembering stuff I had placed in a deep 
black hole in my mind...  :-)

yes, it sure is a lot of fun

I'm officially a geek... I actually laughed when I read a bit of 
ASM that had the   lea   instruction in it.. and instantly remembered 
what it meant hehehe  


three little characters, pop up 17 years later and my mind does a 
180 degree shift    :-)

:)

yes sire! just signed in as you first beta tester please  ;-))

created a new group for this specific extension.  we should continue 
any discussion about /library  there .

Max, I don't know what you do but the overall concept would be:
1. Loading the DLL dynamically

2. Finding all requested functions dynamically (Windows has a call 
for this where you provide a string of the function name (just can't 
remember the call name)).

3. Implementing a generic R3 extension function that will be marshalled 
on Rebol site so that the first parameter will the function name 
and than all paraemters (I would use a block here).
4. Rearrange all this to call the Win32 function.

You shouldn't deal with calling conventions etc. at all. At least 
if I had to it would be a sign for the wrong way.

Robert, three problems with that approach (even just on Windows):

- Not all DLLs export that info, some just export numbered entry 
points ane expect you to use a .def file or some such.

- Even for the DLLs that do export names, the C-compatible APIs don't 
have info about function arguments, data structures, ...

- The languages that have real reflection models and encoded info 
(Delphi, C++, .NET, Java) aren't compatible with an R2-style model.

Which is what Maxim is working on. You can't use reflection with 
C-style APIs, and API models that you can use reflection on can get 
their own extensions to access them :)