World: r3wp

because of web site availability problems, i have changed my site 
: you will find here the three  "experimental" extensions that I 
have done to learn the extension mechanism : a text to speech extension, 
a matlab engine extension, a simple windows api extension with some 
useful calls : http://www.colineau.fr/rebol/R3_extensions.html

cool ...

Great  ! Jocko

In theory it would by possible to make an extension that could implement 
the /Library dialect, or a better version of it.

I'm just saying that salaried workers may have different requirements 
than those working by themselves

I would like to point out, that wiki somewhere contains Ladislav's 
input on that ... I will try to find it ....

The trick is that the struct! and routine! types would only exist 
within the dialect - they would be handle! and command! outside of 
it.

I still don't get the point of !handle.  its useless within R3 no? 
 otherwise any integer can be used for !handle... no?

We wouldn't be able to create a proper struct! type until we have 
user-defined datatypes.

or is !handle, secretely, an UNsigned integer?  ;-)

http://www.rebol.net/wiki/DLL_Interface

The point of handle! is to store a value that REBOL can't really 
do anything with without native code. So it's a great place to put 
pointers.

is it protected in any way?

And handles, for that matter.

Yes, it's protected. From REBOL code you can't do *anything* with 
a handle aside from modifying operations. It's an immediate type 
so it's not modifiable in any way.

defining a struct dialect is actually quite easy, as long as we stay 
close to the basic types.


the only real issue, still, is the incapacity to have UNsigned values 
in REBOL which is annoying in many cases.

aside from modifying operations -> aside from assigning it to something

so I can assign a handle to an integer?  and the extension with get 
a  64int *myhandle ?

In native code, yes. Not in REBOL code.

We don't have unsigned *operations* in REBOL. We can have unsigned 
*values* in REBOL by making our own operations that treat the signed 
values of the same size that we do have as if they were unsigned.

yeah but unsigned could be a bit in the integer.  it would help for 
many things... MANY values can't be negative.  I would love to have 
an quantity! type. which is just like integer but without possibility 
for negation.

A handle is a 64bit value that can be treated in any way that the 
relevant native code wants it to be treated. It is returned by native 
functions or commands and is taken by native functions or commands.

ok.

when I said "a bit in the integer" I meant in the integer's internal 
datatype... but a quantity! type would be even better.

If you want user-defined datatypes, they're planned. Or you can just 
fake them using techniques similar to those in R2/Forward.

yeah... but quantity! should be a default type... its just such a 
basic part of programming.

returning an errror whenever math operations would make it negative.

Its a complicated thing to manage manually.  I know how negative 
values work... but its a REAL pain to work around it.

anyhow.  I wonder, can anyone tell me if its easy to load dll and 
map functions dynamically on LINUX?

(*.so)

Possible, yes. Easy, that's up to you to decide.

on windows its a simple function call,   does it require to have 
an extra package installed, or it part of the basic kernel?

There are simple APIs, though they might be different depending on 
which object format the distribution uses. ELF is common.

That's ok, its up to platform distros to accomodate.

I recall something about "dynld" being the key word to look for.

I can make a simple /library like dll loader for windows if anyone 
really needs it.    I won't put time on this unless there is a real 
need, but if you need it, just speak up, its fairly easy for me to 
do.


a simple struct dialect would take a few hours to iron-out tops. 
 it would be much more flexible than the struct! datatype for sure.

I can make a simple /library like dll loader for windows if anyone 
really needs it.    I won't put time on this unless there is a real 
need, but if you need it, just speak up, its fairly easy for me to 
do.


a simple struct dialect would take a few hours to iron-out tops. 
 it would be much more flexible than the struct! datatype for sure.

Maxim: loading and using shared libs on linux is rather trivial. 
dlopen(3) and dlsym(3) are what you need

they are part of POSIX, and you'll have to link against the dl library

Maxim, here are the Cheyenne stuffs that use /library http://code.google.com/p/cheyenne-server/source/browse/#svn/trunk/Cheyenne/misc
if you come up with something that would make -1 on requirements 
to port it to R3 8-)

Max - any interesting info for you in following proposals? http://www.rebol.net/wiki/DLL_Interface

I think that some users and especially novices might still welcome 
a bit improved /library interface to the full fledged Extension possibilities 
...

Maxim, rebdev message #6257 points to a patch of mine along with 
other needed fixes for the hostkit to enable R3 extensions to work 
on Linux.

thanks everyone.

pekr... looked at it quickly. not sure, it looks most like a resume 
of potential approaches.

can anyone confirm that debian is working/ported under R3?

Max: "on windows its a simple function call" Could you tell us which 
one? I don't remember seeing such thing in win32...but I didn't looked 
at it since a long time.

debian is working fine, yes

doc, i guess maxim is referring to LoadLibrary and GetProcAddress 
in win32

Then, that's not /Library.