World: r3wp

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 )

If you want to call your modules .rm or .r3m or whatever, go for 
it. We don't have a standard suffix for scripts, but feel free to 
make one. Actually, the default suffix for R3 module files is .reb 
:)

bleee :-)

And that is only used when you are doing lookup by name through module-paths.

if reb, then extensions should be .rex :-)

But servers as Github will not colorize any extension as REBOL code:) 
I like colorized code.

The .rex extension is taken on Windows by a third-party app, but 
that may not matter. The main reason the default extension is .reb 
is because Carl likes it, but the programmer is expected to change 
it, and even Carl doesn't use it. I like .r3 for R3 scripts and modules 
both, because there's really not enough of a difference between them 
to justify a different name, but YMMV. Maybe we can get Github to 
treat .r3, .r2 and .reb as REBOL scripts.

.r3 and .r2 are already... don't know .reb

well, there was even one other suffix, for a compressed scripts, 
was it .rip? I like .r3, .rm, .rx, and those I will use (maybe really 
not necessary to do a separate suffix, I will see). .reb just says 
- nothing ...

btw... it would be good to update the colorizer used, the source 
is here https://github.com/Oldes/RebolLexer

I think that is the real reason the default is set to .reb: Noone 
uses it. People either use .r or .r3, and you are expected to change 
system/options/default-suffix to what you need it to be. That is 
the reason it's a system option.

we are very flexible, what do users think? I want free buttons, different 
extensions. I hope R4 prohibits user to load script, that would be 
best - we should be strict :-)))

No separate extension for compressed scripts is needed, as all scripts 
can be compressed. For that matter, script-encoded compressed scripts 
can even be colorized, though the data is just a big binary. Again, 
YMMV, you might have another opinion about this :)

pekr... "we should be strict "   hahaha    ;-)

if people are distributing their files in a single dir, they will 
have .so, .dll  in the same dir.


can't we just build a little .r file which imports the proper lib, 
no?

Many of you are conflating distribution and usage here.

Distribution is an entirely different matter to what Kaj is getting 
at.

Once your libraries are distributed (and installed), you already 
have the proper library suiting your specific platform.

You won't have 4 .dll's and 10 .so's. You will have _one_ file that 
suits your platform.

And as R3 extensions are loaded via the platform's regular loader, 
you can utilise all the features of said loader.

At which point it makes a _lot_ of sense to not artificially hide 
an R3 extension's nature as dynamic library and just use the platform-specific 
conventions.

Which will generally lead to better tool support and acceptance.

Now for most extensions they: a) won't be delayed extensions built 
into the host, and b) will easily be cross-platform across at least 
some platforms.