World: r3wp

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.

Would only be portable, if there are ported versions of the extension 
they are needing

So if you only have a .so version of your extension, using Needs: 
%foo.so has no harm done

It's better to not have .so in there at all. Part of the design strategy 
of the R3 language is to at least pretend that the language is portable, 
and keep all of the non-portable stuff wrapped in extensions or hidden 
in the host code.

But realistically there will be loads of purpose built non-portable 
extensions

And as allowing them to be used with their native extension does 
no harm as far as I can tell, I'd enable that usage alongside the 
.rx

Doesn't negate my argument. Having them named .rx will mark them 
as extensions, which have a specific calling convention that must 
be supported. Nonetheless, if you do decide to also allow the default 
platform dynamic library naming convention, only allow the name supported 
by the current platform. So no .dll on Linux, no .so on OS X, no 
.dylib on Windows.

Sounds like needlessly complicating the code

.so is correct on osx

simply marking rx/dll/so/dylib as possible extensions for extensions 
sounds perfectly reasonable

Not needlessly - .dylib files don't work on Windows.

Yeah, but who cares?

They even might, if someone wrote a dylib loader for windows

We do. Simplifying the code would be to just support .rx and have 
the LOAD-EXTENSION native in the host code do the translation.

Go for it, then