World: r3wp

What is more important - can we UNLOAD the extension?

I thought that was included in R3 now?

You can't unload extensions.

Zlib in R3 doesn't work.

http://issue.cc/r3/1667

Kaj, here's an example %rebol.r for your scenario:

REBOL []
use [sys-path] [
sys-path:  %/some/safe/directory/full/of/extensions/
sys/load-module/delay map-each x read sys-path [sys-path/:x]
]

I have no time to wai for built in zlibt. But for me is every small 
extension a good C exercise

Then you make sure that your extensions can survive being delayed 
:-/

How much time and memory do delayed modules take? In any case, it 
will be too much on for example CGI scripts

BrianH: isn't having just one name going to be a problem for us? 
I like the .rx extension very much. But think about distros. You 
can't have one storage of extensions for various platforms. Dunno 
if such use case would exist. Something like big directory of extensions 
somewhere on the fileshare. In the same path. If the suffixes would 
be different, then those files could co-exist. Hmm, maybe not, because 
.so works for Linux, other Unixes, and those might require different 
extension binary anyway? How would you solve such a case? Subdirs 
per system? e.g. /amiga, /win32, /win64, /linux, /syllable?

Time: not much. Memory: don't know, platform-specific. They don't 
have their source decoded, but the library is loaded (I think), though 
no code is called except RX_Init (from what I gather). I haven't 
done much work with extensions yet but Carl says they work like that.

Alien binaries shouldn't be installed, so you need separate packages, 
or a package with an extension installer. If you really don't want 
to do that, you need subdirectories

A system-wide loader like that is a feature of an OS that starts 
once, not of a language platform that launches many times

Pekr, the idea behind .rx is to make it possible to write cross-platform 
extensions and have them be called by cross-platform code. If people 
are using extensions then they are expected to be importing them 
before they use them. The .rx convention is one way to do this; platform-specific 
loaders is another. Choose what you prefer.

Subdirs per platform is one way to do this (if you are calling your 
app from a network share, or building it from source for instance).

So how about import/extension ?

BrianH: I fear of the following problem - some user thinkining - 
hah, %sqlite.rx, downloads the extension, but the extension is in 
fact only Windows one :-)

Have them download a zip file containing the Windows binaries. That's 
how SQLite does it.

Kaj: No need. You can import the extensions by filename. We want 
the initial import of an extension to be really clear, distinct from 
the import of a module. If you say that LOAD-EXTENSION looks up the 
file in the system library path, that shoul;d be all the searching 
we would need.

Importing an extension has security implications, so it isn't something 
we want to happen by accident. Make it clear by including the filename.

Do you acknowledge my concern at all, even after learning that R3 
uses the OS loader?

I would like to get back to Oldes' quesiton - is unloading extension/module/gui 
or other elements technically impossible?

I mean - once I define e.g. layout, objects get defined, and unview 
just hides the window, but the rest is still in the memory without 
any way to be cleared. Is that even solvable? I have no idea of how 
to track all possible references to be unset :-)

I think it's just not implemented yet... R2 was using FREE to unload 
library.

(sorry to spoil the extensions group for my question, but it might 
be similar)

I don't know. I think that extensions are unloaded when the program 
closes.

Once the program closes is not usefull at all. Think about R3 as 
an OS. It somehow should track resources. And/or stuff like GUI etc. 
should be isoloted in some context which you could easily scrape 
- unset, free, whatever ... or the memory consumption will rise endlesly?

I don't think we are so far (making R3 OS) :)

Oldes - maybe not, but those things have consequences. if we don't 
plan on collection resources info, how do we know how to free memory? 
That might influence some internals, modules, extensions, etc.?

I am not clever enough to suggest a solution, but I think that some 
solution could be at least thought about ....

Maybe we could CC it as a wish - how to free rebol resources for 
more complex stuff as a gui?

why not... it looks the CC is the only way how to ask Carl for something 
at this moment and get response in reasonable time.

(resonable time is months unfortunately)

Indeed

Yeah, Carl not much active (apart from RMA reports of some activity) 
since late October ....

Kaj, you do realize that you won't be able to just load any system 
library, right? Unless that library has an R3 extension API, it can't 
be loaded as an extension. And if you can only load R3 extensions 
anyways, why not name them as R3 extensions? The .so filename suffix 
isn't even portable to all POSIX platforms. If you want your code 
to be portable and load filenames, use a portable filename. That 
is why we have the .rx convention. And we have %rebol.r for anything 
specific to your personal platform - you don't even have to touch 
host code. For that matter, CGI scripts could call a R3 interpreter 
that is in a different directory than the user R3 interpreter so 
they would use different %rebol.r settings.

Still, the only way to get a proposal submitted around here is to 
go to CureCode

Oldes, Pekr, I don't know whether extensions can be unloaded. Last 
time I checked it was considered unsafe to do so, because the import 
process doesn't isolate things. In theory you could clean up after 
a module, remove it from the system modules list, remove all references 
to it from all other modules (that you have tracked), and then let 
the module be collected by the garbage collector, but I don't know 
if extensions are unloaded when they are collected.

The main way to free resources is to remove references to these resources 
and then collect them with the GC. Other resources can be freed manually 
using cleanup functions. In the case of extensions, they would need 
to provide their own cleanup functions, as only they can know what 
resources they are using.

So there is no way, how to "disconnet" an extension from your app, 
so that OS finds out - look, some not connected orphan here, let's 
clear the memory here?

Right, because R3 has no way of knowing what resources the extension 
is using. But extensions could be swapped out to VM if they aren't 
being used (depending on the OS), they don't have to stay in main 
memory.

You'd have to eventually call the OS loader again to unload ir

it

OK, after reading all the above, I agree on .rx being a suffix for 
an extension. The reasons? Even dll or so are not necessarily crossplatform, 
plus having an extension even as .dll is confusing - normally it 
might not be clean .dll, which you can load in some other environment 
- there might be packed rebol code inside. But I don't want to complicate 
Kaj's aproach, and more important - I never coded any extension, 
so regard it being just an opinion ...

Actually, you can only unload modules in general in extremely limited 
circumstances. There has to be no outstanding indirect references 
to the module's context, and that usually can't be tracked.

We could also create .rm, for MODULES ... but modules are plain text, 
no? Or even binary? Dunno if it would make sense to distinguis them 
from normal scripts?

OTOH it would be imediatelly obvious, that the code is some module, 
not a plain script, which necessarily does something ...

You can distinguish R3 modules from scripts with LOAD/header or some 
such. But you can call R3 scripts anything you like. Scripts are 
just a kind of module in R3 anyways (one of 3 or 5, depending on 
how you count it).

I thought about user, downloading a distro. If those are not distinguished, 
I would try to DO each script, just to demo the REBOL. And doing 
a module usually does nothing more than loading the module = nothing 
visually usefull. So I would not mind having .r3, .rm, .rx

(I know that modules are distinguished by the header, but that was 
not the reason to propose having .rm )