World: r3wp

or even easier  ;-)

include cstub.h

myfunc 1000 [12 1024]

oops again...

include %cstub.h

note, I've got the whole C language mapped into PARSE ... its just 
the emitter which is giving me headaches... 

because of REBOL's backtracking, you may end-up declaring/defining 
things several times, until the right match is found.

so I'm in the process of rewriting the rules differently which is 
quite complex ATM.

pekr, read Ladislav's DLL document a bit, and yess, it provides usefull 
information ...  gotcha's mainly which point out a few things, not 
to forget when defining the struct! dialect and other details.

I would also be very happy if there was /library in R3. I think many 
of use really don't want to write and compile c code (especially 
for multiple platforms) unless it's really really necesarry (thats 
why we use rebol).  Max I don't work in R3 for now, but if you make 
/library I will port the libharu pdf binding to R3.

Amen :-)

and although you say library is limited is is *good enough* for many 
things.

once again - why not have best of both worlds? Carl stated, that 
Extensions might be internalised (packed into main distro). So - 
let's use default interfacing method - Extensions. And let's make 
/library extension. Should work no? If it would allow many ppl to 
wrap thing here or there, and even if it will not be so powerfull 
as full fledged extensions, why not to have it, right?

( as it was demonstrated by many comunity members with many bindings, 
and I could also make a pdf binding that is already used for serrious 
stuff, and works on linux and windows without me ever touching the 
hairy low level stuff)

OK, I am donating 100 USD to the developer, who brings /library interfacing 
method to R3. But - it shold be developed in cooperations, so that 
it is acceptable for many ppl.

... and if it will a bit more powerfull, than R2 version, even better 
(referring to Ladislav's proposed enhancements)

The thing is, if we can come up with corrent architecture. R3 plans 
on handle! type, as well as custom datatypes (not sure it is needed), 
but surely is R3 not planning to use routine! and struct! ones (IMO)

I am without money currently so I donate 50 USD but happily for same 
thing that Pekr

license - BSD or MIT - simply for devs being able to use it freely 
...

OK, so we have got 150 USD ... who's next? :-)

me, I am in with 100 usd

and another  100 usd if nested structs and clean pointer handling 
are included

ok, thats 250 + 100 USD, upon above defined conditions :-)

I'm in with 100USD for the os x version of /library if that is usefull 
for porting Che

that will be difficult, as we don't even have an osx hostkit right 
now :)

It's not difficult to start; that's just a matter of doing the research 
on dynamic library loading and mocking up some code. And once extensions 
(not the host kit) are available on OS X, then the code can be tweaked 
and compiled.

You can start by going through R3 chat and helping Carl with his 
difficulties with porting the host kit and extensions to OS X.

That's exactly what I did

See rebdev message #6332, from 39 days ago

Cool.

The extensions are not the problem, they will work on OSX just as 
they work on Linux.

And in rebdev message #6257 I explain how to get extensions working 
on Linux.

(45 days ago)

Good. So once we resume work on such things (we're working on bug 
fixes and tickets now) the information will be there. Thanks.

Besides that I have 10 more patches lined up, which I held back to 
not overwhelm anybody.

Um, Carl is *right now* working on integrating community patches 
into a new host kit. Don't hold back.

Community = mostly Maxim, but you could tip the balance if you post 
your patches.

As I said, I posted two already, did not get any feedback so far.

Because we have been working on other things, mostly R2 and the web 
site (and R3 mezzanines in my case).

Mostly a matter of process, though. No idea if Carl is fine with 
dumping patches onto R3 chat.

He is OK with that.

If they are mezzanine fixes, you don't have to wait for Carl. You 
can submit them directly, or post them for comment there or here 
if they apply to functions that someone else is in charge of (like 
LOAD or the module system).

The only mezz fix I had for now, is in rebdev #6258

I saw that one, but it doesn't seem to be the right approach. Two 
reasons:

- .so and .dynlib aren't dynamicly linked library formats on Windows, 
.dll isn't on Linux, etc.

- It kind of defeats the purpose of extensions: making all of that 
platform-specific stuff go away.


Don't get me wrong, the current behavior also has the second problem. 
Extensions are imported like modules, and so the code that is asking 
for them has to specify the filename to load them. However, *that* 
code is supposed to be cross-platform, so putting a platform-specific 
filename in their Needs list is inappropriate.


What do you think of using a generic filename extension like .rx 
for extensions, then having LOAD translate to the native filename? 
Or on platforms that don't require a specific filename extension 
for their dynamic library loader (like Windows), you could use the 
.rx extension directly.

Sounds good

I'd keep on using .dll on windows, though

And I'd also keep the platform specific extensions in system/options/file-types

Why keep the extensions stored as .dll?: I'd prefer not hiding the 
fact that a rebol extension is really a proper dynamic library

Windows is the one that needs to use the .rx extension the most, 
and the one that we definitely can use it. And system/options/file-types 
has to have the extension we are trying to LOAD, not what it might 
be translated to.

Why does Windows need .rx the most?

It's not hiding. Most of the executable file types on Windows are 
really DLLs, including .dll, .exe, .ocx, .vbx, ...

Is there any harm in allowing .rx alongside with .dll .so and .dylib?

We need it on Windows so we can make a .rx wrapper for a .dll third-party 
library.

With both .rx and .dll having the same name? OK.

The harm comes from having .dll, .so or .dylib in the Needs lists 
of what would be otherwise portable REBOL modules and scripts.